[Owasp-modsecurity-core-rule-set] Setting default action for blocking rules only?

Mario Santana msantana at terremark.com
Wed May 19 14:20:54 EDT 2010


On May 19, 2010, at 12:47 PM, Brian Rectanus wrote:

> What version of CRS?  If 2.x, then blocking is done via anomaly scoring.
> This setvar can be added to the rule checking the anomaly score.

I'm actually using the rules on the trunk, thought I'm only playing with the base_rules so far.  And you're right - there are only two rules that check the anomaly score.  I've added the setvar to them, but there are 19 other rules that don't specify a disruptive action (i.e., pass.)  Also, at least some of those rules don't seem to have id: actions.  (Many of these rules seem to be auto-generated from PHPIDS?)  No worries - I added the setvar to those rules directly, but I wonder if those rules could be better integrated into the whole anomaly-scoring scheme?

I still have some finishing up to do, but all in all it was a lot less work than I thought it would be.  Mostly due to the elegance of the CRS - so thanks!  =)  Still, a generic solution would let me work with any rule set without modifying it...

> You could probably write a script to
> maintain this :)

That's the next step, part of figuring out how to keep the rules updated once this goes into production.

> But I think the easiest way is to use a phase:5 rule.  For example:
> 
> # Example blocking rule
> SecRule ARGS "attack" \
>  "phase:2,log,auditlog,deny,status:403,id:12345"
> 
> # In phase 5, then look for that 403 and set SESSION var
> SecRule RESPONSE_STATUS "@eq 403" \
>  "phase:5,pass,nolog,setvar:SESSION.tagged=1"

I played with this sort of scenario for most of a day.  The underlying problem is to identify whether a transaction has been blocked.  Using a status like your example (or TX variables, or whatever) only rearranges the problem, because (as far as I can tell) mod_security doesn't expose a flag to show whether the transaction is being blocked.

I went so far as to browse the mod_security code to see how hard it would be to expose that information, perhaps by enhancing the RULE collection.  I quickly realized that it would take more than an idle afternoon to familiarize myself with the code enough to even begin thinking about that...




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