Re: [mod-security-users] False positives on core rules

[Ryan B. <Ryan.Barnett@Breach.com>]

Hey Al,

You are on the right track with both your deployment (testing it in
DetectionOnly mode for awhile) and will your apprehension with hacking
away at the Core Rules.  As you accurately pointed out, if you can
customize your configs without modifying the Core Rules themselves, it
will be much easier for you to upgrade to the latest and greatest rules
when they become available.  Please refer to my recent Blog post on this
topic -
http://www.modsecurity.org/blog/archives/2007/02/handling_false.html.

=20

The steps for creating your custom rules files that work with the Core
Rules are outlined in the Blog post, however I will provide you with
some sample rules that you can test for situation.

=20

1.	For rule ID 960023 - take the existing rule and make a copy of
it to place in your custom rules 60 file that gets processed after all
of the Core Rules.  You should then update the RegEx to allow the
Request Methods that you need for WebDAV (such as PROPFIND).  You then
need to specify SecRuleRemoveById to disable the Core Rule that is
causing the hit and then make sure to assign a new custom rule ID # in
the 1XXX range.

=20

SecRuleRemoveById 960032

SecRule REQUEST_METHOD "!^((?:(?:POS|GE)T|OPTIONS|HEAD|PROPFIND))$"
"phase:1,log,auditlog,status:501,msg:'Method is not allowed by policy',
severity:'2',id:'1234'"

=20

2.	For rule ID 960015 - you can do the same process and add the
following to your custom rules 60 file -

=20

SecRuleRemoveById 960015

SecRule &REQUEST_HEADERS:Accept "@eq 0" \

    "chain,skip:1,log,auditlog,msg:'Request Missing an Accept Header',
severity:'2',id:'12345'"

SecRule REQUEST_METHOD "!OPTIONS" chain

SecRule REQUEST_HEADERS:Via|REQUEST_HEADERS:User-Agent "!@rx aol"
t:lowercase

=20

What this updated rule is doing is taking into account both the
User-Agent and Via header data to see if there is any "AOL" string.  If
so, then this rule will NOT match.  A more accurate approach would be to
actually include the IP ranges that AOL has for its proxy servers -
http://webmaster.info.aol.com/proxyinfo.html.

=20

=20

Let me know if you need more info and good luck!

=20

--=20
Ryan C. Barnett
ModSecurity Community Manager

Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
Author: Preventing Web Attacks with Apache

=20

--------------

Web Security Threat Report Webinar on May 9, 2007 (12 pm EST)

Learn More About the Breach Webinar Series:

http://www.breach.com/webinars.asp

--------------

=20

________________________________

From: mod...@li...
[mailto:mod...@li...] On Behalf Of
AF...@ex...
Sent: Tuesday, March 27, 2007 1:53 PM
To: mod...@li...
Subject: [mod-security-users] False positives on core rules

=20


Hi All-=20

I'm just getting involved with mod_security and so far, very impressed.
I have it running on a pair of reverse proxies, frontending a few of our
applications.  Currently its in DetectionOnly mode while I work out the
kinks.  I currently have been getting a ton of false positives which I'm
trying to figure out the best way to fix.  Any advice would be much
appreciated.=20

One of the false positives is generated when the clients are working
with the website using webdav.  The Request Method rule doesn't like the
PROPFIND method and I'm getting the following error in my audit log:

Message: Warning. Match of "rx ^((?:(?:POS|GE)T|OPTIONS|HEAD))$" against
"REQUEST_METHOD" required. [id "960032"] [msg "Method is not allowed by
policy"] [severity "CRITICAL"]=20

The other false positive seems to come from anyone on AOL.  I get the
following error in the audit log:

Message: Warning. Match of "rx OPTIONS" against "REQUEST_METHOD"
required. [id "960015"] [msg "Request Missing an Accept Header"]
[severity "CRITICAL"]=20

And there request looks likes:=20

--00003343-B--=20
GET /xxxxxxxxxxxxxxxxxxx HTTP/1.1=20
Accept-Encoding: gzip, deflate=20
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; AOL 9.0; Windows NT 5.1)=20
Via: HTTP/1.1 cache-rtc-ae08.proxy.aol.com[98A3650C]
(Traffic-Server/6.1.5 [uScM])=20
Host: xxxxxxxxxxxxxxxxxxxxx=20

I agree, they are missing Accept headers - but I'd be fired if I dropped
everyone from AOL.=20

What would be the best approach to dealing with these two?  I know I
could hack apart the core rules, but I'd rather add something to a
custom conf file so I don't have do this all over again when a new
version of the rules come out.=20

Thanks in advance,=20

Al