[Snort-devel] spp_tcp_stream.c

Martin Roesch roesch at ...48...
Fri Sep 29 12:12:42 EDT 2000


Dragos Ruiu wrote:
> 
> On Sat, 23 Sep 2000, Fyodor wrote:
> > ~ :
> > ~ :The other fix for this might be to send on packets that are not part of an
> > ~ :established TCP stream, e.g. they have a SYN, SYN/FIN, or otherwise don't
> > ~ :look to be data packets.  Packets which are regular session traffic could
> > ~ :then have p->tcph set to NULL.  This should prevent them from traversing
> >
> > well, yep, in the current source packet will not be processed if p->tcph
> > is NULL, even if p->iph->ip_proto is IPPROTO_TCP. But we would have to
> > make sure that we will not miss any data in this case. Having extra-false
> > positives (or doubled positives in this case) is better than having any
> > false-negatives.
> 
> This was my initial base assumption with the defragger as well.
> I feed the fragments _and_ the reassembled packets back into
> snort main.  I was contemplating making it a rules file option
> to turn this feature on or off... and then it could either leave
> the fragments from a reassembly to pass through the main loop
> or it could keep them in the "holding tree" and pass the
> fragment back with a null ptr for the IP hdr?

IP fragments don't go thru the detection phase of the detection engine, just
the preprocessors.  If you call the detection engine from within your
preprocessor (handing it the newly built/decoded packet) you can easily manage
the memory on the return from the detect.  Another idea is to keep the pointer
to the rebuilt packet in the preprocessor module and then free it on the next
pass.  

[snip]

> In general I like this pass the packet data back, but
> pass a null ptr to the header when plug-ins take
> responsibility for the packet.  I would request one
> more thing, one or more levels of alarm flags (how
> about, one 32 bit word full of flags?) that can be
> set on a packet by a plug-in and snort-main when
> that packet has triggered the respective alarm or
> condition....  Maybe, initially this can be used for
> the alarm severity and varied alarm output plug-ins
> to get  multiple reporting paths (two bit flags for
> severity?) ???

There's a do_detect global that your preprocessor can set to zero that will
prevent the packet from being doubly fed through the detection engine.  If you
set do_detect = 0 in your preprocessor, it'll keep the Detect() function from
being called for the current packet.  Even if do_detect is zero, the rest of
the preprocessors will fire in order.

     -Marty


-- 
Martin Roesch
roesch at ...48...
http://www.snort.org



More information about the Snort-devel mailing list