This lesson will help you create your first security policy in F5 Advanced WAF (AWAF). It covers important concepts and terminologies you need to know to create a security policy, such as security templates, enforcement mode, learning mode and signature staging.
You’ll also learn how to assign a security policy to a web application.
Table of Contents
F5 AWAF Security Policy Components
Just to remember, we have already configured two vulnerable web applications “Hack-it-Yourself” and “DVWA” that are accessible via F5 LTM virtual server through the names „auction.f5demo.com“ and „dvwa.f5demo.com“.
F5 AWAF Lab Preparation Part 1 _ Setting Up DVWA for Security Testing
F5 AWAF Lab Preparation Part 2 _ Prepare Hack-It-Yourself PHP Auction
Create Security Policy
Now we will protect web applications by creating the first security policy. In the section “Security > Application Security > Security Policies > Policy List”, we can create a new security policy.
There are a few options you need to understand when configuring a security policy. Now I will give you a basic understanding, but as the course progresses you will learn these concepts in more depth, even if you don’t want to learn them.
- Policy Name:
We will call it “DVWA_security_Policy” since I will be assigning it to the DVWA web application.
- Policy Type:
During the course we always choose the default option “Security”, in a specific lesson we will discuss the other option “Parent”.
- Policy Template:
There are pre-configured security settings for different purposes and applications, making it easier to start with a template instead of creating a security policy from the start.
Some of the security templates are application specific templates, such as sharepoint, which is clear how to use them. But between generic templates, “Rapid Deployment”, “Fundamental” and “Comprehensive” are more commonly used.
The template Rapid Deployment is designed for quick setup and is ideal for beginning users. It creates a basic security policy that does not block any violation initially, allowing you to review and fine-tune the policy over time.
The template Fundamental provides enhanced security by actively blocking violations during the policy building process. It requires more time to fine-tune compared to the Rapid Deployment template and is aimed at intermediate users.
And finally Comprehensive Template offers maximum security by turning on all violations, features, and learning capabilities. It’s intended to provide the highest level of security enforcement and is recommended for expert users.
- Logging Profile:
You can decide whether to log all web application requests or just violations. In a special lesson you will learn how to configure to log all requests and responses. Now I configure to log only web application requests.
Application Language:
Specifies the primary language used by the web application. Configuring this setting is important for WAF to understand the application’s character sets and language-specific attributes. usually we configure Unicode (utf-8).
Enforcement Mode:
This is how the AWAF stops malicious traffic from hurting your web app.
In “transparent” mode, the system logs violations but does not block them. This mode is suitable for monitoring and fine-tuning the security policy in the initial days without affecting legitimate traffic.
In “blocking” mode, the system actively blocks requests that cause violations. For the first policy, I configure it as “blocking”.
Learning Mode:
The AWAF learns from the traffic or administrator to get smarter at protecting web application.
In manual learning mode, the system provides suggestions based on traffic that does not conform to the current policy, which may actually be an attack or a false positive. You can review these suggestions and decide whether to accept them if they are false positives or do nothing since they are actually attacks. Accepting suggestions is an important keyword that we will use frequently throughout the course.
In automatic learning mode, the system takes over a large part of the learning process for you and update the policy automatically. The system accepts learning suggestions based on traffic frequency. In other words, if a certain type of traffic occurs frequently and comes from different sources, it is usually reliable and achieves a certain learning score.
However, there might be some suggestions that, despite reaching the necessary score, still require manual review and acceptance due to their potential impact on the application’s functionality or security.
Note that you can still accept suggestions manually in automatic learning mode.
In fully automatic learning mode, system accepts all learning suggestions that reach a score of 100, even those that normally require manual acceptance.
Signature Accuracy:
Refers to the ability of an attack signature to correctly identify an attack, with a focus on minimizing false positives The value “high” means minimal false positives and “low” means maximum security but with more false positive. For the first security policy I choose the „low“ value.
Signature Staging:
During the staging period, which is seven days by default, the system applies the attack signatures to the web application traffic, but does not block traffic matching the signature. Instead, learning suggestions are generated that you can accept, meaning it is a false positive and the traffic is not an actual violation.
After the learning or staging period, signature staging is disabled, and all traffic that matches the signature will be blocked. For the first security policy, I disable signature staging.
Server technologies:
Refers to the technologies used in web applications that can be automatically detected by F5 AWAF module. But by specifying the technologies used in the web application, you can help F5 AWAF apply only the associated signatures to traffic and minimize the likelihood of false positives.
Web applications “Hack-it-yourself” and “DVWA” are based on PHP/MySQL, Apache web server and Linux operating system,
Note that to block traffic that matches a signature, the “enforcement mode must be set to Blocking” AND “signature staging must also be disabled”, otherwise the traffic will not be blocked. It is exactly what we configured in the first security policy.
apply security policy to web application
After you create a security policy, you must apply it to the web application so that the web application can be protected by the security policy.
In the section „Local Traffic > Virtual Servers > Virtual Server List“, select the virtual server associated with the web application you want to protect. Then you need to enable the “Application Security Policy” in the “Security” tab and apply the security policy that you have configured.
It is also recommended to apply “Log Profile” to the web application to enable logging of traffic. We select “Log all requests”. Later in a dedicated lesson, you’ll learn how to create a log profile to log all requests and responses.
Test and Monitor the effect of security policy
To verify the operation of security policy, I send a simple SQL injection attack and expect F5 AWAF to block the traffic since I have set enforcement mode to blocking and also disabled signature staging.
In the DVWA web application, in the SQL Injection section, I attack with a simple SQL injection command, “%’ or 1=’1” as we discussed in the previous lesson.
As expected, traffic is blocked.
In the section “Security > Event Logs > Application::Request“, you can review the blocking log and traffic details, as well as the appropriate signature.
The log shows that the traffic is blocked because it matches the SQL injection signature. You can also see the details of traffic.
As shown in the output, there is a learning suggestion about this violation that you can accept if the traffic was not really a violation. But it will be discussed in the coming lessons.
