Issue with applying Event Action filters

[gautamzone]

Dear friends,

A general question on Event Action filters. There is a signature with sig ID 6257.

The following is the event action filter configuration:

service event-action-rules rules0

filters edit DHCP

signature-id-range 6257

subsignature-id-range 0

attacker-address-range 172.20.20.10,172.20.20.11

actions-to-remove produce-alert

filter-item-status Enabled

stop-on-match True

os-relevance not-relevant

exit

Even though a valid DHCP offer is being given by the DHCP server, this alert is getting fired.

We have even excluded the IP's of the DHCP Servers - 172.20.20.10 and 172.20.20.11 from the Attacker Address range parameter in the signature but still this alert gets fired.

evIdsAlert: eventId=1204853641442197329 vendor=Cisco severity=low

originator:

hostId: IDSM2Core1

appName: sensorApp

appInstanceId: 592

time: April 7, 2008 5:46:48 AM UTC offset=180 timeZone=1

signature: description=DHCP Client DoS id=6257 version=S316

subsigId: 0

sigDetails: Server Offered a Malicious IP Address

marsCategory: DoS/Host

interfaceGroup: vs0

vlan: 200

participants:

attacker:

addr: 172.20.20.10 locality=OUT

port: 0

target:

addr: 10.1.1.78 locality=OUT

port: 0

os: idSource=unknown type=unknown relevance=unknown

summary: 4 final=true initialAlert=1204853641442197267 summaryType=Regular

alertDetails: Regular Summary: 4 events this interval ;

riskRatingValue: 25 targetValueRating=medium

threatRatingValue: 25

interface: ge0_7

protocol: udp

Looking forward to your kind help and advise on this.

Thanks a lot

Gautam

[marcabal]

Some things to check:

1) Is the filter in the active list? Filters can be enabled or disabled, but they can also be active ro inactive. You've only show a part of your configuration so I can't tell if the filter is part of the active list.

2) Are there actions other than produce-alert for the signature? Or is an event action override adding other actions?

Produce-alert is not the only action that can cause an alert to be generated. The produce-verbose-alert, request-snmp-trap, log-attacker-packets, log-victim-packet, and log-pair-packets will also cause alerts to be generated. Modify the filter to also remove these actions.

3) The alert you've shown is a Summary Alert. There may be an issue with Summarization and the Filters. Try modifying the signature to set it to FireAll with no summarization.

4) If you have multiple filters then check the order of the filters. If the event is matching an earlier filter where the stop-on-match is set to True, then it will not check the event against this filter. Either move this filter up higher in the filter list, or change earlier filters to be "stop-on-match false".

5) Also check to see if you are running the latest 5.1(7) or 6.0(4) Service pack. If running earlier 5.1 or 6.0 versions you might be hitting a bug that could have already been fixed.

If none of the above help, then contact the TAC. It could be that you may have foung a bug that the sensor development team is unaware of.

To help in identifying the problem take a packet capture of the packets from 172.20.20.10 for several minutes around the time when the sensor is generating these alerts.

This way the team can both check if the signature is firing correctly, and if the filters are working correctly for that signature.