(OPTIONAL) Lab 7 - Manage the L7 DoS protection settings

Lab 7 will provide guidelines on how to manage the L7 DoS protection settings that mitigate denial-of-service (DoS) attacks.

L7 DoS protection provides automated protection against DDoS attacks by behavioural analysis of traffic using machine learning and data analytics.

L7 DoS protection examines traffic flowing between clients and application servers in data centres, automatically establishes the baseline traffic/flow, then dynamically builds signatures and implements various protections as needed based on application and attacker behavior, reducing false positives and providing faster time to mitigation.

You can enable, or disable the detection and mitigation techniques based on your application’s security requirements.

In addition, you can set the mitigation mode, which allows you to balance between the precise mitigation (conservative), service protection (standard) and monitoring only (none).

To review notifications of when an attack started, ended, or a bad actor was detected (if applicable to your settings), see Reference: L7 DoS Event Logs or go to: Security → Event Logs → L7 DoS.

Hint

If using an API, you can modify the L7 DoS settings and settings directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.


Configure L7 DoS Protection settings

  1. Click the workspace icon next to the F5 icon, and click on Security.
  2. From the left menu click Policies under WAF.
  3. Create a new policy by click on Create.
../../../_images/Module7_create_new_waf_policy.png

  1. Name the new policy juice_shop_policy_l7ddos and provide a meaningful description i.e. juice shop policy for the L7 DDoS lab.
  • Disable Bot Defense and enable L7 DoS Protection.
  • Leave all other options Default and Save the config.
../../../_images/Module7_enable_l7dos_protection.png

  1. Select the newly created policy juice_shop_policy_l7ddos Enable Advanced View
../../../_images/Module7_l7dos_policy_settings.png

  1. From here you enable the Trust XFF Header option (at the bottom of the policy).
../../../_images/Module7_l7dos_policy_settings_trust_xff.png

Note

BIG-IP Next WAF will honor the X-Forwarded-For header by enabling this setting in the policy.


  1. Now navigate to the L7 DoS Protection settings.

Hint

If L7 DoS Protection is disabled, toggle the Enabled button. This then will allow you to see the policy’s settings.

../../../_images/L7DoS_IV.png

  1. The Mitigation Mode is set to Standard which is the default setting.
  • Standard (Default) - For Bad Actors, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server’s health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server’s health. If Signatures is enabled, this blocks requests that match attack signatures.
  • Conservative - For Bad Actors, rate slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server’s health.
  • None - Learns and monitors traffic behavior, but no action is taken.
../../../_images/L7DoS_VI.png

  • Signatures are “enabled” by default When enabled, the policy examines requests and creates behavioral signatures that describe patterns found in attacks identified.
  • Bad Actors are “enabled” by default. When enabled, the policy identifies IP addresses of bad actors by examining traffic behavior and anomaly detection.
  • TLS fingerprint is “enabled” by default. When enabled, the policy uses TLS fingerprinting to distinguish between bad and good actors behind the same IP (NAT) and only blocks traffic from bad actors.
../../../_images/L7DoS_VII.png

  1. In case you plan to make any modifications, click on on Save & Deploy before you leave the menu.

Deploy a HTTP load balancer and attach recent created WAF policy


  1. From Applications - My Application Services click on + Add Application”.
../../../_images/L7DoS_X.png

  1. Enter juice_shop_app_80_l7ddos as the “Application Service Name”, select From Template and click on Select Template.
../../../_images/L7DoS_XI.png

  1. Choose the http template and click on Start Creating.
../../../_images/L7DoS_XII.png

  1. Click on Start Creating for Virtual Servers again.
../../../_images/L7DoS_XIII.png

  1. Click on Pools then Create
  • Enter the name juice_shop_pool and the port number 3000.
../../../_images/L7DoS_XIV.png
  1. Click on Virtual Server
  • Enter the name juice_shop_vs_80”
  • Select the pool you just created before, “juice_shop_pool” from the drop down menu
  • Enter the port 80
../../../_images/L7DoS_XV.png

  1. Click on “Edit” for “Security Policies
../../../_images/L7DoS_XVI.png

  • Enable Use a WAF Policy
  • Select the Security Policy named “juice_lab_policy_l7ddos” from the drop-down menu of the WAF Policy Name menu.
../../../_images/L7DoS_XVII.png

  • Click ** Save **

Attach a XFF-Mixed_Attacker iRule

Because we do not have dozens of good and bad source IPs available for clients and attackers in this environment, we will simulate them by adding an iRule to the virtual server. The iRule adds a randomized X-Forwarded-For (XFF) header to each request.

  1. Create and attach a new iRule to the Application Service by clicking the iRules Menu.
../../../_images/L7DoS_XXX.png

  1. Enable Use iRules and press Add and afterwards Create to add a new iRule.
../../../_images/L7DoS_XXXI.png

  1. The name of the iRule will be L7DDoS_XFF_mixed_attacker_good. Please use the following code for the new iRule.

    when HTTP_REQUEST {
    # Good traffic
    if { [IP::addr [IP::client_addr] equals 10.1.10.6] } {
    #set xff 153.172.223.[expr int(rand()*100)]
    set xff [expr int(rand()*100)].[expr int(rand()*100)].[expr int(rand()*100)].[expr int(rand()*100)]
    HTTP::header insert X-Forwarded-For $xff
    log local0.info "$xff"
    }
    # Attack traffic
    if { [IP::addr [IP::client_addr] equals 10.1.10.20] } {
    set xff 132.173.99.[expr int(rand()*25)]
    HTTP::header insert X-Forwarded-For $xff
    }
    }
    

  • Click Save
  1. Assign the new created iRule to your Application Service by selecting the iRule L7DDoS_XFF_mixed_attacker_good from the menu. Click Add to complete.
../../../_images/L7DoS_XXXIII.png

  • Afterwards click Save and continue by clicking Review & Deploy.
../../../_images/L7DoS_XVIII.png

Note

You finished the configuration of the generic part and the instance/locations specific part is configured in the next step. For this example we use only one location.


  1. Click on “Start Adding” Instance/Locations to start the site specific configuration
  • Select e.g. “big-ip-next-03.f5demo.com”
  • Click on “Add to List”
../../../_images/L7DoS_XVIX.png

  1. Configuration the Virtual Address and Pool Members:
  • Enter the Virtual Address 10.1.10.131

  • Click on “Members” dropdown - then + Pool Members

  • Click on “Add Row” and add both pool members:

    Node1 – 10.1.20.100

    Node2 – 10.1.20.101

../../../_images/L7DoS_XX.png

  • Click Save to return to the previous screen
  • It is recommended to validate changes, Click on Validate All
  • Once the configuration has been validated Click Deploy Changes.
../../../_images/L7DoS_XXI.png

  • Finally you should see the app and the WAF policy deployed
../../../_images/L7DoS_XXII.png

Demo L7 DoS to the Juice Shop App

This chapter will guide you on how to demo L7 DoS against the Juice Shop App.

Generate Traffic to Establish Baseline

BIG-IP Next WAF L7 DoS Protection feature is based on learning and analyzing all traffic to the web application, building baselines, and then idenitifying anamolies when server stress is detected.

As a result, in this lab, we need to generate normal traffic allowing BIG-IP Next WAF to build a baseline.

You will use the Super Jump Host called Ubuntu Jump Host to generate legitimate traffic and bad traffic.

In the directory (/demo/l7dos) on the Ubuntu Jump Host, you will find the two scripts used for this lab:

  • baseline.sh - is used to create baseline traffic
  • AB_DOS.sh - is used to launch L7 DOS attacks
  1. SSH to the Super Jump Host called Ubuntu Jump Host (client/server).
../../../_images/L7DoS_VIII.png
  1. Change working directory and privilege by running:

    ubuntu@ubuntu:~$ cd demo/l7dos/
    ubuntu@ubuntu:~/demo/l7dos$ sudo su
    
  2. Start baseline traffic by typing:

    root@ubuntu:/home/ubuntu/demo/l7dos# ./baseline.sh
    
    - Select option 2 **alternate** and not stop baseline traffic script anytime during the demo
    
../../../_images/L7DoS_XXXIV.png

Note

This is your valid traffic, and the number of requests will change over time. The requests also change as the script continuously alters the User-Agent header and the requested URI. Both values are randomly taken from files in the “source” directory in the home directory.


Run a L7DDoS attack on the App juice_shop_app_80_l7ddos

In this module you will be initiating a L7 DDoS attack on App juice_shop_app_80_l7ddos. Again we use the Super Jump Host called Ubuntu Jump Host to generate traffic.

  1. Start attack traffic by typing:

    root@ubuntu:/home/ubuntu/demo/l7dos# ./AB_DOS.sh
    
    1) Attack start - similarity
    2) Attack start - score
    3) Attack end
    4) Quit
    #?
    
    - Select **2** – Attack start - score
    
../../../_images/L7DoS_XXXV.png

Note

The bad traffic script will send traffic will be coming from 10.1.10.20 as the source IP address. This source IP will match XFF_mixed_Attacker_Good_iRule, and an X-Forward-For header will be inserted in the HTTP request in the 132.173.99.0/24 IP address range. Once the attack begins the BIG-IP Next WAF will immediately switch into attack mode due to the server health deteriorating almost immediately.


Attack started

To get insights on whether an Attack has started, please navigate Security –> Event Logs –> L7 DoS. Change the view to Attack Status

../../../_images/l7ddos_attack_started.png

As the server gets totally overwhelmed, you may at first notice the good script dropping requests. That’s why L7 DoS first mitigates with a global rate limit just to protect the server. In a short time, the good script will go back to all 200 OK responses.


Attack signature detected

To check for the presence of attack signatures change the event logs L7 DoS View to –> Signatures

../../../_images/l7ddos_attack_sig_detected.png

Bad Actor detected

Are there any bad actors? Now change the event logs L7 DoS View to –> Bad Actors

../../../_images/l7ddos_bad_actor_detected.png

Congratulations - You have finished Module 7