Email - Alert. Buffered Events Configuration

Hi streetfox, 

i think i found it.
But you can not change it in the WebGUI, you need to make modifications in a file on the commandline.

As i understand the system, the process ips-reporter.pl handles the statistics and email-sending for the ips.

open the file:
/usr/local/bin/reporter/ips-reporter.pl

go to line: 37
and change the line to:
my $max_events = 1000;           # max event buffer

save it and restart the syslog server with:
/etc/init.d/syslogng restart

and you are done.

hope that helps, 
regards polluxxx

Hi thanks for the message, this was fast. I'll try and give a comment if it worked.

Second...some suggestions for the notification mails:

It would *really* be a good idea to include not only the system uptime but also the system time during detection !! Because otherwise it is pretty useless

 [ QUOTE ]
 
A packet was identified that may be part of an intrusion attempt. 
The packet was detected by the Intrusion Detection system. The matching 
rule classified this as medium priority level. The packet properties 
and the alert reason are:

[1:499:0] A ICMP Large ICMP Packet [Classification: Potentially Bad Traffic] [Priority: 2]:  {PROTO001} xx.xxx.xxx.x -> xxx.xxx.xxx.xxx


-- 
Last WebAdmin login: admin at Thu Jan  6 08:03:22 from xxx.xxx.xxx.xxx
System Uptime      : 0 days 14 hours 39 minutes
System Load        : 0.14
System Version     : Astaro Security Linux 5.100
License usage      : 2 of 10 users active

Please refer to the manual for detailed instructions.
 
 

[/ QUOTE ]

This value suggested by polluxxx is only a maximum value of events which will get buffered. This is a DOS protection, because every IPS event needs memory to be buffered.

The actual number of events which are sent to you in those "buffered" notifications do not depend on that value - only the upper limit is controlled by this max value. As long as the maximum is not reached, you do not need to change that value. Instead, the number of events buffered depends on the number of events which occured in a certain time:

Every event generates a notification, until a limit is exceeded. Then, buffering begins, and events are collected for a certain time span. At the end of this time span, the buffered events are sent in those "buffer" notifications, and a new time span begins. If the event limit has been reached in the last time span, the time span is increased (in 5 minute steps, until 30 mins is reached). If the limit has not been reached, the time span is reduced (in 5 minute steps, until 5 mins is reached).

The reason for this behaviour is to not congest your mailbox if your network is under attack, and to minimize the effects of an attack on the functionality of the ASL.

As to your second point, the time stamping:  notifications are sent real-time, so the mail header date indicates the system time of the notification generation. But I can see your point, we will check if there is a need for an additional time stamp in notifications.

Regards,
andreas

Hi andreas

thanks for your detailed answer. It sure is a clever point of how to manage these events...but my mailbox receives each 30mins a mail with 100 buffered events and 5 notifications about an IP event + buffer activation.

As IT point of view I would not mind. As customer point of view I definately would. every 30min an email is too much and I do like to have a possibility to set a prio level and an event collection value for each prio-level. Say:

Prio 1: 0 buffered events (The intrusion attempt will be alerted directly)
Prio2: 1000 buffered events
Prio3: No notification

As an example, in the last 48(!) hours uptime the SASSER and BLASTER rule counted together 32'000 events, so my network segment is really unsecured by ISP (smile)

That would really be something you could include in the next major version. Together with the systime in the notification (by the way...the systime is missing also in the buffered events mail...so the timestamps of all but the least detection are cut off)

But Astaro is really on a good track to conquer with other products. As you leave your protection free it helps securing the internet.

cheers
streetfox

Hi andreas

thanks for your detailed answer. It sure is a clever point of how to manage these events...but my mailbox receives each 30mins a mail with 100 buffered events and 5 notifications about an IP event + buffer activation.

As IT point of view I would not mind. As customer point of view I definately would. every 30min an email is too much and I do like to have a possibility to set a prio level and an event collection value for each prio-level. Say:

Prio 1: 0 buffered events (The intrusion attempt will be alerted directly)
Prio2: 1000 buffered events
Prio3: No notification

As an example, in the last 48(!) hours uptime the SASSER and BLASTER rule counted together 32'000 events, so my network segment is really unsecured by ISP (smile)

That would really be something you could include in the next major version. Together with the systime in the notification (by the way...the systime is missing also in the buffered events mail...so the timestamps of all but the least detection are cut off)

But Astaro is really on a good track to conquer with other products. As you leave your protection free it helps securing the internet.

cheers
streetfox

Hi streetfox,

the problem is that on one side you want to be notified of bad things happening the instant they occur, and on the other side you don't want the IPS notifications to drown possibly more interesting things. To cross that gap, we decided that the network is really hammered with attacks, an admin could take 5 mails per 30 minutes. If you do not check your admin mailbox for more than a day, you can disable the IPS notifications altogether; the purpose of those notifications is to enable the admin to take immediate action. But enough of that, I am quite sure you already got the idea :-)

Regarding your suggestions: I don't think we'll ever implement "buffer" notifications without real-time notifications. That's what log files are for. The problem with sending a notification every n events is that you could possibly have an attack firing of 999 events, but the 1000th event which would lead to a notification occurs only hours (or days?) later. While designing that system we thought that a notification at most every 30 minutes would be a good compromise for most admins, but you can tune that easily by playing with the min_period and max_period values in the reporter. If you hit the maximum of 100 events per  period and you feel that you still have excess memory, you can increase max_events to a value you like more. We are trying to keep the things as simple as possible, since most users never need/use that feature. This is also true for the priority thing: you already can configure priorities for notifications, but only on a very rough "give me all / only the worst"-level. This fits most, but not all customers.

The timestamping issue is a diiferent thing: surely it would take more memory to store the actual timestamp of the buffered events, but that would be a tradeoff I'd be willing to make for the next version. Let's keep that in mind.

I am always eager  to hear suggestions on how to improve existing features (or add features if needed). Customer input, especially from power users, helps us a lot. The big community around ASL allowed us to push forward incredibly fast, from version 1.x to version 5. 
It is a huge gap between 3-user low hardware installations and high-end mulitprocessor gigabit environments with thousands of users, and we have to walk the narrow path of making a product which satisfies both ends. Don't be disappointed if some of your ideas don't make it into our product - it's the same for us. ;-)

Thanks for your input so far, and if you have still more ideas, don't hesitate to let us hear them!
Cheers,
andreas