This article can also be found in the Premium Editorial Download "Information Security magazine: The power of SIMs for visibility and compliance."
Download it now to read this article plus other related content.
The Great Wall
Mod_security is powerful, but like most IDS/IPS solutions, it takes a default-permit, or exclusionary approach. You will want to use some additional modules available with Apache for a Web app firewall that begins to attain a default-deny posture. Here are some additional modules to get the job done:
This is a typical Web transaction using an open-source Web app firewall. A client request for a static HTML page is rewritten as a dynamic request behind the gateway and inspected, scanned and validated. HTTP response headers are also rewritten to mask the Web server and hide its underlying platform.
- Mask your platform. Web server
version banners are an easy way for an attacker to discern the platform of a Web server. A simple
telnet to port 80 and an HTTP GET request will yield the version number and often any additional
extensions that are loaded on the server. Masking the server header and any other platform-specific
headers with mod_headers is a simple measure that reduces information leakage.
To stop more advanced fingerprinting tools, you could go a step further and modify the Apache source to send unique error headers and reorder responses.
- Rewrite and sanitize content. With no
changes to code running on the back end, you can modify outbound responses or inbound requests, and
validate input, all via simple regular expressions.
Mod_rewrite is a popular tool used to rewrite inbound HTTP requests, often to present Web content in a format that's more easily parsed by search engines. Using regular expressions, you can create a filter to limit what's allowed through to your Web environment according to specific security rules (such as maximum length for a parameter, alpha or numeric characters only, maximum length for a request), sending all other requests to a generic error page.
Mod_proxy_html works in a similar way, but on output, rather than input. It reads and then replaces HTML returned by a server. By combining mod_proxy_html and mod_rewrite, it's possible to perform Web application impersonation that's analogous to network address translation, rewriting the content presented by a given site.
This opens almost limitless possibilities for tricking an attacker: ASP pages can be impersonated as PHP, dynamic content can be made to appear static, and sites can be split across multiple servers transparently to the outside world.
Another tool, mod_lineedit, provides the same rewrite functionality as mod_proxy_html for not only HTML, but any content in an HTTP message. It's very useful for stripping out other sources of information leakage, such as META tags that name the author or tool used to create a Web page, developer comments and any other potentially dangerous data not caught by your filters.
Bricks and Mortar
A host of other tools can be deployed on a proxy that inspects all Web traffic:
- Traffic-throttling tools can minimize worm traffic and DoS attacks by limiting the number of requests a specific host or network can make per second.
- Log parsers will help detect anomalies in Web request logs.
- Traffic analysis apps alert when load differs from the norm.
- The Web security gateway is a great place to add multifactor authentication, or use LDAP or another mechanism to integrate with an enterprise directory for single-sign-on.
Building your own Web app firewall requires substantial heavy lifting up front, but the returns are potentially quite high. Whether you build a solution or buy one, don't wait to find out the hard way that network security defenses are blind to what's going on in your Web environment.
This was first published in September 2006