[Snort-devel] Checksums

Christopher Cramer cec at ...56...
Wed Oct 25 16:35:12 EDT 2000


Marty,

I think the fastest code may be along the lines of the portable BSD
checksum code.  Since it is under the BSD license, we could probably snipe
it, cite it and hack it to work better with Snort.  If that makes you
uncomfortable (it makes me a little uneasy), I can take the _principles_
used for their fast portable code and implement it myself.

For the Packet struct, we might consider a u_short variable (or u_char)
which is the OR-ing of flags representing checksum errors in IP, TCP, UDP,
etc.

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.

-Chris



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
> 




More information about the Snort-devel mailing list