[Snort-devel] Re: Status alert
elof at ...969...
Tue Feb 24 08:26:23 EST 2004
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...
> > * 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
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
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
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.
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?
More information about the Snort-devel