[Snort-devel] fragroute related fixes need testing on real networks

Chris Green cmg at ...402...
Mon Apr 22 16:36:01 EDT 2002


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 at ...402...>
Fame may be fleeting but obscurity is forever.





More information about the Snort-devel mailing list