[Owasp-modsecurity-core-rule-set] CRS 2.0.6 Optional Rules: 42, 46, and 49

[Ryan Barnett]

On Wednesday 24 March 2010 21:46:59 Mark Lavi wrote:
> Hello all,
> 
> I've upgraded to CRS 2.0.6 with ModSecurity 2.5.12 on my development web
> server and reviewed the documentation on
> http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Pr
> oject#tab=Documentation. I've got a few questions that I haven't see
> addressed in the last two months on the mailing list.
> 
> For the first three below, I've created empty files and then ModSecurity
> could load and execute these rules. My question boils down to, how am I
> supposed to populate these data files?
> 
> 1) optional_rules/modsecurity_crs_42_comment_spam.conf: requires a data
> file "optional_rules/modsecurity_42_comment_spam.data," but that doesn't
> exist.
> 
The various *.data files are actually in the base_rules dir so you can either copy/move the 
file over under the optional_rules dir or change the path to the file in the @pmFromFile 
operator.  I suggest the former.

> The documentation mentions a RBL check against SPAMHAUS, am I supposed to
> provide the source IP address in this file?
> 
The following rule in the 42 comment spam file will automatically take the client's IP from 
the REMOTE_ADDR variable and check it against the sbl-xml SPAMHAUS RBL -

SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org" 
"phase:1,t:none,pass,nolog,auditlog,msg:'RBL Match for SPAM 
Source',tag:'AUTOMATION/MALICIOUS',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.automation_score=+%{tx.warning_anomaly_score},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.
%{rule.id}-
AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var},setvar:ip.spammer=1,expirevar:ip.spammer=86400,setvar:ip.previous_rbl_check=1,expirevar:ip.previous_rbl_check=86400,skipAfter:END_RBL_CHECK"

This rule also sets a few variable so that it will only run a remote RBL check once per 
day/per IP address and it saves the results.  The various rules around this one 
(before/after) inspect the saved TX variables on subsequent requests.

> 2) optional_rules/modsecurity_crs_46_et_sql_injection.conf: requires a data
> file "optional_rules/modsecurity_46_et_sql_injection.data," but that
> doesn't exist. 

Same as above - suggest copying it from the base_rules dir.

> 3) optional_rules/modsecurity_crs_46_et_web_rules.conf:
> requires a data file "optional_rules/modsecurity_46_et_web_rules.data,"
> but that doesn't exist.
> 

Same as above.

> I see that you're converting
> http://www.emergingthreats.net/cgi-bin/cvsweb.cgi/rules/
> emerging-web_server.rules and emerging-web_specific_apps.rules. Am I
> supposed to pull down these Snort rule sets from their web site? I imagine
> that I'm looking for your converted versions instead, is that right?
> 

We have already done the conversion for you and the data is all in the 46 files.

> 4) optional_rules/modsecurity_crs_49_header_tagging.conf : Syntax error on
> line 29 of optional_rules/modsecurity_crs_49_header_tagging.conf: Invalid
> command 'RequestHeader', perhaps misspelled or defined by a module not
> included in the server configuration.
> 
> I see this is an Apache directive for mod_headers
> (http://httpd.apache.org/docs/2.2/mod/mod_headers.html), but this module
> is disabled by default. It is not mentioned in mod_security's installation
> documentation:
> http://www.modsecurity.org/documentation/modsecurity-apache/2.5.12/modsecu
> rity2-apache-reference.html#installation.
> 

This is a new experimental rule set and thus we haven't gone back to update any of the 
ModSecurity install data for it.  I believe it is best to mention it in the CRS README and 
in the comments for this file.

> Can we add a note to configure Apache with: --enable-headers for this
> optional rule?
> 
> Also, would it be prudent to enclose the entire file or perhaps just the
> RequestHeader lines inside a <IfModule mod_headers.c> </IfModule>
> condition?  I did so and got ModSecurity to load this rule and start up.
> 

Good idea.

On another note for the 49 request header tagging file - I am assuming you are running 
ModSecurity on a reverse proxy, correct?  This rules file will add Mod alert match data to 
some new Request Headers when it is proxied so that the destination server may inspect 
them and potentially take action.  Is this your intent?  Are you going to try and inspect 
these headers on the destination app?  I am interested in the request header concept as I 
believe that it has potential for WAFs to share data with the destination app servers but 
it is a new concept and I want to get feedback from users.

Cheers,
Ryan