[Snort-users] Log vs. Alert --end the confusion!

Steve Halligan giermo at ...187...
Mon Aug 12 14:23:06 EDT 2002

Ok, lets start with some definitions:

Alert:  Generate an alert for a packet.  This is meant for events that are
considered "high priority".  Most signatures have this as their default
action.  After the alert is generated, the event is also logged.  Note that
payload is not captured in an alert.  If you want to investigate further,
look at the log output of the event corresponding to the alert.

Log:  Log the event.  Meant for less important event, and also to capture
additional data from alert events that may be needed for further

Ok, those definitions may not be exactly right, but I think that they catch
the drift of things.  My problem is the following inconsistancy relating to
ALERT and its use by preprocessors.

Let me use portscan2 as an example, however this also applies to fnord and
possibly others.

1)  Calls alert, but never logs.  Therefore no way to get payload data.  If
you use barnyard, in order to see these alerts you need to process the
unified alert.  If you do that, then none of your events have payload data.
If you run 2 barnyard processes, one for log and one for alert, you get
duplicates.  I suppose you could have an alert database and then a log
database for further investigation and correlation, but that seems silly.

2)  Why are these using Alert in the first place.  Portscans seem low
priority.  Wouldn't they be better in log?

As an aside.  I would like to put my vote in for a single generic message
from portscan2.  As it is, the msg looks like this "Portscan detected from
a.b.c.d blah blah blah".  For those of us that use a database, this adds a
unique signature for each and every portscan.  In addition to clogging up
the signature table, it frustrates signature based queries.  Why put the ip
in the message?  You can see it in the ip addr field anyway.  If you need to
know the number of ports/hosts, you can look in the scan.log.


More information about the Snort-users mailing list