A feature of the Cisco Intrusion Prevention System appliances and modules which is both powerful and largely not discussed is the Event Action Filter. This blog entry will elaborate on the varied functions of each of the entry fields. Before we go into such detail, however, an understanding of the placement of the filter in the overall operational scheme of IPS is in order.
Event Action Filters are but one of two components in the Event Action Rules configuration subsection, the other being Event Action Overrides. While the overrides describe additional actions to be taken by the sensor (typically deny packet or deny attacker) when a minimum computed Risk Rating is met, filters “take away”, exclude, or subtract such actions based on a more complex set of criteria.
Although Event Action Filters are typically implemented to exempt a certain IP address (such as a vulnerability scanner) from being blocked through the sensor, additional qualifiers can be added as is illustrated below:
The screen shown above, viewed with IPS Device Manager, shows just one filter rule in what could be a multi-rule list. As shown by the second-to-last item Stop on Match, this list can be processed using a first match Yes or an additive No approach. Secondly, the filter rule can be placed in an inactive rule list by choosing No under the Active line where it will no longer be considered for evaluation or it can be kept in the active rule list but not evaluated by choosing No under the Enabled line.
Event Action Filter rules apply to all IPS signatures by default, as shown by the pre-supplied range of 900 – 65535. This can be modified to be a more discrete range of signatures, a comma-separated list of signatures, or a combination of both.
The Attacker Address field listed below the signature ID fields is the most common one entered, as frequently a network administrator wants to exclude a network vulnerability scanner from being denied transmitting packets through the sensor. This can be further supplemented by adding the Victim Address field to limit the exclusion of the scanner to only valid destination networks.
The inclusion of Risk Rating allows for a filter rule to be configured as a counterpart to an Event Action Override. If the override specifies that an attacker will be denied for the Risk Rating being ≥ 95, for example, that same criteria could be input here to exempt a source address or source-destination pair from being denied.
Below the Risk Rating field, the OS Relevance entry area can be used to subtract actions in situations where a signature is deemed to be irrelevant to the target Operating System. This feature is given the alternate name OS Relevance Filter.
The final remaining field on this screen is a Deny Percentage, an interesting value which defaults to 100 and can provide a crude rate-limiting function for deny actions. One such example of this would be to use a number of 75 and associate this with a flood signature whereby traffic would be throttled to 25% of arrival rate to the sensor.
Author: Doug McKillip