Overview #

This article explains how to migrate an F5 BIG-IP iRule used to block requests based on the X-Forwarded-For HTTP header into RELIANOID using the integrated WAF/IPDS (Intrusion Prevention and Detection System) powered by ModSecurity/OWASP ruleset compatible.

The original iRule inspects the X-Forwarded-For header and returns HTTP 410 Gone when a match is found against a list of IP addresses.

Original F5 iRule #

when HTTP_REQUEST
{
    if
    {
        [HTTP::header values "X-Forwarded-For"] contains "31.192.108.123" ||
        [HTTP::header values "X-Forwarded-For"] contains "65.103.109.21" ||
        [HTTP::header values "X-Forwarded-For"] contains "193.90.12.87" ||
        [HTTP::header values "X-Forwarded-For"] contains "208.100.0.117" ||
        [HTTP::header values "X-Forwarded-For"] contains "100.113.150.102" ||
        [HTTP::header values "X-Forwarded-For"] contains "176.10.99.200" ||
        [HTTP::header values "X-Forwarded-For"] contains "163.172.143.114" ||
        [HTTP::header values "X-Forwarded-For"] contains "163.172.209.46" ||
        [HTTP::header values "X-Forwarded-For"] contains "188.138.9.49" ||
        [HTTP::header values "X-Forwarded-For"] contains "217.23.13.129" ||
        [HTTP::header values "X-Forwarded-For"] contains "162.247.72.27" ||
        [HTTP::header values "X-Forwarded-For"] contains "194.67.208.57" ||
        [HTTP::header values "X-Forwarded-For"] contains "41.216.186.114"
    }
    {
        HTTP::respond 410
    }
}

RELIANOID Migration Approach #

In RELIANOID, this logic can be implemented using:

• WAF/IPDS module
• ModSecurity/OWASP custom rules
• External IP match file

This approach is more scalable and easier to maintain than embedding multiple IP comparisons inside a script.

Recommended RELIANOID Architecture #

The migration uses:

• Inspection of the X-Forwarded-For HTTP header
• External blacklist file containing IP addresses
• Dynamic IP matching using ModSecurity/OWASP ruleset operators

Advantages:

• Easier IP management
• Centralized blacklist
• No need to edit rules for every IP change
• Better scalability

WAF Rule Configuration #

The following ModSecurity/OWASP rule can be configured in Raw Mode inside the WAF/IPDS module.

SecRule REQUEST_HEADERS:X-Forwarded-For "@ipMatchFromFile /usr/local/relianoid/config/ipds/waf/sets/xff_blacklist.data" "\
id:1001,\
msg:'Custom Match',\
phase:1,\
deny,\
nolog"

How the Rule Works #

This rule performs the following actions:
REQUEST_HEADERS:X-Forwarded-For: Reads the X-Forwarded-For HTTP header
@ipMatchFromFile: Compares the header value against an external file
xff_blacklist.txt: Contains the list of blocked IPs
phase:1: Executes during request header processing
deny: Blocks matching requests
nolog: Disables logging for matched requests

Blacklist File Configuration #

Create the blacklist file:

/usr/local/relianoid/config/ipds/waf/sets/xff_blacklist.data

Example contents:

31.192.108.123
65.103.109.21
193.90.12.87
208.100.0.117
100.113.150.102
176.10.99.200
163.172.143.114
163.172.209.46
188.138.9.49
217.23.13.129
162.247.72.27
194.67.208.57
41.216.186.114

Configure the rule via webUI #

Create the IP data list #

Create a new WAF data file in the section IPDS > WAF > Files including the IP list content:

Create the rule condition #

Create a new WAF ruleset in the section IPDS > WAF > Rulesets including the match IP condition:

Enable the rule in the farm #

Enable the ruleset and assign to the farms required.

Important Operational Note #

Any modification of the blacklist file requires:

• Stopping the WAF rule
• Starting the WAF rule again

This reloads the rule and applies the updated IP list. This will only affects to the WAF rules inspected in the affected farms, not affecting the actual traffic going through the load balancer.

Validation and Testing #

The following command can be used to validate the rule behavior:

curl -k -H "X-Forwarded-For: IP_ADDRESS" https://LB_VIP -v

Example:

curl -k -H "X-Forwarded-For: 31.192.108.123" https://192.168.1.100 -v

Expected Result #

When the IP matches the blacklist:

• Request is denied by WAF
• HTTP error response is returned

Optional Enhancement: Returning HTTP 410 #

The original F5 iRule explicitly returns:

HTTP 410 Gone

By default, ModSecurity/OWASP rulesets deny actions may return HTTP 403 Forbidden.

If exact behavioral parity is required, the rule can be enhanced to return 410.

Example:

SecRule REQUEST_HEADERS:X-Forwarded-For "@ipMatchFromFile /usr/local/relianoid/config/ipds/waf/xff_blacklist.txt" "\
id:1001,\
msg:'Custom Match',\
phase:1,\
deny,\
status:410,\
nolog"

Troubleshooting #

Rule Not Triggering #

Verify:

• WAF/IPDS is enabled on the farm
• Rule is loaded correctly
• Header exists in the request
• Rule restarted after file changes

Requests Not Blocked #

Check:

• IP formatting inside the file
• No extra spaces or hidden characters
• Correct file permissions

Header Missing #

Some upstream proxies may not send X-Forwarded-For. Validate with:

curl -k -H "X-Forwarded-For: 1.2.3.4" https://LB_VIP -v

Logging Needed for Troubleshooting #

Temporarily remove:

nolog

This allows ModSecurity/OWASP rulesets logging for debugging purposes.

Best Practices #

• Maintain blacklist files centrally
• Use automation for blacklist updates
• Periodically review blocked IPs
• Protect WAF rule files with proper permissions
• Prefer external files over hardcoded rules for scalability

Summary #

F5 iRules performing X-Forwarded-For filtering can be migrated efficiently into RELIANOID using the integrated WAF/IPDS module and ModSecurity rules.

This approach provides:

• Centralized IP management
• Better scalability
• Easier maintenance
• Native WAF integration
• Reduced scripting complexity