[Snort-sigs] Calling Samba/SMB experts (was RE: NETBIOS Stuff on Snort-Sigs)
g.coochey at ...138...
Fri Mar 1 16:09:11 EST 2002
It's time to become effective in this area.
Part of the success in Snort is encompassing all IP traffic, which must
include Samba and NetBIOS traffic.
If anyone is interested in assisting with a Samba/SMB protocol decode
project to understand and develop current and new SMB/NBT rules please
contact me BROM.
If anyone also has Xover to the Samba project itself - let me know.
Otherwise, we'll continue at our allowable rate, because of job restrictions
I can throw resources at this myself, but at significant loss to my personal
From: Al [mailto:a.hood at ...314...]
Sent: 01 March 2002 18:19
To: g.coochey at ...138...
Subject: NETBIOS Stuff on Snort-Sigs
>Signatures that are designed to detect NetBIOS activity will also have to
>check port 445 to catch Win2k <--> Win2k NetBIOS events and not ports
>137,138 (UDP) and 139 (TCP).
>Some of the signatures may also have to be reengineered.
Yup, also true, IMHO. I mentioned this on snort-sigs a while back, but
nobody's got back (they either all hate SMB or I'm too lame to respond to
>Thanks to the person who contacted me to look into the NetBIOS saga
>recently. When I was looking at the NetBIOS Nimda events. I've got your
>email around here somewhere, just don't know where.
It was probably me - I dropped you a note 4/2/02. Shall we just agree some
new improved SMB rules and post them? There are also issues in the sigs re:
Unicode vs Ascii/Ansi, I reckon. My previous posting is copied below, and
you need the capture files I'll send them to you on Monday.
The above correspondence is solely informal, and does not
constitute the views or advice of QinetiQ in any way
I've started looking at some NetBios sigs to help with the documentation
drive, but found that some of them are different from my observations -
- SID 530 doesn't match any null share captures I've seen - I've looked
through sample transactions (by eye, admittedly, under ethereal) and can't
work out what the pattern is meant to represent, under NT4 or Samba. Am I
missing something (eg is it W2K or some dialect of SMB, or am I just being
packetblind)? Also, isn't it the same in concept as SID 537? Does anyone
get any hits with this rule?
- SID 532 - my captures show the string as containing additional nulls (a
Unicode thing?), and the service name differs depending on whether you're
connecting from NT4 or Linux - | 00 41 3a 00 | ie A: is | 3f 3f 3f 3f 3f |
????? under Samba/Linux. Alternative/additional sig could therefore be | 5c
00 41 00 44 00 4d 00 49 00 4e 00 24 00 00 00 | followed by | 41 3a 00 | for
NT4 attacker or | 3f 3f 3f 3f 3f 00 | for Samba/Linux attacker. Again, does
anyone see this rule report ADMIN$ connects accurately?
- SID 533 - as for 532, extra nulls in my packet captures that might cause a
false neg. Alternative sigs seem to be | 5c 00 43 00 24 00 00 00 | then
either | 41 3a 00 | for NT4 or | 3f 3f 3f 3f 3f 00 |for Samba/Linux.
- SID 536 - more nulls. Amended sigs would be | 5c 00 44 00 24 00 00 00 |
then either | 41 3a 00 | for NT4 or | 3f 3f 3f 3f 3f 00 | for Samba/Linux.
- SID 537 - ditto. The sig is \\IPC$|00 41 3a 00| - I see | 5c 00 49 00 50
00 43 00 24 00 00 00 3f 3f 3f 3f 3f 00 | for both NT4 and Samba/Linux (ie
service name doesn't differ on this one - go figure!).
This null business is bugging me - maybe my test server is requesting
or whatever, and the one used for the original sigs didn't. Any other
Individual packet caps are attached for NT4->NT4 and Samba->NT4, if you want
the whole streams let me know. (I didn't capture 536 D$ as it's conceptually
identical to 533 C$).
All ideas gratefully received - when I'm sure I'm not losing the plot, I'll
submit the issue descriptions for the database.
More information about the Snort-sigs