[Snort-devel] flow nomenclature

Mathew Johnston mjohnston at ...1001...
Mon Apr 8 10:00:50 EDT 2002

> Thanks for all the responses so far.  I guess the question I was
> trying to ask was, how is the flow match really implemented? 

While I do not know the exact answer to that (sorry), it may be useful
to note that perfect session tracking in promiscious mode is not
possible. Since we do not have any control over the flow, we may miss
connection state changes (miss a segment that would increment the
sequence numbers, miss a SYN, an ACK or a FIN or RST, etc). The result
of this is that we can make fairly good guesses about what state the
connection is in, but there's always room for us to be fooled, and we'll
probably never really be able to inspect application layer protocols
with any great reliability. Not unless we do the barnyard thing and live
on a router.

There are also interesting performance questions as well - do we make
much of an effort to re-order badly ordered packets? If we do, how long
do we keep packets around? Do we let each side advertise as large a
window as it likes? Do we pay attention to the windows for our
re-assembly? If we do, can someone send us very unordered segments with
a very very large window to consume resources and turn our session
tracking off? Also, if we notice that we've missed a segment, how long
do we wait until we give up on that segment? (we don't know whether the
segment was lost before it got to us, and will be resent, or whether we
just lost it). 

For these reasons, it would be really neat if snort started to be more
of a firewall, and integrate it's rules more with something like
iptables. It would be neat to have a snort module where you could do
something like:

iptables -N snortdrop
iptables -A logdrop -j SNORTLOG
iptables -A logdrop -j DROP

iptables -A FORWARD -j snortdrop -i $inside -o $outside -s $inside_net
--dport 80 -m state --state new,established -m snort --rule-file

iptables -A FORWARD -j snortdrop -i $inside -o $outside -s $inside_net
--dport 80 -m state --state established -m snort --rule-file

For performance reasons, it would of course have to load the rules file
when the rule was instantiated, instead of when it is matched.
Hopefully, the rule loader code could keep duplicate rules out of

If only this could be available on NT platforms too. :)


More information about the Snort-devel mailing list