Just set the frequency to one, so it will catch after 3 events.... thanks,
On Tue, Feb 15, 2011 at 5:54 AM, --[ UxBoD ]-- <[email protected]> wrote: > ----- 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 ? >
