Best practices for Apache Server hardening?

Question

What are some best practices, recommendations, required reading for securing an Apache Server?

Answer 1

Grab the Center for Internet Security (CIS) guide for securing Apache (it describes in detail how to enhance the security):

Edit: Updated link CIS Apache HTTP Server 2.2.x Benchmark

If you have a license to Nessus, then you can run an automated check by grabbing their audit template:

Answer 2

• Use SSH key based logins
• Secure MySQL
• Disable phpMyAdmin, webmin, etc
• Close all ports/process's that are not needed
• Use a file integrity checker
• Use mod_security
• Set the proper permissions/groups

This is a good guide:
https://serverfault.com/questions/212269/tips-for-securing-a-lamp-server

Basic guide for hardening: http://www.wpsecure.net/server-guide/

If you're running php: http://www.madirish.net/?article=229

Find 404's (or other status codes) in apache log
awk '$9 == 404 {print $7}' access_log | uniq -c | sort -rn | head

Answer 3

The originally highly voted answer to this question that was accepted was deleted because it was a direct plagiarism of 20 ways to secure your Apache configuration. That page is a fantastic resource.

@RoryMcCune also posted this as a link on that answer: There's an OWASP project to develop a ModSecurity Core Rule Set here which could be of use.

Answer 4

There's lots of good advice here, so I won't repeat things already mentioned. But what I will say is:

Don't forget to replace the default error pages with things that don't give away your Web Server release or kernel revision. I tend to replace each default html with 1 liners that are something like "Error 400." It gives very little about the system away. This principal applies to all web servers capable of displaying custom error pages, they all pretty much default to giving away far too much information than is necessary. You would think that ServerSignature would hide this, but in many cases it does not.

Also, don't forget to delete all the default HTML content (language specific etc.) so fingerprinting is that much harder.

As far as good reads go there was a whitepaper from Apcon 2008 that's worth a read.

Mod_Security is mentioned a few times, this is more suited to web applications, so if you are serving static content only, it's not going to help you too much, though there are some attacks it helps defend against during request handling which could affect a static Web Server.

The other thing I'd mention is good log management, if you aren't farming your logs off and keeping a close eye on the system you run the risk of an attacker pounding away at it without having any awareness of it.

Answer 5

All the general security principles apply: run only modules you need, turn off features that you don't need, tidy up your permissions/ownerships (most contents are read only, so why do the files need anything more than 400 perms?).

The stuff that's particular to Apache, like CGI jobs, or different vhosts serving out the same content twice with two different security mechanisms on them are much harder to spot; not exactly an automated check, you actually gotta know Apache, the underlying OS, and what the applications running in Apache are doing.

For completeness sake here's a Apache 2.2 Security Checklist from DISA. UPDATE: Here's a link to their whole collection of webserver hardening documents.

Answer 6

It might be worth giving Apache mod_security a look.

I have been giving it a go on some of my servers lately not only does it perform some configuration tweaks to Apache itself like changing version number etc but it also acts as a web application firewall helping to protect against a wide variety of attacks such as SQL injection etc.

Answer 7

How Do I Secure Apache Web Server

What answer would you expect if you asked "How do I fly a jumb-jet" or "How do I do brain surgery" - the same applies to making a webserver secure - you need to do 1000's of hours of training, practice and research. But since everyone has to start somewhere...

There are lots of basic checklists on the internet for how to harden a server - but as per my comment elsewhere they vary greatly in quality.

I'd recommend the sans one as a good source.

Once you've followed the checklist you need to establish means by which you can

• verify the integrity of your server (you definitely need a host based IDS such as tripwire along with a rootkit detector)
• be aware of and apply patches
• recover your system to a known good state

Don't plan for how you deal with a security incident if it happens. Plan for what to do when it happens.

After you've got your system setup and configured then swap out the hard disk and see how long it takes you to get the service up and running again without using the original disk.

Answer 8

this is not just apache-related (and also counts for nginx+php-fpm), but often forgotten: php-eastereggs, that might be switched of via php.ini

  expose_php = off

it is not as terrible as leaving a phpinfo.php behind, but usually is a hint to very lazy system-administration.

see easter-eggs

Answer 9

Use the latest version of apache, patch your OS and also of the third parties like openssl or any other.

Block unwanted ports.

This will protect you from some known vulnerabilities, but you will always be susceptible to a 0-day, of course.

Answer 10

Good thread turned. Many people say truth.

They forgot one, OpenBSD's way:

In OpenBSD, the Apache httpd(8) server has been chroot(2)ed by default

httpd (v.1 of Apache) included in OpenBSD by default, and chrooted by default.

You can repeat it easy with apache2 or nginx on any other Unix-like OS.

Answer 11

Here 6 key steps :

1. Secure your application code
2. disable all modules not used. Try to disable all, and then, one by one, add modules.
3. remove all scripts and backup files in the web folder.
4. disable directory listing
5. use modsecurity to protect your application from application-level attacks.
6. Use Fail2ban to trigger HTTP errors (403, 404).

Do not rely on your network firewall, it's useless when talking about web security.