Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

Re: [Snort-devel] Re: Status alert

From: Martin Olsson <elof(at)sentor.se>
Date: Tue Feb 24 2004 - 11:17:13 EST


On Tue, 24 Feb 2004, Dirk Geschke wrote:

> Hi Martin,
>
> > Reasons to do it my way:
> > * If we in any case periodically receive alerts just to show us that
> > everything is working fine, why not include some interesting data in the
> > alert? It shouldn't introduce any negative impact on snort.
> ok, but the whole chain starts at the sniffing interface not
> with a snort process acting on a signal...

True.

> > * I have signed a contract that prevents me from sending traffic to the
> > customers LAN. Some sensors even use an ethernet TAP. All monitoring
> > interfaces are configured to run without an IP address.
> > To do it your way I have to create and inject my offending packet
> > directly into the interface, into the packet driver or into the kernel
> > somehow. Sounds like a lot of work. It is much easier just to send a
> > SIGUSR2 to snort. :-)
> This of course is a valid point. But you can even think of a status
> e-mail as a generator for alerts. You don't need to forge a packet,
> this was only an idea to avoid a false-positive generator...
>
> I don't think of generating an alert via the sensor himself. This
> won't make much sense. The idea is to trigger an alert from an
> external packet.

The problem is that we monitor a lot of internal networks where we have no possibility to generate traffic from remote or even from the sensor itself (tap). I guess that we are not the only ones with this problem, that's why I think sending a SIGUSR2 to snort is the second best option to detect failure in the chain.

Ok, if we remove the "detect failure in the chain" criteria, I still think of the feature of having statistics in the alert payload as important enough to ask the developers to implement it. Maybe it could be a new configuration option to the Performance Monitoring plugin?

Configure it to output its data to an alert instead of to a file or the console. Then you could configure it to send status alerts with a given time interval. You could also configure it to send its stats when snort receive a SIGUSR1. Dump the stats both to syslog and into an status alert...

In my startup/shutdown-script I send a SIGUSR1 before I kill snort. This make snort dump its statistics before it terminates. It is a little bit tiresome to go through the collected syslogs in order to find the stats though.
If snort not only logged the stats to syslog but also sent them in a status alert, then I would be able to do _all_ analysis in a single NMS system. No need to switch to another system and dig through the syslogs.

Do you need help?X

What do the developers say? Isn't this a very useful feature regardless of wether you use it to detect failure in the chain between sensor and NMS or if you just want to collect statistics in a central place?

/Martin



SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Snort-devel mailing list
Snort-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel Received on Tue Feb 24 11:58:30 2004

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:08:12 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library