Matt Critcher, our server admin, posted this on his blog the other day about ModSecurity and I thought that it was worthwhile to repost. We implemented ModSecurity a while back and hardened all of our servers to help guard us against a lot of the threats that are out there today. Looking back it was probably one of the smartest things we ever did. Over the years I have worked with a lot of server administrators, but I have never worked with one that has as good a grasp of ModSecurity as Matt.
From a Developers perspective ModSecurity can be a little frustrating on the front end because it will by nature shutdown or cause some elements of your applications to “break” until you get ModSecurity configured correctly and all of these core functions added as includes, but trust me, once you get everything configured correctly it sure does help you sleep better at night knowing that some hacker in India isn’t setting up a rootkit on your server through a hole in one of your applications.
Like Matt says in his post, Security is an ongoing thing, and part of that ongoing process also has to include keeping all of your open source software patched and up to date. Here’s Matt’s post:
Since I’m back, I’ve got a few days worth of log files to dig through. A couple of years ago an old legacy PHP script Pleth was running wasn’t very secure, but was critical to the operations of a particular customer. It got hacked (well, they used it to upload a C99Shell) a couple of times before the vendor released an update. Scouring the internet for a solution, I learned of Mod Mod Security, an application firewall of sorts. It runs as a module in your Apache configuration and uses a set of user-configurable rules files to detect and prevent a number of attacks against a website. The rules list has a huge community backing, and people have written rules for about every vulnerability out there. Open Source is good no? Anyway, as I was digging through those files today it kinda shocked me to see just how much stuff mod_sec blocked. The internet is a dangerous place…..
Among the same lines, you can further protect your server by making a few small php.ini changes as well. Look for the line in yours that says
1: disable_functions = "........and make sure you add
1: shell_exec,escapeshellargto the list there. This will prevent PHP from operating as a shell, which you really don’t need anyway (well, you shouldn’t in my opinion). There’s about a million different things you can actually disable, but some of them are needed.
Another PHP trick is open_basedir, which is a php configuration directive that sorta "jails" the scripts to whatever directories are listed in the open_basedir directive for that particular domain.
From the manual page:
When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it’s not possible to avoid this restriction with a symlink.
It’s not the most friendly option on the planet, but it does work and takes a bit of careful configuration to get it working right. For a site that might be considered risky, it’s worth the effort.
Just don’t be fooled into thinking that these fixes are the end-all-do-all. Security is a never-ending process. PHP is just one aspect of it.
Mod Security is good for you! | www.mcritch.com
Questions or Comments?