File: README.snort

package info (click to toggle)
fragroute 1.2-7
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 692 kB
  • ctags: 520
  • sloc: ansic: 4,331; sh: 2,842; makefile: 74
file content (54 lines) | stat: -rw-r--r-- 1,165 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

attacks against snort-1.8.3, reported Jan 28, 2002:

1. older TCP retransmission chaff (snort's TCP segment reassembly
   seems to always favor newer data, even for properly sequenced
   received data):

	tcp_seg 1
	tcp_chaff rexmit
	order random

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

3. chaff TCP segments with older TCP timestamp options forcing PAWS
   elimination:

	tcp_seg 1
	tcp_chaff paws
	order random

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

5. IP duplicate fragment chaff with bad options:

	ip_frag 8
	ip_chaff opt
	order random

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

there are probably timing attacks against snort's reassembly possible
as well, but i haven't played with it enough to see.