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