Lab 2: Additional Security - Bot Defense and WAF

The API protection profile provides authorization and basic WAF policy to protect an API. This module will demonstrate how to layer on additional protections to further validate what is accessing the API and that the client is behaving within the norms of the API.

Section 2.1 - Setup Lab Environment

By default, security events are not logged, in this lab the student will create a security logging profile with Application Security, Bot Defense and DOS Protection enabled. The student will also place the waf policy in trasnparent to show the difference in behavior when client traffic that is deemed malicious is and is not blocked.

Task 1 - Import Postman Collection

1. From the Jumpbox, open Postman via the desktop shortcut or toolbar at the bottom

   

2. Click Yes if prompted for “Do you want to allow this app to make changes to your device?”

   

3. Click Import located on the top left of the Postman application

   

4. Click Upload Files

   

5. Navigate to C:\access-labs\class3\module4\student_files, select student-class3-module4-lab02.postman_collection.json, and click Open

   

6. Click Import

   

7. A collection called student-class3-module4-lab02 will appear on the left side in Postman

Task 2 - Add Vulnerable API

Note

Ensure you are logged into BIGIP1

1. From the web browser, navigate to Access >> API Protection >> Profile. Click Profile to modify the existing profile api-protection Profile (not the + Plus symbol)

   

2. Click Edit Under Per-Request Policy

   

3. Click the + (Plus Symbol) located between Start and OAuth Scope Check AuthZ

   

4. Select the Classification tab

5. Select Request Classification

6. Click Add Item

   

7. Select Branch Rules

8. Click Add Branch Rule

9. Enter name GET /vulnerable

10. Click Change

    

11. Click Add Expression

    

12. Select Request from the Context dropdown

13. Click Add Expression

    

14. Click Add Expression on the AND line

    

15. Select Path (value) from the Request dropdown

16. Enter /vulnerable in the empty text box

17. Click Add Expression

    

18. Click Finished

    

19. Click Save

    

20. Click the + Plus Symbol on the GET /vulnerable branch

    

21. Click API Server Selection

22. Click Add Item

    

23. Select api-protection_server1 from the dropdown

24. Click Save

    

25. Click the Reject terminal at the end of API Server Selection

    

26. Select Allow

27. Click Save

    

28. The completed policy should look like the below.

    

Section 2.2 - Create and Assign Profiles

Task 1 - Create and assign a Security Logging Profile to the virtual

1. From the web browser, click on the Security -> Event Logs -> Logging Profile and click Create.

2. For the Profile Name enter api.acme.com_logprofile.

   

3. Enable Application Security, an Application Security configuration menu will open up at the bottom. Change the Request Type from Illegal requests only to All requests.

   

4. Enable DoS Protection, a DoS Protection configuration menu will open up at the bottom. Enable Local Publisher

   

5. Enable Bot Defense, a Bot Defense configuration menu will open up at the bottom. Enable Local Publisher and all other checkboxes, leave Remote Publisher set to none.

   

6. Click Create

7. Apply the log profile to the api.acme.com virtual by navigating to Local Traffic -> Virtual Servers -> api.acme.com -> Security -> Policies and after choosing “Enabled” from the dropdown, set the Selected Log Profile to api.acme.com_logprofile.

   

8. Click Update. The virtual will now log Application Security, DoS and Bot related events under Security -> Event Logs when an appropriate security profiles have been applied to the virtual.

Task 2 - Set the WAF policy to Transparent and assign it to the virtual

1. From the web browser, click on the Security -> Application Security -> Security Policies -> Policies List. Click api-protection. Scroll down and you’ll notice the Enforcement Mode is set to Blocking. Set the Enforcement Mode to Transparent. Be sure to click Save, then Apply Policy.

   

2. Apply the waf policy to the api.acme.com virtual by navigating to Local Traffic -> Virtual Servers -> api.acme.com -> Security -> Policies and set the Application Security Policy to enabled and the Policy to api-protection.

   

3. Click Update.

Task 3 - Create and assign a Bot Defense Profile

An api’s clients, unlike a typical web application, will often be non-human, maybe even exclusively. This leaves bot defense more difficult to configure in an api protection scenario, for instance javascript such as captcha cannot be used to proactively determine whether the client is human. In this lab, we demonstrate some scenarios the admin may encounter and how to address them.

Note

Ensure you are logged into BIGIP1

1. From the web browser, click on the Security -> Bot Defense -> Bot Defense Profiles and click Create.

2. For the name enter api.acme.com_botprofile, leave all other settings at their defaults.

   

3. Click Save

   The bot profile is left in transparent mode to demonstrate the logging behavior and behavior differences to the client.

4. Apply the bot profile to the api.acme.com virtual by navigating to Local Traffic -> Virtual Servers -> api.acme.com -> Security -> Policies.

For Bot Defense Profile select Enabled and select api.acme.com_botprofile as the Profile. Click Update.

Section 2.3 - Test Bot Protection

Task 1 - Test Bot Protection in Transparent Mode

1. Now we will test the Bot Defense Profile to see how it affects clients. Go to Postman, expand the collection student-class3-module4-lab02 and select the request Request 1: Retrieve Attributes and click Send.

2. Return to the bigip01 gui and navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the request to the /vulnerable uri as shown below

   

   Note

   The student should pay special attention to the Request Status, Mitigation Action and Bot Class. Bot Class will be one of the categories found in Security -> Bot Defense -> Bot Defense Profiles -> api.acme.com_botprofile -> Bot Mitigation Settings under Mitigation Settings.

Task 2 - Place Bot Profile in blocking and allow appropriate clients

The bot profile was left in transparent to demonstrate the behavior, now we will configure the bot profile to block bot traffic. Keep in mind that the bot profile allows for fine-grained control of categories of bots, which bot fits in those categories. We will explore this later.

1. Navigate back to Security -> Bot Defense -> Bot Defense Profiles -> api.acme.com_botprofile, change the Enforcement Mode to Blocking and click Save.

   

2. Go back to Postman once again and select the request Request 1: Retrieve Attributes and click Send another time.

3. Return to the bigip01 gui and navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the 2nd request to the /vulnerable uri as shown below

Note

Why was this request not blocked? To understand this, we must take a closer look at the Mitigation Settings.

1. Navigate to Security -> Bot Defense -> Bot Defense Profiles -> api.acme.com_botprofile -> Bot Mitigation Settings and examine the Unknown categorization, note that bots that are of category Unknown are simply rate limited.

   

2. Go back to Postman once again, click on the three dots* in the right corner of the collection **student-class3-module4-lab02 collection to open Runner.

3. Click Run Collection

   

4. Configure Runner so iterations is set to 100 and the only request selected is Request 1: Retrieve Attributes.

5. Click Run student-class3-module4-la….

   

6. Notice all responses are 200 OKs.

   

7. Return to the bigip01 gui and navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the Denied request to the /vulnerable uri as shown below.

   

8. We will recategorize the Postman client so that it is a trusted client, this is done via bot signatures. Navigate to Security -> Bot Defense -> Bot Signatures -> Bot Signatures Categories List and click Create.

9. Fill in the Bot Signature Category Name of Trusted Development Tools and select Trusted Bot from the Bot Class dropdown.

   

10. Navigate to Security -> Bot Defense -> Bot Signatures -> Bot Signatures List and click Create.

    

11. Fill in the Bot Name, Bot Category and Rule (User Agent) with the following, leaving all other values at their defaults.

    

12. Click Save.

13. Go back to Postman once again and select the request Request 1: Retrieve Attributes and click Send another time. Note this is done at the main Postman window, not in Runner.

14. Navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the Trusted Bot categorized request to the /vulnerable uri as shown below

    

Section 2.4 - Layer on WAF to provide additional security

APIs are a collection of technologies just like any other application, in the lab the api is built on top of a windows server using powershell. This lab demonstrate how to tune the WAF policy to use attack signatures and meta-character enforcement to provide additional protection against malicious clients.

Meta-character enforcement allows the WAF admin to enforce which characters are allowed into a web application, whether it be in the header, url or parameter. In this lab we examine parameter meta-character enforcement.

Task 1 - Configure Attack Signatures and Change WAF Policy to Blocking

1. Open a command prompt on the jumphost (a shortcut is on the desktop)

   

2. Run the following command curl -k “https://api.acme.com/vulnerable?Inject=|powershell%20badprogram.ps1” -v

   Note

   Pay special attention to the double quotes (“”) around the url.

3. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request. Locate the parameter value |powershell badprogram.ps1. Click the parameter and then hover over the parameter value and additional details will describe this part of the attack.

   

   Note

   The Enforcement Action is None

   The F5 WAF highlights the part of the request it detects as malicious based on the policy’s configuration. This can be very useful for learning and troubleshooting purposes.

4. Next hover over the User-Agent portion of the request.

   

   Notice the user-agent is curl, which may be a legitimate client. Make note of this.

   Ideally we want to block any malicious request, in this case the powershell execution attempt, but want to allow curl as it’s a legitimate client in our case. What about the %20 meta character, should it be allowed? Depending on the application, this could be legitimate.

   In your environment, you must decide what is legitimate and what is illegitimate traffic, the F5 WAF can guide you via learning and help eliminate noise using Bot Defense, however to increase security beyond a basic WAF policy, understanding the application is needed.

5. Click on the Security -> Application Security -> Policy Building -> Learning and Blocking Settings -> Attack Signatures and click Change

   

6. Enable Command Execution Signatures and click Change

   

7. Scroll to the bottom anc click Save.

   

8. Navigate to Security -> Application Security -> Security Policies -> Policies List.

9. Click api-protection

10. Click Attack Signatures

11. Click the filter icon to easily locate the Automated client access “curl” signature.

    

12. For the Attack Signature Name enter Automated client access “curl” and click Apply Filter.

    

    The result is

    

13. Select this signature and click Disable

    

14. Click General Settings and scroll down to “Enforcement Mode” and change it to “Blocking.” Click Save and then Apply the Policy

    

15. Once again run the following command curl -k “https://api.acme.com/vulnerable?Inject=|powershell%20badprogram.ps1” -v

    Pay special attention to the double quotes (“”) around the url.

16. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request.

    

    Notice the enforcement action is still None but also notice the user-agent curl is no longer highlighted (since the signature was disabled). We changed the Policy to Blocking so why wasn’t the request blocked? Hint: Click the “1” under Occurrences and you’ll see the current status of the Attack Signature.

17. Hover over the highlighted payload and notice that the powershell attack signature is triggered.

    

    Powershell execution via http parameters is now mitigated. If you noticed in the request, that the | is considered illegal. What if that character was a legitimate value for a parameter?

    

18. Go back to the command prompt on the jumphost and run

    curl -k “https://api.acme.com/vulnerable?param1=|legitimate%20value” -v

19. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request. Notice the | is considered illegal. However its not blocked, the Enforcement Action is None

    

20. To see why this parameter character violation is not being blocked, but is being logged (alarmed). Navigate to Security -> Application Security -> Policy Building -> Learning and Blocking Settings -> Parameters and enable the Block column for the Illegal meta character in value under the Parameters Section

    

21. Click Save then Apply Policy

22. Go back to the command prompt on the jumphost and run

    curl -k “https://api.acme.com/vulnerable?param1=|legitimate%20value” -v

23. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request. Notice the | is considered illegal and is now blocked.

    

Task 2 - Implement Static Parameter values

1. From Postman, click Send on the Request 2: SSRF Attack-Google request.

   

2. From Postman, run Request 3: SSRF Attack-unprotected-json. This site contains an example ID and Secret key in JSON format. You can now see the endpoint is vulnerable to Server Side Request Forgery attacks because the endpoint can be directed to locations other than Google. Hackers will uses your servers as a jump off point to gain access to internal resources.

   

3. Navigate to Security -> Event Logs -> Application -> Requests and find both requests. Notice nothing appears malicious about these requests except for the destinations.

   

4. We are going to secure the the uri parameter, so it only allows access to Google, but not access to the internal private data.

5. Navigate to Security -> Application Security -> Parameters -> Parameters List. Click the + Plus Symbol

   

6. Enter the Name uri

7. Uncheck Perform Staging

8. From the Parameter Value Type dropdown select Static Content Value

9. Enter https://www.google.com for the New Static Value

10. Click Add

11. Click Create

    

12. Click Apply Policy

13. From Postman, run Request 2: SSRF Attack-Google. Access to Google is still allowed.

14. From Post, run Request 3: SSRF Attack-unprotected-json. This site is now blocked as intended

    

15. Navigate to Security -> Event Logs -> Application -> Requests and find the latest blocked request. The uri parameter is highlighted due to Illegal Static Parameter Value.