On Fri, May 18, 2012 at 10:47 AM, Phil Daws <[email protected]> wrote: > 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 >
You could solve this by not reaching the max emails per hour or using a tiered architecture. > ----- 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 >> >> > > >> > >> >> > > >> >> >> > > >> >> > >> >> >>
