snort-inline doesn't detect second occurrence

[Dave Remien <dave () rem homeip net>]

Howdy,

I'm getting close to having a GenII honeypot together, and have been
testing snort-inline. Some anomalous behavior has shown up in that the
second and subsequent occurrences of a drop match aren't dropped, but
simply cruise right on through. Example:

Config - snort-inline box configged as a bridge; using the posted
drop.rules; drop rule of:

drop.rules:drop tcp $HONEYNET any -> $EXTERNAL_NET 25 (msg:"SMTP vrfy
decode"; flow:to_server,established; content:"vrfy decode"; nocase;
reference:arachnids,373; classtype:attempted-recon; sid:672; rev:2;)

OK, I get on the honeypot, and telnet out through the snort-inline bridge
to my favorite mail server.

I issue a "vrfy decode", and the packet doesn't get through, as expected.
Subsequent TCP retries of that packet on that telnet session never get
through either (can see them on the wire). This telnet session is
basically toast now.

OK, shut that telnet session down, and start up a new one to the same or a
different mail host. Issue a "vrfy decode", and get a valid response back.
Same for subsequent "vrfy"s, and for subsequent telnet sessions. In fact,
as far as I can tell, no other drops work anymore, at all ("vrfy root"
sails right on through, as well; has same drop syntax).

Doesn't matter whether I use the snort-inline executable from the honeynet
web site or one I built myself. Tried this on three different in-line
boxen; two (slightly different) flavors of Linux. Running snort-inline in
"log to stdout" mode shows the "vrfy" packets and responses happily
cruising about (snort-inline -d -v -c snort.conf -Q -i br0).


The date on the Honeynet supplied snort-inline is Jan. 7th, and the
snort-inline source (http://www.snort.org/dl/contrib/patches/inline/) is
dated Aug. 27 of 2002, so one might think that someone has already seen
and dealt with this, but I haven't found anything indicating that.

As a somewhat separate issue, I compiled snort-inline with flex-resp, and
it doesn't appear that including "resp:rst_all;" actually sends a reset
(as in, the connection is never shut down, and I don't see any resets on
the wire). Since there's no mention anywhere of the flex-resp stuff
working in -Q mode, that may be a moot point at this moment. (Could be
related to the libpcap not being initiated in -Q mode; maybe libnet isn't
active at that point either).

Since Jed lives here in town, you'd think I should probably ping him
locally, wouldn't you??

Cheers,

Dave Remien



"Of course, someone who knows more about this will correct me if I'm
wrong, and someone who knows less will correct me if I'm right."
               --David Palmer (palmer () tybalt caltech edu)