On Tue, Sep 18, 2012 at 2:48 PM, Juergen Kahnert <[email protected]> wrote: > On Tue, Sep 18, 2012 at 11:40:49AM -0400, dan (ddp) wrote: >> On Tue, Sep 18, 2012 at 11:21 AM, Juergen Kahnert >> <[email protected]> wrote: >>> On Tue, Sep 18, 2012 at 10:50:51AM -0400, dan (ddp) wrote: >>>> On Tue, Sep 18, 2012 at 10:44 AM, Juergen Kahnert >>>> <[email protected]> wrote: >>>>> The global option email_maxperhour would also be very useful inside >>>>> email_alerts. My testalert stuff consumed all mails per hour so that >>>>> rule 100005 to [email protected] was suppressed (until the end of >>>>> hour). >>>> >>>> So increase the max emails per hour setting. >>> >>> But that's not the same. There can be still one system consuming all >>> alert mails and suppress other alerts. > > This won't happen if OSSEC would allow something like this: > > <email_alerts> > <email_maxperhour>12</email_maxperhour> > ... > </email_alerts> > > The global email_maxperhour counts everything, the option inside > email_alerts just for itself. Even if a system would produce thousands > of alerts per seconds, the global counter would only decrease by 12 (in > this example). >
Then the delayed emails would have to be tracked for each email_alerts section. Gets complicated. I'm not totally against the idea though. Definitely something to ponder. > >>>> Use different OSSEC servers (in hybrid mode if you use 2.7) for each >>>> division, and funnel all alerts to a single server for the people who >>>> need to see everything. >>> >>> But than I have to multiply the syslog traffic by n divisions and also >> >> Why? Each division gets an OSSEC server. It accepts all logs from all >> of the systems the division wants to monitor. > > We have divisions for the operating systems, than divisions for the > services running on those systems, etc. > > The same system produces syslogs for different divisions. Sure, you can > configure those systems to send syslogs to different servers depending > on the facility. > > But come on, the tool has to fit into a given environment and not that > the entire environment has to be reconfigured for every new tool... > > Especially if just a bit of flexibility is missing. > Sounds clunky.
