fragroute related fixes need testing on real networks

[Chris Green <cmg () sourcefire com>]

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