Lab 1 - IP Intelligence Policies


  • Configure Global IPI Profile & Logging
  • Review Global IPI Logs
  • Configure Custom Category and add an IP
  • Apply IPI to a WAF Policy and implement IPI w/ XFF inspection
  • Estimated time for completion: 30 minutes.

Create A Layer 3 IPI Policy

An IPI policy can be created and applied globally, at the virtual server (VS) level or within the WAF policy itself. We will follow security best-practice by applying IPI via a Global Policy to secure Layer 3 device-wide and within the Layer 7 WAF policy to protect the App by inspecting the HTTP X-Forwarded-For Header.


In this lab, we will start by enabling a Global IPI Policy; much like you would do, as a day 1 task for your WAF:

  1. RDP to the Linux Client by choosing the RDP access method from your UDF environment page. You will be presented with the following prompt where you will enter the password only f5DEMOs4u!. The f5student account is hard-coded into XRDP for your convenience.
  1. Once logged in, launch Chrome Browser. You can double-click the icon or right click and choose execute but do not click multiple times. It does take a few moments for the browser to launch the first time.
  2. Click the F5 Advanced WAF bookmark and login to TMUI. admin/[password]. It is normal to see a certificate warning that you can safely click through.
  3. On the Main tab, click Local Traffic > Virtual Servers and you will see the Virtual Servers that have been pre-configured for your lab. Essentially, these are the listening IP’s that receive requests for your application and proxy the requests to the backend “real” servers.
You will see 3 Virtual Servers:

* - Will be used later to send spoofed traffic to the main site
* owasp-juiceshop_443_vs - Main Site - Status of green indicates a healthy backend pool of real servers
* owasp-juiceshop_80_vs - Standard port 80 redirect to main site

  1. On the Main tab, click Security > Network Firewall > IP Intelligence > Policies.


Network Firewall IP Intelligence Policies are a layer 3 enforcement capability and part of Advanced WAF. No additional licensing is necessary beyond Advanced WAF with an IPI Subscription.

  1. Click on the Create button.
  2. For the name: global_ipi
  3. Under IP Intelligence Policy Properties For the Default Log Action choose yes to Log Category Matches.
  4. Browse to the inline Help tab at the top left of the GUI and examine the Default Log Action settings. Inline help is very useful when navigating the myriad of options available within any configuration screen.


Notice in the setting descriptions that hardware acceleration is not available when “logging all matches”. This exercise is to familiarize you with the value of inline help and will not affect our virtual lab.

  1. To the right of the screen, click Add under the categories section.
  2. From the category section choose botnets and click Done editing.
  3. Repeat this process and add the following additional categories: phishing, scanners, spam_sources, & denial_of_service. Outside of this lab, you would want to enable additional categories for protection.
  1. Commit the Changes to the System.
  2. Under Global Policy Assignment > IP Intelligence Policy click on the dropdown and select the global_ipi policy and click Update.

Setup Logging for Global IPI

  1. In the upper left of the GUI under the Main tab, navigate to Security > Event Logs > Logging Profiles and click on global-network
  2. Under the Network Firewall section configure the IP Intelligence publisher to use local-db-publisher
  3. Check Log GEO Events
  4. Click Update


  1. On the Linux Client, open a terminal and cd to /home/f5student/Agility2022wafTools
  2. Run the following command to send some traffic to the site: ./ipi_tester.


The script should continue to run for the remainder of Lab 1 & 2. Do NOT stop the script.

  1. Navigate to Security > Event Logs > Network > Ip Intelligence and review the entries. Notice the Geolocation Data as well as the Black List Class to the right of the log screen.

Create Custom Category

  1. Navigate to: Security > Network Firewall > IP Intelligence > Blacklist Categories and click Create.
  2. Name: my_bad_ips with a match type of Source
  3. Click Finished
  4. Click the checkbox next to the name my_bad_ips and then at the bottom of the GUI, click Add To Category.
  1. Enter the ip address: or any of the other malicious IP’s showing up in the IP Intelligence logs, and set the seconds to 3600 (1 hour)
  2. Click Insert Entry
  1. Navigate to Security > Network Firewall > IP Intelligence > Policies and click global_ipi
  2. Under Categories click Add and select your new custom category my_bad_ips from the drop-down. Click Done Editing and Commit Changes to System.
  1. Navigate back to Security > Event Logs > Network > Ip Intelligence and review the entries under the column Black List Class. You will see entries for your custom category my_bad_ips.

This concludes the Layer 3 IPI policy lab section.

To recap, you have just configured a Global IP Intelligence policy and added a custom category.
This policy is inspecting Layer 3 only and is a best-practice first step to securing your Application traffic.

We will now configure a Layer 7 WAF policy to inspect the X-Forwarded-For HTTP Header.

Attach an IPI policy to your exisiting WAF Policy for Layer 7 Protection

  1. Navigate to Security > Application Security > Policy Building > Learning and Blocking Settings and expand the IP Addresses and Geolocations section of the juiceshop_waf policy. These settings were configured earlier in the OWASP Dashboard lab to enabled, but observe where IPI and Geolocation is set to alarm and/or block.
  1. Navigate to Security > Application Security > Security Policies > Policy List **. Select the **juiceshop_waf policy from the policy list. Click IP Intelligence on the middle pane. In the IP Intelligence screen click on the OFF slider to enable IP Intelligence
  1. Notice at the top left drop-down that you are working within the juiceshop_waf policy context. Enable Alarm and Block for each category.
  1. Click Save and Apply Policy.
  2. Enable XFF inspection in the WAF policy by going to Security > Application Security > Security Policies > Policies List > and click on juiceshop_waf policy. Scroll down under General Settings and click Enabled under Trust XFF Header.
  1. Click Save and Apply Policy

Test XFF Inspection

1. Open a new terminal or terminal tab on the Client (the ipi_tester script should still be running) and run the following command to insert a malicious IP into the XFF Header:

curl -H "X-Forwarded-For:" -k
If that IP has rotated out of the malicious DB, you can try one of these alternates:
  • - Spam Source
  • - Spam Source
  • - Scanner
  • - Scanner
  • - Spam Source
  • - Phishing
  • - Spam Source
  • - Spam Source
  • - Scanner
  1. Navigate to Security > Event Logs > Application > Requests and review the entries. You should see a Sev3 Alert for the attempted access to uri: /xff-test from a malicious IP.
  1. In the violation details you can see the entire request details including the XFF Header even though this site was using strong TLS for encryption.


Attackers often use proxies to add in source IP randomness. Headers such as XFF are used to track the original source IP so the packets can be returned. In this example the HTTP request was sent from a malicious IP but through a proxy that was not known to be malicious. The request passed right through our Global Layer 3 IPI policy but was picked up at Layer 7 due to the WAF’s capabilities. This demonstrates the importance of implementing security in layers.