Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
You might also wanna check the Secure Configuration of the Apache Web Server, Apache Server Version 1.3.3 on Red Hat Linux 5.1 . It's a guide from NSA – labmice Jan 13 '11 at 21:02
"Secure your apache so we can't steal stuff" article hey? ;P – DarkMantis Oct 1 '13 at 8:24
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – Xander Jul 21 '15 at 17:03

11 Answers 11

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:

alt text

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

Basic guide for hardening:

If you're running php:

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

share|improve this answer
Key based logins are great except when you wonder where to keep the keys at. – munchkin Jul 22 '15 at 7:17

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
That returns 404 not found now unfortunately. Do you happen to have a copy of it (assuming it's public domain and you're allowed to share it)? – sa289 Jul 21 '15 at 16:21
@sa289 good catch, updated links – Marcin Jul 21 '15 at 16:58

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.

share|improve this answer

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.

share|improve this answer
thanks alot i will loot at it ... – One Zero Jan 13 '12 at 14:18

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


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.