DivConq Framework

Securing a web server may sound like a daunting task.  It may be tempting to think that complex solutions will provide the most security. This is not always the case, sometimes a simple solution can provide a lot of protection.

A web server is one of the most visible targets for attackers for three reasons:

1. The sure popularity of HTTP
2. The bevy of vulnerabilities found in misconfigured web servers
3. The sometimes poor quality of ‘CGI, etc’ software running on the server

So naturally great care should be taken to secure the web server. But what if the web server should become compromised? Have you increased your attackers surface? Consider this diagram:

Once compromised the web server now provides the attacker multiple new targets such as LDAP, MySQL, and SysLog. A very simple addition to the diagram, the reverse proxy, will put the attacker back to square one – again battling to break into a web server with little else gained.

So your attacker can do one of two things:

1) Deface your web site or otherwise abuse that single server. While this is certainly not an attractive proposition, it definitely beats the news that sensitive data or systems are under attack.

2) Resume the attack and attempt to hack into the next web server – the one in the internal network. To further frustrate the attacker, choose a different web server for the internal network. Whatever vulnerabilities they used to compromise the first web server will likely be useless against this new web server.

Example Configuration

Reverse Proxy Server: consider Nginx a widely used but very light weight web server. The base install includes reverse proxy features. Minimally add a ‘proxy_pass’ setting to the location in the Nginx configuration.

server {
  listen   80;
  server_name  localhost;
  location / {
    proxy_pass http://[private server address]:8000;
   }
}

Private web server: consider lighttpd a light weight HTTP server well suited to running with PHP through the FPM module in PHP (as of PHP 5.3).

Any web server in the private network would work, of course. And the Nginx configuration would be more complex if you need to support SSL, or if you want static files to cache in the DMZ zone. But overall this is a very simple way to get considerably more security for your sensitive systems and data. And, as it turns out, it also scales well – more about that in future posts.

Next Post: The same reverse proxy techniques can be used in in Amazon’s cloud.  (Read now.)