Lab 3: Zero Day Exploit Response with Rate Limiting and Custom Service Policies

Objective:

• Protect against a Zero Day Exploit using Rate Limiting

• Build Custom Service Policies

Narrative:

You’ve been called into an all-hands incident response conference call. There is a zero-day exploit specifically targeting one of ACME Corp’s application. The attacks are coming from multiple IP addresses that are dynamically changin so a simple IP shun will not be effective. The attacks are compomising the application as valid users are getting poor performance as your application infrastructure is being overloaded.

After reviewing the data, the application team has asked if you can deploy Rate Limiting to help ACME Corp limit the load that each individual user can request. Based on the discoveries made, there are two rate limiting rules that need to configured.

• HTTP POST requests to the login page

• HTTP GET requests to the rate-limit page.

The application team would like all other requests to be allowed without any rate-limiting. You leave the all-hands call to focus on the F5 Distributed Cloud configurations while the team members investigate the underlying nature of the exploit.

Expected Lab Time: 30 minutes

Task 1: Establishing a Baseline

In this task you will access a test website/webpage to experience access without a Rate Limiting Policy engaged. This will demonstrate that any user can request data from the application without limits.

1. In your web browser, enable Developer Tools and browse to the ACME Corp application. Chrome is shown in this example (F12)

   https://<namespace>.lab-sec.f5demos.com/ratelimit.php

2. Refresh the page multiple times and notice you do not receive any errors nor blocked messages. The browser’s developer tool will display multiple HTTP 200 OK responses. Let’s change that behavior.

   

Task 2: Creating a Rate Limiting Policy

In this task you will add a Rate Limiting Policy to the application Load Balancer previously created. Rate Limiting can be used to implement a variety of L7 security controls; assisting in L7 DDoS, protecting heavy URLs (service process impactful) or mitigating impacts to other controlled endpoints. This will help alleviate the strain on the application infrastructure by limiting the number of requests each client can make while ACME corp works to protect itself from the zero-day.

1. Return to the Web App & API Protection configuration window. In the left-hand navigation, expand Manage and click Load Balancers > HTTP Load Balancers.

2. Use the Action Dots and click Manage Configuration

3. Click Common Security Controls in the left-hand menu and Edit Configuration in the top right-hand corner.

   

   

4. Click the dropdown for Rate Limiting and select Custom Rate Limiting Parameters.

5. In the expanded Custom Rate Limiting Parameters click the View Configuration Link.

   

   

6. In the resulting Rate Limit Configuration window, in the Request Rate Limiter section set the following values as shown:

   • Number: 3

   • Per Period: Minute

   • Burst Multiplier: 1

7. Click the drop-down for Rate Limiter Policies and select Rate Limiter Policies.

   

8. In the new row for Rate Limiter Policies, click the dropdown an then select Add Item from the list as shown.

   

9. In the Rate Limiter Policy window, enter rate-limit in the Name field in Metadata section and then click Configure within the Rules section.

10. In the resulting Rules window, click Add Item.

    

    

11. In the Rate Limiter Policy window within the Metadata section input rate-limit-auth into the Name field.

12. Using the Actions drop-down select, Apply Rate Limiter.

13. In the left-hand navigation, click on Request Match.

    

14. In the Request Match section and select the Configure link in the HTTP Method section as shown.

15. In the resulting HTTP Method window under Method List, select POST then click Apply.

    

    

16. Observe that HTTP Method now appears Configured.

17. Further down in the Request Match section, select the Configure link in the HTTP Path section as shown.

18. Observe the various Path definition options, click Add Item in the Prefix Values section the input /auth.php as shown and then click Apply.

    

    

19. Observe that HTTP Path now also appears Configured. Click Apply on the Rate Limiter Policy window.

20. Observe the rate limit rule just created and click Add Item to build another rule.

    

    

21. In the Rate Limiter Policy window within the Metadata section input rate-limit-page into the Name field.

22. Using the Actions drop-down select, Apply Rate Limiter.

23. In the left-hand navigation, click on Request Match.

    

24. In the Request Match section and select the Configure link in the HTTP Method section as shown.

25. In the resulting HTTP Method window under Method List, select GET then click Apply.

    

    

26. Observe that HTTP Method now appears Configured.

27. Further down in the Request Match section, select the Configure link in the HTTP Path section as shown.

28. Observe the various Path definition options, click Add Item in the Prefix Values section the input /ratelimit.php as shown and then click Apply.

    

    

29. Observe that HTTP Path now also appears Configured. Click Apply on the Rate Limiter Policy window.

    

    

30. Observe the added rate limit rule and click Add Item to build another rule.

31. In the Rate Limiter Policy window within the Metadata section input bypass into the Name field

32. Using the Actions drop-down, select Bypass Rate Limiter.

33. In the left-hand navigation, click on Request Match.

    

34. In the Request Match section, select the Configure link in the HTTP Method section as shown.

35. In the resulting HTTP Method window under Method List, select ANY then click Apply.

    

    

36. Observe that HTTP Method now appears Configured.

37. Further down in the Request Match section, select the Configure link in the HTTP Path section as shown.

38. Observe the various Path definition options, click Add Item in the Prefix Values section the input / as shown and then click Apply.

    

    

39. Observe that HTTP Path now also appears Configured. Click Apply on the Rate Limiter Policy window.

40. Observe the three created rate limit rules and click Apply.

    

    

41. Observe that rules are now Configured. Complete the custom Rate Limiter Policy by clicking Continue.

    

42. Observe the Request Rate Limiter options for number of requests, the Per Period interval and the Burst Multiplier.

43. Also observe that IPs can be allowed without Rate Limiting policies being applied. In the lab “No IP Allowed” is selected. This ensures that rate limiting will be applied to all IP addresses that make requests.

44. Click Apply to add the Rate Limit Configuration to the application Load Balancer.

    Note

    Although only one policy is being added, multiple Rate Limit policies can be attached.

    

45. Observe that the Custom Rate Limiting Parameters now show Configured and then click on Other Settings in the left-hand navigation.

46. Once at the bottom of the HTTP Load Balancer configuration, click Save and Exit.

    

    

Task 3: Testing Rate Limiting

Now we will retest access to our website and see if our experience has indeed changed.

1. In your local web browser access the following link, replacing namespace with your own:

   https://<namespace>.lab-sec.f5demos.com/ratelimit.php

2. Refresh the page multiple times and quickly… did you experience a different result? Rate Limited responses receive 429 response codes and block pages as shown.

   

3. Rate Limited requests can also be seen in Security Analytics as Service Policy blocks.

4. Review your Security Events by navigating back to the Security Dashboard to see the 429 blocks. You can also use the AI Assistant to investigate the support ID.

   Note

   Review the Lab 1 to find Security Events. You can copy you support ID to search with!

   

   

   

Narrative Check

You have now configured rate limiting on the ACME Corp application. This will slow down the attackers from making multiple requests to your application.

Following your rate limiting deployment, you hop back on the all-hands call and find out that the security and application team have uncovered the attack methodology by reviewing application logs. First the attackers are using CURL to launch their attacks.

Let’s focus on building that custom policy to close the vulnerability that the attackers are using.

Task 4: Create, assign and test a Custom Service Policy

In this task you will add a Custom Policy and assign it to your Load Balancer. Custom Service Policies provide the flexibility to build Positive or Negative security models and custom rules or controls.

This Custom Service Policy will be focused on limiting CURL access as logs are indicating that the attackers are using CURL to access the application. The Custom policy will also focus on protecting a specific page of the application that is vulnerable to close the Zero Day exploit.

1. Before beginning this task, re-evaluate your access from your client to the following:

   • Browser: https://<namespace>.lab-sec.f5demos.com/index.php?page=header

   • cURL: https://<namespace>.lab-sec.f5demos.com/

   • cURL: https://<namespace>.lab-sec.f5demos.com/index.php?page=header

   The expectation is that all are successful based on the current Service Policies.

   Note

   cURL is supported on Windows, Mac & Linux platforms.

   

   

   

2. Returning to Web App & API Protection, in the left-hand navigation menu, expand the Manage section and click Service Policies. In the flyout menu, click the Service Policies link.

3. Observe the existing Service Policies and note that some are sourced from the shared namespace which means they could be used within any other namespace.

4. Click Add Service Policy in the top left area as shown

   

   

5. In the Metadata section enter custom-deny for the Name and then click Rules in the left-hand navigation.

6. Then select Custom Rule List from the dropdown for Select Policy Rules. Locate Rules configuration section and click Configure.

   

7. In the Rules window, click Add Item.

8. In the Metadata section Name field input curl-deny and toggle the Show Advanced Fields to see extra configuration options in Action section.

9. In the Action section, select Deny for the Action and then in the left-hand navigation click Request Match.

   

   

10. In the HTTP Method section, use the Method List dropdown to select GET.

11. In the HTTP Headers section click Add Item.

    

12. In the Header Matcher window, input user-agent for Header Name as shown.

13. Click Add Item under the Regex Values area and input (?i)^.*curl.*$ then click Apply.

    

14. Scroll down to the bottom of the Rule Configuration and click Apply.

    

15. In the custom-deny Service Policy Rule window, click Add Item to add another rule.

    Note

    Multiple Rules can be added to a single Service Policy.

    

16. In the Metadata section Name field input header-page-deny and then click Request Match in the left-hand navigation.

    

17. In the Request Match section under HTTP Methods, add GET to the method list.

18. In the HTTP Path area, click the Configure link.

    

19. Click Add Item in Prefix Values area and in the input field type /index.php. Click Apply.

    

20. Observe that the HTTP Path is now Configured.

21. In section HTTP Query Parameters click Add Item.

    

22. In Query Parameter Matcher window, in the Query Parameter Name field, enter page.

23. In Match Options section, ensure Match Values is selected and then click Add Item in the area with Exact Values as shown.

24. Input header into the Exact Values input field as shown and then click Apply.

    

25. Observe that the HTTP Query Parameters has the value we configured and scroll to the bottom of the rule configuration and click Apply.

    

    

26. Observe that both configured rules are present and then click Apply.

    Note

    Rules within the Service Policy can placed in order as needed.

    

27. Observe that the Custom Rule is now configured for custom-deny Service Policy and click Apply.

    

28. The custom-deny Service Policy is now listed among all Service Policies and has a Rule Count of 2.

    Note

    This window also show the Service Policy “Hits” when validating usage.

    

29. Return to Web App & API Protection in the F5 Distributed Cloud Console, Manage > Load Balancer > HTTP Load Balancers and use the Action Dots and click Manage.

30. Click Edit Configuration in the top right-hand corner.

    

    

31. Click Common Security Controls in the left-hand navigation.

32. From the Service Policies section, click Edit Configuration.

    

33. Observe the order of the previously created Service Policies (allow-geo,deny-all) and click Add Item.

34. Use the drop-down as shown and select <namespace>/custom-deny from the available Service Policy list.

    

35. Click the six squares icon to drag <namespace>/custom-deny into the first position in policy order as shown then click Apply.

    

    

36. Scroll to the bottom and click Save & Exit.

    

37. Time to test to see if the web vulenrability is patched. Now test the following from your client:

    • Browser: https://<namespace>.lab-sec.f5demos.com/index.php?page=header

    • cURL: https://<namespace>.lab-sec.f5demos.com/

    • cURL: https://<namespace>.lab-sec.f5demos.com/index.php?page=header

    

38. What where your results? The zero-day vulnerability should be closed. Check the Security Dashboard or AI Assistant to confirm that the custom-deny policy is blocking the request.

    

39. Finally, let’s make sure access via the Browser is still valid for normal traffic.

    • Browser: https://<namespace>.lab-sec.f5demos.com/

Narrative Check

You have now configured a “custom web application vulnerability signature” for the ACME Corp application using Service Policies.

Service Policies provide a powerful framework to implement both positive and negative security models and you matching criteria from client requests (headers, parameters, paths, request body payload) to effectively control the access to protected applications and APIs.

Service Policies can be a foundational part of an organizations security program by extending zero-trust segmentation capabilities beyond a company’s traditional network utilizng F5’s Regional Edges and Application Delivery Network. Service Policies can also be a key part of security incident response to quickly stop zero-day attacks.

End of Lab 3: This concludes Lab 3, feel free to review and test the configuration. A Q&A session will begin shortly to conclude the overall lab.