Here is the info from the event viewer. Is this enough?

evIdsAlert: eventId=1190445584386567352 vendor=Cisco severity=informational

originator:

hostId:

appName: sensorApp

appInstanceId: 563

time: October 29, 2007 6:14:48 PM UTC

signature: description=TCP SYN Host Sweep id=3030 version=S2

subsigId: 0

marsCategory: Probe/SpecificPorts

interfaceGroup: vs0

vlan:

participants:

attacker:

addr: 10.x.x.x locality=OUT

port: 1148

target:

addr: 10.x.x.x locality=OUT

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

target:

addr: 10.x.x.x locality=OUT

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

target:

addr: 10.x.x.x locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: 10.x.x.x locality=OUT

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

target:

addr: 10.x.x.x locality=OUT

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

target:

addr: 10.x.x.x locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: 10.x.x.x locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: 10.x.x.x locality=OUT

os: idSource=learned type=linux relevance=relevant

target:

addr: 10.x.x.x locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: 10.x.x.x locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: (external IP) locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: (external IP) locality=OUT

os: idSource=learned type=bsd relevance=relevant

target:

addr: (external IP) locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: (external IP) locality=OUT

os: idSource=unknown type=unknown relevance=relevant

target:

addr: (external IP) locality=OUT

os: idSource=learned type=linux relevance=relevant

riskRatingValue: 31 targetValueRating=medium attackRelevanceRating=relevant

threatRatingValue: 31

interface: ge0_x

protocol: tcp

Wow, I hope that is what the problem is. Would it be a bad idea to make the filter (From:internal To:ALL) ?

Edit: That solved the problem! Thanks so much for the help!

The issue here is what addresses are checked by the filter.

The filter does NOT check all of the destination addresses.

The filter ONLY checks the one source adddress and the last destination address that actually triggered the alert.

There are 2 problems that this causes:

1) If you connect to 10 addresses (assuming 10 addresses is the trigger for the signature), then whether or not the alert is generated is determined solely by that 10th address regardless of the first 9.

If you try to filter by Inside addresses, then the first 9 could be Inside, and the 10th be Outside and the sig WILL generate an Alert.

By the same token the first 9 could be Outside, and the 10th be Inside nad the Alert will NOT generate.

This is usually not what users want when trying to filter on sweep signatures.

2) There is a second problem in that determining that trigger address is not always easy. In many sweep signature the trigger destination address is not necessarily seen in the Alert.

To see the trigger address you have to enable the produce-verbose-alert event action. This adds a trigger packet to the alert, and you can look at that actual trigger packet to determine the trigger destination address.

(NOTE: This is a bug in the sweep engine, and will be resolved in a future update so the trigger destination address gets seen in the Alert itself as well.)

The result is that you really can't use the event action filters to get what you want.

HOWEVER, there is a workaround.

Instead of relying solely on event action fitlers you woud need to use the signature address filters that are built into the signature itself.

Edit the 3030 signature and look for the "specify-src-addr-filter" and "specify-dst-addr-filter" parameters. You can fitler out addresses directly on the signature itself.

To get what you want use a combination of the 2 types of filters and cloned signatures.

Create a clone of 3030, and let's call it 63030.

Create an Event Action Filter for 3030 for Inside Source Addresses and remove all actions. This signature will only then Alert on Outside addresses scanning ANY (Inside or Outside) Destination Addresses.

On the new 63030 edit the signature itself and edit the specify-dst-addr-filter to filter out all Inside addresses (note: you will need to specify the actual addresses and can not just say $Inside)

Now create an Event Action Filter for 63030 for Outside source addresses and removes all actions. So now 63030 wll only trigger for Inside Source Addresses scanning Outside Addresses.

So you don't use destination addresses in any Event Action Filters. Instead the destination address type filters are done on the signature itself in 63030.

The filter within the signature itself prevents the signature from even looking at those packets in the first place. So the Inside addresses won't even be counted as scanned hosts. So 63030 will only track the scanning of Outside hosts.

Thanks very much for the info Marco. I saw these parameters in the sig but was unsure if it would cause the signature to only fire if it saw these IP addresses...or the opposite.

Based on my memory it should filter out (not fire on) those addresses.

Though it has been well over a year since I have dealt with those parameters.

So if I want to only filter out external destination addresses I could input 0.0.0.0-9.255.255.255,11.0.0.0-255.255.255.255 in the "dst-addr-filter" field and that should work?

Thanks,

J