[Snort-devel] flow nomenclature

Benjamin.Feinstein at ...1192... Benjamin.Feinstein at ...1192...
Mon Apr 8 06:42:08 EDT 2002


Hey ya'll,

On Sat, 8 Apr 2002, Brian wrote:
The stuff listed in the signature header is related to the source and
destination of the packet.

Correct, the signature header goes ip_src -> ip_dst.

On Sat, 8 Apr 2002, Brian wrote:
In order to cut down on false positives, we are adding checks for the source
and destination of the session.

By the source of a session, do you mean the "initiator"?  By the dstination
of a session, do you mean the "listener"?

On Sat, 8 Apr 2002, Brian wrote:
Right now, flow only relates to TCP source and destinations.

So, the the flow client is the "TCP source" and flow server is the "TCP
destination"?  By TCP source and destination, do you mean TCP initiator and
listener?  I think the destinction between client and server is determined
above the TCP layer in the protocol stack.  I would think an "spp" module
would be needed to determine the client and server of a session, based on
inspection of the relevant application protocol.  The stream reassembler may
be able to tell you which host initiated a connection (or "session" if you
will), but it doesn't neccessarily tell you anything about the application
protocol (if any) riding on top of the stream transport.

Since the flow check appears to be based entirely on whether a packet came
from the TCP initiator or listener, I think it makes sense in relation to
session flow to replace "client" with "initiator" and "server" with
"listerer".  

On Sat, 8 Apr 2002, Brian wrote:
Work is being done to incorporate hogwash's spp_conversation to handle UDP
and ICMP states as well.

I would imagine this code would look an awful lot like the Linux Netfilter
connection tracking for UDP and ICMP.  You may want to look there for
inspiration :)

This all raises a big question: can we reliably track connection state on a
promiscuous interface?  For a variety of reasons, we may miss state
transitions on the wire.  Even before the introduction of the flow check,
intruders could always use a variety of techniques to attempt to defeat the
stream reassembler.  Is a signature using a to/from client/server flow check
any more vulnerable to IDS evasion than any other signature that would need
stream reassembly?

Cheers,
Ben

> Ben Feinstein
>   Software Development Engineer, R & D
>   W: 678.585.7865 x6726 F: 770.645.8311 M: 678.772.4126
>   8302 Dunwoody Pl., Suite 320, Atlanta, GA 30350 www.guardent.com
> _____________________________________________________
> G U A R D E N T
>   Enterprise Security and Privacy Programs
> 




More information about the Snort-devel mailing list