[Snort-devel] New Feature: tagging
roesch at ...48...
Thu Feb 15 00:01:07 EST 2001
I've been working on this one for the past week or so and I think
you're going to like it. What I've implemented is the ability for Snort
to follow sessions/hosts that cause alerts. For instance, if you've got
an alert where you'd really like to follow along for a given period or
number of packets, you can now tell Snort to "tag" the session (or host)
that caused the alert to go off and log all applicable packets.
This is referenced as a rule option but it is not a plugin, it's a
built-in module due to the amount of state that it keeps.
Here's the syntax:
tag: <type>, <count>, <metric>, [direction]
session => log packets in the session that set off the rule
host => log packets from the host that caused the tag to activate (uses
Count is specified as a number of units. Units are specified in the
packets => tag the host/session for <count> packets
seconds => tag the host/session for <count> seconds
Only useful in the context of a "host" tag. Use "src" and "dst" to
tell the tagger which IP address from the packet causing the alert to
The order that you specify the arguments to this function doesn't matter
entirely, the parser should be smart enough to figure it out (he said
This rule tells Snort that when it sees a telnet session initiated from
an external IP network to pop an alert and then log that session for the
next 10 seconds.
alert tcp !$HOME_NET any -> $HOME_NET 23 \
(flags: S; \
tag: session, 10, seconds; \
msg: "incoming telnet session";)
This rule tells Snort that when it sees an IMAP buffer overflow, log the
next 300 packets that come from the source IP that set off the alert.
alert tcp !$HOME_NET any -> $HOME_NET 143 \
(flags: A+; \
content: "|e8 c0ff ffff|/bin/sh"; \
tag: host, 300, packets, src; \
msg: "IMAP Buffer overflow, tagging!";)
Notes: Tagging is not "TCP stateful", it does *not* monitor the state of
TCP connections looking for termination conditions. This is a blessing
and a curse, depending on your view point. Probably the preferred
operational metric for this code is to use the "seconds" mechanism, I'm
still validating the clean up code for abandoned sessions that haven't
met their packet count criteria.
I've done some basic testing on this mechanism to make sure it works in
the general case, I'd still consider it pretty beta. From my testing it
properly allocates and deletes nodes on the tag list, logs correctly and
parses the rules file adequately. As with most rules options in Snort,
if you don't use it then it should not effect the stability of the
system. For those of you with an adventurous spirit, please have a look
at this module (it's now available in CVS) and see what bugs you can
roesch at ...48...
More information about the Snort-devel