Snort mailing list archives
fragroute related fixes need testing on real networks
From: Chris Green <cmg () sourcefire com>
Date: Mon, 22 Apr 2002 19:34:58 -0400
Hey folks, I just committed a lot of changes today to snort's HEAD branch in CVS to deal with the test cases iterated in fragroute. To get the full benefit of these changes: preprocessor frag2: detect_state_problems processessor stream4: detect_state_problems These need a lot of testing and there may very well be more problems laying around. If things go well, I'll backport the changes to snort-stable and release a 1.8.7 If you find a new set of options that evade snort, drop me a line and I'll work to fix and/or detect them and give you full credit. The bugtraq post was the first I'd seen the README.snort so let me just say that I spent a lot of Thursday superlate-> Today thinking about the problems while trying to get work done. Anyway, fragroute is a neat tool and does a lot of the stuff that has been on the todo list to check. Ahh only hours in the day.
1. older TCP retransmission chaff (snort's TCP segment reassembly seems to always favor newer data, even for properlby sequenced received data): tcp_seg 1 tcp_chaff rexmit order random
Should be fixed and if we see retransmissions of older data that differs from what we already have, we generate an alert and throw away the packet
2. forward TCP segmentation overlap, favoring newer data (both Windows and Unix operate this way, in contrast to Ptacek and Newsham's results): tcp_seg 1 new
Fixed and generates alerts on packets that are part of a stream that has already been reassembled.
3. chaff TCP segments with older TCP timestamp options forcing PAWS elimination: tcp_seg 1 tcp_chaff paws order random
This should be relooked at but after making the first two changes, this one was picked up very loudly.
4. older IP fragment duplicates (snort's IP fragment reassembly seems to always favor newer data, even for properly sequenced received data): ip_frag 8 ip_chaff dup order random
Alert on frags with option data and suck them all away. Philosophical question: Should we ignore frags we didn't see the first fragment of?
5. IP duplicate fragment chaff with bad options: ip_frag 8 ip_chaff opt order random
Once the opts were tossed, things worked fine
6. either TCP or IP chaffing with short TTLs (that expire before reaching the end host, but pass by the monitor): ip_frag 8 ip_ttl 11 ip_chaff 10 order random tcp_seg 1 ip_ttl 11 tcp_chaff 10 order random
TCP stream stuff already had the min_ttl option to detect this attack so that it will throw away anything underneath that. I added this option to frag2 Also, there is a ttl_limit option to both. Basically, this will alert on anything that is different by more than a certain limit The default is 5 picked off the cuff. Know of any papers that measure the avg and std deviation of TTLs on normal internet traffic across a large sample and I'll be your buddy. Thanks for your help and patience, Chris -- Chris Green <cmg () sourcefire com> Fame may be fleeting but obscurity is forever. _______________________________________________ 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
Current thread:
- fragroute related fixes need testing on real networks Chris Green (Apr 22)
- Re: fragroute related fixes need testing on real networks Martin Roesch (Apr 22)
- Re: [Snort-devel] fragroute related fixes need testing on real networks Chris Green (Apr 22)
- Re: [Snort-devel] fragroute related fixes need testing on real networks Chris Green (Apr 23)