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
