I guess the underlying issue Dan is that when the limit is reached OSSEC 
disregards the email_alerts stanza and coalesces all the emails into one.  The 
net result is that internal system information could easily be leaked to 
clients; not good at all.
-- 
Thanks, Phil

----- Original Message -----
> On Fri, May 18, 2012 at 4:06 AM, Phil Daws <[email protected]>
> wrote:
> > Interestingly, as a colleague noted, perhaps what should happen is
> > that if the max message limit is reached it should still honour
> > the email alert rules and *not* combine them into a coalesced one.
> > Does that make sense ?
> > --
> > Thanks, Phil
> 
> 
> I think the 0 idea has merit. This idea however would just make you
> further and further behind in notification emails. Perhaps a log
> message about having hit the max emails per hour would be
> appropriate.
> 
> 
> >
> > ----- Original Message -----
> >> A nice feature request would be by setting that to zero limiting
> >> is
> >> completely suppressed. Would that be possible ?
> >>
> >> --
> >> Thanks, Phil
> >>
> >> ----- Original Message -----
> >> > Thanks Dan that is perfect :)
> >> > --
> >> > Thanks, Phil
> >> >
> >> > ----- Original Message -----
> >> > > On Thu, May 17, 2012 at 10:21 AM, Phil Daws
> >> > > <[email protected]>
> >> > > wrote:
> >> > > > We have that already set ... am wondering if the option is
> >> > > > not
> >> > > > exposed and it is a true internal throttling restriction.
> >> > > >  The
> >> > > > problem is when you have something like this in your
> >> > > > ossec.conf:
> >> > > >
> >> > >
> >> > > Sorry, crystal ball's on the fritz.
> >> > >
> >> > > >  <global>
> >> > > >    <email_notification>yes</email_notification>
> >> > > >    <email_to>[email protected]</email_to>
> >> > > >    <smtp_server>email.somedomain.com</smtp_server>
> >> > > >    <email_from>[email protected]</email_from>
> >> > > >  </global>
> >> > > >
> >> > > >  <email_alerts>
> >> > > >    <email_to>[email protected]</email_to>
> >> > > >    <rule_id>10201, 10202, 10203, 10204</rule_id>
> >> > > >    <event_location>[email protected]</event_location>
> >> > > >    <do_not_delay/>
> >> > > >    <do_not_group/>
> >> > > >  </email_alerts>
> >> > > >
> >> > > > can end up that the customer receives alerts for systems
> >> > > > that
> >> > > > they
> >> > > > should not see :(
> >> > > > --
> >> > > > Thanks, Phil
> >> > > >
> >> > >
> >> > > Does this happen at the beginning of the hour? If so, you're
> >> > > possibly
> >> > > hitting the max emails per hour limit. Raise that up, see if
> >> > > it
> >> > > helps.
> >> > >
> >> > > > ----- Original Message -----
> >> > > >> http://www.ossec.net/doc/syntax/head_internal_options.analysisd.html#intopt-maild.groupping
> >> > > >>
> >> > > >> Maybe?
> >> > > >>
> >> > > >> On Thu, May 17, 2012 at 9:59 AM, Phil Daws
> >> > > >> <[email protected]>
> >> > > >> wrote:
> >> > > >> > Hello,
> >> > > >> >
> >> > > >> > when there is a flood of alerts I believe OSSEC throttles
> >> > > >> > them
> >> > > >> > to a
> >> > > >> > 15
> >> > > >> > minute window and then sends out emails.  Is there a way
> >> > > >> > to
> >> > > >> > disable
> >> > > >> > this
> >> > > >> > feature as I have noticed that sometimes alerts are going
> >> > > >> > to
> >> > > >> > people
> >> > > >> > that
> >> > > >> > should not be receiving them!
> >> > > >> > --
> >> > > >> > Thanks, Phil
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >>
> 

Reply via email to