----- Original Message ----- > ----- 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 ? >
Any thoughts on this please ? if compound based rules are not possible due to how frequency works we need to know as we shall write as single ones instead. Sorry, we just really need to know what action to take in helping secure our servers. Thanks, Phil
