|
|
This section briefly outlines the configuration parameters for the Cisco Guard Mitigation device.
Similar to the Detector software, the Guard Mitigation device can be configured by using the command-line interface (CLI) and also the built-in GUI WBM user interface.
The Guard needs to be initialized using CLI for basic parameters such as the IP address, gateway, routes, and ACL. After the Guard 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 Guard CLI are available for user access. The access is mapped according to various CLI privilege levels, in a manner that is similar to the Detector software. By default, the user admin account is available with full administrative access rights to the Guard CLI.
Table 22-2 provides details of the various command and configuration modes used in the Guard CLI.
As mentioned earlier, the Guard needs to be initialized by using the CLI Console access.
However, the Guard can be accessed and managed using one of the following methods:
Built-in WBM application
Cisco DDoS MDM
After the Guard boot process finishes, use the CLI console to log in to the CLI Console, using the default username admin and password rhadmin.
Note
The Guard has four physical interfaces: eth0, eth1, giga0, and giga1. The out-of-band interfaces are eth0 and eth1 (10/100/1000 Ethernet sockets for out-of-band management). The eth0 or eth1 must be configured with an IP address and subnet mask. The in-band interfaces (copper or fiber socket) are giga0 and giga1.
Example 22-2 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 Guard has restricted access and protects access for connections to the Guard, and any user trying to access the Guard must be explicitly permitted within the ACL. Example 22-2 shows a host located at IP address 10.1.1.150 that is being permitted in the ACL so that it can manage the Guard by using the built-in web-based GUI manager (WBM) application.
user@GUARD-conf# interface eth1 user@GUARD-conf-if-eth1# ip address 192.168.10.1 255.255.255.0 user@GUARD-conf-if-eth1# no shutdown user@GUARD-conf# default-gateway 192.168.10.254 user@GUARD-conf# service wbm user@GUARD-conf# permit wbm 10.1.1.150 |
In addition to the previous sample configuration, other basic parameters can also be configured optionally:
Hostname, Date, and Time
Various integrated services (Routing, NTP, SNMP, WBM, and SSH)
Access Control using AAA
TACACS+ parameters and attributes
Keys for SSH, SFTP, and SCP connections
NTP parameters
SNMP parameters
Communication parameters to establish a secure session with the Detector using SSL or SSH
After the configuration of basic initial parameters using CLI is completed, the Guard can be managed via the standard web browser from the desktop PC (Internet Explorer) by entering the following address:
Note
The Guard also supports TACACS+ authentication for user authentication. If configured, the Guard uses the TACACS+ user database for user authentication instead of its local database.
After initializing the Guard as shown in the previous section, several other parameters need to be configured on the Guard 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 of configuring Zones, Zone Filters, Policies, Guard Learning phase, and activating anomaly detection and the Guard device.
Configuring zones: A zone is a network element that the Guard monitors for DDoS attacks. A zone can be any combination of a server, client, router, subnet, or an entire network. The zone is a group of protected devices, which are monitored. The Guard monitors the devices in a zone, and if an attack is identified, the Guard is activated to protect the zone. The Guard can simultaneously monitor traffic for several zones provided that their network addresses do not overlap. There are three ways to create a new zone on the Guard: by using one of the predefined zone templates that allow creation of a new zone with the default policies and filters of the template; by duplicating an existing zone; or by copying a zone configuration from the Detector. After a zone has been created, additional zone attributes need to be configured, such as a 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 Guard to analyze zone traffic for anomalies and apply the basic or strong level of protection to separate legitimate traffic from malicious traffic, drop malicious packets, and forward traffic directly to the zone, bypassing the Guard protection features. Zone filters can be customized for different methods that the Guard uses to detect traffic anomalies. There are several types of zone filters, including User filters, Dynamic filters, Bypass filters, and Flex-content filters. Each of these types is used for analyzing specific traffic flows and applying the required protection level to the specified traffic flow on the Guard. For example, the dynamic filter is created when the Guard identifies anomalies in the zone to protect the zone. Similarly, User filters apply the required protection level to the specified traffic flow. Most important, the User filters are the first to be enforced as an action occurs when the Guard identifies abnormal or malicious traffic. Zone filter parameters can be modified as per user requirements. Figure 22-12 illustrates the Guard Zone filter system.
Note
The information in Figure 22-12 is compiled from Cisco product configuration guide on "Cisco Guard Configuration Guide (Software Version 6.0)" at http://www.cisco.com/en/US/docs/security/anomaly_detection_mitigation/appliances/guard/v6.0/configuration/guide/conffilt.html.
Configuring policies: Each zone contains a set of policies that is 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, such as an ip_scan policy template for detecting scans when a client from a specific source IP address tries to access many destination IP addresses in the zone. Another example is the tcp_services template, which is used for TCP services on ports other than those that are HTTP-related, such as ports 80 and 8080. A final example is the tcp_ratio template, which is used for monitoring ratios between different types of TCP packets, such as the ratio of SYN packets to FIN/RST packets and several other policy templates. Zone policy parameters can be modified after being created. Policy triggers and the action also need to be configured to define the action that the policy takes when it is activated. The Guard also includes additional policy templates for zones designed for specific types of attacks or specific services—for example, to monitor VoIP applications.
Understanding Guard protection levels: As shown in Figure 22-12, the Guard applies three protection levels during the zone filter system process, in which it applies different processes to the traffic flow. Three protection levels exist in the Guard: the Analysis protection level, which allows the traffic to flow monitored, but uninterrupted, during zone protection, as long as no anomalies are detected; the Basic protection level that activates antispoofing and antizombie functions to authenticate the traffic by inspecting the suspicious traffic flow to verify its source; and the most powerful strong protection level, which activates severe antispoofing functions that inspect the traffic flow packets to verify the flow legitimacy. After applying a protection function to the zone, the Guard continuously monitors the traffic for anomalies if it detects an anomaly in traffic destined to the zone, it applies a stronger protection level.
Guard learning process and policy construction phase: As mentioned previously, the Guard is initially in the learning process to establish the normal zone traffic patterns and threshold conditions to establish a baseline for the zone. The Guard creates the zone policies and its thresholds during this learning phase based on the normal traffic patterns. For the Guard to learn the zone traffic characteristics, traffic needs to be diverted from its normal network path to the Guard. As the Guard analyzes the traffic, it injects the traffic back into the network. Note that before initiating the learning process, traffic diversion must be set up correctly. Traffic diversion can be configured using a routing protocol on the Guard. 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 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 done, accept the results from the policy construction phase for the respective zones using the learning accept command.
Activating zone protection: The Guard can be configured to activate zone protection when it receives a message from the Detector; alternatively, zone protection can be manually triggered on the Guard for a zone under attack. To activate the Guard for zone protection, issue the following command in the zone configuration mode.
The learning keyword is optional and enables the Guard to detect anomalies in the zone traffic and tune the zone policy thresholds using the protect and learn function.
Synchronizing zone configurations: The zone synchronization process allows the creation of copies of the 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, in which the Detector copies the zone configuration from itself to the Guard, and the Guard to Detector Synchronization, in which the Detector copies the zone configuration from the Guard to itself.
As discussed previously, several parameters need to be configured to complete the Cisco Guard Mitigation deployment (refer to Table 22-2).
These entire configurations can be accomplished either via the CLI Console access or the built-in GUI WBM application.
For a complete detail of configuring various options, refer to the Cisco technical documentation.
Tip
Refer to the following Cisco documentation for further details to configure the Cisco Traffic Anomaly Detector:
http://www.cisco.com/en/US/products/ps5888/products_configuration_guide_book09186a00807bfb1e.html
http://www.cisco.com/en/US/products/ps5888/products_configuration_guide_book09186a00805e01c8.html
|
|