Top considerations for selecting Web Application Firewall technology
There are critical differences in the protection offered by non-proxy based and proxy-based application firewalls
Hackers are no longer merely scanning for open ports on network firewalls to attack, but have shifted their tactics to targeting applications directly.
These sophisticated attacks evade traditional methods of perimeter and core network protection, making them the current biggest threat to organisations.
The need for increased application defence to protect core data assets has led to the development of Web Application Firewalls (WAF), which add a new layer of protection to an organisation's security arsenal. However, when looking at investing in a WAF one is faced with a choice: to choose a non-proxy based or proxy-based application firewall.
How they differ
In proxy-based application firewalls, the connection to the application is controlled by the proxy, and no packets or sessions flow to the back-end until the proxy has inspected and validated the incoming data. Separate TCP sessions are used to manage and inspect user sessions and back-end server sessions.
Non-proxy based application firewalls either work off a span port by sniffing the traffic or without fully terminating TCP/IP protocol. These WAF products are an extension of intrusion prevention systems (IPS). IPS is a common technology used by data centres to defend common desktops and servers against well-known viral and worm attacks.
When deciding which Web Application Firewall technology best suits your needs, the following functionalities are worth examining:
Hackers gather information in order to launch an attack on a Web server by trying to simulate error conditions on a Web site. Often, the resultant error messages expose information about the Web server, application server, or the database being used. This information is then used to launch a full-scale attack on the Web infrastructure.
A proxy-based WAF intercepts the response from the back-end server and forwards it to the client only if it is not an error. If the response is an error, the WAF can suppress the response containing debugging information and send out a custom response. The WAF also removes headers such as server banners, which can be used to identify servers.
2. Input validation
A WAF should secure applications where the incoming traffic may be encrypted or encoded using a non-standard character encoding.
A proxy based WAF decrypts and normalises data before running various types of checks, in order to ensure that no attacks are smuggled inside of encrypted or encoded packets. It also offers multiple ways of securing inputs - such as encrypting or digitally signing cookies to prevent against cookie tampering attacks. It can also recognise which fields are read-only or hidden and ensure that these fields are not altered. For other fields, it should offer a host of protection mechanisms such as checking for various attacks on the input fields and locking down those inputs based on data type, such as numeric or alpha numeric.
Non-proxy based WAFs do not provide effective input validation. Although some can encrypt and normalise data, because they are not proxy-based they are not able to enforce rules on individual form parameters passed to the application. They also cannot encrypt or digitally sign the application cookie; relying instead on signature matching for security.
3. Data theft protection
Proxy based WAFs intercept outbound data, so they can be configured to ensure that sensitive data - like credit card numbers - are either masked or altogether blocked to protect data leakage.
This is only possible because the proxy-based WAF sits in line with the application server and secures data on both incoming and outgoing paths - so this is not offered by non-proxy based WAFs.
4. Protect against application layer DOS attacks
There are many ways of launching an application layer denial of service attack. Web applications maintain state information - such as the number of items in a shopping cart - with the help of sessions, which require some memory resources on the Web servers. By forcing a Web server to create thousands of session leads, memory resources are locked up and this results in performance degradation and can lead to a server crash.
There are other ways these attacks can be done. The WAF should be able to control the rate at which requests reach the Web server, and track the rate of session creation. This is only possible with a system that proxies on behalf of the Web or application server.
5. Centralised security enforcement
The ability to enforce all security policies from a single control point allows for simplified operations and infrastructure. To ensure safer and more efficient security administration, it is advisable that controlling and enforcing attack prevention, privacy (SSL cryptography) and AAA (Authentication, Authorisation, Accounting) policy is done through a single control point.
Because a non-proxy WAF does not terminate TCP connections, it does not have the ability to request credentials from incoming users, issue cookies upon successful credential exchange, redirect sessions to particular destinations, or restrict particular users to particular resources. Proxy-based solutions, on the other hand, have the capability to be an AAA authority - or to fully integrate with existing AAA infrastructure.
6. Control the response
Because of the wide range of security violations, it is important that the administrator is able to respond to threats differently. For example, in many cases it would be best to respond to a violation with a custom message or connection reset, while in others the administrator may want to follow up with the main action directly, with a longer block time.
Only proxy-based solutions are able to offer this sort of flexibility, as non-proxy based WAFs rely solely on sending TCP resets back to the attacker and temporary network ACLs as their protective mechanisms. Attacking packets will make it through to the server, and blocking actions are time-limited.
7. SSL architectural considerations
Application attacks use SSL cryptography and common encoding techniques to bypass traditional security measures, and hide their attacks. Proxy and non-proxy WAFs are quite different in the way they handle SSL cryptography and key management.
Non-proxy WAF vendors claim that they also have the technology to 'see' into an SSL encrypted packet as it passes by the non-proxy device. However, because decrypting and analysing the data takes time, by the time the non-proxy WAF is ready to make a decision, the attack will have already reached the back-end servers and completed the transaction.
Proxy based WAFs, on the other hand, are designed to serve as an SSL termination endpoint. Proxies tightly couple TCP, SSL and HTTP termination, giving them complete visibility into application content and allowing them to perform deep inspection on the entire session payload, including headers, URLs, parameters and form fields.
8. Accelerate and scale application delivery
It is important that a WAF product does not negatively affect end-user response time. Proxy based firewalls fully terminate the TCP, SSL and HTTP, reducing end user response time. They should be able to cache static content from the application, offloading servers and saving download time; pool TCP connections to the back-end servers and offload SSL processing, thereby reducing server load and end-user response time. Non-proxy based WAF products do not offer these features.
While non-proxy based products have evolved, they only provide some of the functionality necessary to fully protect an application. This isn't adequate when it comes to protecting mission critical business applications and confidential data. On the other hand, proxy based WAFs offer complete and comprehensive protection for enterprise Web applications.