• SupportCompleted

  • Which files can or should have restricted access in the webroot?

Hi,

I'm kind of new to webserver admin. I'm also a little paranoid. I'm wondering which files should have access restricted by my NGINX config.

I ran a script to test unauthenticated access to every file in my test install's webroot, and these are the files I found I had access to (HTTP 200) without being redirected to the login page. I've already added a directive to block access to hidden files (files prefixed with a ".").

There are a few that stand out (db.sql, config.php). While the php files do not show any content when accessed, it's my understanding that they're still being run when accessed by HTTP. Also, the db.sql is downloaded when accessed and obviously fully readable.

Which of these files in this list are able to be or should be blocked from public access without disabling website function?

I'm genuinely asking if I missed something in the install guide about setting permissions for the config.php and db.sql files, or if the expectation is that the person setting this site up is supposed to expect this and deal with it. It seems pretty clear to me that I should add a directive to block access to db.sql, but I kind of had to stumble upon that information, which leaves me worried.

Thanks for taking the time to consider my post.

Hey @wcandrew & welcome!

I can completely understand your security concerns, you really can never be too safe these days.

I can assure you that everything in your ITFlow web folder is intended/safe to be publicly accessible. This is especially true given that the ITFlow core is open source.

To explain a few examples:

  • db.sql - This is just the database structure - your actual data is in the database
  • config.php - This contains your database credentials. It's called by almost every page, but PHP stores the information in memory and doesn't pass it back to the user/browser.
  • .git - This is just the file version info tracking folder to ensure you keep up-to-date from the Github repo
  • XX_modal.php - These are HTML templates that are included as part of pages, but are useless without being logged in
  • XX_model.php - These are PHP templates to prevent code duplication, again useless without being logged in
  • cronXX.php - These require a key to run

You could prevent access to db.sql &config.php if it makes you sleep safer at night 🙂

--

I do have a couple of recommendations though:

  • Configure a login key (Settings > Security) to "hide" your technician login page and provide a nice redirect to the portal for clients/customers
  • Configure/force 2FA for all techs
  • Use HTTPS, with HSTS to prevent MITM attacks
  • Run the MariaDB installation secure script
  • Turn off indexing in Apache/Nginx
  • Ensure that any backups are stored OUTSIDE the public web directory
  • If possible, protect ITFlow behind a WAF like modsecurity or Cloudflare (you'll need to adjust config.php to look for the forwarded-for header instead)

--

For future reference: If you do believe you've come across a security issue in ITFlow, we would ask you follow the responsible disclosure process outlined here. This would ensure that any issues are fixed in full before being publicly disclosed.

--

Happy to answer any other questions 🙂

    I really appreciate your detailed response. Part of the reason for my worry was restricting anything that doesn't have to be visible to reduce my potential attack surface. Maybe it is silly level of cautious, but I will definitely restrict access to config.php and db.sql

    Also thank you for pointing out the responsible disclosure process. I will reach out by the specified method if I have any more detailed concerns.

    I'll definitely be going through your list of recommendations and performing any items there that I haven't yet.

    Thank you for your prompt and detailed reply.

    I mean if your really worried about it you could always put your ITFlow behind a VPN, but in that case you will lose out on some portal / client features.

    wrongecho why don't you implement by default if it's going to make ITFlow even a bit more secure?

        wrongecho

        wrongecho I do have a couple of recommendations though:

        Configure a login key (Settings > Security) to "hide" your technician login page and provide a nice redirect to the portal for clients/customers
        Configure/force 2FA for all techs
        Use HTTPS, with HSTS to prevent MITM attacks
        Run the MariaDB installation secure script
        Turn off indexing in Apache/Nginx
        Ensure that any backups are stored OUTSIDE the public web directory
        If possible, protect ITFlow behind a WAF like modsecurity or Cloudflare (you'll need to adjust config.php to look for the forwarded-for header instead)

              Bigbug

              For the most part, ITFlow is "secure by default". We encourage strong user passwords (through min length) and you can't even login if you're using not using HTTPS (unless you change a config.php setting).

              Configure a login key (Settings > Security) to "hide" your technician login page and provide a nice redirect to the portal for clients/customers

              Configure/force 2FA for all techs

              We could potentially encourage a login key to be used during install, but it is probably unnecessary for some use cases where ITFlow is internal/VPN access only.

              The feature to force MFA is still incomplete. This was a recommendation that all techs should have the box ticked and be told to set it up.

              Use HTTPS, with HSTS to prevent MITM attacks

              Run the MariaDB installation secure script

              Turn off indexing in Apache/Nginx

              Ensure that any backups are stored OUTSIDE the public web directory

              If possible, protect ITFlow behind a WAF like modsecurity or Cloudflare (you'll need to adjust config.php to look for the forwarded-for header instead)

              These are beyond the control of ITFlow and are the responsibility of the server administrator.

                18 days later
                wrongecho locked the discussion .