Server Configuration - Basic Security Part 7
coffeeonthekeyboard.com
coffeeonthekeyboard.com
Apache HTTP: https://benchmarks.cisecurity.org/tools2/apache/CIS_Apache_H...
Tomcat: https://benchmarks.cisecurity.org/tools2/apache/CIS_Apache_T...
especially once you get into PCI compliance, there is no way to do all this yourself.
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
checkout atomicorp.com's ASL, it takes care of a lot of these things,
also aqueduct is also a good starting point, which is a set of bash/puppet scripts to perform these mundane tasks.
It's not hard, you won't get breathless! ;-)
By the configuration stage, the mental tax can often be as low as checking off items on a checklist.
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.
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)
>> Are directories only writeable by the web server user?
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).
With tools like SELinux around you can often help cover yourself from midnight mistakes down the line.
A blisteringly common one not mentioned is database authentication details inside .pl, .py or .php scripts.
>> Is PHP installed on your Python server?
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.
NB: The next point is "Do all of them even need to be? Are you sure?"
> A blisteringly common one not mentioned is database authentication details inside .pl, .py or .php scripts.
I am not sure that's so obvious. Most web servers will serve a .ini or .yml file as plain text, if it's in the wrong spot. On the other hand, a PHP file like https://gist.github.com/3177788, even if it's in the web directory, can't leak the data without some other compromise--and the type of compromise required would generally give you access to any of the values in the .ini file, anyway.
But, see also #5: "Are your firewall rules restrictive enough?" If I can even connect, let alone authenticate, to your database from the web, you have bigger problems.
GCC is an excellent point, though.
>> NB: The next point is
Yes but I didn't want to write a counter point to each point. I'd taken the view from the listing of possible problems presented that the basics weren't being considered. It reads as a list of random points in a large space rather than a comprehensive listing.
To give a specific example, the article talks about writable concerns when really we want to be ensuring readable gets the same treatment.
>> even if it's in the web directory, can't leak the data without some other compromise
Or a config error (a botched upgrade disabling mod_php could do the trick, or more obscurely a content negotiation oversight), or a leaked backup (another common one - storing random backups under www root)... There's more than one way to skin a cat as they say.
>> If I can even connect
You're often better to view security as something you provide in layers. I wouldn't expect to be able to hit port 3306 from here, but if you're not expecting me to ever be inside your network, then priviledge escalation is going to be fairly quick for me once i surprise you by getting in.
This is what happens when people who don't understand security try to tell you how to secure something. Don't do that.
There's only a handful of things you need to do to harden most 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 so many more problems than simply keeping your software stack small, they should be the very first thing you do when you secure any system.
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.
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.
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).
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.
> In the case of PHP, there is no security concern by it just sitting on your hard drive.
It's a surface area question. I could go into more details of the history of why it was there and configured (if you read further, you'd see that it was part of our puppet manifests, and for a reason). But you reduce the surface area of attack by reducing the number of things that can execute arbitrary code. And if you aren't using PHP at all, "yum remove php" saves you disk space and surface area, even if you have another colossal screw up (like we did).
> The most it could affect a user by itself is due to some temp file race someone might be able to take advantage of.
Well, the most it could do is, if you've screwed up someplace else, execute arbitrary code as the webserver user on the machine, thanks to the backtick operator.
Advocating a smaller surface area in your example is the same thing as telling someone to buy a bigger/better lock to protect their door. Sure, it makes your door more secure by reducing the "surface area" of a lesser-designed lock. But if you had done the basic auditing of the outside of the building, you'd see the huge glass window fitted next to the door - which may not be "exploited" yet, but all someone needs is the right size rock.
Tuning your services and filesystem perms is equivalent to putting bars on the window. It doesn't make penetration impossible, but it does a lot more general good than a bigger lock.