- Thanks for the second issue's solution. It suits me perfectly!
- Concerning the first and third issues (as I think that they'll share the
same solution), I'm already using a "SecDefaultAction" that logs everywhere
(for log parsing purposes); but suppose I'm in "Detection" mode and I'd like
to count the requests that ModSecurity would have rejected if I move to
"Blocking" mode. The fast&easy way to do that would be to count lines that
contain "Inbound Anomaly Score Exceeded" but it's currently unreliable as
described in my previous e-mail.
The change you've brought still doesn't fix it. What about this?
# Alert and Block based on Anomaly Scores
#
SecRule TX:/^\d+\-/ "(.*)" "pass,nolog,capture"
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_BLOCKING "@streq on" chain
SecRule TX:ANOMALY_SCORE "@ge
%{tx.inbound_anomaly_score_level}"
and as an extra:
# Alert if Anomaly Score does not exceed the Anomaly Score Level
#
SecRule TX:/^\d+\-/ "(.*)" "pass,nolog,capture"
SecRule TX:ANOMALY_SCORE "@gt 0" \
"chain,phase:2,id:'981176',t:none,pass,log,msg:'Inbound Anomaly Score
(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_BLOCKING "@streq on" chain
SecRule TX:ANOMALY_SCORE "@lt
%{tx.inbound_anomaly_score_level}"
What do you thing of that? Sad that we missed 2.2.2 for this issues, is
there any planned date for the 2.2.3 ?
Thanks Ryan
Rm4dillo
On Wed, Sep 28, 2011 at 10:35 PM, Ryan Barnett <[email protected]>wrote:
>
> 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
