Managing NGINX App Protect WAF for Beginners

F5 NGINX App Protect WAF brings much of the tried-and-true capabilities of the F5 BIG-IP Advanced WAF to the DevOps environment, which demand performance without compromising on delivery velocity. However, as security capabilities like a WAF are traditionally handled by dedicated security teams, DevOps and application teams may find themselves out of their comfort zone when it comes to securing their applications. Having deployed NGINX App Protect WAF with <insert your favourite CI/CD tooling> in your environment, you may find yourself asking "what next?" 

Figure 1: NGINX App Protect WAF and DoS security solution deployment options

NGINX App Protect is a modern app security solution that works seamlessly in DevOps environments and is available as a robust WAF or as a DoS product for app layer defense. Each can be deployed on NGINX Plus in the image shown above. For the purpose of this article, we will be focusing on the WAF product. In this post, I will provide some basic steps to help you get started with operating your NGINX App Protect WAF.

Some mitigation is better than none

Application security is a complex field, just take a look at the security features supported by NGINX App Protect WAF. It is easy to be overwhelmed by the sheer amount of security jargons, let alone identifying the features relevant for your application, leading to a case of analysis paralysis.

Simplifying a lot of this jargon into intent-based policies is a big focus at F5. Instead of talking about signatures that detect malicious traffic based on certain patterns, it could be as simple as saying

• "I don't want untrusted or malicious bots accessing my application", or
• "Sign me up for F5 Threat Campaigns to deal with what's in the wild now"

Some form of mitigation is better than none, so start with simple policies, shown here, to deal with a large amount of unwanted traffic from the Internet. With time, the WAF policy can be tuned based on learnings from the information provided by NGINX App Protect WAF. 

If there are concerns about the WAF unintentionally blocking legitimate traffic and creating a negative experience for your users, configure the policy to be in transparent mode instead of blocking. 

Making sense of the information

With a good amount of security coverage now enabled for your application, let us shift our focus to the information that NGINX App Protect WAF provides to you.

NGINX App Protect WAF conveys security events in the form of logs rich with information, which can be exported via syslog to external logging and monitoring platforms such as an ELK stack, Splunk, or Grafana. These platforms provide powerful search capabilities which enables easier consumption of security events, simplifying some of the day 2 activities - a couple of which are covered in the next section. If anything, they show how much unwanted traffic are trying to access your applications, but are blocked by NGINX App Protect WAF!

For those interested in having high level information immediately, you can also use the information to build dashboards such as the ones here:

• https://github.com/f5devcentral/f5-waf-elk-dashboards
• https://github.com/skenderidis/nap-dashboard

Day 2 and onwards

With NGINX App Protect WAF up and running, much of the operational activities will involve keeping the NGINX App Protect WAF attack signatures updated, which can be easily automated.

Tuning the WAF policy is also a major part of managing NGINX App Protect WAF. A common trigger for WAF tuning is the discovery of a new exploit affecting your applications. In such cases, look up "NGINX App Protect" and the name of the exploit online, and you should find mitigation steps provided by F5. One example is this article on how to Mitigate the Apache Log4j2 vulnerability with NGINX Application Security products. 

Another trigger would be when you start seeing support tickets from your users containing messages as below, indicating that they have been blocked by NGINX App Protect WAF.

Image 1: A support ticket message from NGINX App Protect WAF that provides a Support ID which can be used to obtain further insights.

For this, look up the support ID in the NGINX App Protect WAF security logs (this is where the use of ELK, Splunk and Grafana come in handy), and review the corresponding log entry which contains information on the user request and the reason the request was blocked. 

 

Image 2: A screenshot of log entries displayed from a Kibana dashboard.

If a request is deemed incorrectly blocked by NGINX App Protect WAF, it is known as a false positive, which can often happen when a WAF is first deployed, or changes are recently made to the application, introducing new behaviours previously not considered when defining the WAF policy. The WAF policy can then be updated to disregard the corresponding signatures or violations, allowing your users to access your application once again.

As you get more comfortable with NGINX App Protect WAF, there are other areas of improvement that can be explored, such as implementing WAF policy as code for easier CI/CD pipeline integration, or analyzing the information provided by NGINX App Protect WAF to understand the attack surfaces on your applications, enabling you to focus your security efforts where it counts.

Closing

Hopefully, the information above gives you a better perspective of what is involved in managing NGINX App Protect WAF. In closing, the goal of NGINX App Protect WAF is to secure your application with minimal effort, and have you focus your efforts on delivering business value through your application instead.