Snort
[Top] [All Lists]

Re: [Snort-users] Alert payloads not matching alert rules

To: Joel Esler <joel.esler@sourcefire.com>, spagno_f@ifrance.com, snort-users@lists.sourceforge.net
Subject: Re: [Snort-users] Alert payloads not matching alert rules
From: Marc Norton <mnorton@sourcefire.com>
Date: Wed, 22 Nov 2006 15:34:14 -0500
Delivered-to: sp-com-lists@consult.net
Delivered-to: snort-list@securepoint.com
In-reply-to: <20061122191452.GL1710@Insight.local>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=snort-users>
List-help: <mailto:snort-users-request@lists.sourceforge.net?subject=help>
List-id: "Snort users talk about... Snort!" <snort-users.lists.sourceforge.net>
List-post: <mailto:snort-users@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/snort-users>, <mailto:snort-users-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/snort-users>, <mailto:snort-users-request@lists.sourceforge.net?subject=unsubscribe>
References: <20061122185434.3091F1F8A4@ifrance02.ifrance.com> <20061122191452.GL1710@Insight.local>
Sender: snort-users-bounces@lists.sourceforge.net
User-agent: Thunderbird 1.5.0.8 (Windows/20061025)
On Snort 2.6.0, if your reassembling port 1521 traffic in stream4 you 
might want to use the stream4 zero_flush_buffers options to wipe any 
empty buffer space clean so you don't false positive.  That often clears 
up this symptom, its worth a shot.

Joel Esler wrote:
> Are you dropping any packets?  It seems that with 3 processes of Snort, on 
> the same box, with only 2 Gigs of RAM trying to analyze that much traffic, 
> you are probably dropping packets in addition to Snort overwriting its own 
> memory.
>
> J
>
>
> On Wed, Nov 22, 2006 at 07:54:34PM +0100, it looks like spagno_f@ifrance.com 
> sent me:
>   
>> Hello,
>>
>> The machine is a dual Opteron with 2GB of RAM. It runs 3 instances of snort. 
>> Each snort process sends logs to a specific log directory. Each snort 
>> process has its barnyard process processing its logs/alerts to the mysql DB. 
>> Each snort process listens on its own interface. Each interface is attached 
>> to the SPAN port of a gigabit switch.
>>
>> Fabien
>>
>> Joel Esler:
>>     
>>> How much RAM do you have in your machine?
>>>
>>> Joel
>>>
>>>
>>> On Tue, Nov 21, 2006 at 06:48:22PM +0100, it looks like 
>>> spagno_f@ifrance.com sent me:
>>>       
>>>> 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
>>>>         
>>> +---------------------------------------------------------------------+
>>> joel esler          senior security consultant         1-706-627-2101
>>> Sourcefire    Security for the /Real/ World -- http://www.sourcefire.com
>>>        Snort - Open Source Network IPS/IDS -- http://www.snort.org
>>>          gpg key: http://demo.sourcefire.com/jesler.pgp.key
>>> +---------------------------------------------------------------------+
>>>
>>>       
>> ________________________________________________________________________
>> 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
>>     
>
> +---------------------------------------------------------------------+
> joel esler          senior security consultant         1-706-627-2101
> Sourcefire    Security for the /Real/ World -- http://www.sourcefire.com
>        Snort - Open Source Network IPS/IDS -- http://www.snort.org
>          gpg key: http://demo.sourcefire.com/jesler.pgp.key
> +---------------------------------------------------------------------+
>
> -------------------------------------------------------------------------
> 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
>
>   


-- 
Marc Norton      Snort Team Lead
Sourcefire,Inc   410-423-1924
www.snort.org    www.sourcefire.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

<Prev in Thread] Current Thread [Next in Thread>