Web Application Layer Firewalling with Radware AppWall

I recently deployed Radware’s Web Application Firewall (WAF) aka AppWall in a hands-on lab anybody is welcome to try out (message me for more info). I thought I would provide a WAF 101 post for those unfamiliar with the topic and well as showcase Radware AppWall.

To summarize firewalls, they permit and deny traffic. Overtime, firewalls have combined capabilities with other security tools include adding application-layer visibility, application controls, intrusion prevention and antimalware to name a few of the “next generation” features. The term “Next-Generation Firewall” has been defined many ways but essentially it means a firewall that can view all ports and protocols, control traffic down to the application layer and some people also include in the definition exploitation prevention capabilities.

Exploitation defense in a next gen firewall does not include defending web application exploitation techniques such as cross site scripting or SQL injection. For example, if an attacker identifies a blog is vulnerable to an injection attack, malicious code to be added to a webpage redirecting viewers to some other web source. Scripts such as sqlmap can quickly identify these vulnerabilities on web sources. The next image is an example of creating a popup using a basic injection technic.

Data can also be exposed if poor web application security is deployed. This next example shows the classic something or 1=1 attack, which tricks the vulnerable application to grant access even though the user doesn’t know the right password since 1 always equals 1.

A next generation firewall would not prevent either of these attacks hence the need for a WAF.

There are many benefits of a WAF, which include preventing web-based exploitation, validating input, filtering sensitive information such as converting credit card numbers to XXXXXX’s and preventing different forms of denial of service attacks. There are a few ways a WAF can be deployed to protect web applications. The most common method is deploying it as an inline gateway or configuring the WAF to act as a proxy.

The previous image shows the AppWall configuration tab displaying some of the filters that can be enabled. If a filter is violated, a customized block page can be generated as shown below. This is not only ideal for showing that security is enabled to defend the attempted attack, but this customized message also hides error messages or other data that could disclose information about the web application being attacked.

If an attacker continues to attempt exploitation against a protected web application, AppWall can add that source to a blocklist as shown below. This will prevent brute force and automate response when reconnaissance and exploitation is being repeatedly executed by an attacker.

Radware AppWall includes explaining why an attack is blocked. The next example shows blocking the classic ‘ or 1=1 attack, which a definition is included within the AppWall alert.

To test data loss, the next example shows how I used a real credit card number in the output from a web application. The example represents a customer putting in their bill identifier and their information is displayed including what credit card number was recently billed. AppWall auto hid those numbers by replacing the digits with XXX’s.

There are many more benefits from using a WAF to protect web applications. If your business depends on protecting applications, you should consider a WAF as well as dedicated volumetric denial of service solution. WAFs can prevent protocol based denial of service however, volumetric attacks require a dedicated appliance that can monitor for volumetric DoS behavior. I’ll post about Radware’s Defense Center DoS technology at a later time. Below is a dashboard screenshot of Radware’s AppWall WAF showcasing alerts for the various attacks I covered in this post.