Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Tuning SIG 5583 - SMB Remote SAM Service Access Attempt

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:-

NAME: InsideSAM_SMB

-----------------------------------------------

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

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

attacker-address-range: $Inside default: 0.0.0.0-255.255.255.255

victim-address-range: $Inside default: 0.0.0.0-255.255.255.255

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 10.0.0.0-10.255.255.255

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

originator:

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

participants:

attacker:

addr: 10.36.3.52 locality=Inside

port: 2956

target:

addr: 10.11.1.63 locality=Inside

port: 445

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

riskRatingValue: 25 targetValueRating=medium

attackRelevanceRating=relevant

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.

5 REPLIES
Gold

Re: Tuning SIG 5583 - SMB Remote SAM Service Access Attempt

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).

New Member

Re: Tuning SIG 5583 - SMB Remote SAM Service Access Attempt

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

Gold

Re: Tuning SIG 5583 - SMB Remote SAM Service Access Attempt

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

New Member

Re: Tuning SIG 5583 - SMB Remote SAM Service Access Attempt

You mean replace the $Inside with a specific range like 10.0.0.0-10.255.255.255.

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.

New Member

Re: Tuning SIG 5583 - SMB Remote SAM Service Access Attempt

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.

-JK

526
Views
0
Helpful
5
Replies