[Owasp-modsecurity-core-rule-set] CRS 2.0.4 feedback

Ryan Barnett ryan.barnett at breach.com
Mon Jan 11 17:14:17 EST 2010

On Monday 11 January 2010 04:44:10 pm Ivan Ristic wrote:
> I investigated a couple of CRS false positives today, and I have the
> following feedback for the group:
> - CRS generates great many messages, and it's very difficult to figure
> out what is relevant and what isn't.
They are all relevant.

There are basically 4 phases to the CRS - 

1) Inbound rules - in this case *all* rules inspect the request data and may contributed 
to the anomaly score and set TX variables holding the critical request meta-data.

2) Implementing exceptions - after all of the default inbound signatures run, it is then 
possible to implement exceptions by inspecting the captured TX variable data.  If certain 
criteria is met, then you can adjust the anomaly score and, in the case of the phpids 
rules, actually remove a TX variable altogether.  This is because these rules have not yet 
logged to either the error or audit logs.

3) Checking the inbound anomaly score - this happens in the 49 enforcement file and allows 
the user to decide what and when to block.  They can go by the overall anomaly score or 
any combination of event categories.

4) Correlation - this is done in the 60 file and it allows the user to both inspect the 
outbound response for blocking purposed and to also correlate the inbound with the 
outbound to increase an event severity level to 1 or 0 when you have inbound attacks that 
result in infoleaks.

> - Log suppression, used by CRS to hide the alerts initially, makes it
> very difficult to understand what rules do. The crucial piece of
> information (logdata) is missing. 
This is a good point.  I was already considering adding in the matched data (%{TX.0}) to 
the saved TX variable info.

> The emulation of messages is a poor
> substitute for the original messages and does not contain the original
> information. 
It can include as much as you need.  See the phpids examples.

> It also slows things down. I had to resort to running
> replicas of original requests against a modified version of CRS with
> nolog converted to log, in order to understand why certain rules
> matched.
It is true that there is a performance hit for this, however, it was decided that using 
the TX data for collaboration and exceptions was a greater value.

> - The PHPIDS rules matched against some trivial stuff, for example "name=".
This is an interesting challenge when using the PHPIDS payloads as we have to balance 
false positives and false negatives.  We are trying to address this by conditionally 
applying the regexs to specific variable locations.  Ideally, we would apply them to parsed 
fields such as ARGS, however there were some evasion issues.  If you go the other way and 
apply them to REQUEST_BODY, etc... - you run into more FPs...  So, we opted to first check 
ARGS and then only apply it to REQUEST_BODY if there is no match in ARGS.  We still need 
to work on that logic a bit more though.

I was thinking of the ideas of possibly having the user set some sort of config option 
related to their desired level of paranoia to possibly help choose which rules to run and 
where to apply them.

> - The use of non-numerical rule IDs, which is against the
> specification, makes exceptions impossible. I've reported this problem
> as:
>   https://www.modsecurity.org/tracker/browse/MODSEC-114
>   https://www.modsecurity.org/tracker/browse/CORERULES-28
Rule IDs are used for two reasons - exceptions and for identify which rule actually caused 
the alert.  When using them for exceptions with SecRuleRemoveById or the equivalent ctl 
action - it still works find using non-digit rule IDs.  The only issue is if you wanted to 
remove a range of rule IDs.

Another point - making rule exceptions more flexible was a driver for the new CRS and using 
TX variables.  The rule ID is not as critical for exceptions.

> - Because I couldn't use exceptions, I had to comment some rules out,
> but that's not easy because there is sometimes more than one rule with
> the same ID. I've found that to be a tad confusing.
> - Overall, it hasn't been a fun experience.
Not a ringing endorsement coming from the ModSecurity creator :(  Ultimately, I think that 
we are making some important strides is rule flexibility and management however we need to 
do more testing and received feedback.  I believe that creating proper CRS documentation 
on the OWASP project site is key as well.  

I was waiting for your OWASP CRS project review data in order to update the sites.  Is 
this it or are you sending something different?  What do you say we take this offline and 
come up with a gameplan?


More information about the Owasp-modsecurity-core-rule-set mailing list