[Snort-devel] Re: Status alert
elof at ...969...
Tue Feb 24 06:28:05 EST 2004
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.
* 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. :-)
* You can post-process all the status alerts in a centralized manner,
generating graphs and reports based on the contents of the status
On Tue, 24 Feb 2004, Dirk Geschke wrote:
> > Not really. In my example you check the entire chain from the sensor to
> > the receiving end, not just that the process is running.
> > Example:
> > * Snort receives SIGUSR2 and generate a status alert
> > * The alert is sent using the prelude output plugin
> > * A prelude manager in country A receive the alert and retransmits it
> > * A prelude manager in country B receive the alert and retransmits it
> > * The prelude manager in my country receive the alert
> > * The prelude alert is mangled into a customized idmef alert
> > * The idmef alert is logged to our NMS
> > Every time such a status alert is received, it's an indication that
> > everything is all right.
> > Compare this feature with the "--MARK--" message sent by syslogd. It
> > is nice to have when backtracking a system failure.
> > A nice side effect is that if you fill the alert payload with
> > snort statistics such as the number of dropped packets, you
> > automaticly have a centralized historical archive of the snort's
> > performance without having to use the Monitor Performance preprocessor.
> > The Monitor Performance preprocessor can only log to the console or to a
> > file on the sensor. This is a nice feature, but in my case the sensors are
> > located in different countries and I don't want to build a new system that
> > collects files from the sensors to a central place. I already have a nice
> > working redundant solution (prelude).
> > Why not simply reuse the existing solution for sending statistics and
> > performance data?
> why do you want to use a signal? Simply create a special rule and
> trigger an alert via the network. Then you have tested the whole
> It should be easy to inject a special configured network packet
> which can't be send in via the "normal" traffic. All you need is
> to verify that this packet raises an alert and maybe find it in
> the database.
> Best regards
More information about the Snort-devel