F5 AWAF geolocation enforcement feature enables administrators to allow or block incoming traffic based on geographic location of the client. The source IP address of a client can be determined even if it is behind a proxy by using X-Forwarded-For (XFF) header.
In this lesson, we will demonstrate how to configure and effectively use this feature.
X-Forwarded-For and Geolocation Enforcement
what is HTTP X-Forwarded-For?
Before we begin discussing Geolocation enforcement, it’s important to understand the HTTP X-Forwarded-For header, which we’ll be using in this demonstration.
When a client makes a request to a server through a proxy, the client’s actual IP address is lost because the source IP address is changed to that of the proxy. The X-Forwarded-For (XFF) header is an HTTP header that the proxy may add, including the original IP address of the client. This header enables the server to identify the true origin of the request despite it passing through one or more proxies.
With the X-Forwarded-For (XFF) HTTP header, F5 AWAF can accurately detect the real IP address of the client, even when the client is behind a proxy. This capability enables F5 AWAF to effectively block traffic based on geolocation information.
Preparing the security policy
To demonstrate F5 AWAF geolocation enforcement, we will use the policy created in previous lessons. This policy is based on a comprehensive security template and is assigned to the “hack-it-yourself” web application.
We will also enable “learn,” “alarm,” and “block” for all violations related to “IP addresses and Geolocations” in the “Learning and Blocking Settings“. Specifically, we will focus on the violation “Access from disallowed Geolocation,” which is the main topic of this demonstration.
Simulate HTTP request with XFF header using Postman
To simulate sending traffic through a proxy to the web application using the X-Forwarded-For (XFF) header, we’ll use the Postman application. In Postman:
Set the request method to “GET.”
Enter the URL as “http://auction.f5demo.com/“.
Manually add the client’s IP address to the X-Forwarded-For header.
Keep all other parameters unchanged.
This configuration enables us to replicate traffic passing through a proxy with the specified client IP address effectively.
I chose the IP address “169.239.24.10” which is associated with Zimbabwe. I selected Zimbabwe because it was the last country listed in the F5 AWAF geolocation database. I found this sample IP address by searching over the internet.
To ensure that this IP address is correctly associated with Zimbabwe in the F5 AWAF geolocation database, we can use the “geoip_lookup” command to find the geolocation of the IP address. This command will confirm the geographic location details as stored in the database.
[root@awaf:avrd DOWN:Standalone] config # geoip_lookup 102.128.76.0 Will attempt to lookup ip '102.128.76.0' No database specified. opening database in /usr/share/GeoIP/v2/F5GeoIP.dat size of geoip database = 24330336, segments = 9734200, version = Copyright (c) F5 Networks Inc, All Rights Reserved GEOIP2 v1, 20230501 geoip_seek = 00f30002 geoip record ip = 102.128.76.0 country_code = ZW country_name = Zimbabwe region_name = Harare continent_code = AF Scope = 22 [root@awaf:avrd DOWN:Standalone] config #
Before enabling geolocation enforcement, we will use Postman to connect to the web application and verify that this IP address is currently allowed to access the web application.
If we check the result of the connection in the event log, we will see that the access is successful and permitted. However, we will also notice that the geolocation and source IP address are not updated via the XFF HTTP header. This is because we have not yet configured the system to trust the XFF header.
However, if we examine the details of the HTTP request, we can see that the XFF header with the Zimbabwe IP address is present in the HTTP header. Despite this, the source IP address and geolocation are not updated in the event log because the XFF header has not been configured as a trusted source.
Trust XFF header and configure geolocation enforcement
Now, we will configure the security policy to trust the XFF header and enforce geolocation restrictions.
In the security policy under “General Settings,” enable the option to “Trust XFF Header“.
Navigate to “Geolocation Enforcement” and add the last country on the list, “Zimbabwe,” to the “Disallow Access” list.
These changes will ensure that traffic from Zimbabwe is blocked based on the trusted XFF header.
We will again attempt to access the web application using Postman, with the XFF header set to an IP address from Zimbabwe. This time, the result shows that access is blocked, demonstrating that the geolocation enforcement is working as configured.
If we check the event log, we will notice that the traffic is blocked and that the values for Geolocation and the source IP address are updated using the XFF header. This outcome is a direct result of configuring the security policy to trust the XFF header.
