Many thanks,
I've been playing around with ossec-logtest, and think I have
discovered these facts:
1. If two (or more?) rules match the same log line
then the one with the lowest level wins. They
will not both be activated. The rule id doesn't matter.
1a. If the levels are the same, then the first rule occurring in
the file
wins.
2. If you'd like to give precedence to rule that should trigger a
response,
and it is competing with a rule that has a lower level, then set
the
level to match that of the competing rule. Move your rule above
(closer to the
beginning of the file) the competing rule. Add another rule with
<if_sid> pointing
to your rule. Set its level to the level you want. Include the
description. Drop the
pattern match.
Am I right? Is there more to this?
murf
On Jan 9, 3:05 pm, BP9906 <crazi...@gmail.com> wrote:
> From experience, the way it should be done is:
>
> (Untested)
>
> <rule id="STUFF1" level="1">
> <if_sid>5701</if_sid>
> <hostname>servername</hostname>
> <match>Bad protocol version identification 'quit' from UNKNOWN$</
> match>
> <description>Ignore error from servername</description>
> <options>no_log</options>
> </rule>
>
> <rule id="STUFF2" level="7" frequency="0" timeframe="300">
> <if_matched_sid>STUFF1</if_matched_sid>
> <hostname>servername</hostname>
> <match>Bad protocol version identification 'quit' from UNKNOWN$</
> match>
> <description>Stuff1 happened 3 times in 5 min</description>
> </rule>
>
> **some notes here: A) frequency is 0, but ossec logic is that it
> happened 2+frequency. B) Using level 0 fails on frequency alerts, so
> using alert 1 + no_log option will generate the outcome you expect but
> not log the first event.
>
> On Jan 9, 6:50 am, murf <m...@parsetree.com> wrote:
>
>
>
>
>
>
>
> > On Jan 7, 8:42 am, "dan (ddp)" <ddp...@gmail.com> wrote:
>
> > > On Fri, Jan 6, 2012 at 10:49 PM, murf <m...@parsetree.com> wrote:
> > > > Here I am again. I have a machine where the "big brother" stuff is
>
> > > People still use big brother?
>
> > Apparently!
>
> > Don't look at me-- I just secure the stuff!
>
> > > > How exactly (or even roughly) would this sort of thing be achieved?
>
> > > > murf
>
> > > What do you have so far?
>
> > > Untested:
> > > <rule id="STUFF" level="0">
> > > <if_sid>5701</if_sid>
> > > <match>Bad protocol version identification 'quit' from UNKNOWN$</match>
> > > <description>Ignore from bb</description>
> > > </rule>
>
> > > <rule id="STUFF1" level="7" frequency="0" timeframe="300">
> > > <if_sid>STUFF</if_sid>
> > > <description>More than 1 STUFF in 5 minutes</description>
> > > </rule>
>
> > I'm flying blind here. I read the docs and they aren't being really
> > very helpful
> > in this regard.
>
> > I see that if_sid, if_group, if_level, if_matched_sid gives me some
> > "conditionals"
> > on the activation of a rule, and that these can form a hierarchy.
>
> > Do the rules ALL get tested and matched? Rule evaluation does not stop
> > with the
> > first match?
>
> > The "if_xxxx"'s are the only way to stop conditionally stop a rule
> > evaluation?
>
> > If the above is true, then maybe, just maybe, I could put something
> > together that
> > might work, but it would be nice if the above list (if_sid, etc) had
> > inverses, like
> > if_not_sid, if_not_group, etc.
>
> > Can a rule belong to more than one group? Can I define a group in a
> > group? There's
> > no syntax definition for group in thewww.ossec.net/doc/syntaxstuff
> > on the ossec site.
>
> > I see that a group option exists under <rule>. But beyond "Add
> > additional groupings to the alert",
> > there is nothing more said about it.
>
> > As to your example, the docs do state that if you use level 0, then
> > the rule is tossed immediately,
> > and will not trigger a if_matched_sid, so, assuming the if_matched_sid
> > (as Chris noted), and
> > a level > 0, with perhaps an <options>no_log</options> added, then...
>
> > I'll form my best guess at an attack after some of the above questions
> > are answered....
>
> > murf
