[ossec-list] Re: rule chaining

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

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