Cisco Guard Configuration Guide (Software Version 3.08) - Advanced Filter Procedures [Cisco Guard DDoS Mitigation Appliances]

Table Of Contents

Advanced Filter Procedures

Guard Filter System Overview

Guard Traffic Paths

Flex Filter

Flex Filter Configuration

Displaying the Flex Filter

Removing a Flex Filter

Bypass Filters

Bypass Filter Configuration

Displaying the Bypass Filters

Removing a Bypass Filter

User Filters

User Filter Configuration

Displaying the User Filters

Removing a User Filter

Renumbering the User Filters

The Guard Dynamic Filters

Configuring the Guard Dynamic Filters

Viewing All Zone's Dynamic Filters

Sorting Zone Dynamic Filters

Removing a Dynamic Filter

Zone Dynamic Filter - General View

Specific Dynamic Filter - Detailed View

Advanced Dynamic Filters Configuration

Advanced Filter Procedures

This chapter describes in detail the Guard filter system and the advanced procedures the user can perform to adopt the Guard filters to its protection policy.

Guard Filter System Overview

During protection the Guard operates its filter system as one of its protection means. The Guard filter system is the system that directs the diverted traffic to the required protection modules' mechanisms. The Guard enables the user to set its preferred filter configurations and thus design a variety of possibilities for customized traffic direction and anti-DDoS attack mechanisms.

Figure 9-1 displays the Guard filter system guided by the combination of the user and Guard traffic protection definitions.

Figure 9-1 Guard FIlter System

Prior to a DDoS attack the Guard directs the Zone traffic flows through the Analysis protection module, the Guard Sampler and Rate Limiter and on to the zone (see Figure 9-1). On this path the Guard samples and rate limits the zone-diverted traffic and the Guard Recognition module analyzes the traffic.

When the Guard protection policies' sense abnormal or malicious traffic (by means of Threshold violation) they dynamically configure a set of filters (Dynamic Filters) to direct the traffic to the appropriate protection module ranging from the Basic to the Drop protection modules according to the attack severity.

The Recognition module may decide, based on its traffic analysis, to escalate its counter DDoS attack measures and, via its Dynamic Filters, direct certain traffic flows from the Basic module on to the Strong protection module, or even to the Drop module for a traffic flow, or flows, drop.

As previously mentioned, the user may define its own protection preferences. The user may configure the following:

•The Flex filter—See the "Flex Filter Configuration" section in this chapter for details.

•The Bypass Filters —See the "Bypass Filter Configuration" section in this chapter for further details.

•The User Filter —See the "User Filter Configuration" section in this chapter for further details.

The Flex filter is a Berkley Packet filter that facilitates the user with extremely selective filtering capabilities (see the "Flex Filter" section in this chapter). The user can decide either to count or drop the desired particular traffic.

The Bypass filter is a filter designed to support the user on protection policy decisions that the user thinks should not involve the Guard's protection mechanisms. Decisions of such a kind may, for example, be letting a trusted traffic flow bypass the Guard's protection modules including the anti-spoofing mechanisms.

The User filters, however, are different in the options they offer the user to customize the Guard protection. The User filters enable the user to set guiding rules to handle desired traffic flows when an attack is suspected. The user can configure its preferred anti-spoofing mechanisms or even decide to drop a specified traffic flow.

Note Zone configurations include, by default, a default set of User filters. When initially handling malicious traffic the Guard initializes its protection cycle by utilizing that default set of User filters (see the "Guard Traffic Paths" section).

Guard Traffic Paths

As the user issues the protect command the Guard begins the diversion procedure and the zone traffic begins to flow through the Guard. As long as no signs of an upcoming DDoS attack are indicated the traffic assumes the path leading to the Analysis protection module denoted by the straight line in the above filter system drawing. The traffic travels unhindered (unless otherwise user-configured) through the Flex (if configured to filter) and the Bypass filters, the Analysis protection module, sampled by the Guard Sampler, and onto the zone.

As the Guard, based on its traffic analysis, senses the first indicators of a DDoS attack the suspected traffic changes its flow within the Guard and assumes the path indicated by the arched broken line. The suspected traffic now flows through the Flex, and Bypass filters (provided they are not configured to direct the suspected traffic flow to bypass the Guard's protection), and into the Comparator. The Comparator is fed with the following inputs:

•Input from the Guard Dynamic Filters—As the protection cycle begins the Dynamic filter directs the Guard to follow the User filter protection guidelines.

•Input from the Guard User Filter—As the protection cycle begins the User filters consist of either, default, or user defined protection directions.

As a result the Comparator picks and executes the user filter protection recommendations. The traffic would then flow on to the appropriate protection module, sampled, rate-limited (if applicable) and on to the zone.

As the attack proceeds, and at times, strengthens, the Guard's Recognition module adds more dynamic filters. Now the dynamic filters have other directions than their former `to-user'. The Comparator is now fed with the following inputs:

•Input from the Guard Dynamic Filters—The dynamic filters direct the Guard towards implementing more stringent protection measures. The Guard would now consult the dynamic filter list that is relevant to a specific flow and choose the dynamic filter with the severest protection measure.

•Input from the Guard User Filter—The user filters have their default, or user-configured, protection directions. The user can access the User filters to define its own protection measures (see the "User Filters" section in this chapter for further details).

The Comparator weighs between the inputs to pick and execute the one with the severest suggested protection measure.

Note The user may access the Guard's Dynamic filters (see the "The Guard Dynamic Filters" section in this chapter for further details) and configure them to its protection policy. However, the user should consider that dynamic filters are designed to meet dynamically changing protection needs and so the Guard assigns them a limited lifespan (Timeout). The implication is that user-configured dynamic filters that do not out-weight the Guard's Recognition decision will not be implemented. The user-configured dynamic filters are removed once the protection ends.

The user can, for example, configure a User filter to direct a TCP traffic flow destined to a user-port 8080 to the Strong module (see Chapter 10, "Advanced Policy Procedures" for further details) anti-spoofing mechanism (while leaving the dynamic filter configured on referring the Guard to the user filter's decision). At he same time the Guard Recognition module configures a Dynamic filter directing the same traffic flow to be dropped. The Guard Comparator would pick and execute the Guard's protection measure. This is since the latter is the severest suggested protection measure of the two. The traffic would then flow to the Drop protection module and be dropped. The Guard protection ends when a certain, configurable, timeout passes since the last dynamic filter is removed (see the "Protection Termination Timer" section in Chapter 5, "Zone Configurations" and the "Removing a Dynamic Filter" section in this chapter for further details).

Flex Filter

The Flex filter is used to drop, or count a desired packet flow. This filter is useful in upfront blocking a minutely defined malicious source of traffic. This filter is very flexible and easily tailored to a specific traffic flow due to its parameter variety. However, only a single flex filter can be configured and it is resource consuming. Therefore, Cisco recommends the user use the Flex filter attentively due to its potential performance penalty.

The Flex filter is a Berkley Packet filter. Additional examples and explanations on the Berkley Packet filter configuration are available at: http://www.freesoft.org/CIE/Topics/56.htm or by issuing the man tcpdump command in Linux.

Flex Filter Configuration

To configure the Flex filter, from the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># flex-filter{drop|count}<parameters>
Where parameters include:

•dst host <host ip address>—Drops or counts the traffic to a destination host IP address

•src host<host ip address>—Drops or counts the traffic from a source host IP address

•host <host ip address>—Drops or counts the traffic to and from both source and destination host IP addresses

•net<net>mask <mask>—Drops or counts the traffic to a specified network

•net <net/len>—Drops or counts the traffic to a specified subnet

•dst port <destination port number>—Drops or counts the TCP or UDP traffic to a destination port number

•src port <source port number>—Drops or counts the TCP or UDP traffic from a source port number

•port<port number>—Drops or counts the TCP or UDP traffic to and from both source and destination port numbers

•less <packet length>—Drops or counts a packet with a length equal or less than the specified length bytes

•greater <packet length>—Drops or counts a packet with a length equal or greater than the specified length bytes

•ip proto <protocol>—Drops or counts a packet with a protocol number of the following protocols: icmp, udp, and tcp.

•ip broadcast—Drops or counts a broadcast ip packet

•ip multicast—Drops or counts a multicast packet

•ether proto <protocol>—Drops or counts ether protocol packets of a specified protocol number or name like ip, arp or rarp.

The Flex filter also has the following expression rules:
exp relop expr 
Where:

•relop is one of >, <, >=, <=, =, !=

•expr is an arithmetic expression composed of integer constants (expressed in standard C syntax), the normal binary operators [+, -, *, /, &, |], a length operator, and special packet data accesses. To access data inside the packet, use the following syntax:
proto [expr: size]
•proto is one of ether, ip, tcp, udp, or icmp, and indicates the protocol layer for the index operation. The byte offset, relative to the indicated protocol layer, is given by expr. Size is optional and indicates the number of bytes in the field of interest; it can be one, two, or four, and defaults to one. The length operator, indicated by the keyword len, gives the length of the packet.

Primitives may be combined using:

•A parenthesized group of primitives and operators (parentheses are special to the Shell and must be escaped)

•Negation (`!' or `not').

•Concatenation (`&&' or `and').

•Alternation (`||' or `or').

Negation has the highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit "and" tokens, not juxtaposition, are now required for concatenation. If an identifier is given without a keyword, the most recent keyword is assumed.

Examples:

•The below Flex-filter counts only unfragmented datagram and fragment zero of fragmented datagrams:
admin@GUARD-conf-zone-scannet#  flex-filter count ip[6:2]&0x1fff=0
This filter is implicitly applied to the tcp and udp index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an intervening fragment.

•The below Flex-filter drops all TCP RST packets:
admin@GUARD-conf-zone-scannet# flex-filter drop tcp [13] & 4 != 0
•The below Flex-filter counts all ICMP packets that are not echo requests/echo reply (ping):
admin@GUARD-conf-zone-scannet# flex-filter count icmp[0] != 8 and 
icmp[0] != 0 
•The below Flex-filter counts all TCP packets destined to port 80 that didn't originate from port 1000.
admin@GUARD-conf-zone-scannet#  flex-filter count tcp and dst port 
80 and not src port 1000
Displaying the Flex Filter

The user may wish to display the Flex filter.

To display the Flex filter perform the following:

1. From the Zone command group level type the following:
user@GUARD-conf-zone-<zone-name># show
2. Choose ENTER. The following sample screen appears:
admin@GUARD-conf-zone-scannet# show
Zone is under PROTECTION
Operation Mode: AUTOMATIC
... ... ...
FLEX-FILTER: tcp and dst port 80 and not src port 1000
FLEX-FILTER ACTION: count
FLEX-FILTER COUNTER: 200
... ... ...
admin@GUARD-conf-zone-scannet#
Note that the flex filter counter indicates 200 packets.

Removing a Flex Filter

The user can remove a flex filter.

To remove a Flex filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># no flex-filter 
2. Choose ENTER.

Bypass Filters

The Bypass filter is used to prevent specific traffic flows from being handled by the Guard's Dynamic filters, protection modules, and the Rate-limiter. This is how the user can direct trusted traffic away from the Guard's protection mechanisms and forward it directly to the zone.

Note The user should note that the Guard Rate-limiter does not consider the bypassed traffic bandwidth when coming to configure the Rate-limiter.

Bypass Filter Configuration

To configure the Bypass filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name>#  bypass-filter <row-numb> 
<src-ip> [<ip-mask>] <protocol> <dest-port> [<fragments-type>]
Where:

–row-numb—An integer to denote the filter and define priority among Bypass filters. The Guard operates the filters according to ascending row-number order.

–src-ip—To direct traffic coming from a specified IP address to bypass the Guard filter system. Type "*" for `any'.

–ip-mask—(Optional) To bypass traffic coming from a specified subnet. The mask will only contain Class C values.

Note If not specified, the Guard assumes a default subnet mask of 255.255.255.255.

–protocol—To direct traffic of a specified protocol to bypass the Guard filter system. Type "*" for `any'.

–dest-port—To direct traffic destined to a specified TCP or UDP port to bypass the Guard filter system. Type "*" for `any'.

–fragments-type—To direct specified fragmented-type traffic to bypass the Guard filter system. The fragmented types are:

•no-fragments—The Bypass filter acts on non-fragmented traffic.

•fragments—The Bypass filter acts on fragmented traffic.

•any-fragments—The Bypass filter acts on fragmented and non-fragmented traffic.

Note Fragments-type can not be defined if a port is specified.

2. Choose ENTER.

Displaying the Bypass Filters

The user may wish to display the Bypass filters.

To display the Bypass filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># show bypass-filters
2. Choose ENTER. The following sample screen appears:
admin@GUARD-conf-zone-scannet# show bypass-filters
... ... ...
**** BYPASS FILTERS ****
Row 
Source IP     
Source Mask   
Proto
DPort
Frg
RxRate 
(pps)
10
65.38.150.15
255.255.255.255
6
25
no
193
20
*
255.255.255.255
6
53
no
230
The table columns denote the filter parameters as explained above, including:

•RxRate(pps)—Indicates the current Bypass filter traffic rate measured in packets per second (pps). Displays N/A when data is unavailable.

Removing a Bypass Filter

The user can remove a desired Bypass filter.

To remove a Bypass filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># no bypass-filter <row-number> 
Where row-number specifies an integer to denote the filter to be removed. Use `*' to remove all Bypass filters. See the "Displaying the Bypass Filters" section to display the filter row number.

2. Choose ENTER.

User Filters

The User filter is used to direct a specified traffic to the desired protection module or to a Guard anti-spoofing mechanism (see the "Guard Filter System Overview" section in this chapter for further details).

User Filter Configuration

To configure the User filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name>#  user-filter  <row-num> 
<src-ip> [<ip-mask>]<protocol> <dest-port> [<fragments>] 
<filter-action> [rate-limit <rate> <burst> <units>]
Where:

–row-numb—An integer to denote the filter and define priority among the User filters. The Guard operates the filters according to ascending row-number order.

–src-ip—To direct traffic coming from a specified IP address to the User filter. Type" * " for `any'.

–ip-mask—(Optional) To direct traffic coming from a specified subnet. The mask will only contain Class C values.

Note If not specified, the Guard assumes a default subnet mask of 255.255.255.255.

–protocol—To direct traffic of a specified protocol to the User filter. Type" * " for `any'.

–dest-port—To direct traffic destined to a specified port to the User filter. Type "*" for `any'.

–fragments-type—To direct specified fragmented-type traffic to the User filter. Type:

•no-fragments—The User filter acts on non-fragmented traffic.

•fragments—The User filter acts on fragmented traffic.

•any-fragments—The User filter acts on fragmented and non-fragmented traffic.

Note Fragments-type cannot be defined if a port is specified.

–filter-action—The action denotes the action the filter performs on the specified traffic type. This could be either of the following:

•permit—The User filter directs the traffic to bypass the Guard anti-spoofing protection mechanisms. It is recommended to set a rate and burst limit for the permit User filter.

•basic/redirect—This User filter is used for authentication of applications over http.

•basic/reset —This User filter is used for authentication of application over TCP, excluding http.

•basic/default —This User filter is used for UDP traffic or when the user is not sure which action to choose.

•basic/dns-proxy—This User filter is used for authentication of TCP DNS applications.

•basic/safe-reset—This User filter is used for authentication of application over TCP, excluding http, for applications that are not tolerant of TCP connection reset.

•strong —This User filter is used when strong authentication for a traffic flow is required or when the previous filters do not seem suitable for the application. Authentication is performed for every connection. The Guard serves as a proxy therefore this filter is not to be used if the network is moderated according to IP addresses (such as using ACL-access control lists).

•drop—The User filter directs the traffic to be dropped

–rate—An integer denoting the rate limit. The units are specified by the units parameter.

–burst—This integer denotes the traffic burst limit. The units are Bits, kilo-bits, kilo-packets, mega-bits, and packets in correspondence to the rate units

–units—Denotes the rate limit units. The units could be one of the following:

•kpps—Kilo packets per second

•pps—Packets per second

•mbps—Megabits per second

•kbps—Kilobits per second

•bps—Bites per second

2. Choose ENTER.

The following is a sample user filter:
admin@GUARD-conf-zone-scannet# user-filter 12 permit * 6 90 rate-limit 
600 400 pps
This User filter row-numbered 12 aimed at traffic coming from all source IPs of protocol 6 (TCP) flowing to destination port 90. The filter permits their flow but limits their flow rate to 600 Packets per Second (pps) and their burst size to 400 packets.

Displaying the User Filters

The user may wish to display the User filters.

To display the User filters perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># show
2. Choose ENTER. The following sample screen appears:
admin@GUARD-conf-zone-scannet# show
... ... ...
**** USER FILTERS ****
Row
Source IP
Source Mask
Proto
D Port
Frg
Action
Rate
Burst
Units
Rx 
Rat pps
10
*
255.255. 
255.255
6
80
no
basic/ 
redirect
332
12
*
6
90
no
permit
600
400
pps
N/A
20
*
255.255. 
255.255
6
*
no
basic/ 
safe-res
et
2144
30
*
255.255. 
255.255
1
*
no
permit
300
300
pps
2270
... ... ...
admin@GUARD-conf-zone-scannet#
The screen columns indicate the following:

•Row—This column indicates the filter priority.

•Source IP—This column indicates the source IP. The source IP may be non-specific. i.e. "*", which means any source IP or more than one source IP was matched for the filter.

•Source Mask—This column indicates the source mask. The source mask may be non-specific. i.e. "*" which means any source mask or more than one source mask was matched for the filter

•Proto—This column indicates the protocol well-known number.

•DPort—This column indicates the filter-protected destination port

•Frg—This column indicates whether the User filter protects against fragmented traffic: `yes' indicates protection against fragmented traffic, "no" indicates protection against non-fragmented traffic, and "any" indicates protection against both fragmented and non-fragmented traffic.

•Action—This column indicates the action the User filter assumes.

•Rate—This column indicates the rate of which the packets were limited. The rate is displayed in the units specified by the `Units' column.

•Burst—This column indicates the traffic burst limit the filter allows per specified flow. The units are Bits, kilo-bits, kilo-packets, mega-bits, and packets in correspondence to the units specified in the `Units' column.

•Units—This column indicates the units by which the rate and the burst rate are displayed.

•RxRate(pps)—This column indicates the current User filter traffic rate measured in packets per second (pps).

Removing a User Filter

The user may remove a specified User filter.

To remove a specified user filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># no user-filter <row-number> 
Where row-number specifies an integer to denote the filter to be removed. Use `*' to remove all User filters. See the "Displaying the User Filters" section to view the filter row number.

2. Choose ENTER.

Caution Removing all user filters results in passing unprotected traffic to the zone when policy action is to-user-filter (see Chapter 10, "Advanced Policy Procedures" for further details).

Renumbering the User Filters

The user may wish to renumber the user filters in increments that would allow the insertion of new user filters.

To renumber the user filters perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># user-filter renumber <start> 
<step>
Where:

–start—An integer to denote starting number of the user filter list. The Guard would operate the user filters according to ascending row-number order beginning from the start number.

–step—The increment between each user filter row number. Enlarging the increment allows for the future insertion of a larger number of user filters.

2. Choose ENTER.

The Guard Dynamic Filters

As the Guard analyses the zone traffic it processes its analysis results into a set of filters that are continuously adapted to the zone traffic and type of DDoS attack. This filter set consists of the Dynamic filters. Once an abnormal traffic is detected the Dynamic filter, by default, refer the Guard to the User filters to compare between the User filters suggested action and the Guard suggested protection. The user can access the dynamic filters and configure them to its needs. See the "Guard Traffic Paths" section in this chapter and Chapter 10, "Advanced Policy Procedures" for further details.

Configuring the Guard Dynamic Filters

To configure the Dynamic filters perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># dynamic-filter <action> 
{<exp-time>|forever} <src-ip> <protocol> [<ip-mask>] <dest-port> 
[<fragments>]
Where:

–action—The action the filter performs on a specified traffic flow. The following options are available:

•to-user-filters—Forwards the specified traffic to the user configured User filters.

•strong—Applies Strong protection anti-spoofing mechanisms to the specified traffic.

•drop —Drops the traffic.

•block-unauthenticated-basic —Drops traffic flows that the Basic anti-spoofing mechanisms defined as unauthenticated.

•block-unauthenticated-strong—Drops traffic flows that the Strong anti-spoofing mechanisms defined as unauthenticated.

•block-unauthenticated-dns —Drops traffic flows (flowing to DNS servers) that the DNS anti-spoofing mechanisms defined as unauthenticated.

•redirect/zombie—The policy adds a filter that enhances authentication for all User filters with an action of redirect.

–exp-time|forever—The specified time for the filter to be active. There are the following options:

•exp-time—Specified desired time measured in seconds.

•forever—Unlimited time

Note When either the user issues no protect or the Guard terminates protection no dynamic filters are produced and the existing ones are removed. The forever parameter is then invalid.

–src-ip—The IP address for the Dynamic filter to be applied on. Use `*' for `any'.

–ip-mask—(Optional) The IP Mask for the Dynamic filter to be applied on. Use `*' for `any'. The mask will only contain Class C values.

Note If not specified, the Guard assumes a default subnet mask of 255.255.255.255.

–protocol—The traffic protocol for the filter to be applied to. This is denoted by the protocol number. Specify "*" for any protocol.

–dest-port—The destination port for the Dynamic filter to be applied on.

–fragments—(Optional) The fragments string consists of the following:
<any-fragments> | <no-fragments> | <fragments>}
The fragments parameter denotes a specified traffic type for the filter to operate on. This could be either of the following:

•any-fragments—The filter acts on fragmented and non-fragmented traffic

•fragments—The filter acts on fragmented traffic

•no-fragments—The filter acts on non-fragmented traffic.

2. Choose ENTER.

Note Dynamic filters can be added only to an already protected zone.

Note The Guard removes a zone's dynamic filters when the zone's protection is terminated.

Viewing All Zone's Dynamic Filters

The user may view all of the zone current Dynamic filters.

To view the zone current Dynamic filters perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># show dynamic-filters
2. Choose ENTER. The following sample screen appears:
admin@GUARD-conf-zone-scannet#show dynamic-filters
**** DYNAMIC FILTERS ****
ID
Action
Exp Time
Source IP
Source Mask 
Proto
DPort
 Frg
RxRate 
(pps)
1
to-user-
filters
568
*
255.255.255.255
6
*
no
N/A
2
strong
570
1.1.1.1
255.255.255.255
6
*
no
1919
The screen columns are:

•ID—This column indicates the filter identification number.

•Action—This column indicates the action the Dynamic filter assumes.

•ExpTime—This column indicates the amount of time for filter activation. After that the filter might be erased according to a set of criteria (see the "Advanced Dynamic Filters Configuration" in this chapter for details).

•Source IP—This column indicates the source IP address of the mitigated attack stream. The source IP may be non-specific. An asterisk (*) indicates that the value is undetermined or that the filter handles several traffic flows from the same IP address.

•Source Mask—This column indicates the source mask of the mitigated attack stream. The source mask may be non-specific. An asterisk (*) indicates that the value is undetermined or that the filter handles several traffic flows from the same source mask.

•Proto—This column indicates the protocol well-known number of the mitigated attack. An asterisk (*) indicates that the value is undetermined or a non-specific protocol attack.

•DPort—This column indicates the filter-protected destination port. An asterisk (*) indicates that the value is undetermined or that the filter handles several traffic flows to the same destination port.

•Frg—This column indicates whether the User filter protects against fragmented traffic: `yes' indicates a protection against fragmented traffic, "no" indicates protection against non-fragmented traffic, and "any" indicates protection against both fragmented and non-fragmented traffic.

•RxRate(pps)—This column indicates the current traffic rate measured for this Dynamic filter in packets per second (pps).

Note The Guard displays a maximum of 1000 dynamic filters. The Guard displays the following message when more filters exist: Please note: only 1000 dynamic filters are displayed. You may examine the log file for a full list.

Sorting Zone Dynamic Filters

The Guard enables the user to sort and view the zone Dynamic filters by ID, rate, action, and expiring time.

To sort and view the zone dynamic filters perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-scannet# show dynamic-filters sort {action| 
exp-time| id| rate}
Where:

–action—The Guard sorts and displays the current dynamic filters by their action ranging from the severest (drop) to the easiest (notify).

–exp-time—The Guard sorts and displays the current dynamic filters by ascending order.

–id—The Guard sorts and displays the current dynamic filters by ascending id number order.

–rate—The Guard sorts and displays the current dynamic filters by ascending order.

2. Choose ENTER. The following prompt appears:
admin@GUARD-conf-zone-scannet#
Removing a Dynamic Filter

The user may temporarily remove a specific Dynamic filter since the Guard will reproduce the dynamic filters again. See note below for further details.

To remove a specific Dynamic filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name>#no dynamic-filter 
<dynamic-filter-id>
Where dynamic-filter-id specifies the dynamic filter ID number. This is a number (integer) assigned by the Guard. Use `*' to remove all Dynamic filters. See the "Viewing All Zone's Dynamic Filters" section to view the filter ID.

2. Choose ENTER.

The user may remove all dynamic filters. The action is effective for a limited period of time since the Guard, being in a Protection operation mode, continues to configure new Dynamic filters to adopt its protection to the dynamically changing traffic state.

To prevent undesired Dynamic filters from being reproduced deactivate the policy that produces them (see the "Disabling a Policy Template" section in Chapter 10, "Advanced Policy Procedures" for further details). To find out which policy produced the undesired Dynamic filters see the sections about viewing Dynamic filters in this chapter.

The user can alternatively:

•Configure a Bypass filter for the desired traffic flow (see the "Bypass Filter Configuration" section in this chapter for further details).

•Increase the Threshold of the policy that produced the undesired Dynamic filters (see the "Threshold" section in Chapter 10, "Advanced Policy Procedures")

Zone Dynamic Filter - General View

The user may view a zone's specific Dynamic filter . The Guard displays the current status of the desired Dynamic filter.

To view a specific zone's Dynamic filter perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name>#show dynamic-filters 
<dynamic-filter-id>
Where dynamic-filter-id specifies the dynamic filter ID number. This is a number (integer) assigned by the Guard. See the "Viewing All Zone's Dynamic Filters" section to view the filter ID.

2. Choose ENTER.

Specific Dynamic Filter - Detailed View

The user may view a specific Dynamic filter with additional information on attack characteristics.

To display a detailed view of a specific Dynamic filter perform the following:

1. From Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name>#show dynamic-filters 
[<dynamic-filter-id>] details
Where dynamic-filter-id specifies the dynamic filter number. This is a number (integer) assigned by the Guard. If not specified, all Dynamic filters will be displayed in a detailed view. See the "Viewing All Zone's Dynamic Filters" section to view the filter ID.

2. Choose ENTER. The following sample screen appears:
admin@GUARD-conf-zone-scannet#show dynamic-filters details
**** DYNAMIC FILTERS ****
ID 
Action      
Exp 
Time
Source 
IP       
Source 
Mask     
Proto
DPort
Frg
RxRate 
(pps)
101  
to-user-filter 
27    
*              
1   
*    
no 
N/A
Attack flow:   1    *   *  192.168.100.34  *  no fragments
   Triggering rate: 8695.65        Threshold: 10.00
   Policy: other_protocols/any/analysis/pkts/protocol
... ... ...
admin@GUARD-conf-zone-scannet
The Guard details the following for each Dynamic Filter:

•Attack flow—The flow of the attack that was mitigated. Note that the mitigated attack flow, displayed in the Dynamic Filters table, could be of a wider range than the attack flow. For example, a non-spoofed attack on port 80 will block all TCP traffic from the originating source IP and not only port 80. The attack flow parameters consist of the following accordingly:

–Protocol—The protocol well-known number of the attack flow

–Source IP—The source IP of the attack flow

–Source Port—The source port of the attack flow

–Destination IP—The destination IP of the attack flow

–Destination Port—The destination port of the attack flow

–Fragments—Indicates whether the attack flow contains fragmented traffic: `fragments' indicates fragmented traffic, `no fragments' indicates non-fragmented traffic, and "any" indicates both fragmented and non-fragmented traffic.

•Triggering Rate—The attack flow traffic rate that violated a policy threshold.

•Threshold—The policy threshold that was violated by the attack flow.

•Policy—Indicates the policy that produced the specified Dynamic filter

A value of * for any of the parameters indicates one of the following:

•The value is undetermined.

•More than one value was measured for the attack flow parameter.

Advanced Dynamic Filters Configuration

The Guard runs a checkout procedure when a Dynamic filter's timeout expires. The Guard runs this procedure to decide whether or not to deactivate a dynamic filter. If the Guard decides not to deactivate the dynamic filter the filter's activation timeout resumes for another time span.

The Guard deactivates a dynamic filter when one of the following applies:

•The zone malicious traffic (equaling the sum of the spoofed and dropped traffic) is equal or less than a user-configured threshold (malicious rate termination threshold).

•Both of the following apply:

Note This item does not apply when the filter rate counter displays N/A.

–The dynamic filter's average traffic rate has been (as calculated across the policy timeout span) equal or less than its user-configured threshold (filter rate termination threshold)

–The dynamic filter's current traffic rate is equal or less than its user-configured threshold (filter rate termination threshold)

The Guard enables the user to configure both thresholds.

Note See the "Guard Traffic Paths" section in this chapter for further details regarding the role dynamic filters play in the Guard protection termination.

To configure the zone malicious traffic threshold perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-scannet# filter-termination 
zone-malicious-rate <threshold>
Where threshold specifies the zone malicious traffic threshold in packets per second units. This traffic consists of the sum of the spoofed and dropped traffic. The is a real number.

Note The default value is 50 pps.

2. Choose ENTER. The following prompt appears:
admin@GUARD-conf-zone-scannet#
To configure the dynamic filter termination threshold perform the following:

1. From the Zone command group level type the following:
admin@GUARD-conf-zone-scannet# filter-termination filter-rate 
<threshold>
Where threshold specifies the dynamic filter traffic threshold in packets per second units. The threshold is a real number.

Note The default value is 2 pps.

2. Choose ENTER. The following prompt appears:
admin@GUARD-conf-zone-scannet#