Ah, so I still can't read :-) . Ryan, so sorry
for any unnecessary grief.
The only reason I haven't upgraded to a later
version of modsecurity is that I run into lua
problems on my CentOS 4.8-based Web server if I
do (lua-5.0.2 is the last RPM-based version that
I can use the doesn't break stuff and, iirc,
ModSecurity v2.5.12 and greater needs lua-5.1x).
That said, I edited
modsecurity_crs_49_inbound_blocking.conf, as per
Ryan's instructions, and we're all good.
If I might I one more question, having edited the
file, what is the effect of not doing macro
expansion? How much does it "weaken" the rule?
My sincere thanks, once again, for your help Ryan.
Dimitri
On Thursday 06 January 2011 4:15:50 pm Ryan
Barnett wrote:
> Ok, I think I found Dimitri's issue. I am
> sending this out the list so others are aware.
>
> Dimitri sent me an audit log file and it showed
> that is using ModSecurity v2.5.9. The macro
> expansions used in the 49 inbound blocking file
> use features of ModSecurity v2.5.12 and
> greater. This is listed in the
> modsecurity_crs_10_config.conf.example file -
>
>
> #
> # -=[ Anomaly Scoring Threshold Levels ]=-
> #
> # These variables are used in macro expansion
> in the 49 inbound blocking and 59
> # outbound blocking files.
> #
> # **MUST HAVE** ModSecurity v2.5.12 or higher
> to use macro expansion in numeric
> # operators. If you have an earlier version,
> edit the 49/59 files directly to
> # set the appropriate anomaly score levels.
> #
> # You should set the score to the proper
> threshold you would prefer. If set to "5"
> # it will work similarly to previous Mod CRS
> rules and will create an event in the error_log
> # file if there are any rules that match. If
> you would like to lessen the number of events
> # generated in the error_log file, you should
> increase the anomaly score threshold to
> # something like "20". This would only
> generate an event in the error_log file if
> # there are multiple lower severity rule
> matches or if any 1 higher severity item
> matches.
> #
> SecAction
> "phase:1,t:none,nolog,pass,setvar:tx.inbound_an
>omaly_score_level=5" SecAction
> "phase:1,t:none,nolog,pass,setvar:tx.outbound_a
>nomaly_score_level=4"
>
>
>
> This means that for Dimitri's install, the
> following part of the chained rule in the
> modsecurity_crs_49_inbound_blocking.conf file
> is not doing macro expansion to properly
> evaluate the tx.inbound_anomaly_score_level
> against the @ge operator -
>
> SecRule TX:ANOMALY_SCORE "@ge
> %{tx.inbound_anomaly_score_level}"
>
>
> So, Dimitri - you have two options:
>
> 1) Upgrade ModSecurity to the latest version
> (recommended), or 2) As the comments say above,
> if you can't upgrade, you need to edit the 49
> file and change the rule so that it doesn't use
> macro expansion -
>
> SecRule TX:ANOMALY_SCORE "@ge 5"
>
> Hope this helps,
> Ryan
>
> On 1/6/11 10:24 AM, "Dimitri Yioulos"
<[email protected]> wrote:
> >All,
> >
> >Anything more on this?
> >
> >Thanks.
> >
> >Dimitri
> >
> >
> >On Tuesday 04 January 2011 4:22:20 pm Dimitri
> >
> >Yioulos wrote:
> >> The value in the 10 config file is the
> >> default:
> >>
> >> SecAction
> >> "phase:1,t:none,nolog,pass,setvar:tx.inbound
> >>_an omaly_score_level=5" SecAction
> >> "phase:1,t:none,nolog,pass,setvar:tx.outboun
> >>d_a nomaly_score_level=4"
> >>
> >> Dimitri
> >>
> >>
> >> On Tuesday 04 January 2011 4:03:31 pm Ryan
> >> Barnett
> >>
> >> wrote:
> >> > The alerts say that there was a user-agent
> >> > string match (mozilla 4.0( ) with the
> >> > comment spam rules. This match raised the
> >> > tx.inbound_anomaly_score to 3. What do you
> >> > have this value set to in the 10 config
> >> > file? By default the blocking level is 5.
> >> >
> >> > --
> >> > Ryan Barnett
> >> >
> >> > On Jan 4, 2011, at 3:46 PM, Dimitri
> >> > Yioulos
> >>
> >> <[email protected]> wrote:
> >> > > On Tuesday 04 January 2011 3:21:41 pm
> >> > > you
> >>
> >> wrote:
> >> > >> On Tue, Jan 4, 2011 at 10:01 PM,
> >> > >> Dimitri Yioulos
> >> > >
> >> > > <[email protected]> wrote:
> >> > >>> Did I forget something in setting up
> >> > >>> Anomoly Scoring Detection Mode, or
> >> > >>> misconfigure something?
> >> > >>
> >> > >> Hi Dimitri,
> >> > >>
> >> > >> What do the logs say?
> >> > >>
> >> > >> --
> >> > >> - Josh
> >> > >
> >> > > Josh,
> >> > >
> >> > > I'm not great at deciphering the log
> >> > > messages that modsec generates. I think
> >> > > I've captured some relevant data, and
> >> > > put it here:
> >> > >
> >> > > http://pastebin.com/kCQ9i8p4
> >> > >
> >> > > Dimitri
> >> > >
> >> > > --
> >> > > This message has been scanned for
> >> > > viruses and dangerous content by
> >> > > MailScanner, and is believed to be
> >> > > clean.
> >> > >
> >> > > ________________________________________
> >> > >___ __ __ Owasp-modsecurity-core-rule-set
> >> > > mailing list
> >> > > [email protected]
> >> > >asp .o rg
> >> > > https://lists.owasp.org/mailman/listinfo
> >> > >/ow as p-modsecurity-core-rule-set
> >
> >--
> >This message has been scanned for viruses and
> >dangerous content by MailScanner, and is
> >believed to be clean.
> >
> >______________________________________________
> >_ Owasp-modsecurity-core-rule-set mailing list
> > [email protected]
> >rg
> > https://lists.owasp.org/mailman/listinfo/owas
> >p-modsecurity-core-rule-set
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
[email protected]
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
