I have Modsecurity 2.9 installed in windows server 2012/IIS 8.5 and it was working fine with OWASP CRS, but due to high number of false positives in WordPress site i purchased one month license of Atomicorp real-time rules in order to test it, i couldn't manage to get it working properly.
First it start giving too many messages of 'IPmatch: bad IPv6 specification' (for ipv4 addresses) and 'Rule processing failed.' for all requests. i was only using the minimum recommended rules for modsecurity version below 2.7. and when i enable the minimum recommended rules for 2.7+ my application pool just crash when there is a rule match.
Note: I am using experimental rules only without any other rules enabled.
Please advise me about those issues and if you know any resources I can use for IIS issues please let me know, I can't find much information in customer portal and forums.
I am attaching my configuration file.
Thanks
RealTime rules on IIS8 and 'IPmatch: bad IPv6 specification'
- mikeshinn
- Atomicorp Staff - Site Admin
- Posts: 4149
- Joined: Thu Feb 07, 2008 7:49 pm
- Location: Chantilly, VA
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
You want to use the rules from the modsec/windows directory in the main rules archive. Just download the main rules, extract them, and use the rules from the "windows" subdirectory, as opposed to the "experimental" rules.
Please let us know if you have any questions.
Please let us know if you have any questions.
Michael Shinn
Atomicorp - Security For Everyone
Atomicorp - Security For Everyone
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
Thanks Mikeshinn for your response.
i used experimental rules as suggested in this post.
I really can't find documentation for IIS support, please share some links if there are any.
The application pool crash issue is gone, but still the main issue remains. i did some tests for the 15 minimum recommended files and the issue happens only when these files included:
- 00_asl_zz_strict.conf
- 10_asl_rules.conf
- 20_asl_useragents.conf
The problem seems be be in '@ipmatch', it parses ipv4 as ipv6 if there is a port number in the string (':').
after removing '@ipmatch' from '20_asl_useragents.conf' i works without issues.
I am running out of time and i need to do alot of testing even after i solve those issues
i used experimental rules as suggested in this post.
I really can't find documentation for IIS support, please share some links if there are any.
The application pool crash issue is gone, but still the main issue remains. i did some tests for the 15 minimum recommended files and the issue happens only when these files included:
- 00_asl_zz_strict.conf
- 10_asl_rules.conf
- 20_asl_useragents.conf
The problem seems be be in '@ipmatch', it parses ipv4 as ipv6 if there is a port number in the string (':').
after removing '@ipmatch' from '20_asl_useragents.conf' i works without issues.
I am running out of time and i need to do alot of testing even after i solve those issues
- mikeshinn
- Atomicorp Staff - Site Admin
- Posts: 4149
- Joined: Thu Feb 07, 2008 7:49 pm
- Location: Chantilly, VA
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
Are you using the rules in the /windows/ directory? They do not have the IPv6 matches in them, the Microsoft port of modsecurity does not handle IPv6 correctly so do not use the experimental rules with IIS.
Michael Shinn
Atomicorp - Security For Everyone
Atomicorp - Security For Everyone
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
Yes i am using rules from /Windows/ directory, and the rules creating problems aren't for ipv6, it tries to parse ipv4 as ipv6 when there is a port number in the address. (xx.xx.xx.xx:xxxx)
e.g.
e.g.
I just disabled those rules and it worked fine. Hopefully i am not wrong.#Webdav doesnt always include Content-Length
SecRule REQUEST_METHOD "^(?:CHECKOUT|PUT)" \
phase:1,id:364359,pass,t:none,nolog,skipAfter:END_TYPE_CHECK_1
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \
phase:1,id:364459,pass,t:none,nolog,skipAfter:END_TYPE_CHECK_1
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
microsofts modsec look up ip4 as ip6? you should definitely report that to micrtosoft then.
If everything was easy, then the world wouldn't need engineers.
- mikeshinn
- Atomicorp Staff - Site Admin
- Posts: 4149
- Joined: Thu Feb 07, 2008 7:49 pm
- Location: Chantilly, VA
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
Wait, the version of mod_security on your system is including the port number in the REMOTE_ADDR variable? If so, thats a bug in the MS port. That variable should only include the IP address of the remote host, not the port number. The port number should be in a separate variable, SERVER_PORT. REMOTE_ADDR should never include the port only the IP address.
So, if thats the case, hosting is right that is a bug that version of MS' port of mod_security.
Can you confirm what the microsoft build number is on the version of their port you have installed?
So, if thats the case, hosting is right that is a bug that version of MS' port of mod_security.
Can you confirm what the microsoft build number is on the version of their port you have installed?
Michael Shinn
Atomicorp - Security For Everyone
Atomicorp - Security For Everyone
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
Yes, that what i was trying to say..
i didn't get you.Can you confirm what the microsoft build number is on the version of their port you have installed?
- mikeshinn
- Atomicorp Staff - Site Admin
- Posts: 4149
- Joined: Thu Feb 07, 2008 7:49 pm
- Location: Chantilly, VA
Re: RealTime rules on IIS8 and 'IPmatch: bad IPv6 specificat
The build number of the DLL. With that said, I've just tested with the latest from microsoft and it has this bug. Microsoft is combining two variables into the REMOTE_ADDR variable, which is invalid for @ipmatch because if its sees :, it assumes its ipv6, which it is not for an IPv4 address with the port added via a :.
So we've removed all @ipmatch directives from the rules.
Keep in mind until this is fixed by microsoft, the lack of the @ipmatch directive means that matching IP addresses can only be done by regular expression or parallel matches. This means that whitelists are limited to simple expressions and do not support CIDRs. For example:
10.10.10.
Could be used to express a /24, but 10.10.10.0/24 is not supported without @ipmatch working correctly.
So we've removed all @ipmatch directives from the rules.
Keep in mind until this is fixed by microsoft, the lack of the @ipmatch directive means that matching IP addresses can only be done by regular expression or parallel matches. This means that whitelists are limited to simple expressions and do not support CIDRs. For example:
10.10.10.
Could be used to express a /24, but 10.10.10.0/24 is not supported without @ipmatch working correctly.
Michael Shinn
Atomicorp - Security For Everyone
Atomicorp - Security For Everyone