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

wcandrew

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.

wrongecho

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 🙂

Bigbug

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

Bigbug

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)

wcandrew

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.

johnny

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

Bigbug

Which bit specifically?

wrongecho

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.