[ossec-list] Re: rule chaining

["Daniel Cid" <daniel.cid@xxxxxxxxx>]

Hi Josh,

It is not the lower level that determine the ordering, but the highest
one. However,
we treat 0 as being the highest.

So, the order is always:

-->
0,15,14,13...3,2.1.

Hope it makes sense.

--
Daniel B. Cid
dcid ( at ) ossec.net


On 8/10/07, Josh Drummond <jdrummon@xxxxxxx> wrote:
>
> Daniel,
>
> Thanks, that is a more succinct way to model the logic.  I'd also
> like to mention for those keeping score at home that for both my 2nd
> (yet verbose) method and Daniel's method, the special case where rule
> #2501 was getting fired no longer required an extra custom rule to
> mute it (my #100003).
>
> Although I still don't quite understand why #2501 which is level 5
> and has no <if_sid> or <decoded_as> parents was getting called before
> my original local rules that were at a lower level 3 (before I added
> the level 0 rule to ignore 2501).... if it is the lower level that
> determines ordering?
>
> Thanks,
> ~Josh
>
> At 07:46 PM 8/9/2007, you wrote:
>
> >Hi Josh,
> >
> >A few changes for your decoders to make them more robust (never checking the
> >same information twice):
> >
> ><decoder name="xauthcheck">
> >   <program_name>XAuth</program_name>
> ></decoder>
> >
> ><decoder name="xauthcheck-success">
> >   <parent>xauthcheck</parent>
> >   <prematch>SUCCEEDED for</prematch>
> >   <regex>XAuthCheck from (\S+) by (\S+) SUCCEEDED for user (\S+)</regex>
> >   <order>srcip, url, user</order>
> ></decoder>
> >
> ><decoder name="xauthcheck-failure">
> >   <parent>xauthcheck</parent>
> >   <prematch>FAILED because</prematch>
> >   <regex>XAuthCheck from (\S+) by (\S+) FAILED</regex>
> >   <order>srcip, url</order>
> ></decoder>
> >
> >Now, for the rules, as I said, it is based on the severity, with the 0
> >starting first. In
> >addition to that, the rules are also first match, so as soon as a rule
> >fires, it stops
> >checking the others. A simple way to have your rules is:
> >
> >  <rule id="100100" level="0">
> >     <decoded_as>xauthcheck</decoded_as>
> >     <description>XAuthCheck grouped</description>
> >   </rule>
> >
> >   <rule id="100102" level="3">
> >     <if_sid>100100</if_sid>
> >     <match>SUCCEEDED for</match>
> >    <description>XAuthCheck Success</description>
> >   </rule>
> >
> >   <rule id="100103" level="3">
> >     <if_sid>100100</if_sid>
> >     <match>FAILED because</match>
> >     <description>XAuthCheck Failure</description>
> >   </rule>
> >
> >It guarantees that the 100100 is going to be checked first, followed
> >by the 1001002 and
> >100103...
> >
> >Hope it helps.
> >
> >--
> >Daniel B. Cid
> >dcid ( at ) ossec.net
> >
> >
> >On 8/9/07, Josh Drummond <jdrummon@xxxxxxx> wrote:
> > >
> > > At 06:10 PM 8/8/2007, Daniel Cid wrote:
> > >
> > > >Hi Josh,
> > > >
> > > >Reply inline...
> > > >
> > > >On 8/8/07, Josh Drummond <jdrummon@xxxxxxx> wrote:
> > > > >
> > > > >
> > > > > I've setup custom decoders and rules for a custom log format I would
> > > > > like to monitor.
> > > >
> > > >Can you post them to us? Seeing the decoders/rules will make
> > things easier.
> > >
> > > Here is (as example) what I currently have that doesn't seem to work:
> > >
> > > Decoders:
> > >
> > > <decoder name="xauthcheck-success">
> > >    <program_name>XAuth</program_name>
> > >    <prematch>SUCCEEDED for</prematch>
> > >    <regex>XAuthCheck from (\S+) by (\S+) SUCCEEDED for user (\S+)</regex>
> > >    <order>srcip, url, user</order>
> > > </decoder>
> > >
> > > <decoder name="xauthcheck-failure">
> > >    <program_name>XAuth</program_name>
> > >    <prematch>FAILED because</prematch>
> > >    <regex>XAuthCheck from (\S+) by (\S+) FAILED</regex>
> > >    <order>srcip, url</order>
> > > </decoder>
> > >
> > >
> > > Rules:
> > >
> > >    <rule id="100003" level="0">
> > >      <if_sid>2501</if_sid>
> > >      <program_name>XAuth</program_name>
> > >      <description>Ignore general user auth failure for xauthcheck
> > > logs</description>
> > >    </rule>
> > >
> > >    <rule id="100100" level="3">
> > >      <decoded_as>xauthcheck-success</decoded_as>
> > >      <description>XAuthCheck Success</description>
> > >    </rule>
> > >
> > >    <rule id="100101" level="3">
> > >      <decoded_as>xauthcheck-failure</decoded_as>
> > >      <description>XAuthCheck Failure</description>
> > >    </rule>
> > >
> > > So my rule #100003 suppresses default rule #2501 if my custom decoded
> > > log is the entry being examined, that works.  However custom rule
> > > #100101 that should also match (its a case where the end of the url
> > > token has "login", thus triggering rule #2501 with the match on
> > > "login FAILED") doesn't get triggered.  That rule does get triggered
> > > for all cases that don't match #2501, so that is known to work.
> > >
> > > It sounds like because those two rules are level 3, that they won't
> > > get fired because a level 0 rule came first?  Using this logic I made
> > > the following changes to the rules:
> > >
> > >    <rule id="100100" level="0">
> > >      <decoded_as>xauthcheck-success</decoded_as>
> > >      <description>XAuthCheck Success</description>
> > >    </rule>
> > >    <rule id="100102" level="3">
> > >      <if_sid>100100</if_sid>
> > >      <description>XAuthCheck Success</description>
> > >    </rule>
> > >
> > >    <rule id="100101" level="0">
> > >      <decoded_as>xauthcheck-failure</decoded_as>
> > >      <description>XAuthCheck Failure</description>
> > >    </rule>
> > >    <rule id="100103" level="3">
> > >      <if_sid>100101</if_sid>
> > >      <description>XAuthCheck Failure</description>
> > >    </rule>
> > >
> > > in order for the custom rules to be on the same "level" as the muted
> > > #2501.  This actually does work, but seems clunky and duplication of
> > > work for just this specific case.  I don't quite understand the
> > > reasoning for the dependence of rule levels?
> > >
> > >
> > > > >Everything seems to be working correctly except in
> > > > > the case where the custom log just happens to match one of the
> > > > > default rules as well (rule #2501, its matching on "login
> > > > > failed").
> > > > >So it looks like it is firing off the rule and not
> > > > > continuing.  I tried writing another local rule that ignores that
> > > > > 2501 rule if the <program_name> matches my custom decoded program,
> > > > > and this works as well.  However, although it now ignores rule #2501
> > > > > in that special case, it still doesn't fire off my custom local rule
> > > > > that matches it further down the chain.  It seems like the first rule
> > > > > it finds that matches (or ignores) the log, it stops right there, and
> > > > > I'm guessing since it starts with the low-numbered rules (the default
> > > > > ones) it will never get to my local rules.  Is there a way around this?
> > > >
> > > >Yes, there is. Since you wrote a decoder for your rules, you can
> > write a rule
> > > >like:
> > > >
> > > >   <rule id="100100" level="0">
> > > >     <decoded_as>my_custom_decoder</decoded_as>
> > > >     <description>All the messages from my decoder.</description>
> > > >   </rule>
> > > >
> > > >And in all your other rules, use "<if_sid>100100</if_sid>".
> > > >
> > > >The way the rules are organized are not based on the id, but on the
> > > >severity (starting
> > > >with the level 0, followed by the highest ones). That's why on most of
> > > >our rules we
> > > >have a "grouped" entry with severity 0, just matching on the decoder,
> > > >to make sure
> > > >they are evaluated first... Does it make sense?
> > > >
> > > >
> > > > > Thanks,
> > > > > ~Josh
> > > >
> > > >
> > > >Hope it helps.
> > > >
> > > >--
> > > >Daniel B. Cid
> > > >dcid ( at ) ossec.net
> > >
> > >
>
>