Lab 4.1 - Create a new policy using using a different template, assign it to an existing application and explore further policy details

This part of the lab shows you how to create a new policy with a different policy template, the RAPID policy template. Afterwards we assign the policy to an existing application and explore further policy configuration options.

Note: Importing a policy has a very similar work flow and you can directly import a “Full JSON” exported policy from BIG-IP Advanced WAF v16.0 and later but you need to make sure that it was exported in “Full JSON” from BIG-IP Advanced WAF.

Backend web apps available on the internal network running on the Ubuntu Jump Host:

• OWASP Juice Shop: 10.1.20.100, 10.1.20.101, 10.1.20.102, 10.1.20.103 on port 3000.
• Simple F5 demo web app 10.1.20.100, 10.1.20.101, 10.1.20.102, 10.1.20.103 on port 8080.

Create a new policy using the RAPID template

1. Create the new policy by following the video which shows the following steps

• Click the top left menu button
• Click on Security -> WAF -> Policies
• Click on “Create” to configure the “Policy Properties”
• Name the Policy custom_lab_policy
• Toggle the Advanced View
• Configure the “Policy Properties” as shown - Bot Defense/ Threat Campaigns / IP Intelligence Enabled
• Set the Enforcement mode to Blocking
• Select the RAPID-Template (NOTE: After selecting RAPID-Template, make sure you set the enforcement mode back to Blocking)

2. The policy should appear in the view and the “0” indicates that it is not assigned to an application yet

Assign the new policy to an existing application on BIG-IP Next Central Manager

1. Follow the video below showing the following steps

• Go to Applications -> My Application Services
• Select the juice_lab_app application
• Click “Edit” in the top right
• Under Security Policies, select “Edit”
• Choose “custom_lab_policy” from the top down menu
• Click “Save”
• Click “Review & Deploy”, “Deploy Changes”, and “Yes Deploy”

2. Go back to the Security -> WAF -> Policies Screen and you see that the “custom_lab_policy” is assigned to “1” application

3. Click on the “1” and you see that the “custom_lab_policy” is assigned to the “juice_lab_app” application

Explore the policy settings

1. Click on the “custom_lab_policy” you have just created before and let’s explore various settings.

Note: Please also compare the default policy settings from this “custom_lab_policy” with the “juice_lab_policy” you have created before in module 2. Both policies are for a different use case and therefore have different default settings as they are based on two different policy templates. In module 2 you have used the “Ratings-Based” template and in this lab module you used the “RAPID” template.

2. Click on “General Settings”

Here you can change generic policy settings including e.g. log illegal or all events.

3. Check out the default settings for “Evasion Techniques” and “HTTP Protocol Compliance”

4. Click on “Attack Signatures”

It shows you the details about the assigned Attack Signatures, Signature ID, Attack type, Accuracy, the number and also what signature(s) are enforced or in staging. In this policy, the signatures are all in staging.

Now we take all signatures out of staging and click on “Enforce” and “Enforce all Staged Signatures” to enforce them.

And you should finally see the status “Enforced”.

5. Click on “Signatures Sets”

You can see that the RAPID policy template includes by default the Generic Signatures set with high and medium accuracy signatures. This section also allows to change the Action for the Signature Set to “Alarm”, “Alarm & Block” or “Disabled”

Click on “Settings” to explore how to add further signatures sets.

6. Click on “IP Address Exceptions” to show the various settings for specific source IP addresses

Please explore the various settings to treat requests from specific source IPs differently. This setting can also be applied to multiple or all policies.

7. As next step click on “Policy Builder”

The Policy Builder works the same way as in BIG-IP Advanced WAF. Click “Settings” to explore the default settings from the RAPID policy template (e.g. “Learning Mode” is set to “Manual”), which means you can accept learning suggestions from the Policy Builder manually. Accepting “Learning Suggestions” manually can be done within the Policy Builder section but also in the “Events” Dashboard to solve false positives easily by just click on “Accept” for a specific event to modify the policy accordingly.

8. Click on Response Pages to explore the options to customize the “Response Body” and the “Response Headers”

You have seen already in module 3 how to modify the response code from 200 to 403 to signal the tool that the request was blocked because the tool in module 3 counts a 200 OK as not blocked. Another example where the response code needs to be changed is the use of a vulnerability scanner, because they interpret a 200 OK response code as not blocked too.

The AJAX Blocking page needs to be used if the client doesn’t accept HTML, which is in general the case e.g. for single page applications.

9. Data Guard, CSRF, Brute Force Protection is covered in more detail in module 6 and Bot Protection is covered in module 3 but of course feel free to click on it and explore the configuration options

10. Click on SSRF (Server-Side Request Forgery) and explore the configuration options

Note: SSRF is part of the OWASP Top 10 for web applications and SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination. As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.

In other words, a SSRF attack allows the attacker access to unauthorized resources using client side parameters containing server-side URIs or hosts. There are some default settings but to customize this feature, you need to identify the parameter that are subject to this attack, these are parameters of data type URI. Create the parameters (there is a wildcard by default though) and also create the specific hosts with the according action. You can use either IP addresses or host names for the “SSRF Host” entries. There is also an allow action in case this is the expected design for for specific hosts.

11. Click on “File Types”

Further modification to File Types are demonstrated in the short video below. Click on “Allowed File Types” and then on the “*” to enable “Response Signatures” checking. Finally click on “Save” and “Deploy”. As you can see, this section allows to configure various maximum length values for the “*” and specific file types.

12. Finally we will explore the config options for the other “Application Elements”

Click on “URLs” and the “*” to show the default settings for the wildcard URL

Click on “Headers” and “Methods*” to show the allowed methods for that policy and also check out the default “Cookies” settings. “Host Names” are configured in module 6.

Click on “Parameters” and the “*” to show the default settings for the wildcard parameter

13. Finally click on “Policy Editor” to show or edit the policy properties using the declarative JSON format. Several feautures which are currently not exposed in the GUI could be configured using this method.

Congratulations - You have finished Module 4