On Fri, Apr 15, 2011 at 4:15 PM, Ryan Barnett <[email protected]>wrote:
> Hey everyone, > I wanted give an overview of the current use of TAG data in rules ( > https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#tag), > as well as, to get some feedback on some new ideas for tag usage. > > First let's look at how TAG is currently being used today in the CRS. Here > is an example SQL Injection rule - > > SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bxp_cmdshell\b" \ > > > "phase:2,rev:'2.2.0',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E,block,msg:'SQL > Injection > Attack',id:'959052',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{ > rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}" > > The TAG action is used to provide the following information: > > 1. Attack Category – example WEB_ATTACK/SQL_INJECTION > 2. Mapping to community taxonomies – such as WASC Threat Classification, > OWASP Top Ten and OWASP AppSensor Detection Points > 3. URL links to specific reference resources – as in this converted ET > sql injection rule that lists a link to a SecurityFocus vuln entry > > # (2007539) SpiderLabs Research (SLR) Public Vulns: ET WEB_SPECIFIC_APPS > 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp model UPDATE > SecRule REQUEST_LINE "@contains /vehiclelistings.asp" > "chain,phase:2,block,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:normalisePathWin,capture,nolog,auditlog,logdata:'%{TX.0}',severity:'2',id:2007539,rev:6,msg:'SLR: > ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- > vehiclelistings.asp model UPDATE',tag:'web-application-attack',tag:'url, > www.securityfocus.com/bid/21154'" > SecRule &TX:'/WEB_ATTACK/SQL_INJECTION.*ARGS:model/' "@gt 0" > "ctl:auditLogParts=+E,setvar:'tx.msg=%{tx.msg} - ET WEB_SPECIFIC_APPS 20/20 > Auto Gallery SQL Injection Attempt -- vehiclelistings.asp model > UPDATE',setvar:tx.anomaly_score=+20,setvar:'tx.%{rule.id > }-WEB_ATTACK-%{rule.severity}-%{rule.msg}-%{matched_var_name}=%{matched_var}'" > > One big idea we have for a new TAG is Confidence Level which would give a > general indication as to the rules accuracy level perhaps on a scale of 0-5 > where 0 is totally experimental without much testing at all and 5 is a very > strong signature that has been rigorously tested and a low chance of false > positives. Example – tag:'CONFIDENCE_LEVEL/5' > > The Confidence Level tag seems like it has the potential to have a very > positive impact to users for two reasons: > > 1. Currently, there isn't much distinction for each rules as to its > accuracy level. We do have the experimental_rules directory for brand new > rules however that does not mean that other rules are all of equal accuracy > levels. > 2. With the new v2.6 enhancement which added SecRuleRemoveByTag and > ctl:ruleRemoveByTag ( > https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecRuleRemoveByTag) > users will then have the ability to make local customizations to disable > entire groups of rules based on TAG data :) For instance, if you wanted to > only run CONFIDENCE_LEVEL/5 rules you could do that in a local custom rules > file modsecurity_crs_60_custom_rules.conf to disable all lower confidence > level rules – > > SecRuleRemoveByTag "CONFIDENCE_LEVEL/[0-4]" > > While this is a great new capability – we will need some help from the > community with identifying the right CONFIDENCE_LEVEL settings for each > rule. I will go through each rule and estimate a CONFIDENCE_LEVEL based on > our intel. This may not be enough however. I have a feeling that most > ModSecurity users silently handle false positives with local exceptions and > they do not also report back to the community which rule IDs are causing > problems. Some users do go the extra mile and actually open Jira tickets > for the CRS with bug reports. That is great and it ensures that I will > review/update the rules. I do think, however, that most end users would > prefer an easier method. What do you all think about us creating a new > mail-list on SourceForge strictly for sending in false positive rule issues? > We could create something like - mod– > [email protected]. > > What do you think? If anyone has any better ideas for false positive > reporting, please speak up. > > I think it's a great idea. In effect having a mailing intended only for the false positives I think it's similar - but in this context with some difference - to what the GNU project have done the years for the bug report : having different mailing for the "bug" and discussion make it more easy to obtain the result you want. What should be standardized is what to send. For example - Full audit log (and what level of logging) or not, only a significative part - what was done in front of the false positive disabling the rule rewriting with a whitelisting approach Best Regards > Ryan > > > > ________________________________ > 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. > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > [email protected] > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set >
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
