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.
This way, for example, a web development team could strip out
SQL code, segments of Javascript and so on from web forms. Surely,
if all this was done properly, there would be little need for an
application firewall at all?
“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
filtering project.
“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
www.computerweekly.com/David_Lacey
Comment on this article:
computer.weekly@rbi.co.uk