Issue with applying Event Action filters

Question

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

Answer 1

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.