-
Cisco Guard Configuration Guide (Software Version 3.08)
-
Preface
-
Overview
-
Initial Procedures
-
Guard Configuration
-
Zone Traffic Diversion
-
Zone Configurations
-
On-Demand Protection
-
Routine Guard Procedures
-
Guard Diagnostics and Maintenance
-
Advanced Filter Procedures
-
Advanced Policy Procedures
-
Interactive Recommendations Mode
-
Attack Reports
-
Glossary
-
Diversion Configuration
-
Diversion Troubleshooting
-
Table Of Contents
Traffic (BGP) Diverting Method
Layer 2 Forwarding Method (L2F)
Policy Based Routing (PBR) - DST (Destination)
VRF (VPN Routing Forwarding) VRF- DST (Destination)
VLAN Policy Based Routing (PBR VLAN)
Diverting Traffic to the Cisco Guard
Traffic Injection from the Guard to the Zone
Next Hop Discovery Introduction
Routing Protocols Next Hop Discovery
Next Hop Router is Derived from IGP Information
Next-Hop Router is Derived from the IGP+BGP
Blocking the Guard from Announcing Traffic/Updates
Next-Hop Discovery using Router Management Protocol (RMP)
Zone Traffic Diversion
This chapter provides information about the diversion process in general and details on diversion methods in L2 and L3 topologies. The chapter concludes by describing the Long Diversion and Next Hop discovery methods.
The Guard diversion mechanism configuration with both Cisco and Juniper routers is documented in Appendix A, "Diversion Configuration."
This chapter contains the following major sections:
•
What is IP Traffic Diversion?
•
•
•
Overview
Cisco places a "cleaning box", the Guard, next to key routers in the network. Upon receiving an alert that a zone might be under attack, the traffic addressed to the zone is diverted from the routers to the Guard. The Guard then analyzes and filters the zone's traffic; the malicious packets are removed from the diverted stream. Finally, the cleaned traffic is returned to the main data path to be forwarded to the zone. The entire cycle is termed the Diversion process. This manual uses the following diversion-related terminology:
•
•
•
•
Note
What is IP Traffic Diversion?
IP traffic diversion involves two tasks: first, diverting the traffic of one or more zones to the Guard without obstructing their flow, and the second is returning the legitimate and cleaned traffic from the Guard to the original data path and on to the zone.
The main benefit of the Guard IP traffic diversion technology is that its filtering arrays do not reside on the critical path. With the Guard diversion system, the zone's traffic is redirected off-path for powerful processing and filtering, thus the whole filter capacity can be used to filter only the attacked sites, while the remaining traffic is allowed to flow directly to the zone.
Diversion Process
The diversion process consists of two parts:
•
Figure 4-1 Diversion Process
•
In cases where multiple possible next hop routers exist, forwarding the traffic also requires learning to find the next hop router to the zone. In such cases the Guard runs a special process, called the Next-hop discovery mechanism. Figure 4-1 illustrates the Diversion process. Both R2 and R3 could be the next-hop router to the zone. The guard would then perform the Next-hop Discovery process, and learn which is the best candidate (R2 in the above figure). In case there is a single next-hop router the Guard will choose it to be the next-hop router. Due to routing changes the current next-hop router to the zone may dynamically change. The Guard would then select the next hop router by duplicating R1's selection. R1's selections are acquired through the next-hop discovery process.
Layer 3 Topology
In a L3 topology scenario (see Figure 4-2) the Guard is directly connected to the divert-from router, R1. The Guard receives the diverted traffic from R1, cleans it, and is about to return the traffic back to the R1 to forward the clean traffic to the zone. At this point there is a danger of a vicious closed loop between the R1 and the Guard since R1 has the Guard as the addressee for any zone traffic. To avoid this malicious loop the user utilizes routing policy techniques (such as Policy Based Routing (PBR), VPN Routing Forwarding (VRF)). These techniques' main feature is their ability to bypass R1's main routing table when R1 receives the traffic from the Guard. These techniques operate in a L3 topology environment and are hence referred to as Layer 3 Forwarding methods (L3F).
Figure 4-2 Layer 3 Topology
The solid line indicates that R2 is the preferred next hop to the zone. However, the zone can also be reached via R3.
Note
Layer 2 Topology
In a L2 topology scenario (see Figure 4-3), the Guard is connected to a Layer 2 switch, so the divert-from router (R1), the next-hop router (R2) to the zone and the Guard are located on the same LAN. The Guard locates the next-hop router (R2) by sending an ARP query to R2 IP address and forwards the clean zone's traffic directly to it. The traffic is then forwarded over to the zone.
Figure 4-3 Layer 2 Topology
The straight solid line to router R2 indicates that this is a preferred next-hop. However, it is also possible to reach the zone via R3.
Note
Note
Long Diversion
Unlike standard diversion techniques where the Cisco Guard diverts traffic only from an adjacent router, the Long Diversion method diverts traffic from remotely located peering routers that may reside several hops away from the Guard. Figure 4-4 illustrates an overview of the long diversion in an MPLS network.
Figure 4-4 Using the Guard for Long Diversion
Traffic (BGP) Diverting Method
The Guard sends the divert-from router an EBGP (or an IBGP) announcement informing that the next hop to the zone is the Guard itself. In order for the announcement to take precedence over any previous routing decision regarding the zone, the announcement goes out with a longer (more specific) prefix than the one representing the zone in the divert-from router routing table.
To ensure that the announcement only reaches the Guard's adjacent router, the BGP announcement is sent out with the no-advertise and no-export BGP community strings. Thus, only the Guard's adjacent router regards the announcement. Hence, if a packet destined to the zone reaches the next hop router, the router would forward that packet to the zone, and not back to the Guard.
The Guard also adds a special string to the BGP announcement indicating that the origin of the announcement is the Guard. We use a community that is combined from two AS numbers, AS-number-ISP:AS-number-guard, where the AS number guard is a private AS-number.
One of the advantages of using BGP for the Guard's routing announcements is that in case of a Guard's failure, the diversion to the Guard stops automatically. This is due to the BGP keep-alive process that automatically withdraws the prefixes from the router if the peer (Guard) has not responded to several keep-alive messages for a certain amount of time.
Traffic Forwarding Methods
This section describes different methods used for forwarding the cleaned traffic from the Guard to the next-hop router. The methods vary according to two main network topology scenarios: Layer 2 and Layer 3 topologies
Layer 2 Topology
In this topology the Guard, the divert-from router, and the next-hop router are on the same VLAN. In a L2 topology, a divert-from router, and an inject-to router are two different devices. The next-hop router and the inject-to router are the same device.
Layer 3 Topology
In this topology the divert-from and inject-to routers are the same router (to be referred to as the router). When diverting the traffic, the Guard sends a BGP announcement, which modifies the router's routing table and thus diverts the zone's traffic to the Guard. The Guard cleans the traffic and returns it to the same router. The divert-from router then sends it to the router that appears as the best path to the zone. This may result in a malicious routing loop. Routing rules that override the router's routing table are associated with the traffic that comes back from the Guard to avoid this loop. There are three main techniques to forward the packet without using the routers' routing table and thus avoiding the loop. These are:
•
•
•
Note
The above-mentioned diversion methods depend on the next hop router configuration. However, the next hop router may be static per a zone or dynamically change. As a result, the diversion methods divide into the following categories:
•
•
Abbreviations
•
•
•
•
•
The following sections detail the different Guard forwarding methods.
Layer 2 Forwarding Method (L2F)
The Layer-2 traffic forwarding method is used in the L2 topology scenario (see Figure 4-3), when all three devices: the Guard, the divert-from router, and the next-hop router are on the same VLAN. In a L2 topology, a divert-from router, and an inject-to router are two different devices. The next-hop router and the inject-to router are the same device.
In the L2F method, the Guard resolves the MAC address of the inject-to/next-hop router and then forwards the traffic to that address. To resolve this MAC address the Guard issues a standard ARP query for the IP address of the inject-to/next-hop router. When using the L2F forwarding method, no configuration on the routers is required.
Depending on a particular network configuration, a zone can be directly connected to a Layer 2 Switch, meaning that the zone is connected to the same LAN as the Cisco Guard. In this case, the Guard forwards the traffic directly to the zone; in other words, the zone's IP address is configured as the inject-to router. If the traffic is sent to the protected zone via some IP forwarding device, this IP forwarding device must be defined as the Cisco Guard's next-hop. See section "Layer-2-Forwarding (L2F) Method" in Appendix A, "Diversion Configuration" for further details.
Layer 3 Forwarding Methods
Policy Based Routing (PBR) - DST (Destination)
This method allows the configuration of routing rules different from those configured in the router's routing table. The PBR rules are configured only on the router's interface that faces the Guard. The user performs the configuration once. A configured rule would specify that all traffic from the Guard to a zone be forwarded to the corresponding next-hop router. Hence, this is a static Next hop discovery method. See section "PBR-DST Configuration Guidelines" in Appendix A, "Diversion Configuration" for further details.
Figure 4-5 PBR Forwarding Method
In Figure 4-5 the PBR method is applied on R1's interface facing the Guard to define a rule according to which all the Zone's traffic coming from the Guard is forwarded to R2.
Note
VRF (VPN Routing Forwarding) VRF- DST (Destination)
This feature allows the configuration of another routing and forwarding table (the VRF table) in addition to the main routing and forwarding tables. The additional routing table is configured to be used only to route traffic that comes into the router's interface that faces the Guard. For that, two separate interfaces are configured on the router's physical interface that faces the guard. The first interface (the NATIVE VLAN) is used to divert traffic from the router to the guard. Traffic on this VLAN is forwarded according to the global routing table, and on this VLAN the Guard sends the BGP announcements that divert the traffic to the Guard. The second VLAN is used to divert the returned traffic from the Guard to the router. A VRF table is configured on this second VLAN, and contains a static routing rule to forward all the zone traffic to a specific next hop router. Hence this is also a static next hop diversion method. Dynamic next hop diversion methods using VRF and PBR are described below. See section "Policy-Based Routing Destination (PBR-DST) Traffic Forwarding Method" in Appendix A, "Diversion Configuration" for further details.
Note
Figure 4-6 VRF Forwarding Method
The VRF method is applied on the router interface facing the Guard. A VRF table on this interface is defined to contain a rule those routes all the zone's traffic coming from the Guard to R2.
Note
In topologies where the next-hop changes dynamically, the following mechanisms apply.
VLAN Policy Based Routing (PBR VLAN)
In this method, a multiple VLAN (Virtual LAN, 802.1Q) trunk is configured between the Guard and router R1 (see Figure 4-7). Each VLAN in the trunk is associated with a different possible next-hop router. In addition, a PBR is configured on each of the VLAN logical interfaces in the router side. Each PBR is configured to forward all the traffic that comes on a specific VLAN to its corresponding next-hop router. The Guard then forwards packets to a particular next-hop router by transmitting the packets over the appropriate VLAN. This allows the Guard to change the next-hop router of a zone by changing the VLAN on which the packets are forwarded. The native VLAN is used for the diversion of traffic (the Guard sends the BGP announcements on this interface to the router).
Figure 4-7 PBR VLAN Forwarding Method
In Figure 4-7, the PBR VLAN method is applied on R1's interface facing the Guard. According to the example traffic that comes over VLAN5 is forwarded to R2 and the zone's traffic coming from the Guard over VLAN6 is forwarded to R3. See section "PBR-VLAN Configuration" in Appendix A, "Diversion Configuration," for further details.
VLAN VRF
This method is the same as the previous PBR VLAN except that a VRF table is associated with each VLAN in the inject-to router instead of a PBR table. Each VRF table simply contains the rule directing all the traffic that arrives on it to the corresponding next-hop router. The Guard then forwards packets to a particular next-hop router by transmitting the packets over the appropriate VLAN. This allows the Guard to change the zone next-hop router by changing the VLAN that are forwards the packets. The native VLAN is used for the diversion of traffic (on this interface the guard sends the BGP announcement). See Appendix A, "Diversion Configuration," for further details.
Figure 4-8 VRF-VLAN Forwarding Method
In Figure 4-8 the VRF-VLAN method is applied on R1's interface facing the Guard. Traffic that flowing over VLAN5 is forwarded to R2 and traffic flowing over VLAN6 is forwarded to R3.
Juniper Routing Instances
Figure 4-9 Juniper Routing Instances
The Routing Instance method is implemented on R1's (a Juniper router) interface facing the Guard. The routing table in this routing instance is different than the main routing table. The routing table contains all the routes that appear in the main routing table except those that are the result of the Guard announcements.
In the Routing Instance method the user configures another routing table to route traffic coming back from the Guard (the Guard-interface-routing-table). The user uses the Filter Based-Forwarding (FBF) ruling method to configure on the router interface facing the Guard. The FBF rule indicates that the traffic arriving from the Guard should be forwarded using the Guard-interface-routing-table. The Guard-interface-routing-table is populated with all the routes of the global routing table except for the routes that are tagged with the Cisco special community string indicating that the route came from the Guard. In some cases, when there is a huge global routing table, one may reduce the size of the Guard-interface-routing-table by limiting the propagation of the routes to possible zones only. Notice, that this method is a dynamic Next Hop Diversion method. See section "Juniper Routers Routing Instance" in Appendix A, "Diversion Configuration," for further details.
Figure 4-10 Juniper Router Internal View
Figure 4-10 displays the flow of information and traffic in the router for this diversion method, while Figure 4-8 (VRF-VLAN Forwarding Method) displays the external flows of the traffic.
Forwarding over a Tunnel
In this method the user configures a tunnel between the Guard and each of the next hop routers. The Guard sends the traffic over the tunnel that ends in the next hop router of the destined zone. Since the returned traffic goes over a tunnel, the inject-to router performs a routing decision only on the end point of the tunnel interface, and not on the zone's address.
Figure 4-11 Tunnel Diversion
In the tunnel diversion method the user configures a tunnel between the guard and each of the possible next hop routers. The guard sends the traffic over the tunnel that ends at the next hop router. This allows the Guard to change the next-hop router to a specified zone by changing the tunnel that the packets are forwarded on. See section "Tunnel Diversion" in Appendix A, "Diversion Configuration," for further details.
Long Diversion Method
Unlike standard diversion techniques where the Cisco Guard diverts traffic only from an directly connected adjacent router, the "long diversion" method diverts traffic from remotely located peering routers that may reside several hops away from the Guard. The basic idea is that the traffic to the zone is diverted from the peering points to the guard over a tunnel such as GRE/IPIP or MPLS LSP. The regular forwarding method can inject the clean traffic back since the forwarding tables of both R1 (attached to by the Guard) and other backbone routers are untouched. This is due to the Tunnel technique. The example below refers to how a diversion is implemented in an ISP backbone that implements MPLS.
Figure 4-12 illustrates the general overview of the long diversion, in which R2, R3 and R4 are peering routers, while R1 is the router adjacent to the Guard.
Figure 4-12 Guard Long Diversion
The long diversion process is divided into three parts:
•
•
•
Diverting Traffic to the Cisco Guard
Once an attack has been launched against a specific zone, diversion is achieved by the Guard sending out an iBGP announcement stating that in order to reach the zone, the traffic should route to the LSP that ends in the Guard's loop back address/interface. To ensure that the BGP announcements do not propagate into all the backbone routers' routing tables, no-advertise and no-export BGP community strings are attached to the BGP announcements. Hence, only R2, R3 and R4 get the BGP announcement about the zone's (with longer prefix) next hop to the corresponding Guards loop back interface.
BGP Announcement
The Guard sends an iBGP announcement (with no-advertise and no-export) to router R2, R3 and R4 informing them that the next hop to the zone is the Guard loop back interface. This process is achieved by setting appropriately the next hop attribute in the BGP announcement (using the command route-map in Cisco IOS). The announcement uses a longer prefix then the original announcement of the zone, and therefore would get priority over the original BGP announcement.
Figure 4-13 iBGP Announcement to the Peering Routers
MPLS LSP
After the iBGP announcement reaches the peering routers, the routers re-route the zone's traffic to the LSP, leading from the peering points to the Guard loop back interface.
Figure 4-14 MPLS LSP from the Peering Routers (R2, R3, R4) to the Guard
While the Guard is at the end of the LSP, it is not required to support MPLS; it only receives pure IP due to the fact that R1 is the egress proxy LSP for the Guard. In other words, R1 performs one before the last hop popping on the MPLS packets that arrive at the Guard's loop back and delivers them directly to the Guard over the static route.
The Guard's loop back address should be routable via IGP in the entire network. To achieve this, R1 is configured with a static route to the loop back address of the Guard, which will redistribute this static route with the IGP protocol (IS-IS in the above example). Note that the Guard does not run IS-IS.
Traffic Injection from the Guard to the Zone
Once the Cisco Guard has cleaned the traffic it injects it back to R1. In this scenario it is assumed that R1 stores all routes to all the possible zones, just as if it was a peering router. Hence, it would forward traffic to the zone using the suitable LSP.
Figure 4-15 Injecting the Traffic to the Zone
Caveats and Limitations
In order for the proposed Long Diversion method to work correctly, there are few points that need to be taken into consideration:
•
•
•
•
Next Hop Discovery Introduction
While returning the traffic to the zone, the Guard should know which router is the next-hop router as determined by the divert-from router. Next-hop discovery is the process that the Guard runs in order to learn which router is the next-hop router. There are two techniques to obtain the next hop router information:
•
•
Routing Protocols Next Hop Discovery
Learning the next-hop router by routing protocols is based on the idea that since the next hop router is the next hop to the zone (according to the divert-from router before diversion) the Guard should have the same view of the routing information as the view of the divert-from router. This routing information may include IGP or/and BGP information. The Guard should have the same neighbors as those of the divert-from router. Note that the Guard should receive all the routing protocols that the divert-from router runs in order to find the route to the zone. This means, that in some cases it would be enough to run only the IGP routing protocols, and in some cases it would require receiving the IGP and the BGP protocols.
This solution is applicable only if the divert-from router normally uses a routing protocol to make its decision on how to route to the zone, as opposed to using static routes to the zones. If a static route is used then the next hop route cannot be deduced from the routing protocol. Therefore, the user should consider a `discovery by Telnet' solution.
In order to receive the same IGP information as the divert-from router the Guard should be connected by tunnels (GRE/IPIP) to the possible next hop routers of the divert-from router.
In order to receive BGP information, it is enough that the Guard be an IBGP neighbor of the divert-from router. Since, in IBGP, the divert-from router announces its routing information to the Guard.
Exercise caution to prevent a situation in which the Guard while receiving routing information would be `visible' to the network and so will be getting traffic other than the zone traffic.
The next section describes how the Guard learns the next hop router. The possible scenarios are:
•
•
Next Hop Router is Derived from IGP Information
There are two situations where the next-hop router can be learned by only receiving the IGP routing information:
•
•
Currently the Guard supports only OSPF and RIP, since the Guard uses the Zebra routing-protocols software that supports only the above IGP protocols.
Figure 4-16 describes a case, in which it is enough to receive an IGP information.
Figure 4-16 Next-hop Discovery Leaning by IGP
Next-Hop Router is Derived from the IGP+BGP
When the zone is in a different AS than the divert-from router, and BGP information is not redistributed to IGP then, the next-hop information to that zone should be derived from both the IGP and BGP routing information. Note that in such cases the divert-from router decides on the next-hop in two phases. First it learns the next BGP hop to the zone, using BGP, and then learns the actual next hop router (interface) leading to that next BGP peer from IGP.
Figure 4-17 Next-hop Discovery learning by IGP+BGP
In order to receive the BGP information of the divert-from router, the Guard receives the IBGP announcement from the divert-from router. Note that the next-hop attribute is unaltered (the original next-hop is saved) in IBGP.
Note that in this method there are two BGP daemons that peer with the divert-from router are necessary on the Guard. The first, the EBGP daemon, for diversion, and the second, the IBGP daemon, for the next-hop discovery process.
In order to receive the same IGP information as the divert-from router, a third daemon is necessary on the Guard, the IGP daemon that is connected by tunnels to the possible next hop routers of the divert-from router.
The Guard performs the same two-phase recursive process as the divert-from router to establish the next-hop to a zone. First it learns the next BGP hop router towards the zone from BGP then uses IGP to find out the route to the next-hop BGP router. In the above figure the Guard learns from the IBGP that the next hop to the zone is R4 and from IGP the IGP route to this interface.
Blocking the Guard from Announcing Traffic/Updates
The Guard participates in IGP and IBGP only in order to learn the next-hop router, and it must not announce any routing information, or receive over the tunnel any traffic besides the routing updates. This means that the following steps should be taken:
1.
2.
3.
Next-Hop Discovery using Router Management Protocol (RMP)
The Guard has the ability to retrieve routing information directly from the Divert-from router using "Telnet" or "SSH" connections. This is in addition to the next-hop discovery using standard routing protocols described in the previous section. Telnet is attempted first and if it fails, Secured Shell (SSH) is used instead. The Guard supports Cisco and Juniper routers. The only command that the Guard uses in the router is show ip route .... longer for Cisco or show route.. .. best for Juniper. Routes as they are retrieved from the routers are inserted into Zebra routing table using administrative distance 10 and signed by letter "M" inside Zebra's show ip route command.
