While network-based attacks rely on vulnerabilities in transport layer protocols such as TCP or even lower level protocols, Web application attacks target vulnerabilities that are specific to the application, such as the input it accepts. Because this application-level visibility is missing in Standard Network Firewalls, they cannot offer sufficient fine-grained protection. This is where web Application Firewalls come in.
Application Firewall or AppFirewall, which is how it is commonly referred to, is available either as a standalone product, as an option with NetScaler Enterprise Edition or is included when purchasing NetScaler Platinum Edition. We will use the term AppFirewall everywhere in the chapter for easier reading.
Note
Payment Card Industry Data Security Standard (PCI-DSS) is a security standard that is aimed to certify whether your e-commerce infrastructure is secure enough for your customers to use for transactions. Web Application Firewalls are specified as Requirement 6.6 of the PCI-DSS standard, which lists that either proactive code reviews (non-trivial due to the personnel requirements) or a properly configured AppFirewall as a mandatory requirement.
While this book is about troubleshooting, application attacks are a new subject for many and hence knowing some of that background information and how it applies to NetScaler is crucial for troubleshooting.
To help you make the most of this chapter by covering this background info, we will use the following order for the topics:
- Deployment considerations
- HTTP changes that occur when using AppFirewall
- Application attacks and how AppFirewall protects against them
- Troubleshooting
While you can stand up a basic AppFirewall deployment quickly, things are far from plug and play and you shouldn't move to production without adequate testing. This topic discusses some of the considerations you should think about during your planning phase.
Deploying AppFirewall involves the following steps:
- Enabling AppFirewall.
- Creating an AppFirewall profile that specifies the protections that will be enabled.
- Creating a policy to narrow down what types of requests need to be scanned.
- Choosing a bind point to specify which VIPs will use these protections.
Creating a suitable profile and policy requires a thorough understanding of the application that you are protecting and the service that it is required to provide. Working with the developers of your applications is key to getting this configuration correct. Questions you should ask are:
- What kind of application am I trying to protect from malicious User input?
- The following points influence the profile type:
- Is it an HTML based application?
- Is it a Web service that typically involves XML?
- Is it a Web 2.0 application that contains a bit of both (for example, xhtml or REST-based services)?
- Do you need a basic profile or an advanced profile? Choosing basic or advanced changes the protections that are enabled by default. The protections that get enabled by default when choosing an advanced profile turn on a behavior called Sessionization. Sessionization introduces AppFirewall cookies and hidden form fields for tracking. The protections that turn on sessionization are:
- Start URL with URL closure
- Cookie consistency
- Form field consistency
- Cross site request forgery
So if you require these four protections, start with an advanced profile.
- Positive and negative security models. You need to consider whether you want to handcraft the protection for your applications or if you want to use signatures. In AppFirewall terms, handcrafting the protections you will apply by inspecting all possible valid User interactions and writing rules for them is known as using a positive security model. While this is a daunting task due to the number of combinations possible, the learning feature greatly alleviates the effort involved by silently monitoring and discovering requests that you can then commit at the click of a button.
Using signatures on the other hand is the negative security model. This model has the advantage of allowing you to benefit from a widely applied knowledge of past and current vulnerabilities. Also, getting the latest protection is as simple as clicking on the update version button from the GUI:
The source of these signatures is snort, which is a leading and trusted open source intrusion protection system. The recommended practice is to use a hybrid model where you apply specific rules you have learned but complement it by turning on signatures suitable for the Web application.