Table Of Contents
Advanced Zone Procedures
Overview
Filters
Policy Templates and Policies
Zone Filter Configuration
User Filter Configuration
Bypass Filter Configuration
Flex Filter Configuration
Policy Templates
Configuring the Policy Template Operational Parameters
Advanced Zone Procedures
This chapter describes how to perform advanced configuration tasks for zones on the Cisco Guard using the Web-Based Management (WBM).
This chapter includes the following sections:
•
Overview (What are Policy templates, Policies and Filters)
•Zone Filter Configuration (configuring the Flex and Bypass filters)
•Policy Templates (configuring policy template parameters)
Overview
Filters
The zone's filters are the mechanism that directs the diverted traffic to the required protection modules. The Guard enables to set its preferred filter configurations and thus design a variety of possibilities for customized traffic direction and anti-DDoS attack mechanisms. There are four filter types used by the Cisco Guard:
•User Filter—The User filters are used to direct specified traffic flow to the desired Guard protection modules.
•Bypass filter—Bypass filters are used to prevent specific traffic flows from being handled by the Guard protection mechanisms.
•Flex filter—The Flex filter is used to count or drop a specified 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. The flex filter enables to use complex Boolean expressions. Only a single flex filter can be configured per zone.
•Dynamic filter—Dynamic filters are created by the Guard as the result of the analysis of traffic flow. This set of filters is continuously adapted 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 in "Protecting Zones," for further details.
Note Changes in the zone's filter configuration take effect immediately.
For detailed information on the Guard's filters, refer to Chapter 8, "Advanced Filter Procedures," in the Cisco Guard User Guide.
Policy Templates and Policies
The policies are the mechanisms that measure a particular traffic flow and take action against the flow as a result of threshold violation. The protection policies are constructed from policy templates.
A Policy Template is a collection of policy constructing guiding rules that will be used during the learning phases to construct the zone's policies (see "Zone Traffic Learning and Policy Construction," for further details).
Zone Filter Configuration
User Filter Configuration
The User filters constitute the zone configuration and define how to handle traffic flows suspected as DDoS attacks. The User filters offer the ability to customize the Guard protection. They enable to set guiding rules to handle desired traffic flows when an attack is suspected and to direct a specified traffic flow to the desired protection module, to a Guard anti-spoofing or anti-zombie mechanism or even to be dropped.
Zone configuration includes a default set of User filters. The Guard continuously analyses traffic destined to the protected zone. It initializes its protection cycle once suspected traffic is identified, and uses that default set of User filters to filter the suspected traffic.
The User filters are activated according to their order. Therefore, it is important, when adding a new User filter, to place it in the desired location in the list.
Figure 5-1 User Filters
To configure the User filters:
From the Zone main menu, select Configuration > User filters.
To delete existing User filters:
1. Select the check box next to the User filter's description.
2. Click Delete.
Adding a new User filter involves a two-step process.
To add a new User filter:
•Click Add.
Step 1 screen, Choose the new filter location (Figure 5-2), appears:
•Choose the location of the new user filter. Click the button in the Insert column. The new user filter is added above the selected row.
Figure 5-2 Adding a User Filter - Step 1
•Click Next.
Step 2, User filter form, appears:
•Enter the User filter configuration.
Enter the following information to configure the User filter:
Parameter
|
Description
|
Source IP
|
Directs traffic coming from a specified IP address to the User filter. Leave blank or enter * for `any'.
|
Source subnet
|
Directs traffic coming from a specified subnet to the User filter. Choose the subnet from the drop-down list.
|
Protocol
|
Directs traffic from a specified protocol to the User filter. The protocol is denoted by the its well known number. Leave blank or enter * for `any'.
|
Dst Port
|
Directs traffic destined to a specified port to the User filter. Leave blank or enter * for `any'.
|
Fragments
|
Denotes specified traffic type to be handled by the filter. Choose from the drop-down list one of the following:
•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
|
Denotes the rate limitation. The User filter limits the traffic to a specified rate. Choose the rate units from the drop-down list.
|
Burst
|
Denotes the traffic burst limit. The units are bits, kilo-bits, kilo-packets, mega-bits, and packets in correspondence to the rate units specified from the drop-down list.
Note The drop-down list defines the units for both the rate and the burst.
|
Action
|
Denotes the action the filter performs on the specified traffic type. This could be either of the following:
•permit—Used to direct traffic to avoid the Guard 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 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—Used to drop traffic flows.
|
In the User filter table, the rate denotes the current traffic rate measured for the User filter in packets per second (pps).
For a comprehensive explanation on the User filter parameters, and examples, refer to Chapter 8, "Advanced Filter Procedures," in the Cisco Guard User Guide.
Bypass Filter Configuration
The Bypass filter is a filter designed to support protection policy decisions that the user thinks should not involve the Guard's protection mechanisms. It is used to prevent specific traffic flows from being handled by the Guard's Dynamic filters, protection modules, and the Rate-limiter. Decisions of such a kind may, for example, be letting a trusted traffic flow bypass the Guard's protection modules including the anti-spoofing and anti-zombie mechanisms. Using the Bypass filter you can direct trusted traffic away from the Guard's protection mechanisms and forward it directly to the zone.
Note Note that traffic handled by the Bypass filter does not go through the rate-limiter module. It is therefore additional to the bandwidth configured for the client.
To create a Bypass filter:
1. From the Zone's main menu select Configuration > Bypass filters.
2. Click Add.
There are no default Bypass filters defined.
Enter the following information to configure the Bypass filter:
Parameter
|
Description
|
Source IP
|
Directs traffic coming from a specified IP address to bypass the Guard filter system. Leave blank or enter * for `any'.
|
Source subnet
|
Directs traffic coming from a specified subnet to bypass the Guard filter system. Choose the subnet from the drop-down list.
|
Protocol
|
Directs traffic from a specified protocol to bypass the Guard 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 specified destination port to bypass the Guard filter system. Leave blank or enter * for `any'.
|
Fragments
|
Denotes specified traffic type to be handled by the filter. Choose from the drop-down list one of the following:
•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:
1. Select the check box next to the Bypass filter's description.
2. Click Delete.
For a comprehensive explanation on the Bypass filter parameters, and examples, refer to Chapter 8, "Advanced Filter Procedures," in the Cisco Guard User Guide.
Flex Filter Configuration
The Flex filter is a Berkley Packet filter which facilitates you with extremely flexible filtering capabilities. It is used to drop, or count a desired packet flow. The Flex 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. We recommend to use the Flex filter attentively due to its potential performance penalty.
To configure the Flex filter:
1. If the zone is already defined, from the Zone's menu select Configuration > General.
2. Click Config.
Alternatively, the Flex filter may be configured while creating a new zone (see the "Creating Zones and Basic Zone Configuration" section in "Zone Creation and Configuration," 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 the Flex filter parameters, and examples, refer to Chapter 8, "Advanced Filter Procedures," in the Cisco Guard User Guide.
Policy Templates
A Policy Template is a collection of policy constructing guiding rules and the output of each template is a group of policies. The Guard policy templates consist of the following:
Policy Template
|
Brief Description
|
dns_tcp
|
This policy template produces a group of policies related to DNS-TCP protocol traffic.
|
dns_udp
|
This policy template produces a group of policies related to DNS-UDP protocol traffic.
|
fragments
|
This policy template produces a group of policies related to fragmented traffic.
|
http
|
This policy template produces a group of policies related 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".
Note The policies created by the ip_scan policy template are resource consuming. Therefore, we recommend to use it attentively due to its potential performance penalty.
|
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 Source IP tries to access many ports on the zone).
By default, this policy template is disabled. The default action for this policy template is "notify".
Note The policies created by the port_scan policy template are resource consuming. Therefore, we recommend to use it attentively due to its potential performance penalty.
|
tcp_connections
|
This policy template produces a group of policies related to TCP connection characteristics.
|
tcp_not_auth
|
This policy template produces a group of policies related to TCP connections that haven't been authenticated by the Guard's anti-spoofing mechanisms.
|
tcp_outgoing
|
This policy template produces sets of policies related to TCP connections initiated by the zone.
|
tcp_ratio
|
This policy template produces sets of policies related 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 related to TCP services on ports other than HTTP-related (such as ports 80, 8080, etc.).
|
tcp_services_ns
|
This template produces a group of policies related to TCP services. By defaults 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 protection module.
|
udp_services
|
This template produces a group of policies related to UDP services.
|
Note The Guard first relates to indicators of TCP traffic on especially dedicated ports 6660 to 6670 and ports 21 to 23. Then:
•If traffic is traced on those ports then the tcp_services_ns policy template produces its group of policies and the tcp_services policy template would relate to TCP services on other ports.
•If no traffic is traced on the above-mentioned ports, then the tcp_services policy template assumes its ordinary function. The tcp_services_ns policy template will not be operated.
•You can add services to this policy as to any other.
The Guard supplies additional policy templates designed to tailor the Guard protection to Zones for which no proxy is to be used. These templates may be used if the zone is moderated according to IP addresses such as an Internet Relay Chat (IRC) server-type zone.
Policy Template
|
Brief Description
|
tcp_connections_ns
|
This policy template produces a group of policies related to TCP connection characteristics. However, this policy template does not create policies with actions that direct traffic flows to the Strong protection module.
|
tcp_outgoing_ns
|
This policy template produces a group of policies related to TCP connections initiated by the zone. However, this policy template does not create policies with actions that direct traffic flows to the Strong protection module.
|
To configure policy templates:
1. From the Zone's main menu, select Configuration > Policy templates.
2. Click on the required policy template name.
Figure 5-3 Policy Templates
Configuring the Policy Template Operational Parameters
During the Learning phases, the zone's traffic flows transparently through the Guard. Each active policy template produces a group of specified policies, according to the Zone's traffic characteristics. The Guard enables the user to define the maximum number of policies the Guard will produce from a specified policy template. This is configured according to the parameter: Max Services. The Guard ranks the services the policy template relates to by their level of traffic volume. The Guard will then pick up the services that have exceeded the defined minimum threshold (as defined by the parameter Min Threshold) with the highest traffic volume and create a policy for each one of them. Some of the policy templates will create an additional policy to handle all traffic flows for which a specific policy was not added. These policies will be added with a service of `any'.
For each of the Policy Templates, the following operational parameters may be configured:
Parameter
|
Description
|
State
|
Specifies the policy template state. The policy template can be enabled or disabled. Disabling a policy template prevents it from producing policies once the Guard undergoes the Policy Construction phase.
|
Min Threshold
|
Specifies the minimum traffic volume threshold for a service. Once the threshold is exceeded, the Guard produces policies that relate to the services' traffic 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.
Setting the threshold enables the user to better adopt the Guard protection to the traffic volume of the user's zone services.
|
Max Services
|
Specifies the maximum number of policies (each relating to a service) that will be produced from the specified policy template. The Guard ranks the services the policy template relates to by their level of traffic volume. The Guard will then pick up the services that have exceeded the defined minimum threshold (as defined by the parameter Min Threshold) with the highest traffic volume and create a policy for each one of them. An additional policy to handle all other traffic flows service (such as dns_tcp that relates to service 53), or for policy templates that relate to a specified traffic characteristic (such as fragments).
Limiting the service number allows the user to better tailor the Guard protection policies to its preferred traffic flow requirements.ith the characteristics of the policy template may be added with a service of `any'.
This parameter may be defined only for policy templates that detect services, such as tcp_services. It cannot be configured for policy templates that relate to a specified
|
Caution Disabling a policy template results in the Guard's inability to protect the zone from traffic of the kind the policy template relates to. This may seriously compromise the Guard's protection.
