[Snort-devel] Checksums

Christopher Cramer cec at ...56...
Thu Oct 26 11:15:23 EDT 2000


Last night I wrote checksumming into the decode engine for IP, TCP, UDP
and ICMP.  The algorithm is not optimal, it could stand to use some loop
unrolling.  However, it does put a csum_flags field in the Packet
structure and it fills in the appropriate CSE_IP | CSE_TCP | ...  flag
(CSE standing for Check Sum Error).

I did diverge from many standard codes in one respect.  I gave the
checksum function the ability to deal with two pointers (either of which
can be NULL).  The reason for this is that UDP and TCP checksum both their
own headers and data, but also a pseudo IP header.  I wanted to avoid
copying the pseudo IP header and the packet data into one piece of
contiguous memory.  I suppose I could have checksumed the UDP/TCP data
separate from the pseudo IP header, and then combine them later, but this
worked just as well and looked cleaner on the decode side.  This is sort
of similar to the BSD code where you can checksum a linked list of mbufs.

Anyway, I'm including a patch that will modify decode.[ch], Makefile.am,
Makefile.in and will add checksum.[ch].  If the checksum prototype is left
alone, we can still modify the checksum code for optimization.

-Chris



On Wed, 25 Oct 2000, Dragos Ruiu wrote:

> 
> Gee you must be psychic.... I've been looking for
> what is the fastest checksum algorithms... both for snort's
> defragger and my IDS eval traffic generator (I'm doing an IDS
> comparison, incl... Snort/OpenBSD!!!), but more on that
> later.
> 
> I agree with you about your BSD conclusion so far... but I want 
> to have  a look through any relevant research papers for the fastest 
> algorithm before declaring that a winner.  P.s. sorry that I haven't shipped
> libsplay yet... my current customer insisted that I fly on-site to a different
> city so I can test servers in my home town of Vancouver, so that's been 
> pretty much eating my evening dev time.  Grrr... I'll take another shot at it
> tonight.
> 
> cheers,
> --dr
> 
> P.s. I'm agreeing with Marty on both counts...
> 
> On Wed, 25 Oct 2000, Christopher Cramer wrote:
> > 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
> > > 
> > 
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel at lists.sourceforge.net
> > http://lists.sourceforge.net/mailman/listinfo/snort-devel
> -- 
> Dragos Ruiu <dr at ...9...>   dursec.com ltd. / kyx.net - we're from the future 
> gpg/pgp key on file at wwwkeys.pgp.net
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/snort-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-checksum
Type: application/octet-stream
Size: 9945 bytes
Desc: 
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20001026/eedc05ad/attachment.obj>


More information about the Snort-devel mailing list