[ossec-list] Re: rule chaining

[Josh Drummond <jdrummon@xxxxxxx>]

Ah yes, that does make sense now.  Highest to lowest with zero the 
"ace" of the deck.

Thanks much,
~Josh

At 07:25 PM 8/13/2007, you wrote:

>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
> > > >
> > > >
> >
> >