On Thu, 2009-11-12 at 10:20 -0500, Ryan Barnett wrote:
> Hey Matthew,
> A few comments -
>
> 1) We have a different mail-list for the ModSecurity Rules/Core Rule
> Set (CRS). Please sign-up and post there -
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
OK Sorry. I just missed it when I went looking for a list. I will
switch over.
> 2) This rule appears to be from an older version of the CRS. The
> latest version is v2.0.3. You can download it from the OWASP project
> website -
> http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project#tab=Download
The rule set I have is the one that ships with the latest RHELv5. I can
see this is one of those things that will need to be maintained
separately to stay current in that environment.
> 3) Once you get the new CRS installed, you can take a better approach
> to creating an exception. Take a look at the examples in the 48 local
> exceptions file in the new CRS and/or this JIRA ticket which gives an
> example fix for a false positive -
> https://www.modsecurity.org/tracker/browse/CORERULES-2
OK Will do. Thanks.
>
> Let me know if you need more help.
>
> Ryan
>
> ________________________________________
> From: Matthew Saltzman [mjs@...]
> Sent: Thursday, November 12, 2009 10:06 AM
> To: mod-security-users@...
> Subject: [mod-security-users] False positive
>
> I'm kind of new at this, kind of a regex tyro. We are having trouble
> with a false positive when posting a page to the Trac project management
> system. The offending string in the page body seems to be '%_', which
> sets off
>
> [Thu Nov 12 09:43:55 2009] [error] [client 130.127.255.224]
> ModSecurity: Access denied with code 400 (phase 2). Pattern
> match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at
> ARGS:text. [id "950107"] [msg "URL Encoding Abuse Attack
> Attempt"] [severity "WARNING"] [hostname "projects.coin-or.org"]
> [uri "/CoinBinary/wiki/BuildingCoinRpms"] [unique_id
> "kpasfEKtxHEAABtWqyAAAAAK"]
>
> But I don't have much confidence that I've got the analysis correct. A
> co-worker tried editing the page until he got it to go through, and that
> was the string that seemed to interfere.
>
> We tried deleting the rule and replacing it in
> modsecurity_localrules.conf. That didn't stop the 400 error (so we must
> not have gotten the modification right), but for some reason it did seem
> to allow the page to be saved. Going back to the original rule, the
> page is not saved after the error.
>
> Could someone suggest the correct way to modify the rule to allow this
> construct?
>
> Thanks.
> --
> Matthew Saltzman
>
> Clemson University Math Sciences
> mjs AT clemson DOT edu
> http://www.math.clemson.edu/~mjs
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Appliances, Rule Sets and Support:
> http://www.modsecurity.org/breach/index.html
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
|