Configuring and Managing the Cisco Traffic Anomaly Detector

The following sections briefly outline the configuration parameters for the Cisco Traffic Anomaly Detector device.

Similar to the IPS sensor appliance, the Anomaly Detector can be configured by using the command-line interface (CLI) and the built-in GUI WBM user interface.

The Detector needs to be initialized using CLI for basic parameters such as the IP address, gateway, routes, and access control list (ACL). After the Detector is initialized and routable in the network, it can be accessed using the web-based GUI to configure the remaining tasks.

Several command modes on the Detector CLI are available for user access, and the access is mapped according to various CLI privilege levels, similar to the IPS Sensor software. By default, the user admin account is available with full administrative access rights to the Detector CLI.

Table 22-1 provides details of the various command and configuration modes used in the Detector CLI.

Table 22-1. Detector Command Configuration Modes

Mode	Description
Global	Allows connection to remote devices and listing system information. The Global prompt is the default prompt when logged into the Detector. The command prompt is as follows: user@DETECTOR#
Configuration	Allows configuration of features that affect the Detector operations and have restricted user access. To enter configuration mode, use the configure command in global mode. The command prompt is as follows: user@DETECTOR-conf#
Interface configuration	Allows configuration of the Detector networking interfaces. To enter interface configuration mode, use the interface command in configuration mode. The command prompt is as follows: user@DETECTOR-conf-if-<interface-name>#
Router configuration	Allows configuration of the Detector routing configuration. To enter router configuration mode, use the router command in configuration mode. The command prompt is as follows: router>
Zone configuration	Allows configuration of the zone attributes. To enter zone configuration mode, use the zone command in configuration mode or use the configure command in global mode. The command prompt is as follows: user@DETECTOR-conf-zone-<zone-name>#
Policy template configuration	Allows configuration of the zone policy templates. To enter policy template configuration mode, use the policy-template command in zone configuration mode. The command prompt is as follows: user@DETECTOR-conf-zone-<zone-name>-policy_template-<policy-template-name>#
Policy configuration	Allows configuration of the zone policies. To enter policy configuration mode, use the policy command in zone configuration mode. The command prompt is as follows: user@DETECTOR-conf-zone-<zone-name>-policy-<policy-path>#
Guard configuration	Allows configuration of the zone definitions that are unique to the Guard, such as user filters. To enter guard configuration mode, use the guard-conf command in zone configuration mode. The command prompt is as follows: user@DETECTOR-conf-zone-<zone-name>(guard)#

Managing the Detector

As mentioned earlier, the Detector needs to be initialized using the CLI Console access.

However, the Detector can be accessed and managed using one of the following methods:

• CLI Console access (for bootstrapping initial parameters)

• Secure Shell (SSH) session

• Built-in Web-Based Management (WBM) application

• Cisco DDoS Multi-Device Manager (MDM)

Initializing the Detector Through CLI Console Access

By default, the Detector does not have a configuration and requires basic initial parameters enabled for management via the GUI application. When the Detector boot process finishes, use the CLI console to log in to the CLI Console through the default username admin and password rhadmin.

Example 22-1 shows basic initial configuration parameters in the configuration mode that are used to activate the out-of-band management interface, assign the default gateway, and enable the built-in web-based GUI service for management (WBM).

By default, the Detector has restricted access and protects access for connections to the Detector, and any user trying to access the Detector must be explicitly permitted within the ACL. Example 22-1 shows a host located at IP address 10.1.1.150, which is being permitted in the ACL, so that it can manage the Detector by using the built-in WBM application and shows how to enable the MDM.

Example 22-1. Basic Detector Initialization Parameters Using CLI Console

user@DETECTOR-conf# interface eth1 user@DETECTOR-conf-if-eth1# ip address 192.168.1.1 255.255.255.0 user@DETECTOR-conf-if-eth1# no shutdown user@DETECTOR-conf# default-gateway 192.168.1.254 user@DETECTOR-conf# service wbm user@DETECTOR-conf# permit wbm 10.1.1.150 user@DETECTOR-conf# service mdm user@DETECTOR-conf# mdm server 10.1.1.150

In addition to the previous sample configuration, other basic parameters can be configured optionally:

• Configuring Hostname, Date, and Time

• Configuring various integrated services (for example, Routing, Network Time Protocol (NTP), Simple Network Management Protocol (SNMP), WBM, MDM, and SSH)

• Configuring Access Control using AAA

• Configuring TACACS+ parameters and attributes

• Configuring keys for SSH, SSH FTP (SFTP), and SCP connections

• Configuring NTP parameters

• Configuring SNMP parameters

• Configuring Communication parameters to establish a secure session with the Guard using SSL or SSH

After configuring basic initial parameters using CLI is completed, the Detector can be managed via the standard web browser from the desktop PC (Internet Explorer) by entering the following address:

https://Detector-ip-address/

Configuring the Detector (Zones, Filters, Policies, and Learning Process)

After initializing the Detector as shown in previous section, several other parameters need to be configured on the Detector to complete the configuration, such as Zones, Zone Filters, and Policies. These can either be configured using the CLI Console or are best implemented using the built-in web-based GUI manager application.

The following section highlights some of the basic concepts for configuring Zones, Zone Filters, Policies, and the Detector Learning phase, and for activating anomaly detection and the Guard device:

• Configuring zones: A zone is a network element that the Detector monitors for DDoS attacks. A zone can be any combination of a server, client, or router, or a subnet, or an entire network. The zone is a group of protected devices that are monitored. The Detector monitors the devices in a zone, and if an attack is identified, the Guard is activated to protect the zone. The Detector can simultaneously monitor traffic for several zones provided that their network address does not overlap. There are two ways to create a new zone: first, using one of the system-defined zone templates that allow creation of a new zone with the default policies and filters of the template; and second, duplicating an existing zone. After a zone has been created, additional zone attributes need to be configured, such as the zone IP address range.

• Configuring zone filters: After a zone is defined, zone filters need to be applied to enable the analysis detection level for the zone traffic flow. Zone filters also define the way the Detector handles specific traffic flows. Zone filters enable the Detector to analyze zone traffic for anomalies and bypass the Detector anomaly detection features. Zone filters can be customized for different methods that the Detector uses to detect traffic anomalies. There are several types of zone filters, such as Dynamic filters, Bypass filters, and Flex-content filters. Each of these is used for analyzing specific traffic flows and applying the required protection level to the specified traffic flow on the Detector. For example, the dynamic filter is created when the Detector identifies anomalies in the zone traffic and activates the Guard device to protect the zone. Zone filter parameters can be modified as per user requirements. Figure 22-11 illustrates the Detector zone filter system.

  Figure 22-11. Detector Zone Filter System

  [View full size image]
  

  Note

  The information in Figure 22-11 is compiled from Cisco product configuration guide on "Cisco Traffic Anomaly Detector Configuration Guide (Software Version 6.0)" at http://www.cisco.com/en/US/docs/security/anomaly_detection_mitigation/appliances/detector/v6.0/configuration/guide/conffilt.html.

  
  

• Configuring policies: Each zone contains a set of policies that are used to perform statistical analysis of the zone traffic flow and enforce the policy. The Detector uses predefined policy templates to construct the policies for each zone. A policy template is a collection of policy construction rules that the Detector uses during the policy construction phase to create the zone policies. Several default policy templates are available for use. Here are three examples: First, the ip_scan policy template is used to detect scans when a client from a specific source IP address tries to access many destination IP addresses in the zone. Second, the tcp_services template is used for TCP services on ports other than those that are HTTP related, such as ports 80 and 8080. Third, the tcp_ratio template is used for monitoring ratios between different types of TCP packets. For example, the ratio of SYN packets to FIN/RST packets and several other policy templates are available. Zone policy parameters can be modified after they are created. Policy triggers and the action also need to be configured to define the action that the policy takes when it is activated. The Detector also includes additional policy templates for zones designed for specific types of attacks or specific services—for example to monitor TCP-based WORM attacks.

• Detector learning process and policy construction phase: As mentioned previously, the Detector is initially in the learning process to establish the normal zone traffic patterns and threshold conditions to establish a baseline for the zone. The Detector creates the zone policies and its thresholds during this learning phase based on the normal traffic patterns. To activate the policy construction phase for zones, use the learning policy-construction command from the global configuration. For example, the learning policy-construction * command initiates the learning process for all zones when the asterisk (*) character is used. Alternatively, individual zones can also be named to initiate the learning phase separately. Similarly, use the learning threshold-tuning command from the global configuration mode to initiate the threshold tuning phase. After the learning is completed, accept the results from the policy construction phase for the respective zones using the learning accept command.

• Activating zone anomaly detection: Finally, to activate zone anomaly detection, issue the following command in the zone configuration mode.

  detect [learning]

  The learning keyword is optional and enables the Detector to detect anomalies in the zone traffic and tune the zone policy thresholds by using detect and learn functions, as mentioned previously in the detector learning process section. Note that to enable the learning process, the switch must be configured with the port mirroring feature.

• Activating the guard to protect a zone: As discussed previously, the Detector monitors the zone continuously for anomalies. When the Detector detects a zone traffic anomaly, it creates dynamic filters that can activate the Guards that are associated with the Detector. There are several ways to configure the Detector to activate a remote Guard: for example, the first way is to use a remote Guard list that uses SSL to enable remote activation and zone synchronization; the second way is to use SSH to enable remote activation only; the third way is to use BGP to send a BGP route update to inform the adjacent router to divert the target zone traffic to the remote Guard. The Detector can also be configured as offline to issue a notification when an attack on the zone occurs or enable manual activation to create dynamic filters to activate remote Guards.

• Synchronizing zone configurations: The zone synchronization process allows you to create copies of zone configuration on both the Detector and the Guard. The synchronization process can be used to create, configure, and modify a zone on the Detector and then update the same zone information to the Guard. There are two modes of synchronization: the Detector to Guard Synchronization, where the Detector copies the zone configuration from itself to the Guard, and the Guard to Detector Synchronization, where the Detector copies the zone configuration from the Guard to itself.

As discussed previously, several parameters need to be configured to complete the Cisco Traffic Anomaly Detector deployment (refer to Table 22-1).

These entire configurations can either be done via the CLI Console access or the built-in GUI WBM application.

For complete details on configuring various options, refer to the following Cisco technical documentation.