[Owasp-modsecurity-core-rule-set] More Squirrelmail Denials

Arthur Dent misc.lists at blueyonder.co.uk
Sat Jan 16 17:54:47 EST 2010

On Thu, 2010-01-14 at 17:11 -0500, Ryan Barnett wrote:
> On Thursday 14 January 2010 01:26:29 pm you wrote:
> > > 
> OK, the debug log certainly helped.  I thought that there was only 1 false positive match 
> however the debug log shows that there were multiple matches that needed to be fixed.  My 
> example exception was only capturing the last match since it used MATCHED_VAR_NAME in the 
> 2nd part of the rule.  In order to capture *all* matches, try this rule -
> SecRule TX:'/^PHPIDS-30-(.*)-ARGS_NAMES/' "@contains ][" 
> "chain,phase:2,t:none,nolog,pass,setvar:tx.name_counter=+1,setvar:tx.name_%{tx.name_counter}=%{matched_var_name}"
>        SecRule TX:'/^NAME_/' "TX\:(.*)" "capture,t:none,setvar:!tx.
> %{tx.1},setvar:tx.anomaly_score=-4"
> Let me know if this helps.


Thank you very much for this. It worked!

I have only done very limited testing, but the specific case I outlined
previously (adding a new email identity in squirrelmail) certainly
worked without any mod_sec intervention. Interestingly, deleting an
identity did cause an entry in the mod_sec log but the action was not
blocked and the identity was deleted. This is such a rare event that I
can't say that it merits any more work or investigation on your part.

So once again, thank you for all your help.

I do still have one other outstanding issue with mod_sec, and that is to
do with its relationship with squidGuard on my network (I posted about
that too some time ago) but I am conscious that I have already taken too
much of your time and I think I will wait until CRS 2.0.5 comes out
before I bother you with that again, in case 2.0.5 solves it anyway.



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