Repository navigation
Mod_security IPV6 ipMatchFromFile not working as expected. #2192
Description
Hello,
ModSec version is 2.7.3 used with IBM HTTP server
We have a scenario.
We use configuration like below.
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/opt/cpf/conf/modsecurity_whitelist" "id:250000004,phase:1,nolog,allow"
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/opt/cpf/conf/modsecurity_whitelist" "id:250000005,phase:5,nolog,skipAfter:WHITELIST_NOLOG"
ISSUE:
When we whitelist an IPv6 address( in whitelist file the address is expanded), if a request then comes from a non expanded IPV6 address, it is not whit list it and mod_security blocks it.
Is this a known issue that is fixed in alter versions?
We don't have any logs for this since it is happening in a customer environment and we dont have many IPV6 test labs.
Activity
zimmerle commentedon Oct 25, 2019
Hi @arjunvrm,
An update is really recommended as 2.7.3 is indeed a very old version. You can check the changelog on the release page -
https://github.com/SpiderLabs/ModSecurity/releases
Apart from that, it will be very interesting to have an example of the ipadress that there are falling so that we can put it on our regression tests. Do you think you can find these?
arjunvrm commentedon Oct 30, 2019
I can try to get some examples that happened in the customer environment. But have anyone reported anything similar ?
The thing is that , we can add these IP's to the inline string like below and everything works.
SecRule REMOTE_ADDR "@ipMatch ::1,"IPVD adrress here"" "id:250000006,phase:1,nolog,allow"
Irrespective of the IPV6 address being short or long in the above string, the white listing works. The issue is when using the file as the medium of storing the IP's.
paimangala commentedon Oct 30, 2019
Here is an example,
We have the below in our conf file.
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/opt/cpf/conf/modsecurity_whitelist" "id:250000004,phase:1,nolog,allow"
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/opt/cpf/conf/modsecurity_whitelist" "id:250000005,phase:5,nolog,skipAfter:WHITELIST_NOLOG"
And here, are the contents of the whitelist file.
Problem: When I make a brute force attack from a VM having this IP 2b00:8c00:4000:020d:0000:0000:008a:0a57
It blocks this IP address
The following is the snippet from my log file
msg "2019/10/18 21:24:03#bf#error#platform#IP#2b00:8c00:4000:20d::8a:a57#userIdentity#user#BruteForce attack detected from the IP."]
The difference I see is in the IPV6 address format.
I also tried adding this IP 2a00:8a00:4000:020c:0000:0000:008b:0d57directly in the conf file in the Secrule IpMatch tag, and it did not block the IP as it did before
ndouglasward commentedon Jan 11, 2025
I know this is an old ticket but I would like to add notes to revive it. We are attempting to whitelist IPv4 addresses, but are seeing similar behavior.
We are running modsecurity version 3.3.2-1. I added the following rule to REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf:
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/modsecurity/crs/ips.txt" "id:1,phase:1,pass,nolog,ctl:ruleEngine=Off"I will attach the IP address file recommended by our security scanning company. When I start a manual scan, the error log shows all of the connection attempts and that they are blocked. I manually checked the file for a few of the IP addresses and confirmed they are listed. Is the format of this rule incorrect? I appreciate any help you can offer with successfully whitelisting our security scanner. Thanks!
ips.txt
airween commentedon Jan 12, 2025
Hi @binaryFlow,
thanks for reporting this.
I think 3.3.2-1 is the CRS version, not the ModSecurity version. Could you write us the exact version of your engine?
I think yes, this is a correct format of listing of IP addresses (see our manual).
For a while, could you turn your SecDebugLog (and set the
SecDebugLogLevelto9- but only for a while) while you see a request from any of those addresses? Then please check that transaction in the produced debug.log (and turn off your debug).First we have to be sure that rule is activated and in use.
ndouglasward commentedon Jan 12, 2025
We are running Ubuntu Server 22.04.5 LTS. ModSecurity was installed using apt from the repo for this server version.
user@server:~$ sudo apt list --installed | grep modsecuritymodsecurity-crs/jammy,now 3.3.2-1 all [installed,automatic]I'm not sure where else to check for a version number. If you let me know, I will pull the information for you. I enabled SecDebugLog and initiated a remote security scan. Here's the startup message I see in /var/log/apache2/error.log (not sure if this is helpful).
[Sun Jan 12 22:10:36.887513 2025] [mpm_prefork:notice] [pid 34180] AH00170: caught SIGWINCH, shutting down gracefully[Sun Jan 12 22:10:37.217509 2025] [:notice] [pid 34576] ModSecurity for Apache/2.9.5 (http://www.modsecurity.org/) configured.[Sun Jan 12 22:10:37.218306 2025] [:notice] [pid 34576] ModSecurity: APR compiled version="1.7.0"; loaded version="1.7.0"[Sun Jan 12 22:10:37.218320 2025] [:notice] [pid 34576] ModSecurity: PCRE compiled version="8.39 "; loaded version="8.45 2021-06-15"[Sun Jan 12 22:10:37.218326 2025] [:warn] [pid 34576] ModSecurity: Loaded PCRE do not match with compiled![Sun Jan 12 22:10:37.218331 2025] [:notice] [pid 34576] ModSecurity: LUA compiled version="Lua 5.1"[Sun Jan 12 22:10:37.218336 2025] [:notice] [pid 34576] ModSecurity: YAJL compiled version="2.1.0"[Sun Jan 12 22:10:37.218341 2025] [:notice] [pid 34576] ModSecurity: LIBXML compiled version="2.9.13"[Sun Jan 12 22:10:37.218345 2025] [:notice] [pid 34576] ModSecurity: Status engine is currently disabled, enable it by set SecStatusEngine to On.[Sun Jan 12 22:10:37.410683 2025] [mpm_prefork:notice] [pid 34577] AH00163: Apache/2.4.52 (Ubuntu) OpenSSL/3.0.2 configured -- resuming normal operations[Sun Jan 12 22:10:37.412740 2025] [core:notice] [pid 34577] AH00094: Command line: '/usr/sbin/apache2'Running the security scanner generated 6.8 GB of text in modsec-debug.log. I immediately disabled the debug log to avoid generating more text. I verified that I see whitelisted ip addresses in the log. What should we be looking for in this log file? It's too big to try to attach to this case. Is there a different way I should send it?
I appreciate your help figuring this out!
marcstern commentedon Jan 14, 2025
@ipMatchFromFile and @ipMatch code (same code in v2 & v3) becomes buggy from a certain number of IP. Nobody knows where this code comes from, so it's very difficult to fix it. We should replace it by a new code from a "trusted source" who maintains it.
fzipi commentedon Oct 12, 2026
Revisiting this one. The original report is from 2.7.3 (2013). Both branches parse
@ipMatchentries and the looked-up address withinet_pton, so expanded and compressed forms of the same IPv6 address compare equal; the later comments in the thread turned out to be about the CRS version, not the engine. Two undefined-behaviour fixes landed in the tree code recently (#3541, #3542).If anyone still sees a compressed IPv6 address fail against an expanded entry on a current release, a minimal file plus the request address would let us turn it into a regression test. Otherwise I suggest closing.
fzipi commentedon Oct 12, 2026
#3588 found a concrete bug in the radix tree: when a node gets a second netmask the previous ones are discarded, so earlier CIDR entries stop matching. That is the likely explanation for the reports here.
fzipi commentedon Oct 12, 2026
Follow-up: with the root cause confirmed in #3588 (earlier netmasks on a tree node are discarded when another is added), this report is covered there. Suggest closing this one as a duplicate of #3588.