Bluehost.com Web Hosting $6.95

Re: [Snort-users] NETBIOS Unicode Access - False Positives

This is a discussion on Re: [Snort-users] NETBIOS Unicode Access - False Positives within the Snort forums, part of the System Security and Security Related category; Excuse the formatting, this is what happens to HTML email when you get a digest version of the list. On ...


Go Back   Usenet Forums > System Security and Security Related > Snort

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 08-23-2004
Nigel Houghton
 
Posts: n/a
Default Re: [Snort-users] NETBIOS Unicode Access - False Positives

Excuse the formatting, this is what happens to HTML email when you get a
digest version of the list.

On 0, snort-users-request@lists.sourceforge.net allegedly wrote:
> Message: 8
> Date: Wed, 18 Aug 2004 22:55:40 -0400
> From: "Gross, Mark" <mgross@microstrategy.com>
> To: <snort-users@lists.sourceforge.net.>
> Subject: [Snort-users] NETBIOS Unicode Access - False Positives
>
> This is a multi-part message in MIME format.
>
> ------_=_NextPart_001_01C48598.03157D00
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi all,
>
> =20
>
> I checked out the list regarding a lot of the NETBIOS rules and there =
> seemed to be some others who are having similar (or the same) issues as =
> I. Alerts are being generated for packets that are part of normal =
> traffic. I am sure that this has been covered somewhere, so if it's a =
> duplicate, or you are aware of this, then please disregard it. If there =
> are updated rules they are not official as the below listed rule was =
> taken from the daily Aug. 18th, 2004 and I found no updates in the =
> database (with or without documentation).


This is a known issue, yes. Please make sure your $HOME_NET and
$EXTERNAL_NET variables are set correctly in snort.conf. These rules rely
on these variables.

Essentially, these Netbios shares should not be accessible over the
Internet or from a DMZ host. The $EXTERNAL_NET variable should be everything
not on your protected network, i.e. !$HOME_NET (simplisticly speaking).

> =20
>
> The rules that are causing ALERTS:
>
> =20
>
> NETBIOS SMB C$ share unicode access (sid:2470), NETBIOS SMB IPC$ share =
> unicode access (sid:538), NETBIOS SMB-DS C$ share unicode access =
> (sid:2472) and NETBIOS SMB-DS IPC$ share unicode access (sid:2466).
>
> =20
>
> Apparently this is triggered anytime that anyone accesses a network =
> share on a 2002 server (maybe others too) with the NETBIOS command "Tree =
> Connect AndX Request".


Shouldn't happen from a host not on your protected net.

> =20
>
> The alerts are generated by accessing ANY/EVERY network share weather a =
> user has the rights or not.


Right, the rules are looking for administrative share access, something you
don't want to see from anything outside your protected network.

> =20
>
> I only listed one of the four rules, however the other three are matched =
> later in the stream.
>
> =20
>
> Here is the rule and one packet (Tree Connect AndX Request).
>
> =20
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (msg:"NETBIOS SMB IPC$ =
> share unicode access"; flow:to_server,established; content:"|00|"; =
> depth:1; content:"|FF|SMB"; depth:4; offset:4; =
> byte_test:1,>,127,7,relative; content:"I|00|P|00|C|00 24 00 00|"; =
> distance:33; nocase; classtype:protocol-command-decode; sid:538; =
> rev:11;)
>
> =20
>
> =20
>
> 000005D3 00 00 00 5a ff 53 4d 42 75 00 00 00 00 18 07 c8 =
> ...Z.SMB u......=C8
>
> 000005E3 00 00 48 92 dd 80 0b bb 2c bd 00 00 00 00 ff fe =
> ..H'=DD..=BB ,......=FE
>
> 000005F3 03 48 40 2e 04 ff 00 5a 00 08 00 01 00 2f 00 00 =
> .H@....Z ...../..
>
> 00000603 5c 00 5c 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 =
> \.\.S.E. R.V.E.R.
>
> 00000613 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 5c 00 49 00 =
> -.1.-.I. A.S.\.I.
>
> 00000623 50 00 43 00 24 00 00 00 3f 3f 3f 3f 3f 00 =
> P.C.$... ?????.
>
> =20
>
> =20
>
> There were a total of 33 packets from the time that the Tree Request was =
> made to the time that the Tree Disconnect was made. In those 33 packets =
> all 4 of the above listed rules were true.
>
> =20
>
> It would seem that the rule needs to be modified to ALERT if the "NT =
> Status: STATUS_ACCESS_DENIED (0x0000022)" is returned anywhere in the =
> stream.


But then you would miss a sucessful attempt to connect.

>
> --__--__--


If these rules continue to generate false positives when the variables are
set correctly, please forward packet captures and the relevant variable
information from snort.conf.

+-------------------------------------------------------------------------+
Nigel Houghton Research Engineer Sourcefire Inc.
Vulnerability Research Team

"Dude, dolphins are intelligent and friendly!" - Wendy
"Intelligent and friendly on rye bread, with some mayonaise." - Cartman
+-------------------------------------------------------------------------+


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/...fo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.p...st=snort-users
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +1. The time now is 04:08 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0