Snort mailing list archives

Garbling FTP alerts


From: Gary_Portnoy () itginc com
Date: Wed, 25 Feb 2004 16:34:58 -0500

Hi there,

I am having a weird issue with snort 2.1.1RC1.  I have fast logging in 
tcpdump format configured, and everything works fine, except that packets 
that trigger an FTP alert are not logged to the tcpdump file properly. I 
see the proper alert in my alerts file, but in the tcpdump log snort 
appears to prepend 2 bytes of data to the beginning of the ether frame, 
throwing everything off.  All other types of alerts work properly.  I had 
this happen to me with the following two rules so far:

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT STAT * dos 
attempt"; flow:to_server,established; content:"STAT"; nocase; content:"*"; 
distance:1; reference:bugtraq,4482; classtype:attempted-dos; sid:1777; 
rev:2;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP CWD ..."; 
flow:to_server,established; content:"CWD"; nocase; content:"..."; 
classtype:bad-unknown; sid:1229; rev:5;)

Here is the what the alert file shows:

02/24-11:04:52.013548  [**] [1:1229:5] FTP CWD ... [**] [Classification: 
Potentially Bad Traffic] [Priority: 2] {TCP} 65.205.204.91:52731 -> 
x.x.x.x:21

Here is what gets logged into the tcpdump file:

11:04:52.013548 2c:35:0:1:42:71 0:0:0:3:ba:27 5ac1 171:
0x0000   0800 4510 009d 0000 0000 f006 0000 41cd 
0x0010   cc5b xxxx xxxx cdfb 0015 d530 8e6d e656 
0x0020   deb8 5018 fd5c 0000 0000 2e2e 2e2e 2e2e 
0x0030   2e2e 2e2e 2e2e 2e2e 5041 5353 2067 6c6f 
0x0040   6261 6c31 0d0a 5459 5045 2041 0d0a 4357 
0x0050   4420 4656 4d5f 7465 6d70 0d0a 504f 5254 
0x0060   2036 352c 3230 352c 3230 342c 3931 2c31 
0x0070   3638 2c32 3033 0d0a 4e4c 5354 2070 6f72 
0x0080   7466 6f6c 696f 2a32 2e33 2e31 2e6f 7574 
0x0090   7075 742e 6373 760d 0a51 5549 54 

As you can see, the first 2 bytes SHOULD be 4510, instead they are 0800. I 
am 99% certain that the problem is not with my hardware, since the alert 
log actually shows the correct information, and the stack on the ftp 
server wouldn't be able to process these packets, yet everything works 
fine.

The MAC address are also wrong.  They should be 0:1:42:71:5a:c1 and 
0:3:ba:27:2c:35

Any ideas/correlation?

-------------------------------------------
Gary Portnoy

Current thread: