No budget for an application firewall? Use open-source components to build your own.
More information from SearchSecurity.com
Learn the ten steps to a successful business impact analysis.
HTTP is rapidly becoming the default transport for any and all business logic. With the advent of Web services and service-oriented architecture, XML has become the glue that holds disparate applications and data types together. Web portals, content management systems, and even corporate blogs and wikis are becoming preferred communication channels.
But defending Web applications is an uphill battle. Traditional network security defenses have concentrated on the first four OSI layers, but, by definition, most Web app exploits are valid HTTP traffic, passed through proxies and firewalls.
Open-Source vs. Commercial Web Application Firewalls
Click here for a comparison of Open-Source vs. Commercial Web Application Firewalls (PDF).
What to do? You can certainly buy a commercial Web app firewall product, but perhaps you can't (or won't) add another yearly license renewal to your budget. The alternative is building a Web app firewall using freely available open-source tools to parse, rewrite and filter HTTP traffic to defend against application attacks. You won't get all the functionality of a commercial solution (See "Open-Source vs. Commercial Web Application Firewalls," at right). But, you'll add a much needed layer of protection in front of Internet-facing Web services and apps.
A Solid Foundation
A Web app firewall will ideally sit behind your Inter-net-facing firewalls, acting as the sole ingress path for all of your Web traffic. Use a hardened Unix or Linux platform, such as OpenBSD, with its stack protection, minimal installation and aggressive source code auditing. Bastille is also an excellent hardening tool available for most Linux distributions.
Since the firewall will parse all Web traffic, the load will be substantially higher than a typical proxy. You'll need as much CPU as you can afford, and a lot of RAM. You can build several redundant gateways and use an HTTP load balancer in front of multiple security gateways.
However, sizing a solution like this can be complex. As with a network IDS or IPS deployment, the number of rules in your configuration, the amount of traffic to your sites, and the complexity of your rewriting and parsing operations will all affect performance.
Still, a good rule of thumb is to size your Web app firewall as large as your busiest Web server. Since performance will vary based on the types of applications you use in your organization, be prepared to tune, test and benchmark prior to any move to production.
Knowledge to Build On
As a Web app firewall mason, you will need a strong Unix/Linux background and a solid understanding of Web applications, Web attacks, and the HTTP protocol. Some of this will feel a bit like Web development: You will need to test and ensure that the filtering does not affect any Web applications, and run Web-scanning tools like Nikto (www.cirt.net) to compare the original and proxied content.
You should know your way around a command line, and be familiar with Apache configuration syntax to load the modules required and create security rules and filtering expressions. You will find that a good comfort level working with regular expressions (which are often used in Snort rules) will also come in handy.
Now, let's look at some open-source components you can use to construct a Web app firewall.
Of all the commercial and open-source HTTP proxies available, the Apache Web server stands out with its ability to parse and rewrite content. Apache includes a fast and stable built-in HTTP proxy as part of its core distribution, and its modular design allows you to tune it extensively, so you can deploy it in a proxy-only configuration. You can leverage its content-awareness to build a filtering and rewriting HTTP proxy.
Starting with version 2.0, Apache includes the PCRE (Perl Compatible Regular Expressions) library as a built-in pattern-matching engine, which substantially improves the performance of regular expressions. It also allows for the ordering of multiple parsing and rewriting operations, based on the type of content.
These features, combined with the third-party and built-in modules discussed later, provide a powerful toolkit for protecting Web applications.
Mod_security (www.modsecurity.org) is at the heart of your firewall's Web intrusion prevention capabilities. It began as a simple pattern-based filtering engine to block network worm traffic, but has matured into a full-blown Web security suite.
Mod_security signatures use a regular expression-based filtering language that will be familiar to users of Snort, and can be automatically updated via the mod_security site, much like typical IDS signatures. These include filters against cross-site scripting and SQL statements in URLs, and traffic that contains shell commands and path or user ID information.
Free, frequently updated signatures for mod_security are available for download at www.gotroot.com.
Mod_security also normalizes and sanitizes Uni- code traffic to protect against URL-encoding attacks.
Mod_security's pattern matching can also be used to prevent error message leakages that might give an attacker useful information. Any messages that might disclose Web server configurations can be filtered and redirected to a generic error message. You can also use mod_security to enforce what file types can be requested from the environment, such as .php, .asp, .jsp, and .html files.
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.