Table Of Contents
Configuring Zone Filters and Policy Templates
Zone Filters
Configuring User Filters
Configuring Bypass Filters
Configuring the Flex Filter
Policy Templates
Configuring Policy Templates
Configuring Zone Filters and Policy Templates
This chapter describes how to use the Web-Based Management (WBM) to perform advanced configuration tasks for zones on the Cisco Anomaly Guard Module and includes the following sections:
•
Zone Filters
•Policy Templates
Zone Filters
The zone filters are the mechanism that directs the diverted traffic to the relevant protection modules. The Guard module enables you to set filter configurations to design a variety of possibilities for customized traffic direction and anti-DDoS attack mechanisms. The Guard module uses four types of filters:
•User Filter—User filters are used to direct specific traffic flow to the relevant protection module. See the "Configuring User Filters" section for further details.
•Bypass filter—Bypass filters are used to prevent specific traffic flows from being handled by the Guard module protection mechanisms. See the "Configuring Bypass Filters" section for further details.
•Flex filter—A Flex filter is used to count or drop a specific packet flow. It is a Berkley Packet filter that provides extremely flexible filtering capabilities such as filtering according to fields in the IP and TCP headers and filtering according to content bytes. You can use complex Boolean expressions, but you can only configure one flex filter per zone. See the "Configuring the Flex Filter" section for further details.
•Dynamic filter—The Guard module creates dynamic filters as the result of the analysis of traffic flow. It continuously adapts this set of filters to the zone traffic and the type of the DDoS attack. Dynamic filters have a limited life span and are erased after the attack has terminated. See the "Dynamic Filters" section for further details.
Note Changes in the filter configuration of a zone take effect immediately.
For detailed information on the Guard module filters, refer to the Cisco Anomaly Guard Module Configuration Guide.
Configuring User Filters
The User filters make up the zone configuration and define how to handle traffic flows suspected as DDoS attacks. They enable you to customize the Guard module protection and to set rules to handle traffic flows when an attack is suspected. You can direct a specific traffic flow to the relevant protection module, configure the anti-spoofing or anti-zombie mechanism, or drop specific traffic.
Zone configuration includes a default set of User filters. The Guard module continuously analyses traffic destined to the protected zone. It initializes its protection cycle once suspected traffic is identified, and uses the default set of User filters to filter the suspected traffic.
Note User filters are activated in order. When you add a new User filter, it is important to place it in the correct location in the list.
Figure 5-1 User Filters
To configure User filters, select the zone to be configured and select Configuration > User filters from the zone's main menu.
To delete existing User filters, check the box next to the User filter's description and click Delete.
To add a new User filter, perform these steps:
Step 1 Click Add. Figure 5-2 appears.
Figure 5-2 Adding a User Filter
Step 2 Choose the location of the new user filter and check the button in the Insert column. The new user filter is added above the selected row.
Step 3 Click Next and enter the parameters in the User Filter Form. Table 5-1 describes the parameters.
Table 5-1 User Filter Parameters
Parameter
|
Description
|
Source IP
|
Directs traffic coming from a specific IP address to the User filter. Leave blank or enter * for any.
|
Source subnet
|
Directs traffic coming from a specific subnet to the User filter. Choose the subnet from the drop-down list.
|
Protocol
|
Directs traffic from a specific protocol to the User filter. The protocol is denoted by its well known number. Leave blank or enter * for any.
|
Dst Port
|
Directs traffic destined to a specific port to the User filter. Leave blank or enter * for any.
|
Fragments
|
Specifies the traffic type to be handled by the filter. Possible values are:
•without—The User filter acts on non-fragmented traffic.
•with—The User filter acts on fragmented traffic.
•*—The User filter acts on fragmented and non-fragmented traffic
|
Rate
|
Specifies the rate limitation. The User filter limits the traffic to the rate specified. Choose the rate units from the drop-down list. If you choose the unlimit unit, the traffic rate is not limited.
|
Burst
|
Specifies the traffic burst limit. The units are the same as the rate units.
|
Action
|
Specifies the action the filter performs on the traffic type. Possible values are:
•permit—Used to direct traffic to avoid the Guard module anti-spoofing or anti-zombie protection mechanisms. It is advisable to set a rate and burst limit for the permit User filter.
•basic/redirect—Used for authentication of applications over http.
•basic/reset—Used for authentication of applications over TCP, excluding http.
•basic/safe-reset—Used for authentication of applications, that are not tolerant of TCP connection reset, over TCP, excluding http.
•basic/default—Used for UDP traffic or when you are not sure which action is to be chosen. The basic/default filter examines the flow and determines which action is to be taken.
•basic/dns-proxy—Used for authentication of TCP DNS applications.
•strong—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 module serves as a proxy. Do not use this filter if the network is moderated according to IP addresses (such as using ACL - access control lists).
•drop—Used to drop traffic flows.
|
For a comprehensive explanation on the User filter parameters, and examples, refer to the Cisco Anomaly Guard Module Configuration Guide.
Configuring Bypass Filters
A Bypass filter is a filter designed to support protection policy decisions that you think should not involve the Guard module protection mechanisms. Use Bypass filters to prevent the Guard module Dynamic filters, protection modules, and Rate Limiter module from handling specific traffic flows. For example, you may decide to allow a trusted traffic flow to bypass the Guard module protection modules, including the anti-spoofing and anti-zombie mechanisms. Using the Bypass filter, you can direct trusted traffic away from the Guard module protection mechanisms and forward it directly to the zone.
Note Traffic that is handled by the Bypass filters does not go through the Rate Limiter module.
To create a Bypass filter, select Configuration > Bypass filters from the zone main menu, click Add and enter the parameters in the Bypass Filter Form.
There are no default Bypass filters defined. Table 5-1 describes the bypass filter parameters.
Table 5-2 Bypass Filter Parameters
Parameter
|
Description
|
Source IP
|
Directs traffic coming from a specific IP address to bypass the Guard module filter system. Leave blank or enter * for any.
|
Source subnet
|
Directs traffic coming from a specific subnet to bypass the Guard module filter system. Choose the subnet from the drop-down list.
|
Protocol
|
Directs traffic from a specific protocol to bypass the Guard module filter system. The protocol is denoted by the its well known number. Leave blank or enter * for any.
|
Dst Port
|
Directs traffic destined to a specific destination port to bypass the Guard module filter system. Leave blank or enter * for any.
|
Fragments
|
Specifies the traffic type to be handled by the filter. Possible values are:
•without—The Bypass filter acts on non-fragmented traffic.
•with—The Bypass filter acts on fragmented traffic.
•*—The Bypass filter acts on fragmented and non-fragmented traffic.
|
In the Bypass filter table, the counter denotes the current Bypass filter traffic rate measured in packets per second (pps) that was filtered by the Bypass filter.
To delete a Bypass filter, check the box next to the relevant Bypass filter description and click Delete.
For a comprehensive explanation on the Bypass filter parameters, and examples, refer to the Cisco Anomaly Guard Module Configuration Guide.
Configuring the Flex Filter
The Flex filter is a Berkley Packet filter with very selective filtering capabilities. Use the flex filter to drop, or count a desired packet flow and to identify a minutely defined malicious source of traffic. The Flex filter has many parameters and is very flexible and easily tailored to a specific traffic flow. However, you can only configure a single Flex filter and it is resource consuming. We recommend that you use Flex filters cautiously as it might effect performance.
To configure the Flex filter, choose Configuration > General from the zone menu (if the zone is already defined), click the Config button below the second table with the Flex filter information and enter the parameters in the Zone Form.
You can also configure the Flex filter while creating a new zone. See the "Managing Zones" section for further details.
For a detailed explanation on the Berkley Packet filter configuration options see: http://www.freesoft.org/CIE/Topics/56.htm.
For a comprehensive explanation on Flex filter parameters, and examples, refer to the Cisco Anomaly Guard Module Configuration Guide.
Policy Templates
Guard module policies measure particular traffic flows. Once the Guard module senses suspicious threshold violations, the policies take action that can range from merely notifying, to directing the traffic to Guard module anti-spoofing or anti-zombie mechanisms and even dropping malicious traffic. The Guard module policies enable the Guard module to keep up-to-date with the zone traffic, detect traffic anomalies, and take action accordingly. The policies are constructed from policy templates.
A policy template is a collection of rules and guidelines that are used during the learning process to construct the zone policies. the output of each template is a group of policies. The name of the policy template is derived from the characteristics that are common to all the policies it creates. This can be a protocol (such as DNS), an application (such as HTTP) or the objective (such as ip_scan). For example, the policy template tcp_connections produces policies that relate to connection such as the number of concurrent connections. See "Learning Zone Traffic and Constructing Policies," for further details on the Guard module policies.
Table 5-3 shows a list of the Guard module policy templates.
Table 5-3 Policy Templates
Policy Template
|
Description
|
dns_tcp
|
This policy template produces a group of policies relating to DNS-TCP protocol traffic.
|
dns_udp
|
This policy template produces a group of policies relating to DNS-UDP protocol traffic.
|
fragments
|
This policy template produces a group of policies relating to fragmented traffic.
|
http
|
This policy template produces a group of policies relating to HTTP traffic flowing (by default) through port 80 (or other user-configured ports).
|
ip_scan
|
This policy template produces a group of policies relating to IP scanning (a situation in which a source IP tries to access many destination IPs on the zone). This policy template is relevant when the zone is defined as a subnet.
By default, this policy template is disabled. The default action for this policy template is notify.
The policies created by the ip_scan policy template are resource consuming and can affect performance.
|
other_protocols
|
This policy template produces a group of policies relating to non TCP or UDP protocols.
|
port_scan
|
This policy template produces a group of policies relating to port scanning (a situation in which a remote client from a specific source IP address tries to access many ports on the zone).
By default, this policy template is disabled. The default action for this policy template is notify.
The policies created by the port_scan policy template are resource consuming and can affect performance.
|
tcp_connections
|
This policy template produces a group of policies relating to TCP connection characteristics.
|
tcp_not_auth
|
This policy template produces a group of policies relating to TCP connections that have not been authenticated by the Guard module anti-spoofing mechanisms.
|
tcp_outgoing
|
This policy template produces sets of policies relating to TCP connections initiated by the zone.
|
tcp_ratio
|
This policy template produces sets of policies relating to ratios between different types of TCP packets. For example, SYN packets versus FIN/RST packets.
|
tcp_services
|
This policy template produces a group of policies relating to TCP services on ports other than HTTP-related (such as ports 80 and 8080).
|
tcp_services_ns
|
This policy template produces a group of policies relating to TCP services. By default, the policy relates to IRC ports (666X), SSH and Telnet. This policy template does not create policies with actions that direct traffic flows to the Strong module.
|
udp_services
|
This template produces a group of policies relating to UDP services.
|
The Guard module relates first to indicators of TCP traffic on dedicated ports 6660 to 6670 and 21 to 23.
•If it traces traffic on these ports, the tcp_services_ns policy template produces its group of policies and the tcp_services policy template relates to TCP services on other ports
•If it does not trace traffic on these ports, it does not operate the tcp_services_ns policy template
•You can add services to this policies that are created from the tcp_services_ns policy template in the same way that you can to any other policy
Table 5-4 lists additional policy templates that are designed for zones for which no proxy is to be used. You can use these templates if the zone is moderated according to IP addresses such as an Internet Relay Chat (IRC) server-type zone.
Table 5-4 Policy Templates for Zones with No Proxy
Policy Template
|
Description
|
tcp_connections_ns
|
This policy template produces a group of policies relating to TCP connection characteristics. The policies, however, do not have actions that direct traffic flows to the Strong module.
|
tcp_outgoing_ns
|
This policy template produces a group of policies relating to TCP connections initiated by the zone. The policies, however, do not have actions that direct traffic flows to the Strong module.
|
http_ns
|
This policy template produces a group of policies relating to HTTP traffic flowing (by default) through port 80 (or other user-configured ports). The policies, however, do not have actions that direct traffic flows to the Strong module.
|
Configuring Policy Templates
To configure policy templates, choose Configuration > Policy templates from the zone main menu, choose a policy template from the list (Figure 5-3), click on the name and enter the parameters in the Policy Template Form.
Figure 5-3 Policy Templates
To add or remove services from all policies that were created from a specific policy template, see the chapter on "Learning Zone Traffic and Constructing Policies".
During the learning process, the zone traffic flows transparently through the Guard module. Each active policy template produces a group of policies, according to the zone traffic characteristics. The Guard module enables you to define the maximum number of policies that the Guard module produces from a specific policy template, according to the Max Services parameter. The Guard module ranks the services by their level of traffic volume and then picks up the services that have exceeded the minimum threshold (as defined by the Min Threshold parameter) with the highest traffic volume and creates a policy for each one of them. Some of the policy templates create an additional policy to handle all traffic flows for which a specific policy was not added. These policies have a service of any.
Caution If you disable a policy template, the Guard module can no longer protect the zone from traffic of the kind the policy template relates to. This may seriously compromise protection.
Table 5-5 describes the parameters that can be configured for each of the policy templates:
Table 5-5 Policy Template Parameters
Parameter
|
Description
|
State
|
The policy template state. Possible values are:
•enabled—The policy template continues to produce policies once the Guard module undergoes the Policy Construction phase.
•disabled—The policy template will not produce policies once the Guard module undergoes the Policy Construction phase.
|
Min Threshold
|
The minimum traffic volume threshold for a service. Once the threshold is exceeded, the Guard module produces policies that relate to the traffic of specific services according to the particular traffic flow that violated the threshold.
This parameter cannot be configured for policy templates that are essential for proper zone protection and therefore always produce a policy, such as fragments.
|
Max Services
|
The maximum number of services that the Guard module picks up and creates policies for, from the specific policy template.The greater the number, the more memory the zone uses. The Guard module ranks the services the policy relates to by their level of traffic volume. It then picks up the services that have exceeded the defined minimum threshold (as defined by the Min Threshold parameter) with the highest traffic volume and creates a policy for each one of them.
You can only configure this parameter for policy templates that detect services, such as tcp_services. You cannot configure maximum services for policy templates that relate to a specific service (such as dns_tcp that relates to service 53), or for policy templates that relate to a specific traffic characteristic (such as fragments).
|
