----- Original Message -----
>
> ----- Original Message -----
> > It is all on this doc:
> >
> > https://bitbucket.org/dcid/ossec-hids/src/002e73da1e46/src/analysisd/eventinfo.c
> > :)
> >
> > Joking aside, I don't think this is documented anywhere. Since
> > english
> > is not my main language,
> > those keywords always made sense to me, but changing them right now
> > would create more issues
> > than by improving the docs and explaining well what they do.
> >
> > Thanks,
> >
> > On Thu, Feb 10, 2011 at 4:50 PM, --[ UxBoD ]-- <[email protected]>
> > wrote:
> > > ----- Original Message -----
> > >> Seems to me that there is also an interpretation that, once the
> > >> rule
> > >> has fired and six more firings have occurred, there will be a
> > >> frequency alert for each subsequent firing until the events per
> > >> time
> > >> interval is no longer operative. I realize that most "frequency
> > >> warning systems" don't do this but instead reset to zero after
> > >> each
> > >> event/interval firing has occurred.
> > >>
> > >> I have problems with the nomenclature for this: the word
> > >> "frequency"
> > >> really (in the real world) means some number of events per unit
> > >> of
> > >> time, but in the OSSEC rule definition it really means more like
> > >> "count", and "timeframe" really means "interval". This confused
> > >> me
> > >> for a fair while at first until I saw some examples and read
> > >> their
> > >> explanations. I think that changing these to "count" and
> > >> "interval",
> > >> instead of "frequency" and "timeframe", would go a long way to
> > >> improving understanding of this kind of rule.
> > >>
> > >> --
> > >> Shane Castle
> > >> Data Security Mgr, Boulder County IT
> > >> CISSP GSEC GCIH
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: [email protected]
> > >> [mailto:[email protected]] On Behalf Of --[ UxBoD ]--
> > >> Sent: Thursday, February 10, 2011 13:11
> > >> To: [email protected]
> > >> Subject: Re: [ossec-list] Overriding a rule
> > >>
> > >> ----- Original Message -----
> > >> > Hey,
> > >> >
> > >> > The frequency of 6, actually means 8 events for it to alert.
> > >> > It
> > >> > makes
> > >> > sense when you think of the rule in these terms:
> > >> >
> > >> > if_matched_sid -> Alert me if the rule XYZ fired in the last
> > >> > ABC
> > >> > seconds more than 6 times (not including the current event).
> > >> >
> > >> > So in your case, the rule 5551 will check if in the last few
> > >> > minutes
> > >> > the rule 5503 was set more than 6 times... So out of the 31
> > >> > events, you would get 3 alerts from the rule 5551.
> > >> >
> > >> > So why is that? Because you can write rules like this one:
> > >> >
> > >> > <if_group>authentication_success</if_group>
> > >> > <if_matched_group>authentication_failure</if_matched_group>
> > >> >
> > >> > So the current event is not tied to the list when searching on
> > >> > the
> > >> > if_matched_* signatures....
> > >> >
> > >> > Hope it made some sense :)
> > >> >
> > >> > Thanks,
> > >> >
> > >>
> > >> SNIP
> :) Daniel, how feasible would it be for it to check '>=' instead of
> '>' as then it would probably make more sense; 6 alerts and then
> trigger on the seventh ?
>
Still no further forward with getting the rule to work :( Have taken a fresh
look based on the information and help that has been given. I have 31 alerts in
my test file that I am passing through ossec-logtest. Here are my local rules:
<rule id="10044" level="1">
<if_sid>5551</if_sid>
<description>Multiple SSHD authentication failures (Override
Generic)</description>
<group>authentication_failures,</group>
</rule>
<rule id="10061" level="10" frequency="3" timeframe="180">
<if_matched_sid>10044</if_matched_sid>
<same_source_ip />
<description>Multiple SSHD authentication failures - GLPI #493</description>
<group>authentication_failures,</group>
</rule>
The first one triggers three times, as Daniel said it would, based on 31 / 8.
So how would one get rule 10061 to fire ? if we wanted it to alert when 10044
had hit three times do we set the frequency to be one ? I am guessing that the
granularity we are trying to achieve by using compound rules is not possible ?
