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.
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.
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}".
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?
Cheers,
Rm4dillo
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
[email protected]
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
