----- 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, > >> > > >> > >> Hi Daniel, > >> > >> Thank you very much for taking the time to respond it is > >> appreciated. > >> > >> Would it not be 7 events then ? If 6 had come through, and one > >> discards the current, then you would be alerting on the seventh. > >> > >> Long day so trying to get my head around the logic :) > >> > >> Thanks, > >> > >> P. > >> > > > > Hi Shane, > > > > I kind of agree with that and the change in the names would be good > > IMHO. > > > > Would be interested to hear from Daniel in which FAQ/Doc this is in > > as I must have missed it! I even have the book :) > > > > Will need to go back and re-write a lot of our local rules based on > > this information as they will not be triggering as we expected; > > especially compound rules. > > > > Very useful discussion and very appreciative of all those who have > > posted. > > > > Thanks. > > > > P. > > >
:) 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 ?
