Linux hardening - web servers

Question

What are your checklist/routine when setting up a Linux web server?

What do you recommend to achieve maximum security?

Is there any preferred way to perform repeated maintenance?

Answer 1

• First of all, be aware that any scripting ability in Apache (php, cgi, ruby,...) is the potential equivalent of a shell account with privileges of the user running the script.

• If the server is shared with multiple users, you might want to think about using suexec (- or ITK MPM - Suggested by David Schmitt) so not every script runs as the same apache user.

• Virtualize or chroot apache, so that any compromise is at least somewhat contained in an additional layer of security. Be aware that when you chroot apache, maintenance may become harder, as you end up moving libraries to the jail etc. If you're on FreeBSD you can use a jail instead, which is much easier to maintain, since you can just install apache from ports, and run portaudit from within it, without having to worry about any library dependencies and moving files manually, which always becomes an ugly mess. With BSD jails you can simply keep using the package management system (ports). (On GNU/Linux you can also use VServer for virtualization. - Suggested by David Schmitt )

• (obviously) Keep up with updates and patches, not only for Apache, but also PHP, ruby, perl, etc... don't just trust your OS to give you all the updates either. Some distro's are extremely slow with their patches. Limit exposure time to 0-day vulnerabilities as much as possible. Stick the milw0rm feed in your RSS reader, subscribe to the insecure.org mailing lists, etc... Not only will it help you learn about vulnerabilities before your OS gets around to releasing a patch, you will also learn about vulnerabilities in certain php cms applications for example, which may not even be managed or patched by your OS at all.

• Use something like tripwire/aide, audit, or mtree(on BSD) to keep track of changes on your filesystem. This one is really important. Have any changes mailed to you regularly, review them manually, every day. If any file changes that shouldn't change, investigate why. If some malicious javascript somehow gets inserted into your pages through whatever method, you WILL catch it this way. This not only saves your server, but also your users, as your own webpages can be abused to infect your visitors. (This is a very very common tactic, the attackers often don't even care about your server, they just want to infect as many of your visitors as possible until discovered. These attackers also don't even bother to hide their tracks usually. Catching a compromise like this as fast as possible is very important.)

• Using stuff like suhosin to protect php helps. But also learn to understand it, tweak it's config to your application's expected parameters.

• Using a kernel patch such as PaX may help protect you from many buffer overflow vulnerabilities. Even if your software is vulnerable. (This does not make you invulnerable, it's just yet another, minor, layer.)

• Don't get over-confident when using some security tool. Understand the tools you use, and use common sense. Read, learn, keep up with as much as you can.

• Consider using mandatory access control (eg: SELinux). It allows you to specify, for each application, what it is allowed to do, in great detail. What files is it allowed to access. What kernel calls is it allowed to make, etc. This is a

Answer 2

I recommend the Linux Security Checklist, from SAN. I use that, plus another in-house procedures. The checklist might be a bit out-dated, but many of the key points stand true.

Answer 3

• I set up a firewall, and only poke holes to add each service individually
• For any services, I read the application's help documents for their configuration file(s), and make sure I at least skim every setting.
• I subscribe to security mailing lists
• I run rkhunter and lynis nightly on a cron job
• I have all errors over a certain threshold mailed to me
• I have all changes relating to logging (restarting the logging service, etc) emailed to me
• I keep etc in subversion

Answer 4

edit your ~/.ssh/config

permit_root_login no

this makes

ssh root@server

not respond but

ssh user@server
user$ su

will work if you want to login as root.

Answer 5

There will always be countless permissions to check, countless checklists, never ending discovery of new bugs/vulnerabilities. Security I wouldn't think is something you turn on or off, it is something you do constantly.

Given the "inevitable failure" of software, SELinux helps put out some worries (again no silver bullet for security). assuming a userspace application is compromised the correct SELinux policy will prevent it acting at its usual (ie if SELinux was disabled or permissive) privileges. This of course will require you to monitor your audit logs and analyze installed policy and modify it where necessary to allow applications to function.

Not saying default policy wouldn't help but I personally like to know what it allows.