Re: snort mixes multiple (unrelated) payloads into one alert

[Martin Roesch <roesch () sourcefire com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 24, 2006, at 11:37 AM, Frank Knobbe wrote:

> On Sun, 2006-07-23 at 23:34 -0400, Jason wrote:
> > \"This will cause Stream4 to zero out the memory of the
> > rebuilt packet before copying in the new data.  So, when
> > packets are missing from the middle of the rebuilt packet,
> > you'll get 0x00 in those bytes, rather than whatever was
> > there from the previous rebuild."
> >
> > The problem is packet loss. A single buffer is used for  
> > reassembly. If
> > you are missing packets when reassembly is done then the old data is
> > still in the gaps...
>
> Yeah, I remember that we've discussed that before now :)
>
> But a question comes to mind: When Snort reassembles the stream,
> shouldn't it be able to tell which segments are reassembled and which
> not? Snort should be able to fill the first segment, the third  
> segment,
> the fourth segment, and then realize that it never got the second
> segment, then null just that before sending the packet to the matching
> engine.
>
> Nulling the whole buffer before reassembly seems like a waste of
> resources, which is probably why a lot of folks don't turn it on. I
> believe you guys even warned about the performance impact.
>
> To me, the solution would seem to write the stream4 such that is
> recognizes a missing segment and nulls just that. From a performance
> standpoint, it should require as much as copying an existing segment
> into the stream.
>
> Thoughts?

I think doing successive 32-bit sequence-number-safe (i.e. wrap safe)  
compares and memset()'s to clear out the gaps would probably not save  
us any time and would probably cost us clock cycles to perform as  
opposed to just memset()'ing the whole stream buffer (which is a  
dynamic value anyway and should be less than 64k typically).  Once  
you factor in the compares and the function call overhead I  
intuitively believe (with no evidence other than my gut) that just  
zeroing the reassembly buffer is the best way to handle it and the  
least error prone (one line of code).

     -Marty

- --
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFExSAHqj0FAQQ3KOARAkdqAJ4jWAta67dEQHyYp6YVoyRbZhfPswCdFqvH
l5X2hMvVNWVBjTTDSm2Qi1c=
=hSXp
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users