Server Configuration - Basic Security Part 7

The Apache STIG from DISA is a decent starting point for Apache. It takes some translation for modern versions of Apache, as well as newer technologies, but there is some sound information available. <a href="http://iase.disa.mil/stigs/a-z.html" rel="nofollow">http://iase.disa.mil/stigs/a-z.html</a>

these days, we use set of pre-built commercial scripts to harden servers.<p>especially once you get into PCI compliance, there is no way to do all this yourself.<p>things to perform generally are: - install grsecurity kernel - clamav - aide / rkhunter (IPS) - proper file perm/ownersips - JIT (just-in-time patching) - real-time malware - anti ddos via sysctl - disabling un-needed services<p>checkout atomicorp.com's ASL, it takes care of a lot of these things,<p>also aqueduct is also a good starting point, which is a set of bash/puppet scripts to perform these mundane tasks.

&#62;&#62; Configuring a server correctly is both 1) hard and 2) critical.<p>It's not hard, you won't get breathless! ;-)<p>By the configuration stage, the mental tax can often be as low as checking off items on a checklist.<p>It is a whole different skill set though and it's trickier in some ways e.g. a developer can often depend on his compiler to tell him if he's messed up the basics.<p>You could go-live with a host having most attack surfaces battened down tighter than a crab's harris at 50 fathoms, but because nothing told you about DNS tunnelling... (feel free to insert A.N. other rarely talked about but trivial attack)<p>&#62;&#62; Are directories only writeable by the web server user?<p>The web server user shouldn't be able to write anywhere except perhaps an upload directory inside its chroot. At no point should it be serving files from that dir (a common mistake).<p>With tools like SELinux around you can often help cover yourself from midnight mistakes down the line.<p>A blisteringly common one not mentioned is database authentication details inside .pl, .py or .php scripts.<p>&#62;&#62; Is PHP installed on your Python server?<p>Another common one is GCC installed. Often when building perl / python / ruby / nodejs modules or whatever, these will be built on the prod server in small shops. That often means a full compiler suite laying around.

<i>"Is PHP installed on your Python server?"</i> ...<p>This is what happens when people who don't understand security try to tell you how to secure something. Don't do that.<p>There's only a handful of things you need to do to harden <i>most</i> servers, and one of those things is filesystem access controls and mount options. One of the others is configure your network services to only do exactly what you need right now. These two things will solve <i>so many more problems</i> than simply keeping your software stack small, they should be the very first thing you do when you secure any system.<p>First, you secure your filesystem. That means scouring the whole thing for any setuid-root files and any files that are group-writeable or world-writeable and disabling those permissions - except /tmp of course (and /var/tmp, which should probably be symlinked to /tmp). You can also double check you have no overly-permissive posix ACLs, security extensions or capabilities set on any files. Once that's done, you can mount your user-writeable data partition using options which disable files from being executed, set a default security context, disable device files, and disable setuid files. Then it's on to configuring your services.<p>In the case of PHP, there is no security concern by it just sitting on your hard drive. It's not setuid-root and it's not a service. The most it could affect a user by itself is due to some temp file race someone might be able to take advantage of.<p>The reason it was abused in the author's case was due to a misconfiguration of Apache. Starting with an empty Apache config file and adding only the parts they needed would have excluded PHP from being interpreted in most cases (the module could be compiled in, which can be checked for, but I don't think most default Apache installs are done so; in addition I think you still need to manually configure Apache to bind ".php" files to the PHP application mime type).<p>This practice should be used for every service you have running on your server. It may be tedious, but when you do it once you'll become much more familiar with the software and it'll be easy to replicate in the future.