[ossec-list] Re: rule chaining

[Josh Drummond <jdrummon@xxxxxxx>]

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