ApacheCon – Hardening / Securing Enterprise Apache Installations

 

2007 Web Hacking Incident Graph

2007 Web Hacking Incident Graph

The Threat Model - Who gets attacked?  Everyone!  Just because you’re small doesn’t matter.  What are the goals of those trying to attack?  The chart on the right shows a breakdown based on data from the Web Hacking Incidents Database.

Maybe not so surprisingly was the next slide, that showed that most successful attacks (I think somewhere near 50%) were because of someone getting the admins passwords through some means, perhaps social engineering or phishing.  Sysadmins should definitely be more careful with this sensitive data.

So, how do you protect against these attacks?  That’s what Sander will cover in this session.

Apache HTTP Server is Secure
There have been very few security vulnerabilities reported against Apache, and no critical vulnerabilities in the 2.2.x branch.  If you do think that you have found a security vulnerability in Apache, you can email security@apache.org and they will respond swiftly if it is a real vulnerability.  This includes them reporting it to CVE, a government defense contractor that tracks vulnerabilities.
 
Installing Apache and Securing it
If you build Apache yourself, the default is a pretty secure installation.  If you install it from a distribution (such as a Linux RPM, etc), there are a variety of configurations and differences between packages.  For instance, RedHat 4 Enterprise includes 2.0.46 at this time, even though this is very old.  Then they manage pulling in and backporting patches themselves.  In this case, they have a secure version because of their tediously updating patches, but you must understand the difference between getting the “latest” version of Apache, and getting the “latest” from your particular distributor.
 
Apache Configuration Tips
  • Sander suggests writing your own configuration file
  • Use formal testing against your configuration.  Write a test script that tries to get various URLs from your server and make sure that you get expected behavior.
  • He also suggests avoiding <IfModule> in your configuration.  If you don’t need the module, don’t include it.  If you do need it, you should want the server startup to fail if the module didn’t load.  This makes a lot of sense!
  • Disable unused modules

Operating System Hardening (mostly Linux)

  • Keep the amount of writable directories as low as possible. 
  • Since every Linux distro has a /tmp directory that is writable, you could try mounting that with NoExec so that even if someone targets the /tmp directory and successfully gets a file stored there, it can not be executed.
  • Chroot / FreeBSD / Solaris Zones – look into these on Linux
  • Turn off services that you are not using.  He suggests that you probably don’t
  • Remove unused packages, such as header files and other things you are not using.  Uninstall the compiler on the web server.
  • He also suggests that you consider having your web servers boot from a network server.

Windows - Use what you know!!  Sander says that a poorly maintained Linux installation by someone who doesn’t know what they’re doing is worse than a well maintained Windows installation by someone who is only familiar with Windows.

Network Infrastructure

  • Block outgoing connections.  Web servers only serve incoming connections, and typically do not need to go out to the web.  This will make running updates more difficult, but blocks malicious scripts from downloading things to your server and blocks other zombie activities.
  • Minimize incoming connections – port 80 and 443 will probably need to be open, but do any others really need to be open?
  • Use a firewall
  • You can also block it so that SSH requests are only accepted from another machine within your hosted environment – not accepting requests from outside machines.  This means you have to SSH to your middle machine, and then to your web server, possibly through your VPN. 

ModSecurity – the next session will talk more about ModSecurity, but basically it is a Web Application Firewall that runs right inside Apache.  It can do rule-based security, and a whole host of other things to protect you.  Since it runs inside Apache, it can also see inside HTTPS packets – something a hardware firewall couldn’t do.

Always ask yourself “WHY”

  • Why must the server have to “see” the net?
  • Why can users upload stuff that gets executed?
  • Many others….  Sorry, he moved to fast.

Change Management – you should implement change management for your server environment.  This means that you do not make changes to the configuration files on the live server.  Do them in a testing environment first (after asking “why?”).  Then apply them to the live server, with a backup of the previous configuration.  (Could you use a version control system for your config files?)

Database Privileges – Many applications that you download to install (Joomla / WordPress / etc) have bad default configuration advice – like GRANT ALL PRIVILEGES.  Do you really need to do this?  No!  What app really needs create table and drop table privileges?  You will only need to do this to set up the application.

PHP Configuration - Here are some configuration details to make your PHP installation more secure:

  • register_globals = Off
  • allow_url_fopen = Off
  • display_errors = Off (production – dump them to a log instead)
  • enable_dl = Off

Further Reading

Sander says that he will be posting his slides at: http://people.apache.org/~sctemme/ApconUS2008/

Be Sociable, Share!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>