Realizing value from a WAF in front of your application - Part 1

For many years, I spent a lot of time evangelizing and educating customers and partners about the value proposition of the implementing strong and effective application security measures. One key recommendation always involves deploying a Web Application Firewall (WAF), and since F5 has a great marketing-leading WAF called BIG-IP Application Security Manager (ASM), much of my time has been spent explaining all the benefits and protections that it affords when deployed in front of the application.

Of course, application security is a complex topic, and one of the most frequently asked questions that I encounter is: “How long does it take for me to deploy a security policy in blocking mode to effectively protect my application?” There is no universal answer there, but after one such customer meeting recently, it motivated me to put myself in the customer shoes, deploy ASM in front of a publicly accessible application, and share my observations and results to help provide some real-world long-term observations.

I spun up a modern vulnerable application - Hackazon from Rapid7. But before I let the world loose at it, I needed to provide robust application protection to ensure it does not get hacked. So, I went in and deployed BIG-IP ASM in front of the application and configured a security policy in blocking mode. How long did it take me? A total of 15 minutes!

Now, you may say to me that it’s not true or fair. After all, I have many years of experience working with F5 products and focusing on application security. And while it is all true, we have made deploying a baseline security policy very easy and effective over all these years (thanks to F5 Product Development team!). And my goal is to walk in your shoes as much as possible here, I’m simply following the shortest and the most effective process that has been proven over many years - and what I did is a great start that I recommend you begin with.

First to be fair, my 15 minutes I mentioned above did not include provisioning and installing F5 BIG-IP device or virtual edition from scratch. In here, I am making some assumption that BIG-IP Local Traffic Manager is already up and running - a part that is often handled by network folks anyway - and the focus is to get the WAF piece turned on and deployed. After BIG-IP LTM was all setup to pass traffic to the application, I went ahead and created a security policy based on the Rapid Deployment Policy template that we have been using as the launchpad for most application security deployments for many years.

By default, the Rapid Deployment security policy includes the following security checks:

• Performs HTTP compliance checks
• Checks for mandatory HTTP headers
• Stops information leakage
• Prevents illegal HTTP methods from being used in a request
• Checks response codes
• Enforces cookie RFC compliance
• Applies attack signatures to requests (and responses, if applying signatures to responses)
• Detects evasion technique
• Prevents access from disallowed geolocations
• Prevents access from disallowed users, sessions, and IP addresses
• Checks whether request length exceeds defined buffer size
• Detects disallowed file upload content
• Checks for characters that failed to convert
• Looks for requests with modified ASM™ cookies

While it’s all great, I used my knowledge and experience to add two small tweaks to the policy. First, I enabled IP Intelligence-based blocking.

What it means is that any request to access this application from an IP address that is classified under any of the malicious categories, the security policy will block it - period. This helps stop any type of traffic - explicit hacks or seemingly benign probes from the known bad actors. Known bad actors comprise a good percentage of hacking attempts, and eliminating these requests via this simple enhancement to the Rapid Deployment Policy is very effective low-hanging fruit.

After making this change, I put the policy in blocking mode and opened up the application to the Internet (in blocking mode).

In a matter of a couple hours, I got a couple of Illegal Request in my logs:

 

As you can see from the very first request at the bottom, someone was probing me to see if the backend is Asterisk A2Billing Softswitch. My policy blocked this request (which by itself wasn’t malicious) - great! Another request, right above it, was also blocked because it was sourced from a malicious IP address. I was happy. But looking at the first violation jotted my memory about the need to make yet another tweak to the policy. If you look at the arrow pointing to the hostname header in the screenshot above, you will see that the request used IP address as the Host header. Using IP addresses as Host headers is not part of normal access to the web applications, especially in the SSL world, as you cannot issue an SSL cert to an IP address. As such, it’s safe to say that any request to an SSL-enabled application that uses IP address in the Host header is likely to be malicious. The bad guys don’t know the full URL/domain name that the application uses - so they are forced to put the destination IP in the HTTP Host header to make a connection - and that’s a dead giveaway.

This led me to make a second tweak to the policy. I enabled blocking for the violation where the Host header contains an IP address:

 

Now, any request, no matter which IP address a request originates from, gets blocked by ASM if the Host header contains an IP address.

Why is this very important? Imagine a breakout of a 0-day vulnerability that affects a particular backend server infrastructure you’re using. For me, my application is running on Apache, so a good example might be to discuss Apache Struts vulnerability. As soon as 0-day vulnerability is in the wild and starts spreading, hackings tools are targeting IP addresses, as most do not target/know the proper Hostname of the application they’re probing/trying to hack. Thus, any request that either does not have a Host header or has one with IP address in it won’t reach your server, and you are instantly protected against such 0-day breaches unless the hackers start targeting you specifically. How’s that for easy and seamless protection against 0-day attacks?

In summary, I deployed a pretty robust and effective security policy in front of my application in about 15 minutes, and now I am can sit back and watch the logs to visualize the value of the security policy that I just implemented. Stay tuned for more articles as I explore more details about observations on the longer-term effectiveness of this protection and and discuss additional simple tuning and enhancements to the security policy to make it even more effective in securing the application behind it.