10-26-2007 01:20 PM - edited 03-10-2019 03:51 AM
Hi Guys,
On my 4240 and IDSM2 IPS I tried applying an event action filter to filter this sig from firing from internal IPs and going to internal IPs on all ports. The signature is still being reported to my respective MARS boxes. I've tried different combinations of internal IP addresses and the filter still won't work. I've also moved the filter up to the first position in the list. This is the only filter out of dozens that does not work, btw.
Has anyone else encountered a similar problem or have a possible solution?
Thanks
Solved! Go to Solution.
10-29-2007 11:43 AM
I think I know what is happening. Remember, the event action filters are simply removing actions for the alarm. This particular alarm contains a few destination IP addresses outside your filter, so the actions aren't being removed.
10-29-2007 07:14 AM
Can you show us one of the alarms?
10-29-2007 11:28 AM
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
10-29-2007 11:43 AM
I think I know what is happening. Remember, the event action filters are simply removing actions for the alarm. This particular alarm contains a few destination IP addresses outside your filter, so the actions aren't being removed.
10-29-2007 11:51 AM
Wow, I hope that is what the problem is. Would it be a bad idea to make the filter (From:internal To:ALL) ?
10-29-2007 12:26 PM
Edit: That solved the problem! Thanks so much for the help!
10-29-2007 01:27 PM
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.
10-29-2007 01:37 PM
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.
10-29-2007 01:41 PM
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.
12-18-2008 06:41 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide