Re: [mod-security-users] DetectionOnly for All Rules except for one
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] DetectionOnly for All Rules except for one
|
From: Todd M. B. <to...@to...> - 2012-01-18 17:59:50
|
Ryan, This worked like a charm. Thanks for the continued education. Be well. On Jan 17, 2012, at 6:36 PM, Ryan Barnett wrote: > See the Note for SecRuleUpdateActionById - http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecRuleUpdateActionById > > > Note > If the target rule is a chained rule, you must currently specify chain in the SecRuleUpdateActionById action list as well. This will be fixed in a future version. > > Here are updates which will update the disruptive action on the first rule and then turn the rule engine on if the second SecRule matches. You want the ctl action on the second rule otherwise it would toggle the rule engine on before you want it too when only the first rule matches. > > SecRuleUpdateActionByID 960335 "deny" > SecRuleUpdateActionByID 960335:1 "ctl:ruleEngine=On" > > Ryan > > On Jan 17, 2012, at 9:14 PM, Todd Michael Bushnell <to...@to...<mailto:to...@to...>> wrote: > > Thanks again for your earlier advice, Ryan. Per the blog post, the rule that I needed to set to deny was the following: > > # Maximum number of arguments in request limited > SecRule &TX:MAX_NUM_ARGS "@eq 1" "chain,phase:2,t:none,block,msg:'Too many arguments in request',id:'960335',severity:'4',rev:'2.2.3'" > SecRule &ARGS "@gt %{tx.max_num_args}" "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.policy_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-POLICY/SIZE_LIMIT-%{matched_var_name}=%{matched_var}" > > Using your advice, I set this rule to deny via modsecurity_crs_60_customrules.conf, like so: > > # Multi-Platform Hash Collision Vulnerability (CVE-2011-3414) > # http://blog.spiderlabs.com/2012/01/modsecurity-mitigations-for-aspnet-hashtable-dos-vulnerability-cve-2011-3414.html > SecRuleUpdateActionByID 960335 "deny,ctl:ruleEngine=On" > > Unfortunately, after doing this, all my attempts to hit the site are blocked like so: > > > [Wed Jan 18 01:25:31 2012] [error] [client x.x.x.x] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 1 at TX. [file "/etc/httpd/modsecurity/base_rules/modsecurity_crs_23_request_limits.conf"] [line "31"] [id "960335"] [rev "2.2.3"] [msg "Too many arguments in request"] [severity "WARNING"] [hostname "XXX.com<http://XXX.com>"] [uri "/favicon.ico"] [unique_id "TxYfiwohckIAABqQA6sAAABD"] > > To confirm it's a modsecurity config issue vs. perhaps the site, I bumped the max number of request args from 255 to 10255, like so: > # modsecurity_crs_10_config.conf > SecAction "phase:1,id:'981211',t:none,nolog,pass,setvar:tx.max_num_args=10255" > > Regardless of the value I used, I continue to get this blockage unless I comment out the SecRuleUpdateActionByID message. I looked through the audit and debug logs, but did not see where modsecurity was counting the number of ARGS and setting the value to the variable. I'll keep poking away at it this evening after I get the kids to sleep, but if anyone sees something I did wrong, I'd appreciate the correction. Thx. > > todd > > > > > > > On Jan 17, 2012, at 11:04 AM, Ryan Barnett wrote: > > Todd, > You should try the SecRuleUpdateActionById directive - > http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Referenc > e_Manual#SecRuleUpdateActionById > > Since you are running with SecRuleEngine DetectionOnly mode and using > anomaly scoring with pass in SecDefaultAction, you will need to change > these two actions with the SecRuleUpdateActionById directive like this - > > SecRuleUpdateActionByID XXXXXX "deny,ctl:ruleEngine=On" > > You will need to set the correct rule ID and then place this rule in your > modsecurity_crs_60_custom_rules.conf file. The "deny" action will > override the "block" action currently in the rule and the ctl action will > toggle the rule engine from detection only to on. The result is that this > rule will be able to trigger the deny disruptive action while other rule > matches will still only log. > > Let me know if this works, > Ryan > > > > On 1/17/12 1:36 PM, "Todd Michael Bushnell" <to...@to...<mailto:to...@to...>> wrote: > > I'm running modsecurity in DetectionOnly mode at the moment as I go > through the lengthy process of tuning all false positives. Recently, a > security alert came out that we need to block immediately, but I'm simply > not ready to run ModSecurity in blocking mode as there is still a bit of > tuning to do. What I'd like to do is add the custom rule that will > handle this specific alert, set that rule to block, but leave everything > else in DetectionOnly (log, but no block) mode to allow me more time to > address all the false positives. What is the easiest way to accomplish > this without changing the action for every rule in the core rule set? > Based on my reading of the manual, my thought is to leave everything in > block to allow for my default action, but then set my new/custom rule to > deny. I'm running DetectionOnly w/ Anomaly Based Scoring (default action > Pass to support this) so I'm a little hung up on how this all impacts > what I'm trying to do. Appreciate any advice. > > todd > > > -------------------------------------------------------------------------- > ---- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > mod-security-users mailing list > mod...@li...<mailto:mod...@li...> > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > > > > This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > mod-security-users mailing list > mod...@li...<mailto:mod...@li...> > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > > ________________________________ > This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. |