As new threats emerge would it not be a good idea to have a copy of the most secure .htaccess file somewhere on the site?
And what is the most secure .htaccess content at the moment?
Most secure .htaccess file
-
nuno
Re: Most secure .htaccess file
Hi
in docs have cool stuff
http://wiki.cmsmadesimple.org/index.php ... l_Settings
helps?
Best regards
in docs have cool stuff
http://wiki.cmsmadesimple.org/index.php ... l_Settings
helps?
Best regards
-
Pierre M.
Re: Most secure .htaccess file
Please notice the link to the howto/security small guide too (at the end of the URL filtering section).
Pierre M.
Pierre M.
Re: Most secure .htaccess file
PHP.INI definitely should not be world-readable. PHP needs to read it, but the web server doesn't need to publish it.
Worth looking at the wider filesystem too. For example, where is PHP storing its session files? If they are in the webroot, then it's probably worth ensuring that they are blocked in .htaccess just to prevent any possibility of retrieval by brute-force filename guessing, potentially leading to session hijacking (probably very unlikely/time-consuming but worth blocking anyway).
I don't use Apache, but I use a web server with similar access controls. At present I'm not using much dynamic functionality, so I am able to block public access to most of the PHP files.
I have two views: public HTTP, and private HTTPS for admin & editing ("no authentication without encryption"). The HTTPS service uses pre-auth in the web server config. The HTTPS admin view can see everything, but the public HTTP view uses the equivalent of .htaccess to block a lot of stuff.
It occurs to me that I could use a "default block" rule in my web server access control file, as the public HTTP view only needs /index.php, /stylesheet.php, /uploads, /images and /favicon.ico. If I recall correctly there is the odd little image file (CSS Menu arrow or something) tucked away in a module folder, but I can watch the server log during testing and add fine-grained exceptions where necessary. That way, the number of PHP modules that an attacker can directly invoke is kept down to a bare minimum, which reduces the potential attack surface.
If your server config can specify it, block access to PHP scripts in /uploads, just in case an attacker finds a way to upload arbitrary content there through the CMS - then at least he can't exploit that to execute arbitrary code on your box.
.htaccess rules still need to be combined with other measures, of course: e.g. tightening PHP.INI (disable_functions and open_basedir for starters); making the Unix files and directories mostly read-only and not owned by the public web server process; and making the public CMSMS process connect to the DB under a read-only user account.
Your mileage may vary. It depends how much dynamic functionality your site uses, and how much time and effort you can be afford - knowing that your lockdown will break things and so you will have to back out some changes. It's worth having scripts to set up and clear down all the lockdown settings, so that you can easily revert to a more open system while testing, debugging and for installing CMSMS updates.
Have fun! Don't be afraid to lock it down till it breaks - just keep notes so that you know exactly what you did, and can back it out a little till it works again
- Martin.
Worth looking at the wider filesystem too. For example, where is PHP storing its session files? If they are in the webroot, then it's probably worth ensuring that they are blocked in .htaccess just to prevent any possibility of retrieval by brute-force filename guessing, potentially leading to session hijacking (probably very unlikely/time-consuming but worth blocking anyway).
I don't use Apache, but I use a web server with similar access controls. At present I'm not using much dynamic functionality, so I am able to block public access to most of the PHP files.
I have two views: public HTTP, and private HTTPS for admin & editing ("no authentication without encryption"). The HTTPS service uses pre-auth in the web server config. The HTTPS admin view can see everything, but the public HTTP view uses the equivalent of .htaccess to block a lot of stuff.
It occurs to me that I could use a "default block" rule in my web server access control file, as the public HTTP view only needs /index.php, /stylesheet.php, /uploads, /images and /favicon.ico. If I recall correctly there is the odd little image file (CSS Menu arrow or something) tucked away in a module folder, but I can watch the server log during testing and add fine-grained exceptions where necessary. That way, the number of PHP modules that an attacker can directly invoke is kept down to a bare minimum, which reduces the potential attack surface.
If your server config can specify it, block access to PHP scripts in /uploads, just in case an attacker finds a way to upload arbitrary content there through the CMS - then at least he can't exploit that to execute arbitrary code on your box.
.htaccess rules still need to be combined with other measures, of course: e.g. tightening PHP.INI (disable_functions and open_basedir for starters); making the Unix files and directories mostly read-only and not owned by the public web server process; and making the public CMSMS process connect to the DB under a read-only user account.
Your mileage may vary. It depends how much dynamic functionality your site uses, and how much time and effort you can be afford - knowing that your lockdown will break things and so you will have to back out some changes. It's worth having scripts to set up and clear down all the lockdown settings, so that you can easily revert to a more open system while testing, debugging and for installing CMSMS updates.
Have fun! Don't be afraid to lock it down till it breaks - just keep notes so that you know exactly what you did, and can back it out a little till it works again
- Martin.
