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

That's possible no matter how you set it up. As long as you limit the
number of email alerts that can be sent out, one system can DoS your
alert mechanism.

> I know, it's not a feature of OSSEC right now.  And I'm free to submit a
> feature request or better than that, submit a patch. ;)
>
>
>>> The OSSEC server is performing very well with all the events, but I
>>> need a way to send out email alerts without mixing different divisions
>>> together (see below).
>>
>> 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. So, basically the same
amount of traffic you saw before. The only addition is the data sent
from the spokes to the hub, but that's generally the alerts from the
division servers, not every log. That makes the amount of traffic much
smaller.

The only additional processing necessary is looking at the alerts from
the division servers. It doesn't have to look at every log message, so
this isn't a huge drain on resources.

You could even put the division servers in the same physical location
as the hub server, so the data transfer doesn't have to take up any
slower links.

> every OSSEC server has to analyse all the stuff again, which results
> into more hardware / CPU usage.
>
>
>> Submit a patch and it should be accepted, after 2.7 anyhow.
>
> I'll think about it.
>
> Thanks for OSSEC, nice work.
>

Reply via email to