Hackers will use anything they can lay their hands on to get into a network.
Attack vectors can range from an open telnet port to a poorly configured FTP server. Port scanning tools, which attempt to find back doors into the network, are an intruder’s best friends.
But even after blocking off all other ports, the most diligent network managers must still keep port 80 open. Adept hackers can exploit web applications that must use port 80, manipulating them to take advantage of flaws in the code. They can either compromise the activity of the application itself, or use flaws to dig down into the underlying web server and operating system. Application firewalls were developed to help keep such intrusions out.
Traditional firewalls are designed to block external access through network ports unless specifically allowed, and can also be programmed to pass traffic through open ports only to specific servers.
But these network-layer devices do not analyse what is passing through the port to determine whether it is malicious or not. To do that, you need something that works at a higher level in the stack.
An application firewall will generally work as a proxy server, terminating traffic coming from one direction, processing it against a series of rules, and then passing it on to its destination.
“They are using two-way inspection,” says Gartner vice-president and distinguished analyst John Pescatore. “The browser connects to the server and goes through the web application firewall, and the server connects to the browser and goes through it too. The web application firewall is saying, ‘Based on what I have seen so far, here is an acceptable range of responses from the browser’.”
An application-level firewall will often carry out stateful packet filtering at a network level (working out where a piece of traffic is going and which address it is coming from) in addition to application-level filtering, where it inspects the content of a packet. If someone sends an unexpected command to a web application, it will simply drop the command so that the web application cannot be manipulated.
Pescatore classifies application firewalls as purely HTTP-focused, whereas others expand the category to include firewalls targeting other types of traffic. For example, Borderware sells a range of firewalls targeting specific applications: its Mxtreme Mail Firewall deals exclusively with e-mail security, and it also sells firewalls focusing on Session Initiated Protocol (Sip) for voice over IP.
One of the problems with application firewalls is their high cost. David McKechan, a consultant at security consultancy DNS, says, “The hardware can get pretty expensive. It is more like five figures than four for the ones I have looked at.”
Part of the reason for the expense is doubtless the extra processing that must be done. Analysing a packet header to work out which server it is going to and where it came from is one thing. Trying to analyse the packet contents, possibly even getting down to the level of scanning a series of packets for viruses, is much more processor-intensive.
Another challenge is SSL-encrypted communications. SSL certificates encrypt traffic to keep sessions secured, and are used for things such as password entry and credit card transactions. An application firewall cannot examine the content of encrypted traffic, but software developers should not disable one type of security just to enable another.
The easiest way to deal with this is to decrypt the SSL traffic at the application firewall before it is checked, says Donal Casey, security consultant at technology integrator Morse.
Because the firewall is owned and trusted, it would be easy to give it an SSL certificate. Once decrypted, the traffic would be forwarded to the server as clear text, on the understanding that the internal network was trusted and secure. Traffic would then be re-encrypted by the application firewall on the way out to the client from the server.
Suppliers are now folding application firewall functions into other products. F5, for example, has incorporated a firewall into its Big-IP application management system. Big-IP handles load balancing to improve application performance, but now also deals with application-layer filtering.
The processor load, combined with the multiple functions included in some of these devices, means that the positioning of an application firewall is particularly important. Putting it on a high-speed portion of the network where it will encounter lots of traffic will put it under strain and require a bigger investment.
“If you use an application firewall to protect a SQL server behind a web page, the latency does not matter much,” says Raimund Genes, chief technology officer at security software and services provider Trend Micro. If, on the other hand, it was used by an application that required extremely fast responses, then the extra milliseconds of latency might not be acceptable.
Why would you want to protect a SQL server with an application firewall? Because many modern web attacks will attempt to exploit internal computing resources using poorly configured applications.
For example, SQL injection attacks use valid SQL commands entered into web forms or URL parameters in an attempt to fool a web application into sending a bogus SQL query to a database.
Other common web attacks that have – astonishingly – been known to work include changing user session ID information to see someone else’s account details, while cross-scripting attacks involve posting malicious script in other web pages, often via web forms, which can then be used to manipulate the browsers of other users.
The most obvious response is simply to take more time and care when developing your web applications. Theoretically, it seems easier to code a small collection of functions that validate web application input against a small number of accepted formats.
“You should be able to switch the application firewall off and the application should still be secure,” says Eliot Mansfield, application firewall expert at IT services provider Eurodata Systems.
He says that the device can be particularly useful for stopping zero-day exploits. “What the application firewall is doing is creating positive logic, so it understands how the application works and everything that is normal. If someone discovers a new vulnerability, the application firewall should then catch that.”
There are some situations where legacy applications simply cannot be changed. “We have seen this with some systems that we put in. We ask why they do not just fix the application, and they say the developer died 10 years ago, and no one can fix it,” says Mansfield.
The other possibility is that a vulnerability may be discovered in an application, but the back-end change management process may make it impossible to change the code for weeks. In the meantime, an application firewall can be configured to protect the system.
Managing the relationship between the security team configuring the application firewall and the software team developing the application can be one of the hardest parts of any application-layer
“If you are going to deploy this thing, you are going to go in and develop a set of rules and deploy,” says Bill Pennington, vice-president of services for security services company WhiteHat Security.
Even though network firewalls can contain complex sets of rules, it is child’s play compared to the hundreds of rules that tend to populate an application firewall’s database. “Any time the code changes on the web application, you need to go change those rules again,” Pennington says.
That can be tricky, because the application firewall configuration team is unlikely to speak the same technical language (or have the same set of goals) as the software development team. Security teams generally like to lock things down, whereas software developers generally like to exploit new features. Getting one to talk to the other can be difficult, especially if, say, the software development team is part of an external consultancy.
“Every time there is a problem with the application, the developers point their finger at the web application firewall,” Pennington says. Does an IT director or project manager want to solve that operational problem?
Complications around software development will probably get worse, as application logic moves away from the server onto the client and other servers. Rich internet applications using programming techniques like Ajax, Java and Flash process imports more fluidly on the client side, eliminating the click-and-wait model associated with conventional multi-page web forms.
The downside to this is that it provides less control. The server does not know what the client has done until it submits an XML request to complete the transaction. Nor can the server tell whether the client-side code has been hacked and manipulated.
In fact, the whole Web 2.0 concept will present problems for application firewall manufacturers, says Pescatore. “When you look at mashups, where information may be presented from five different websites, the web application firewall will not see parts of what is being sent out to the users. The number of responses just go to infinity and that is a major break.”
An XML firewall that scans XML files specifically to help protect web service-based applications might help. But configuring yet another type of appliance to cope with this will be one more overhead for IT departments wanting to take the application-layer filtering route.
“There is a lot of configuration to go on, and it assumes that all the schemas for XML coming through the system are known and can be checked for compliance,” says Casey. “The technology is there to do that, but it is a big configuration effort.”
As a network manager, it seems that monitoring applications is maintenance-intensive. Just as with intrusion detection devices, application firewalls are sufficiently complex that simply leaving one gently whirring away in the corner gives a false sense of security.
Being prepared to devote the time and budget to ongoing management is a vital part of any application firewall project, and it is important to understand the political ramifications as well as the technological ones.
Read David Lacey’s security blog
Comment on this article: firstname.lastname@example.org
This was first published in January 2007