Ryan, one interesting thing to do with the Confidence Tag could be a block/pass based on confidence. This can help the use of signatures, and even test/improve the signatures without disabling it. And in anomaly mode, this could rise the weigth of rules with with a higher confidence or lower the weight of a rule with lower confidence, having the same behaviour.
Klaubert On Fri, Apr 15, 2011 at 11:15 AM, 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. > > 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
