On 4/17/02 9:49 PM, "Vern Paxson" <[EMAIL PROTECTED]> wrote:
>> The TCP evasions are fairly easily detectable as overlaps should not >> normally occur. > > See the Bro paper - Bro has detected this possible evasion for many years > now, and in fact we do see overlaps operationally, and unfortunately they're > just about always innocuous (busted TCPs, not attacks), so alerting on them > has a high false positive ratio. Snort is capable of detecting a variety of TCP foolishness as well, it's just turned off by default because people complain about the "noise". To enable Snort's TCP stream protocol violation alerts, configure the stream4 preprocessor the following way: preprocessor stream4: detect_scans, detect_state_problems >> Similarly the IP fragmentation detection just needs slightly more rigorous >> overlap detection and alerting, as these overlaps will not be occurring >> in normal situations. > > Also discussed in the Bro paper - we do see these in practice, both innocuous > and as evasion attempts. Snort has overlap detection and mitigation built into its frag2 preprocessor, I fixed it when Dug told me it was broken back in January. >> For now as a workaround you can just alert on small >> fragments (resurrect minfrag... heh) which should be indicative of games >> being played. > > (same - you see tiny fragments for innocuous reasons, sigh) >From misc.rules: alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"MISC Tiny Fragments"; fragbits:M; dsize: < 25; classtype:bad-unknown; sid:522; rev:1;) This has existed for a while and is the reason that we dumped the minfrag preprocessor (as a historical note). Tiny frags do happen, but I've rarely see them outside of live attacks. Then again, I don't hang on .edu networks very much... ;) >> Basically all the chaffing at the IP and TCP level is detectable as those >> should not be normal conditions. > > Per the above, this is unfortunately not true, if you're watching a large > traffic stream. For small traffic streams (e.g., a hundred local hosts), > yes, my experience has been that these don't normally occur. Snort has both TCP and IP forward overlap detection and mitigation in its stream and defrag preprocessors, something might not be working right currently (we've been doing lots of dev work lately, it's not inconceivable that something may have been broken). When Dug sent me the message about the problems back in January I took the time to fix the overlap conditions and we worked out minimum TTL drops as well. The chaffing conditions should be defeated since then, we're doing some testing over here to see what's going on and seeing if the readme.snort with fragroute needs some updating. So, for the record: 1. older TCP retransmission chaff - FIXED in January 2. forward TCP segmentation overlap, favoring newer data - FIXED in January 3. chaff TCP segments with older TCP timestamp options forcing PAWS elimination - NOT FIXED 4. older IP fragment duplicates - FIXED in January 5. IP duplicate fragment chaff with bad options - NOT FIXED 6. either TCP or IP chaffing with short TTLs - FIXED in January We currently *do not* have the following: PAWS detection/bad packet drops IP frags with bad options drops I'll see about adding them this weekend. As a side note, it might be nice if we could test the commercial systems out there to see how they fare, the damn media is having a field day with this one. -Marty -- Martin Roesch - Founder/CEO, Sourcefire Inc. - (410)290-1616 Sourcefire: Professional Snort Sensor and Management Console appliances [EMAIL PROTECTED] - http://www.sourcefire.com Snort: Open Source Network IDS - http://www.snort.org