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