-
Cisco Anomaly Guard Module Configuration Guide (Software Version 4.0)
-
Index
-
Preface
-
Introduction
-
Configuring the Guard Module on the Supervisor Engine Module
-
Initializing the Guard Module
-
Configuring the Guard Module
-
Configuring Zone Traffic Diversion
-
Configuring Zones
-
Configuring Zone Filters
-
Configuring Policy Templates and Policies
-
Interactive Protect Mode
-
Attack Reports
-
Guard Module Diagnostics and Maintenance
-
Analyzing Guard Module Mitigation
-
Glossary
-
Table Of Contents
Configuring Zone Traffic Diversion
Displaying the Diversion routes
Out of Path Network Configuration
Configuring Out of Path Diversion
Configuring Zone Traffic Diversion
This chapter provides information about the Cisco Anomaly Guard Module (Guard module) diversion process. It consists of the following sections:
•
Out of Path Network Configuration
Overview
The Cisco Anomaly Guard Module (Guard module) is a high performance network service module deployed in a distributed upstream configuration, at the ISP/MSP/backbone level, protecting the entire network. It is a module installed in a Catalyst 6500 series switch with a Supervisor Engine 2 with a Multilayer Switch Feature Card (MSFC) or Supervisor Engine 720 with Cisco IOS software. When an attack is detected, the system diverts only the attacked zone traffic to the Guard module. The Guard module analyzes the data flow. All DDoS elements are blocked, the malicious packets are removed from the diverted stream and the cleaned traffic is returned to the main data path and allowed to continue flowing to the intended zone.
When the Guard module is in learning mode, the system diverts the zone traffic to the Guard module. The Guard module analyzes the traffic to create protection policies. It returns the traffic, without modifying it, to the zone main traffic path.
The entire cycle of diverting the zone traffic to the Guard module and returning it to the main data path is called the diversion process.
When there are no suspected attacks, you do not need to activate the diversion process, and the Guard module does not see the traffic.
Traffic Diversion
IP traffic diversion involves two tasks: diverting the traffic of one or more zones to the Guard module and returning the legitimate and cleaned traffic from the Guard module to the original data path and on to the zone.
The diversion process consists of two parts:
•
•
Network Configurations
You can install the Guard module in one of the following network configurations:
•
Figure 5-1 Inline Network Configuration
•
Figure 5-2 Out of Path Network Configuration
Diversion Mechanism
The Guard module diversion configuration is global. The diversion configuration defines how packets are to be routed to each subnet. It defines the routes needed for both hijacking and injection. When a zone enters protect or learning mode, the Guard module consults the diversion configuration and the zone definition (see the "Basic Zone Configuration" section) and determines how to divert traffic intended for that zone and how to inject traffic back to the zone main traffic path.
The Guard module uses an internal protocol with the supervisor (RHI) to add routes to the supervisor onboard routing table. The relevant routes are added when protect or learning mode is initiated for a zone. They are removed once the mode ends.
Figure 5-3 provides a graphical illustration of how packets are routed between the supervisor onboard routing engine and the Guard module.
Figure 5-3
Diversion Mechanism
Note
You can configure the following diversion parameters:
Hijacking Parameters
Once protection for a zone is activated, the supervisor onboard routing engine diverts the zone traffic to the Guard module. The traffic from the supervisor to the Guard module is diverted on the VLAN receive-via-vlan. The Guard module uses the IP address, receive-via-ip, to receive the zone traffic on this VLAN. The same VLAN can be used for both hijacking and injecting traffic.
The Guard module installs a static route in the supervisor onboard routing table, pointing to the Guard module as the next-hop to the zone to ensure that the zone traffic is diverted to it. The Guard module exploits the longest-prefix match algorithm; it divides each route into two routes with a longer prefix and advertises these routes to the supervisor onboard routing table. For example, the route for a 24-bit length zone subnet (class C) is published as two routes of 25-bit length zone subnets.
You can add multiple hijacking routes. Each hijacking route has a weight that defines the route preference. The supervisor onboard routing engine prefers the path with the highest weight. By default, all hijacking routes are added with a weight of 1. You can change the default weight to define preference among multiple hijacking routes.
You can associate hijacking parameters with an injection route. Alternatively, you can configure global hijacking parameters.
Note
See the following section, "Injection Parameters", for information on how to associate hijacking parameters with an injection route.
To configure the global hijacking parameters, enter the following command:
diversion hijacking {receive-via-ip receive-via-ip | receive-via-vlan receive-via-vlan | weight weight}
Table 5-1 provides the arguments for the diversion hijacking command.
Use the no diversion hijacking command to restore the default values.
Injection Parameters
The Guard module removes malicious packets from the diverted stream and returns the cleaned traffic either to the supervisor onboard routing engine (Layer 3) or directly to the zone main traffic path (Layer 2). It sends the cleaned traffic on VLAN send-via-vlan. The next-hop router and the Guard module must be on the same VLAN for Layer 2 injection. To inject traffic to the zone main traffic path in Layer 2, configure the next-hop to the zone to be the next-hop router IP address.
Caution
To configure the injection parameters, enter the following command:
diversion injection ip-address ip-mask nexthop next-hop
The ip-address and ip-mask arguments define the zone IP address and the next-hop argument defines the next-hop router IP address.
The IP address and subnet mask do not have to match that of a specific zone. They can be a subset of the zone definition or they can consist the subnets of several zones. For example, you can use one or two commands to configure diversion for a network of hundreds of potential zones.
You can associate hijacking parameters with an injection route. Alternatively, you can configure global hijacking parameters.
To associate hijacking parameters with an injection route, enter the following command:
diversion injection ip-address ip-mask nexthop next-hop [hijacking [receive-via-ip receive-via-ip] [receive-via-vlan receive-via-vlan] [weight weight] ]
The ip-address and ip-mask arguments define the zone IP address and the next-hop argument defines the next-hop router IP address. See the previous section, "Hijacking Parameters", for information on the hijacking parameters.
Displaying the Diversion routes
The Guard module modifies the supervisor onboard routing table using RHI messages. The relevant routes are added when protect mode or learning mode is initiated for a zone. They are removed once the mode ends.
To view the diversion settings on the Guard module, use the show diversion command.
You can view these messages on the supervisor when the zone is in protect mode or learning mode.
To view the routes the Guard module advertised, enter the following command on the supervisor:
show anomaly-guard module module_number advertised-route
The module_number argument specifies the number of the slot that the module is plugged into.
For example:
Sup# show anomaly-guard module 9 advertised-routeRHI routes added by slot 9ip mask nexthop vlan weight-------------- -------------- --------------- ------ ------A 192.168.252.8 255.255.255.0 192.168.8.10 8 1To verify that the Guard added the static routes, display the supervisor onboard routing table.
Enter the following command on the supervisor:show ip route
For example:
Sup# show ip routeC 192.168.8.0/24 is directly connected, Vlan8S 192.168.252.8/32 [1/0] via 192.168.8.10, Vlan8...Inline Network Configuration
In inline network configuration, the Guard module is installed in a switch which resides on the zone critical path, that is, zone traffic flows through the switch whether the zone is protected by the Guard module or not.
Hijacking
To configure diversion, the Guard module adds routes to the supervisor onboard routing table using RHI messages. The Guard module adds these routes using the longest-prefix match to ensure that the zone traffic is forwarded directly to the Guard module. It then analyzes the data flow. It removes all malicious packets from the diverted stream and returns the cleaned traffic to the main data path, using the injection mechanism, so that it continues flowing to the intended zone.
Injecting
To return the cleaned traffic to main data path, you can use either Layer 2 or Layer 3 traffic forwarding methods. See the "Traffic Injection Methods" section for further details.
Configuring Inline Diversion
Figure 5-4 displays an example of traffic diversion in an inline network configuration. In this example, hijacking is performed in Layer 3 and injection is performed in Layer2.
Note
Figure 5-4 Sample Inline Network Configuration, L3 Topology
•
•
This example shows how to configure the supervisor and the Guard module with the sample configuration.
Step 1
Sup# conf termSup(config)# vlan 8,9Sup(config)# anomaly-guard module 9 port 2 allowed-vlan 8,9Sup(config)# interface vlan 8Sup(config-if)# ip address 192.168.8.3 255.255.255.0Sup(config-if)# no ip proxy-arpSup(config-if)# no shutdownSup(config-if)# exitSup(config)# interface vlan 9Sup(config-if)# ip address 192.168.9.3 255.255.255.0Sup(config-if)# no ip proxy-arpSup(config-if)# no shutdownSup(config-if)# exitSup(config)# interface GigabitEthernet2/2Sup(config-if)# switchportSup(config-if)# switchport mode accessSup(config-if)# switchport access vlan 9Step 2
admin@GUARD# conf termadmin@GUARD-conf# interface giga 2admin@GUARD-conf-if-giga2# no shutdownadmin@GUARD-conf-if-giga2# exitadmin@GUARD-conf# interface giga 2.8admin@GUARD-conf-if-giga2.8# ip address 192.168.8.10 255.255.255.0admin@GUARD-conf-if-giga2.8# no shutdownadmin@GUARD-conf-if-giga2.89# exitadmin@GUARD-conf#interface giga 2.9admin@GUARD-conf-if-giga2.9# ip address 192.168.9.10 255.255.255.0admin@GUARD-conf-if-giga2.9# no shutdownadmin@GUARD-conf-if-giga2.9# exitStep 3
admin@GUARD# conf termadmin@GUARD-conf# diversion hijacking receive-via-ip 192.168.8.10admin@GUARD-conf# diversion hijacking receive-via-vlan 8admin@GUARD-conf# diversion injection 192.168.252.0 255.255.255.0 nexthop 192.168.9.2Step 4
Use the show anomaly-guard module advertised-route command to display the routes that the Guard module advertised. Use the show ip route command to display the static routes that were added to the supervisor onboard routing table.
This example shows how to display the routes that the Guard module advertised to the supervisor:
Sup# show anomaly-guard module 9 advertised-routeRHI routes added by slot 9ip mask nexthop vlan weight-------------- -------------- --------------- ------ ------A 192.168.252.0 255.255.255.128 192.168.8.10 8 1A 192.168.252.128 255.255.255.128 192.168.8.10 8 1
Note
This example shows how to display the static routes that were added to the supervisor onboard routing table:
Sup# show ip route...192.168.252.0/24 is variably subnetted, 3 subnets, 2 masksS 192.168.252.0/25 [1/0] via 192.168.8.10, Vlan8S 192.168.252.128/25 [1/0] via 192.168.8.10, Vlan8
Out of Path Network Configuration
In out of path network configuration, the Guard module is installed in a switch that does not stand in the regular line of zone traffic, but outside it. In this configuration, the zone traffic is diverted from the regular line of zone traffic to the switch.
Hijacking
To configure diversion, the Guard module adds static routes to the supervisor onboard routing table using RHI messages. The Guard module adds these routes using the longest-prefix match to ensure that the zone traffic is forwarded directly to the Guard module. You must set up in advance the distribution of routing tables so that the relevant routing protocols, such as BGP, advertise these static routes.
When the you activate protect or learning mode for a specific zone, the Guard modifies the supervisor onboard routing table. You must configure the supervisor or the MSFC to issue a BGP (EBGP or IBGP) announcement to the router from which the zone traffic is diverted (divert-from-router). The divert-from-router modifies its routing table based on this BGP announcement. The announcement lists the Guard as the best next hop to the specific zone. To ensure that the Guard module adjacent router does not forward the announcement, set the no-advertise and no-export BGP community strings. This way, if a packet destined to the zone reaches the next-hop router, the router will forward that packet to the zone, and not back to the Guard module.
Injecting
To return the cleaned traffic to the main data path, you can use Layer 2 or Layer 3 traffic forwarding methods. See the "Traffic Injection Methods" section for further details.
Configuring Out of Path Diversion
Figure 5-4 displays an example of traffic diversion in an out of path network configuration. In this example, hijacking is performed in Layer 3 and injection is performed in Layer2.
Note
Figure 5-5 Sample Out of Path Network Configuration, L3 Topology
•
•
•
Note
This example shows how to configure the supervisor and the Guard module with the sample configuration.
Step 1
sup# conf termSup(config)# vlan 8,9Sup(config)# anomaly-guard module 9 port 2 allowed-vlan 8,9Sup(config)# interface vlan 8Sup(config-if)# ip address 192.168.8.3 255.255.255.0Sup(config-if)# no ip proxy-arpSup(config-if)# no shutdownSup(config-if)# exitSup(config)# interface vlan 9Sup(config-if)# ip address 192.168.9.3 255.255.255.0Sup(config-if)# no ip proxy-arpSup(config-if)# no shutdownSup(config-if)# exitSup(config)# interface GigabitEthernet2/2Sup(config-if)# switchport mode trunkSup(config-if)# switchport trunk encapsulation dot1qSup(config-if)# switchportSup(config-if)# switchport access vlan 9Sup(config-if)# switchport mode accessStep 2
Enter the following:
sup# conf termSup(config)# access-list 61 permit 192.168.8.10Sup(config)# route-map PERMIT_GUARD_ONLY permit 10Sup(config-route-map)# match ip next-hop 61Sup(config-route-map)# set community no-export no-advertiseSup(config-route-map)# exitSup(config)# route-map PERMIT_GUARD_ONLY deny 20Step 3
Enter the following:
sup# conf termSup(config)# router bgp 55Sup(config-router)# bgp log-neighbor-changesSup(config-router)# neighbor 192.168.8.29 remote-as 100Sup(config-router)# address-family ipv4Sup(config-router-af)# redistribute static route-map PERMIT_GUARD_ONLYSup(config-router-af)# neighbor 192.168.8.29 activateSup(config-router-af)# no auto-summarySup(config-router-af)# no synchronizationSup(config-router-af)# exit-address-familyStep 4
admin@GUARD# conf termadmin@GUARD-conf# interface giga 2.8admin@GUARD-conf-if-giga2.8# ip address 192.168.8.10 255.255.255.0admin@GUARD-conf-if-giga2.8# no shutdownadmin@GUARD-conf-if-giga2.8# exitadmin@GUARD-conf# interface giga 2.9admin@GUARD-conf-if-giga2.9# ip address 192.168.9.10 255.255.255.0admin@GUARD-conf-if-giga2.9# no shutdownadmin@GUARD-conf-if-giga2.9# exitStep 5
admin@GUARD# conf termadmin@GUARD-conf# diversion hijacking receive-via-ip 192.168.8.10admin@GUARD-conf# diversion hijacking receive-via-vlan 8admin@GUARD-conf# diversion injection 192.168.252.0 255.255.255.0 nexthop 192.168.9.2Step 6
RouterR0# conf termRouterR0(config)# router bgp 100RouterR0(config-router)# neighbor 192.168.8.3 remote-as 55Step 7
Use the show anomaly-guard module advertised-route command to display the routes that the Guard module advertised. Use the show ip route command to display the static routes that were added to the supervisor onboard routing table.
This example shows how to display the routes that the Guard module advertised:
Sup# show anomaly-guard module 9 advertised-routeRHI routes added by slot 9ip mask nexthop vlan weight-------------- -------------- --------------- ------ ------ A 192.168.252.8 255.255.255.0 192.168.8.10 8 1
Note
This example shows how to display the static routes that were added to the supervisor onboard routing table:
Sup# show ip route...192.168.252.0/24 is variably subnetted, 3 subnets, 2 masksS 192.168.252.0/25 [1/0] via 192.168.8.10, Vlan8S 192.168.252.128/25 [1/0] via 192.168.8.10, Vlan8Step 8
The following example shows the BGP routing table before the Guard module advertised the new routes to the zone:
RouterR0# show ip bgp...Network Next Hop Metric LocPrf Weight Path*> 192.168.252.0/24 192.168.9.2 0 0 100 ?The following example shows the BGP routing table after the Guard module advertised the new routes to the zone:
RouterR0# show ip bgp...Network Next Hop Metric LocPrf Weight Path*> 192.168.252.0/25 192.168.8.3 0 0 55 ?*> 192.168.252.128/25 192.168.8.3 0 0 55 ?RouterR0#
Traffic Injection Methods
This section describes different methods used for injecting the cleaned traffic from the Guard module to the next-hop router. The methods vary according to two main network topologies:
Layer 2 Topology
In this topology, to return the cleaned traffic to main data path, the Guard module forwards the cleaned traffic directly to the next-hop router. It does not require the supervisor to make a routing decision.
The Guard module locates the next-hop router MAC address by sending an ARP query to its IP address (see the "Injection Parameters" section for further details). It forwards the cleaned traffic to the switch interface that is connected to the relevant next-hop router. Therefore, the supervisor and the next-hop router to the zone must be located on the same VLAN and the Guard module must have an IP address on that VLAN.
See the "Configuring Inline Diversion" section and the "Configuring Out of Path Diversion" section for a configuration example.
Layer 3 Topology
In this topology, to inject the cleaned traffic back to the zone main data path, the supervisor must make a routing decision. The Guard module can inject the cleaned traffic to one of the following destinations:
•
•
When activating a zone by issuing the protect or the learning commands, the Guard module modifies the routing table (the supervisor onboard routing table or that of the adjacent router, depending on the network topology) to be listed as the best path to the zone. If the Guard module returns the cleaned traffic to where it diverted the traffic from, the result could be a routing loop. To overcome such routing loops, you can associate routing rules with the cleaned traffic that the Guard module forwards to the zone. You can configure these rules to override the global routing table.
You can use VPN Routing and Forwarding (VRF) routing instance to create an additional forwarding table in the supervisor onboard routing engine. You can use this method to forward traffic without using the supervisor onboard routing table and thus avoiding routing loops. Use this forwarding table to define an alternative forwarding path to route packets that are sent from the Guard module to the zone. Include only information on how to forward traffic to the next-hop router to the zone.
You can forward the zone traffic directly to the nexthop router or inject it into a tunnel.
Figure 5-6 Sample of Layer 3 Forwarding Configuration
Configuring VRF
VRF is a forwarding method, deployed in Layer 3 network topologies, where the Guard module injects the cleaned traffic back to the same router from which the traffic was hijacked. VRF can be applied in both inline network configuration and in out-of-path network configuration.
VRF enables you to create a routing and forwarding table (called the VRF table) in addition to the global routing and forwarding tables. Configure this table to route traffic that is received on the interface with the Guard module.
Note
Configure two interfaces:
•
•
Note
The configuration in this section applies to the network configuration in Figure 5-6. The Guard module is installed in slot number 9 in the switch.
This example shows how to configure the supervisor and the Guard module with the sample configuration.
Step 1
Sup# conf termSup(config)# ip vrf Guard-vrfSup(config-vrf)# rd 100:1Step 2
•
•
Step 3
Sup# conf termSup(config)# interface vlan 8Sup(config-if)# ip address 192.168.8.3 255.255.255.0Sup(config-if)# no ip proxy-arpSup(config-if)# no ip directed-broadcastSup(config-if)# no shutdownSup(config-if)# exitSup(config)# interface vlan 9Sup(config-if)# ip vrf forwarding Guard-vrfSup(config-if)# ip address 192.168.9.3 255.255.255.0Sup(config-if)# no ip proxy-arpSup(config-if)# no shutdownSup(config-if)# exitSup(config)# anomaly-guard module 9 port 2 allowed-vlan 8,9Step 4
admin@GUARD# conf termadmin@GUARD-conf# interface giga 2.8admin@GUARD-conf-if-giga2.8# ip address 192.168.8.10 255.255.255.0admin@GUARD-conf-if-giga2.8# no shutdownadmin@GUARD-conf-if-giga2.8# exitadmin@GUARD-conf# interface giga 2.9admin@GUARD-conf-if-giga2.9# ip address 192.168.9.10 255.255.255.0admin@GUARD-conf-if-giga2.9# no shutdownadmin@GUARD-conf-if-giga2.9# exitStep 5
admin@GUARD# conf termadmin@GUARD-conf# diversion hijacking receive-via-ip 192.168.8.10admin@GUARD-conf# diversion hijacking receive-via-vlan 8admin@GUARD-conf# diversion injection 192.168.252.0 255.255.255.0 nexthop 192.168.9.3
Injecting Directly
Add a static route to the VRF table to specify the route to the zone. The global keyword indicates that the route to the next-hop router is learned from the global routing table. Enter the following command on the supervisor:
Sup(config)# ip route vrf Guard-vrf 192.168.252.0 255.255.255.0 192.168.250.2 globalAlternatively, you can define a specific routing protocol instance for each VRF. For example, you can use the address-family ipv4 vrf command to create a specific BGP instance for the VRF.
Injecting Over a Tunnel
To configure injection over a tunnel, perform the following steps:
Step 1
Note
Sup# conf termSup(config)# interface tunnel5Sup(config-if)# ip address 192.168.145.2 255.255.255.252Sup(config-if)# tunnel source 192.168.8.3Sup(config-if)# tunnel destination 192.168.7.1Step 2
router# conf termrouter(config)# interface tunnel5router(config-if)# ip address 192.168.145.1 255.255.255.252router(config-if)# tunnel source 192.168.7.1router(config-if)# tunnel destination 192.168.8.3Step 3
Sup(config)# ip route vrf Guard-vrf 192.168.252.0 255.255.255.0 192.168.145.1 global
