Oups... id collision... 981174 seems to be available
On Thu, Sep 29, 2011 at 10:35 AM, rm4dillo D <[email protected]> wrote:
> - 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
