Worm Mitigation Technical Details - Cisco Systems
Sinkholes
A sinkhole is a multifaceted security tool-essentially, a portion of the network that is designed to accept and analyze attack traffic. Sinkholes were originally used by ISPs to engulf attack traffic, in many cases drawing attacks away from a customer or other target. In more recent times, sinkholes have been used in enterprise environments to monitor attacks, detect scanning activity from infected machines, and generally monitor for other malicious activity.
This document illustrates how a sinkhole can be used in diverting attack traffic, monitoring for worm propagation, and monitoring other potentially malicious traffic.
Traditional Sinkhole - Diverting Attack Traffic
In the first sinkhole application, a publicly accessible Web server is the target of either a DoS or DDoS attack. Figure 1 illustrates how server WWW1 is unavailable due to the attack. Additionally, the extremely high traffic volume has saturated links and routers, making server WWW2 unavailable as well.
The Attack
The Diversion
Monitoring for Worm Propagation
Backscatter Traffic
First Sinkhole Design Option
Second Sinkhole Design Option
Routing Techniques
Again using an attack scenario as an example, there are many cases where it will not be desirable or feasible to shift the attack stream to a sinkhole. In these cases, it might be preferable to simply drop the stream as close to ingress as possible.
As such, a technique called remote-triggered black hole routing (also known as remote-triggered black hole filtering) can be used. Although the technique was originally developed for dealing with attacks in ISP environments, it can also be used effectively in an enterprise network for preventing worm spread. Additionally, this technique can be used for "black holing" any internal hosts participating in outbound DoS attacks, in the event that a host (such as a roaming laptop) has been compromised in this way.
This technique performs multiple functions:
- Black hole traffic at the line rate
- Provide remote trigger capability to multiple routers
- Process a large number of addresses if required
- Drop traffic based on both destination and source address, if required
To explain the technique, we will initially illustrate how it is used to mitigate an Internet-based DoS or DDoS attack. We will then explain how it can be adapted in an enterprise network.
Black Hole Routing
Remote-Triggered Black Hole Routing
Configuration for Announcing Prefixes to Send to Black Hole
router bgp 999
...
redistribute static route-map STATIC-TO-BGP
...
!
route-map STATIC-TO-BGP permit 10
match tag 66
set ip next-hop 192.0.2.1
set local-preference 50
set community no-export 999:000
set origin igp
!
Route-map STATIC-TO-BGP permit 20
!
...
ip route 171.xxx.xxx.1 255.255.255.255 Null0 Tag 66
!
Mapping of a Prefix to Null0
Internal Routing Operation of Remote-Triggered Black Hole Routing (Filtering)
Dropping on Source Address
One of the criteria for remote-triggered black hole routing to be effective as a security tool is the ability to drop traffic based on both destination address and source addresses. For example, if a host is infected with a worm, it will be identified by its source address. To prevent the spread of the worm, it is necessary to have the capability to drop any traffic originating from that source address.
A second scenario requiring a mitigation technique is one in which spoofed source addresses are used. With recent worms, such as SQL Slammer and Blaster, the host’s real IP address is used to propagate the worm. This is not to say that other worms might not use spoofed addresses. As such, the scenario needs to be accommodated. There is no reason that any host should ever send out a packet with an address other than what was assigned to it. Any packets being sent out with illegitimate source addresses should be dropped at the first router hop.
The feature that enables both of these requirements is Unicast Reverse Path Forwarding (Unicast RPF). Information about Unicast RPF is available at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fothersf/scfrpf.htm
Unicast RPF in the traditional strict mode. If a packet is received on an interface, a route to that packet’s source address must be available back through the same interface on which the packet was received. If this route does not exist, the packet fails the RPF check and is dropped. It is recommended that this technique be deployed on all user-facing interfaces. This technique is an effective way to drop any spoofed packets from hosts on the local network at the first router hop.
Unicast RPF in Strict Mode
!
interface FastEthernet2/0
ip address 192.xxx.xxx.50 255.255.255.0
ip verify unicast reverse-path
...
speed 100
full-duplex
!
Unicast RPF in Loose Check Mode
!
interface FastEthernet2/0
ip address 192.xxx.xxx.50 255.255.255.0
ip verify unicast source reachable-via any
...
speed 100
full-duplex
!
Selective Remote Traffic Dropping
