Tuning SIG 5583 - SMB Remote SAM Service Access Attempt

Unanswered Question
Feb 11th, 2008
User Badges:

We are running Active Directory and this sig is firing 30000+ times a day. I do not want to disable the sig as we would likt to watch for external IP's as the source or destination.

Trouble is I cannot get an event filter to work for this beast and I cannot filter it at the sig level since there is no source/destination IP settings in the sig itself (SMB Engine).

Here is the event filter definition:-



signature-id-range: 5583,5579 default: 900-65535

subsignature-id-range: 0-255 default: 0-255

attacker-address-range: $Inside default:

victim-address-range: $Inside default:

attacker-port-range: 0-65535 <defaulted>

victim-port-range: 139,445 default: 0-65535

risk-rating-range: 1-100 default: 0-100

actions-to-remove: produce-alert|produce-verbose-alert default:

deny-attacker-percentage: 100 <defaulted>

filter-item-status: Enabled default: Enabled

stop-on-match: True default: False

user-comment: <defaulted>

os-relevance: not-relevant default: relevant|not-relevant|unknown

The $Inside variable is

basically our entire internal network.

The events I am being flooded with are single events and not summarized.

Here is an example of an alert:-

evIdsAlert: eventId=1192231627181681635 vendor=Cisco severity=informational


hostId: IDS

appName: sensorApp

appInstanceId: 571

time: 11 February 2008 15:59:52 UTC offset=0 timeZone=GMT00:00

signature: description=SMB Remote SAM Service Access Attempt id=5583 version=S262

subsigId: 0

sigDetails: SMB Remote SAM Service Access Attempt

marsCategory: Info/Misc/NetBios

interfaceGroup: int8

vlan: 36



addr: locality=Inside

port: 2956


addr: locality=Inside

port: 445

os: idSource=learned type=windows-nt-2k-xp relevance=relevant

riskRatingValue: 25 targetValueRating=medium


threatRatingValue: 25

interface: ge0_8

protocol: tcp

As you can see BOTH the source and destination are within the ranges specified in the filter but the event is still firing.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
mhellman Mon, 02/11/2008 - 15:17
User Badges:
  • Blue, 1500 points or more

hmm..nothing stands out as being wonky in my mind. The only thing I can think of is to check for another filter that matches before with a 'stop on match' that doesn't remove the alert action(s).

andrewtorry Tue, 02/12/2008 - 00:50
User Badges:

Forgot to mention that I have moved this filter to the TOP to specifically avoid any previous filters getting in the way.

mhellman Tue, 02/12/2008 - 05:41
User Badges:
  • Blue, 1500 points or more

You might try entering a static IP range in the filter and see if it works.

andrewtorry Tue, 02/12/2008 - 05:48
User Badges:

You mean replace the $Inside with a specific range like

Hmm. Nope. I have tried that and I have even tried specific IP addresses for the source/destination but still get alerts with exactly those two addresses getting through.

Filtering is working though as I have a filter active also for the 'DHCP offer' sig in that I have filtered out all our 'expected' DHCP sources, and SMTP filters for 'expected' SMTP sources.

Why can I not filter out SMB sources/ destinations such as Windows Servers and/or M$ Domain Controllers.

Come on Cisco, event filtering was so easy in IDS4, why complicate it so much in IPS6.

jakasper Tue, 02/12/2008 - 14:10
User Badges:

The filter says: os-relevance: not-relevant

But the alert says: os: idSource=learned type=windows-nt-2k-xp relevance=relevant

I suspect that is why this one filter is not matching.

You probally want to revert the os-relevance to its default setting for this filter.

Also, make sure you examine the 'stop-on-match' filters closely. If you match a filter that has 'stop-on-match true', it will stop evaluation of any more filters for that alert, so that could cause strange results.



This Discussion