2.2.4
On Mon, Oct 24, 2011 at 6:25 PM, rm4dillo D <rm4dillo@...> wrote:
> Same applies for modsecurity_crs_59_outbound_blocking.conf.
>
> May those changes be applied in the 2.2.3 ?
>
> Thanks
>
> Rm4dillo
>
>
> On Thu, Sep 29, 2011 at 10:36 AM, rm4dillo D <rm4dillo@...> wrote:
>
>> Oups... id collision... 981174 seems to be available
>>
>>
>> On Thu, Sep 29, 2011 at 10:35 AM, rm4dillo D <rm4dillo@...> 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 <RBarnett@...:
>>>
>>>>
>>>> From: rm4dillo D <rm4dillo@...>>
>>>> Date: Wed, 28 Sep 2011 12:18:17 -0500
>>>> To: "owasp-modsecurity-core-rule-set@...:
>>>> owasp-modsecurity-core-rule-set@...>" <
>>>> owasp-modsecurity-core-rule-set@...:
>>>> owasp-modsecurity-core-rule-set@...>>
>>>> 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.
>>>>
>>>>
>>>
>>
>
>
|