[Snort-devel] Checksums

Christopher Cramer cec at ...56...
Wed Oct 25 16:59:55 EDT 2000


> 
> > This way, an optimization would be to have some plugins bail if the
> > checksum variable != 0, improving speed.  However, a stats plugin might
> > record the number of checksum errors of different types.
> 
> I'm extending the stats packet counter (thing that prints out the packets when
> you exit Snort) to include frags and other data now, are you talking about
> this or something else?
> 

that's pretty much what I was thinking.  Although if someone had a
statistical analysis package hooked on or in to snort, this is the kind of
info they might be interested in.

-c


> > 
> > On Wed, 25 Oct 2000, Martin Roesch wrote:
> > 
> > > Checksumming should be done in the decoder, and we should probably think hard
> > > about what to do with packets with known bad checksums.  I advocate dropping
> > > them, since any OS worth anything (even crap from MS) is going to drop those
> > > packets.  OTOH, there might be some analysis we'd like to do on them (covert
> > > channel detection, etc) so we might just want to have a flag in the Packet
> > > struct.  Either way, with the defrag and stream reassembly, we need these
> > > functions implemented ASAP (hopefully before 1.7 ships).
> > >
> > > One request: make it fast, make it portable! (ok, two requests...)  ;)
> > >
> > >    -Marty
> > >
> > > Christopher Cramer wrote:
> > > >
> > > > Guys,
> > > >
> > > > I've been thinking about insertion attacks recently, and it seems to me
> > > > that a lot of snort is, or through defrag and tcp_stream will be, subject
> > > > to a variety of insertion attacks.  Many of these are do to a lack of
> > > > checksum testing in the decode engine.
> > > >
> > > > For the tcp stream reassembly code, I was about to add in some checksum
> > > > tests (both the IP and the TCP checksum tests) before I incorporated the
> > > > packet data in the tcp stream.  It occured to me that it might be better
> > > > if we handled checksums in the decode engine.
> > > >
> > > > While I don't think we should necessarily drop packets with bad checksums,
> > > > I think a set of flags that say which checksums suceeded and which
> > > > failed would be a helpful addition.  This does mean the Dragos's defrag
> > > > and my tcp_stream preprocessors should probably compute the correct
> > > > checksum before sending our faked packets, but that's not too hard.
> > > >
> > > > If this sounds reasonable, I can go ahead and begin the implementation.
> > > >
> > > > -Chris
> > > >
> > > > ----------------------------------------------------------------------
> > > > Dr. Christopher E. Cramer
> > > > Assistant Research Professor
> > > > Duke University, Department of Electrical and Computer Engineering
> > > > 114 Hudson Hall, Box 90291, Durham, NC  27708-0291
> > > > PH:  919-660-5248     FAX:  919-660-5293     email:  cec at ...56...
> > > >
> > > > _______________________________________________
> > > > Snort-devel mailing list
> > > > Snort-devel at lists.sourceforge.net
> > > > http://lists.sourceforge.net/mailman/listinfo/snort-devel
> > >
> > > --
> > > Martin Roesch
> > > roesch at ...48...
> > > http://www.snort.org
> > >
> 
> -- 
> Martin Roesch
> roesch at ...48...
> http://www.snort.org
> 




More information about the Snort-devel mailing list