[Snort-devel] Possible bug with 2.0.1: decoder masking fragroute traffic from stream4 preprocessor

Allen Harper harperaa at ...398...
Fri Sep 26 06:08:29 EDT 2003


Developers,
While working on a book for McGraw-Hill, I have been conducting some
testing of snort.  When I looked at 1.8.7, it handled default fragroute
traffic well by the stream4 preprocessor sounding the alert ": Multiple
Acked Packets (possible fragroute)".  I may have found a problem with
2.0.1.  It seems that there are some changes in the 2.0.1 that make the
decoder fire "WARNING: TCP Data Offset is less than 5!" which of course
could mean lots of things besides fragroute.  It is much less
descriptive and will probably be chalked up as a false positive by an
analyst.  It looks like the decoder is stealing the stream4
preprocessors thunder here.   Details follow:
 
Here is the problem:
Both snorts 1.8.7 and 2.0.1 have default configs and rules.  Using
default config for fragroute.
 
root at ...2207...[knoppix]# ping 10.10.10.33
root at ...2207...[knoppix]# fragroute 10.10.10.33
fragroute: tcp_seg -> ip_frag -> ip_chaff -> order -> print (starts
fragroute, then open another window for ftp session)
 
ftp 10.10.10.33 (proceed to log-in, move to /etc subdir, get passwd,
then log out)
 
--------------------------
snort 1.8.7
 
 
[**] [111:18:1] spp_stream4: Multiple Acked Packets (possible fragroute)
[**] 09/23-14:58:05.445121 10.10.10.102:33039 -> 10.10.10.33:21 TCP
TTL:64 TOS:0x10 ID:26987 IpLen:20 DgmLen:53
***AP*** Seq: 0x1B4A6A08  Ack: 0x6EE8F32C  Win: 0x16D0  TcpLen: 32 TCP
Options (3) => NOP NOP TS: 33629416 62418991
 
[**] [111:18:1] spp_stream4: Multiple Acked Packets (possible fragroute)
[**] 09/23-14:58:05.445214 10.10.10.102:33039 -> 10.10.10.33:21 TCP
TTL:64 TOS:0x10 ID:63939 IpLen:20 DgmLen:53
***AP*** Seq: 0x1B4A6A0A  Ack: 0x6EE8F32C  Win: 0x16D0  TcpLen: 32 TCP
Options (3) => NOP NOP TS: 33629416 62418991
 
[**] [111:18:1] spp_stream4: Multiple Acked Packets (possible fragroute)
[**] 09/23-14:58:05.445094 10.10.10.102:33039 -> 10.10.10.33:21 TCP
TTL:64 TOS:0x10 ID:3410 IpLen:20 DgmLen:53
***AP*** Seq: 0x1B4A6A0C  Ack: 0x6EE8F32C  Win: 0x16D0  TcpLen: 32 TCP
Options (3) => NOP NOP TS: 33629416 62418991
 
 
This is good...
 
 
------------------ snort 2.0.1
 
[**] [116:46:1] (snort_decoder) WARNING: TCP Data Offset is less than 5!
[**] 09/23-15:02:13.783931 10.10.10.102:0 -> 10.10.10.33:0 TCP TTL:64
TOS:0x10 ID:37117 IpLen:20 DgmLen:52
*2U**R** Seq: 0x3330556E  Ack: 0x50537257  Win: 0x374E  TcpLen: 16
UrgPtr: 0x75
30
 
[**] [116:46:1] (snort_decoder) WARNING: TCP Data Offset is less than 5!
[**] 09/23-15:02:14.886738 10.10.10.102:0 -> 10.10.10.33:0 TCP TTL:64
TOS:0x10 ID:37119 IpLen:20 DgmLen:52 *2***R*F Seq: 0x6B645039  Ack:
0x2B65597A  Win: 0x4B79  TcpLen: 12
 
[**] [116:46:1] (snort_decoder) WARNING: TCP Data Offset is less than 5!
[**] 09/23-15:02:14.888232 10.10.10.102:0 -> 10.10.10.33:0 TCP TTL:64
TOS:0x10 ID:37120 IpLen:20 DgmLen:52
*2U***S* Seq: 0x4B633332  Ack: 0x56583431  Win: 0x3373  TcpLen: 16
UrgPtr: 0x37
57
 
this is not good... looks like the decoder is stealing the thunder of
the stream4 preprocessor... this can easily be chalked up as a
false positive by the analyst and there is no mention or inkling that
fragroute is being used...  So, it appears that fragroute becomes useful
again.  
 
Allen
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20030926/52852308/attachment.html>


More information about the Snort-devel mailing list