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
accross a similar exemple (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 becomes almost unusable since, when we try to analyse
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
________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
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
