Apache Webserver security and optimization tips

Question

Hi.

I'm about to deal with managing and running my first Internet connected Apache webserver and I was wondering if there are any sys admins and developers out there that would like to share some of their knowledge regarding security and optimization tips for running Apache webserver.

Maybe you can share your top five (or ten) list of things you immediately do after installing Apache webserver (on a Linux box).

Any help very much appreciated.

Answer 1

• Ensure the Apache process isn't running as root.
• Be sure to be on the latest stable release
• If the box is directly connected to the internet ensure you have thought about all other services, like ssh.
• Carefully inspect your local firewall rules, tighten it down. (See iptables)
• Don't turn on options you don't understand or don't plan to use
• Consider subscribing to an Apache security mailing list so you'll learn right away of any critical patches

Answer 2

If you're running a standard LAMP (Linux, Apache, MySQL, PHP/PEARL/PYTHON) environment: Put MySQL on another machine than Apache. Will be a little slower with only a few concurrent processes (due to network latency), but will be MUCH faster with many concurrent processes.

Answer 3

Make sure you have configured it to detect DOS (Denial Of Service) attacks.

Answer 4

Basic

1. Be sure to have the latest stable version installed. Running old or unstable version of Apache could expose your system to security flaws or untested solutions
2. Be sure only the intended requests are actually processed. You should consider who has to access the web resources exposed by Apache and how.
3. Avoid running Apache as root. This is a must.
4. Handle your logs. Logs tend to become bigger and bigger; consider to setup logrotate or to clean your log periodically.
5. Monitor Apache health with a monitoring system. I like to couple munin and monit, both easy to setuo and to maintain. Nagios and others are worth a look.
6. If Apache is serving web apps (i.e. PHP, Perl, Rails) be sure the requests are handled by the right module in the right order.
7. Write a nice 404 and 500 message. Sooner or later your visitors will catch an error.
8. Stop and restart Apache, so you can be sure both the shoutdown and start procedure is working flawlessy.
9. Use mod_security

Security

1. Protect Apache against DOS.
2. Load only the modules really needed.
3. Monitor your log to figure out if something strange is happening.

Performance

1. If you are compiling Apache from source code, be sure to use MPM (Multi-Processing Modules).
2. Load only the modules really needed.
3. Check the MaxClients setting so that your server does not spawn so many children it starts swapping.
4. Use the mod_deflate module, it provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.

Answer 5

1. Chroot the webserver
2. Disable any module you aren't going to need
3. One you instead need is mod_security
4. Set up a file integrity checker for your webroot
5. Secure everything else on the same server and switch off anything not used
6. Run tests against your server with tools like nmap or Metasploit

Answer 6

I'm going to interpret "after installing Apache on a box" as "Preparing a new server installation for production use", because of course this would all be done on a development server and committed to SCM or built into an automated install.

Everything you do to optimise must be done based on real measurments. Set up a test environment with your actual application you intend to run, as realistically as possible. Some points to consider are:

• Don't set MaxClients too high. You can use up a lot of RAM, particularly with prefork servers with a large application embedded in them (e.g. mod_perl, PHP etc). Using too much memory is counter-productive. It's better for clients to wait for a successful service than be served an error.
• Consider carefully whether you have Keepalives on. These can both speed up and slow down depending on your environment. If you choose to have them on, you should think about your keepalive timeout based on the actual use case.
• Do performance testing with HTTPS enabled if you're using HTTPS in production
• Set "Last-modified" and "Expires" headers appropriately on objects which change infrequently (to maximise client side caching). Test client side caching in a variety of browsers.
• Make sure your application uses HTTPS correctly, not in a way which causes browsers to generate security warnings (this is another good reason you need to use HTTPS during testing)