Adding a WAF to your application can help protect against numerous threats including injections, cross-site scripting, ddos, etc. With Avi, the process to add the WAF protection is quite simple, and in this first blog post about the WAF, we’ll just demonstrate configuring the WAF on a virtual service.
To learn more about what a WAF can do, check out the Avi WAF Page.
For a more detailed overview, see the full Avi WAF Solutions guide.
In this blog we’ll keep it simple with the following tasks.
- Apply the WAF Policy to the hackazon application.
- Inspect the WAF Policy
- Test a vulnerability and see if it is blocked
Table of Contents
Software Versions used in this demo
|Avi Controller & Service Engines
So for this blog, I’ve setup an Avi controller and connected to the vCenter environment. Additionally I’ve created a single virtual service pointing to a single backend server, my hackazon application. Why hackazon application? Well it is a simple to deploy and highly vulnerable application, perfect for testing application security.
View of the virtual service above, showing Green. Which indicates that the health check on the pool is up and working, and there are service engines deployed in vCenter to load balance the application.
Green shows the server is passing the health check.
Navigate to Applications -> Virtual Service and click edit on the virtual as shown below.
In the field “WAF Policy” select the “System-WAF-Policy”. Best practice is to create a new profile instead of using system default profiles, but for this example we can use this policy.
Click Save on the virtual service.
You can see the application now has a little circle with a shield around the health score. This indicates that the application is now protected by the WAF.
Inspect the WAF Policy
Waf Policy Features
It was incredibly easy to protect the application by applying the WAF Policy, but what did applying that policy to the virtual service actually do? Let’s inspect the WAF Policy and learn more about the default settings.
Navigate to Templates -> WAF -> WAF Policy
Click edit on the System-WAF-Policy. You’ll see there are MANY different knobs that you can modify and fine tune for your applications.
In the image above I have highlighted 2 sections, the WAF Profile and the Policy Mode.
The WAF Profile is attached to the WAF Policy and is designed to be shared and reused across multiple applications of the same type. We’ll cover some of the elements of the WAF Profile here in a moment.
Policy Mode can be set to either Detection or Enforcement. When set to Detection, the WAF will not block any attacks, it will simply alert on them. When set to enforcement, the WAF will start blocking the bad traffic, as per the WAF Policy/Profile settings.
So for now, let’s leave them as default and keep on exploring the WAF Policy.
Learning Mode allows Avi to “learn” about your application via good known traffic and build positive security rules around the known good behavior of the application.
Allow List is essentially a white list. Very useful if you have security scanners or internal traffic that you would like to bypass the WAF.
We talked about Positive Security earlier, but the idea with positive security is that everything by default will be blocked, except what is allowed via the positive security rules.
Application Rules are a cloud connected feature (not available in the offline version of Avi, since it requires updates as the application changes). The App rules allow you to apply specifically tailored rulesets to your applications. There’s 100s of preconfigured applications available, including Microsoft, Oracle, etc.
Signatures can be run before or after the OWASP ModSecurity Core Rule Set (CRS) signatures are run. These signatures are basically a set of rules that are run against the incoming data, and if they match the signature of a particular attack, then some action can be taken. So create a log/alert if in Detection mode, or block the traffic if in Enforcement mode.
That’s the high level on the various components of the WAF Policy. Let’s take a look at the WAF Profile
The WAF Profile provides additionally functionality of the WAF, specifically tailored to your application. I won’t cover all the different available settings in the waf profile (because there is a ton, and already really good documentation on this.) Waf Profile Extra Reading
I normally don’t modify anything in the WAF profile, I just use it as is. Then again, I mostly do labs and demos.
Test a vulnerability and see if it is blocked
We’ll perform 2 tests. The first test with the WAF in the default state of Detection mode. And again, with Enforcement mode enabled.
Let’s look closer at what we can see in Avi.
Navigate to the virtual service “vs-1”
Applications -> Virtual Services -> vs-1 -> Logs
The transaction was logged and flagged by the WAF, however it was not blocked.
And on the WAF tab, we can see the following information about the registered attack. The CRS group, and particular rule that was triggered by this attack.
Let’s set the WAF policy to enforcement mode, and retest that XSS attack.
Navigate to Templates -> WAF -> WAF Policy and click edit on the System-WAF-Policy
Change the policy mode to Enforcement, and Save.
You can also create custom Error pages…
Below are the logs for the hackazon application and you can see that the malicious transactions were REJECTED, and blocked.
On the WAF dashboard below you can see we finally have some movement on the chart as well as all the recorded WAF hits.
As you can see it is easy to protect your applications with the Avi WAF. The WAF is very powerful out of the box, and yet there is so much more you can do with it. This blog post just touches the surface.
I’ll try and include a series about Application security going forward, and add more posts about protecting your applications.