[Snort-devel] spp_tcp_stream.c

Christopher Cramer cec at ...56...
Fri Sep 22 15:09:43 EDT 2000

On Fri, 22 Sep 2000, Fyodor wrote:

> ~ :I've been running it over here without any stability issues.
> ~ :
> ~ :However, one problem I see with the preprocessor is that on monitored
> ~ :ports one can get two alerts on the same attack signature.  The reason is
> ~ :that if the attack is not a stealth attack (i.e. no one has broken the
> ~ :attack up into multiple tcp packets) the original packet itself generates
> ~ :an alert.  Then, the dummy packet based on the reconstructed stream will
> ~ :get sent later on and also generate an alert.
> ~ :
> ~ :There are a few ways I see around this.  One would be to have the stream
> ~ :preprocessor ignore larger packets.
> Hmm.. If I understand your concerns correctly, it doesn't seem that it
> would solve the problem in all cases. As far as I understand a tcp packet
> would be passed to detection engine twice, first time when it is captured
> straight off the wire, and the second time when it becomes a part of a
> dummy packet (tcp reassembled stream). What ideally should be here is some
> sort of feedback from detection engine to tcp reassembly engine to mark
> currently reassembled packet `triggered alert X'. Later if the packet
> matches certain signature, dection engine should verify whether this
> packet (a part of it) has already `triggered alert X'... we should think
> carefully though how to implement it properly, since we still would like
> to see core snort system being independant from preprocessors, maybe
> bring up some sort of detection preprocessors thing or place the thing
> into alert/log engine?

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
the tcp alerts chain.  IF this is implemented, it would NEED to be done
carfeully and should probably be declared experimental and be turned on by
a non-default option.  That said, I think it could be done correctly
without making drastic (any?) changes in the core snort system and without
the danger of scans being missed.



More information about the Snort-devel mailing list