From: rm4dillo D <[email protected]<mailto:[email protected]>>
Date: Wed, 28 Sep 2011 12:18:17 -0500
To:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [Owasp-modsecurity-core-rule-set] 981176's last matched data issues
I have three questions concerning the changes that have been applied to the
rule 981176 in order to add the last matched data in the log line.
Yeah, these rules in the 49 inbound blocking file can certainly be improved
upon.
First, when ModSecurity is in "DetectionOnly" mode, the chained rule ( SecRule
TX:/^\d/ "(.*)" ) that has been added is triggered as many times as the number
of variable names in the transaction collection that match the "^\d" regular
expression. This makes ModSecurity log only one entry when it's in the
"Blocking" mode and lots of entries when in "DetectionOnly" mode.
This is true however you can control how you want the rules to log by editing
the SecDefaultAction within the 10 config file. If you wan to run in anomaly
scoring mode with blocking and less logging, then you can set SecDefaultAction
to "pass,nolog,auditlog" and this will mean that each individual SecRule will
log an entry to the audit log but only the rules in the 40 inbound blocking
file will log to the Apache error_log. This will give you the overall anomaly
score and data on the last rule match.
If you want to run in anomaly scoring mode with blocking but to have more
logging in the Apache error log, then simply change the SecDefaultAction to
"pass,log" and this means that all rules will log to both the audit and error
logs. This is more chatty obviously but you will still have all logging.
The second issue with this chained rule is that the "^\d" regular expression is
not discriminant enough as it matches the "capture" action variables "TX:0",
"TX:1", ... and "TX:9" when in "DetectionOnly" mod. A quick fix to avoid that
would be replacing the regular expression by "^/d{2}".
Agreed. I updated it to this and it seems to work better -
SecRule TX:/^\d+\-/ "(.*)"
The last issue (still related to this chained rule; I think that I don't like
it much ;-) ) is that the "matched_var" variable does not really contain the
"Last Matched Data". In "DetectionOnly" mode, it will only be valid for the
last logged line as it corresponds to the last matched rule and erroneous for
all the other lines (Cf. first issue). In "Blocking" mode (as we log only once
then the request is rejected if the score has exceeded) it will contain the
matched data of the first rule that matched and the message (tx.msg) of the
last one.
This produces misleading logs as the one below:
[Wed Sep 28 18:44:53 2011] [error] [client ::1] ModSecurity: Warning.
Pattern match "(.*)" at TX:959073-WEB_ATTACK/SQL_INJECTION-ARGS:test. [file
"/etc/modsecurity/activated_rules/modsecurity_crs_49_inbound_blocking.conf"]
[line "26"] [id "981176"] [msg "Inbound Anomaly Score Exceeded (Total Score:
44, SQLi=15, XSS=30): Last Matched Message: IE XSS Filters - Attack Detected"]
[data "Last Matched Data: benchmark("] [hostname "localhost"] [uri "/"]
As most rules use the "capture" action, why don't we replace the chained rule
"hack?" with a simple "logdata:'Last Matched Data: %{tx.0}". This still would
be better but still not perfect as the content will sometimes be erronuous
because some rules can't capture. Or, even cleaner, why don't we add a
"setvar:'tx.last_matched_data=..." in every rule?
I updated the rules to use the following. Let me know if this is any better -
# Alert and Block based on Anomaly Scores
#
SecRule TX:ANOMALY_SCORE "@gt 0" \
"chain,phase:2,id:'981176',t:none,deny,log,msg:'Inbound Anomaly Score
Exceeded (Total Score: %{TX.ANOMALY_SCORE}, SQLi=%{TX.SQL_INJECTION_SCORE},
XSS=%{TX.XSS_SCORE}):
%{tx.msg}',logdata:'%{tx.0}',setvar:tx.inbound_tx_msg=%{tx.msg},setvar:tx.inbound_anomaly_score=%{tx.anomaly_score}"
SecRule TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_level}" chain
SecRule TX:ANOMALY_SCORE_BLOCKING "@streq on" chain
SecRule TX:/^\d+\-/ "(.*)" "capture"
-Ryan
Cheers,
Rm4dillo
________________________________
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
