Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

up vote 23 down vote accepted
  • 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

share|improve this answer
    
+1, great list! I'd recommend taking a look into the ITK MPM (mpm-itk.sesse.net) instead of suexec and Linux VServer (linux-vserver.org) instead of chroots. Also, for the file system scans, there's tripwire or aide and chkrootkit. –  David Schmitt May 10 '09 at 7:11
    
So, in the end, protecting a web server nearly takes a lifetime. It seems you cannot prepare well enough, so regular updates about strange happenings are far better than the first security tool you might found in the package manager. :) Great list, but I'll take my time. Highly likely this answer will be the one. :) –  pestaa May 10 '09 at 8:46
    
@David : Yeah, with mentioning tripwire I kind of implied aide, I'll add an aide link just in case. I'll also add the vserver suggestion. Yes, virtualisation and/or paravirtualization are going to be better than chroot, which is also why I mentioned FreeBSD jails. One thing with virtual machines though is that having to replicate the userland+required tools for each vm is going to eat a lot of extra disk space, which can be an issue –  jns May 13 '09 at 2:38
    
if you're in need to virtualize lots of things, or short on cash/hardware. Jails+nullfs mounts can circumvent that problem. and since jails aren't virtualized or emulated there is no overhead at all. I guess vserver is the next best thing on GNU/Linux. –  jns May 13 '09 at 2:40

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.

share|improve this answer
  • 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
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.