Hello,

We encounter a strange problem with snort 2.6.0, Barnyard, BASE, all compiled from source files. 

We have alerts which do not match the alert rules generating the alert. Actually, by looking at the payload, we cannot 
find content we should see. It seems several people already complained about this problem before, without any real 
answer (http://marc.theaimsgroup.com/?l=snort-users&m=112505975311791&w=2)

Here is an example below. 
We have this rule generating alerts we see in BASE :

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 NOOP";
content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; depth: 128;
reference:arachnids,181; classtype:shellcode-detect; sid:648; rev:4;)

Alert generated by this rule, in BASE :

#(6 - 56146) [2006-09-29 15:27:22] [arachnids/181] [local/648] [snort/:648]
SHELLCODE x86 NOOP
IPv4: 172.16.5.27 -> 172.16.5.12
      hlen=5 TOS=0 dlen=155 ID=59197 flags=2 offset=0 TTL=128 chksum=45271
TCP:  port=3563 -> dport: 1521  flags=***AP*** seq=831827579
      ack=2816413717 off=5 res=0 win=16370 urp=0 chksum=12348
Payload:  length = 115

000 : 00 73 00 00 06 00 00 00 00 00 03 5E 98 20 80 00   .s.........^. ..
010 : 00 06 00 00 00 00 00 00 00 00 01 0C 00 00 00 00   ................
020 : 01 00 00 00 00 E8 03 00 00 00 00 00 00 00 00 00   ................
030 : 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 00   ................
040 : 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
050 : 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00   ................
060 : 00 00 00 00 00 00 00 00 00 00 00 00 07 05 C4 05   ................
070 : 31 0B 07                                          1..

As you can see there is no '90' bytes, as we should see in the payload. 

This not the only rule with this problem. Others have the same problem too (sometimes eevn preprocessors like 
http_inspect too).

While looking at the ASCII dump.log file generated by barnyard I have also came across a similar exemplar (below). For 
this alert, we should see a "user" somewhere in the payload, but we don't :


[**] [1:2650:2] ORACLE user name buffer overflow attempt [**]
[Classification: Attempted User Privilege Gain] [Priority: 1]
[Xref => http://www.appsecinc.com/Policy/PolicyCheck62.html]
Event ID: 62662     Event Reference: 62662
11/21/06-17:16:04.892127 172.16.0.136:34833 -> 172.16.5.12:1521
TCP TTL:64 TOS:0x0 ID:32755 IpLen:20 DgmLen:100 DF
***AP*** Seq: 0xB700F908  Ack: 0xF1594793  Win: 0x3309  TcpLen: 32
TCP Options (3) => NOP NOP TS: 2796076485 835448929 
00 30 00 00 06 00 00 00 00 00 03 68 FB 01 00 00  .0.........h....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 01  ................ 

With this problem Snort (which is a widely used network monitor & packet sniffer) becomes almost unusable since, when we try to analyze an alert to see if this is a false 
positive or not, we cannot have the correct payload which generated the alert. We don't know if this is a Snort or a 
Barnyard problem. Unfortunately, for now, I was not able to do a tcpdump of one of these packets.

Have you noticed the same behavior ?

What could be the cause of the problem ? What solution to apply ?

Thank you for your help

Other topics of interest include:
How to Save & Exit from VI or VIM via Command line.