DDOS MASSIVE: REVENGE OF THE KIDDIES

In this section, we briefly identify a few common types of DDoS attacks that traverse the modern Internet and provide a few examples of such misbehavior. We won't spend pages and pages on DDoS attacks because thousands of pages and probably hundreds of articles and books have already been dedicated to this subject. However, here we'll cover this topic from the Cisco point of view, as it provides, for people dealing with these devices, some idea of how to mitigateor try to mitigate these types of attacks. We say try to mitigate because not all attacks can be easily resolved within a desirable amount of time. In addition, the effects of some attacks can be stopped or eased only by contacting your ISPs and getting help from their side to stop the traffic at their border routers.

Direct DDoS Attacks

Direct DDoS attacks were the first form of DDoS on the Internet. A vast amount of tools has been floating about in the underground and official security lists that have a common criterion: they use zombie machines/servers to send junk traffic directly to the targeted host. These attacks usually come from some forms of Trojans that are being installed on the attacking machines, which then start sending a lot of digital rubbish to the target. You can find many of the common direct DDoS tools (both servers and clients ) at http://www.packetstormsecurity.org/distributed/indexdate.html and try them out against your own or your clients' hosts . Such DDoS attacks are still commonly used by various cracking communities to bring down their targets. For example, criminal racketeering groups use the DDoS threat to extort money from online traders, casinos, and betting shops .

Tip 

Probably the most complete web site about all things DDoS is http://www.staff.washington.edu/dittrich/misc/ddos/ . It is regularly updated and definitely worth visiting.

Reflective DDoS Attacks

Reflective DDoS attacks, on the other hand, do not send traffic directly at the targeted host. Instead, they usually spoof the originating IP addresses and send the requests at the reflectors . These reflectors (usually routers or high- powered servers with a large amount of network resources at their disposal) then reply to the spoofed targeted traffic by sending loads and loads of data to the final target. Finding the reflectors is easyjust fire a mass Nmap scan for a needed service against a specific network that is close to the target (see Chapter 4 for intelligent zombie net [floodnet] selection methods and principles) or randomly do it with a -iR option as a less intelligent approach.

The initiators of these types of attacks are usually difficult to locate, which is the reason behind the popularity of reflective attacks. In addition, if the core Internet routers (look out for TCP port 179!) or DNS servers are selected as reflectors, and an automatic Intrusion Prevention System (IPS) or inexperienced system administrator blocks them as offending hosts, great connectivity troubles will follow. Some of the SNMP-based attacks mentioned in this chapter, as well as DNS- abusing ihateperl.pl and drdos , are all examples of reflective DDoS assaults.

While a variety of reflective DDoS tools are available on the Internet, we'll provide two examples of quite powerful, yet simple, reflective DDoS attack utilities so that you can get a better grasp of the threat presented by this attack type. If you are interested in the topic of reflective DDoS, we also suggest taking a close look at pHorgasm and reflector.c .

ihateperl.pl

Attack 

Popularity:	9
Simplicity:	9
Impact:	9
Risk Rating:	9

Obtained from PacketStorm security archives, ihateperl.pl is a small, yet effective, DNS-based reflective attack. It uses a list of predefined DNS servers to spoof the requests of name resolution by the targeted host. As an example, the script uses google. com as the host being resolved by the target, which can be changed to whatever you likeif you don't feel imaginative, http://www.sco.com, http://www.microsoft.com, or http://www.intel.com are just a few examples. To use the tool, simply create a list of open DNS servers, specify the target IP address, and set the count of requests to send. Sit back and enjoy the ride while your target machine is being washed away by tons of DNS replies.

 $ perl ihateperl.pl      Usage: ./ihateperl.pl <target IP> <loop count> 

Note 

You must have root privileges to execute the script, as it requires opening raw sockets on the local host.

drdos

Attack 

Popularity:	8
Simplicity:	8
Impact:	10
Risk Rating:	9

This Perl script incorporates in itself a small collection of reflective DDoS attacks that can be implemented and used by hackers and security professionals. One can send spoofed NetBIOS queries, flood the networks with TCP SYN/ACK requests, and send loads of ICMP traffic. This is a fun script you can use to test your network DDoS resilience. Download it and fire it up to check its power for yourself.

 arhontus # perl drdos  drdos v2 <[e-mail]>      Usage drdos -a <attack type> -f <reflectors> -t <target> -w <weight>      Attack Types:      nbt      netbios tcp      syn      attack icmp      useless  icmp attack      dns      dns attack 

Cisco-Specific Countermeasures Against Various DDoS Attacks

Countermeasure 

Many DDoS attacks are difficult to combat since the requests sent by zombies are completely legitimate and standards-compliant; there are just too many to deal with them all. You can block ICMP echo requests with an appropriate ACL; however, as reviewed in Chapter 4, if you have your own autonomous system, you should let the Internet authorities ping you. Not being able to ping can reduce the troubleshooting capabilities of your ISP or technical support company, if you have one. It is also possible to counter SYN floods with the Cisco TCP Intercept feature:

 cisco2611(config)#ip tcp intercept list 101      cisco2611(config)#ip tcp intercept max-incomplete high 3500      cisco2611(config)#ip tcp intercept max-incomplete low 3000      cisco2611(config)#ip tcp intercept one-minute high 2500      cisco2611(config)#ip tcp intercept one-minute low 2000      cisco2611(config)#access-list 101 permit any any 

However, TCP intercept can consume a lot of low-end router resources and is not available on IOS versions without the o3 security designation in the IOS image name. And if Context Based Access Control (CBAC) is available, you can use its timeouts and thresholds to counter SYN flooding and UDP junk floods. Here's an example:

 cisco2611(config)# ip inspect tcp synwait-time 20      cisco2611(config)# ip inspect tcp idle-time 60      cisco2611(config)# ip inspect udp idle-time 20      cisco2611(config)# ip inspect max-incomplete high 400      cisco2611(config)# ip inspect max-incomplete low 300      cisco2611(config)# ip inspect one-minute high 600      cisco2611(config)# ip inspect one-minute low 500      cisco2611(config)# ip inspect tcp max-incomplete host 300 block-time 0 

Caution 

It is not recommended that you use TCP intercept and CBAC defenses simultaneously , since they use the same internal engine and this may lead to router overload.

Turning on Cisco Express Forwarding (CEF) can also help the router withstand floods with random packet source addresses. You can tweak the scheduler to avoid the complete CPU overload of a flooded router:

 cisco2611(config)#scheduler allocate 3000 1000 

After such a configuration, the IOS would handle network interfaces interrupt requests for 3 seconds and then move on to performing other tasks for a second afterward. On older systems, you may have to use the scheduler interval < milliseconds > command.

Another useful countermeasure against DoS/DDoS attacks is standard Cisco antispoofing , described earlier in this chapter. However, these measures cover only a small spectrum of currently available DDoS attacks and would be useless against floods with legitimate HTTP GET requests, ICMP echo replies, and SNMP GetBulk responses. In addition, there is always a possibility of a DDoS side-effect caused by massive propagation of new worms through the Internet. To distinguish worm-generated traffic from legitimate requests, we often need to look at the upper layers of the OSI model. In this case, the traditional ACLs and other countermeasures we have mentioned here would be useless. Nevertheless, efficient Cisco-specific means of countering these threats at the network perimeter are available.

Countermeasure: Using NBAR to Counter DDoS Attacks and Worm-Caused Traffic Floods

Countermeasure 

Network-Based Application Recognition (NBAR) is a Cisco IOS mechanism that examines packets on Layers 4 to 7. It isn't a security featurethe initial drive for NBAR development was traffic classification for QoS purposes. However, NBAR can be successfully used to counter some DDoS attacks and worm-generated traffic by identifying the malicious packets and performing further actions such as rate-limiting or dropping them.

The first thing we need to do when employing NBAR is to classify packets. This is done by enabling Cisco Express Forwarding (CEF) and applying a class map describing what you consider to be a malicious traffic. You can do Boolean AND or OR packet parameter matching:

 c2611(config)#class-map ?       WORD        class-map name       match-all   Logical-AND all matching statements under this classmap       match-any   Logical-OR all matching statements under this classmap 

Let's do a more strict match-all map:

 c2611(config)#class-map match-all test      c2611(config-cmap)#?      QoS class-map configuration commands:        description  Class-Map description        exit          Exit from QoS class-map configuration mode        match         classification criteria        no            Negate or set default values of a command        rename        Rename this class-map 

You can flag out quite a variety of parameters with the match command:

 c2611(config-cmap)#match ?        access-group         Access group        any                  Any packets        class-map             Class map        cos                  IEEE 802.1Q/ISL class of service/user priority values        destination-address  Destination address        discard-class        Discard behavior identifier        dscp                 Match DSCP in IP(v4) and IPv6 packets        fr-de                Match on Frame-relay DE bit        fr-dlci              Match on fr-dlci        input-interface      Select an input interface to match        ip                   IP specific values        mpls                 Multi Protocol Label Switching specific values        not                  Negate this match result        packet               Layer 3 Packet length        precedence           Match Precedence in IP(v4) and IPv6 packets        protocol             Protocol        qos-group            Qos-group        source-address       Source address 

If you want to describe the traffic using an extended ACL, use the access-group command together with the ACL number. This way, you can drop or rate-limit requests for specific portsfor example, those used by DDoS agents . For protocol-specific matching on layers higher than 4, type match protocol? and enjoy the long list of protocols supported. A common case is matching a string in the URLfor example, the filename zombie.exe , which is an abstract DDoS agent scanned for by crackers:

 c2611(config-cmap)#match protocol http url "*zombie.exe*" 

Do we need any outside requests searching for zombie.exe on our or our client's network? Of course not! Let's drop them all.

We will use Differentiated Services Code Point (DSCP) to label zombie.exe requests for further extermination. Differentiated Services (DiffServ) is a new model of traffic prioritization based on the IP type of services (ToS) field and outlined in RFCs 2474 and 2475. You can read more about DSCP at http://www.cisco.com/warp/public/105/dscpvalues.html .

First, we'll define zombie.exe :

 c2611(config)#class-map match-any pest-binary      c2611(config-cmap)#match protocol http url "*zombie.exe*" 

Then this definition needs to be bound to a policy map and assigned a DSCP priority value:

 c2611(config)#policy-map label-inbound-pest-binary      c2611(config-pmap)#class pest-binary      c2611(config-pmap-c)#set ip dscp 1 

Then, we'll apply this policy to the external router interface:

 c2611(config)#interface serial 0/1      c2611(config-if)#service-policy input label-inbound-pest-binary 

Now let's drop those annoying packets with a DSCP label:

 c2611(config)#access-list 101 deny ip any any dscp 1      c2611(config)#access-list 101 permit ip any any 

And to be sure, we can also apply this access list to the internal interface leading to the web servers:

 c2611(config)#interface ethernet 0/1      c2611(config-if)#ip access-group 101 out 

Now execute show access-list 101 to see the body count of dropped zombie.exe requests. Can you spot a potential problem? Passing packets through an access list is resource-consuming, especially if the flood is massive. Wouldn't it be better to blackhole the defined packets to Null0 instead, thus saving some precious CPU cycles? Let's do it.

After you have done the class map and assigned these pesky requests a DSCP value, configure an access listthis time with a permit statement:

 c2611(config)#access-list 101 permit ip any any dscp 1 

Now it's time to create a route map leading to oblivion:

 c2611(config)#route-map black_hole 10      c2611(config-route-map)#match ip address 101      c2611(config-route-map)#set interface Null0 

A route map must be applied to the input interface:

 c2611(config)#interface serial 0/1      c2611(config-if)#ip policy route-map black_hole 

Sit back and watch those puny requests dying in your logs.

It is also possible to perform a similar function using the policy-map and police commands. However, to illustrate their functionality, we'll use a different example, since we've had enough of that silly zombie.exe business. Good old smurf is probably the most ancient (but still relevant) DDoS attack.

For starters, we'll define ICMP echo replies with an access list:

 c3600(config)# access-list 101 permit icmp any any echo-reply 

Then we need to create a class map. The one based on the access list above will suffice:

 c3600(config)# class-map match-any smurf-flood      c3600(config-cmap)# match access-group 101      c3600(config-cmap)# exit 

Time to do the familiar DSCP trick:

 c3600(config)# policy-map kill-smurf      c3600(config-pmap)# class smurf-flood      c3600(config-pmap-c)# set ip dscp 1      c3600(config-pmac-c)# exit 

A policy must be assigned to an interface:

 c3600(config)# interface serial 0/1      c3600(config-if)# service-policy input kill-smurf      c3600(config-if)# exit 

NBAR cannot perform two policies on one interface (for example, mark and limit), so we need to invent a separate policy with its own class map:

 c3600(config)# class-map match-any smurf-labeled      c3600(config-cmap)# match dscp 1      c3600(config-cmap)# exit 

Now to the most exciting partbuilding the main policy map and enforcing the rate limit on ICMP echo replies:

 c3600(config)# policy-map limit-smurfing      c3600(config-pmap)# class smurf-labeled      c3600(config-pmap-c)# police 16000 4000 4000 conform-action transmit exceed-action drop violation drop 

Here the average throughput for ICMP echo replies is 16 kbps, with additional allowed normal and excessive packet burst sizes of 4 kbps. The violation command dictates that if either normal or excessive burst rates are violated, all exceeding ICMP echo replies will be dropped.

The final strike is to apply the policy map to an interfacein this case an internal one:

 c3600(config)# interface ethernet 0/0      c3600(config-if)# service-policy output limit-smurfing 

Tip 

You can use policy maps and well-thought-out traffic classification to protect the route processor and management/control router planes in general from resource exhaustion caused by DoS/DDoS attacks. To find more information about this approach, consult http://www.cisco.com/en/US/about/ac123/ac114/ac173/Q4-04/techtips_policing.html and http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_white_paper09186a0080211f39.shtml.

So what did we achieve at the end? The legitimate users on your network can ping and get back their replies; this shouldn't take more that 16 kbps of bandwidth and they can still get it up to 20 kbps. However, the smurf kids will have to select a better target.

Committed Access Rate (CAR) and Controlling DoS/DDoS Attacks

Countermeasure 

CAR is a yet another QoS feature that can be efficiently deployed to counter different types of traffic floods. Just as with NBAR, you can either drop the offending traffic or, at least, limit the amount of bandwidth it consumes. In fact, you may have to combine both CAR and NBAR to combat floods defined as malicious on the basis of analysis of network layers above the transport layer. Otherwise, the traffic definition is done via standard or extended access lists.

Traffic rate limiting is meaningful only if it is done at the ISP router level. Thus, this particular section, as well as the preceding one describing rate limiting via the police command, is mainly relevant for ISP system administrators and security specialists. The only possible exception is egress filtering on border routers of a large organization or corporation from which the attack originates. Of course, this is only a temporary countermeasure to be put in place until the attackers are discovered and prosecuted.

Two classical examples of countering DoS/DDoS attacks with CAR is rate-limiting ICMP and TCP SYN floods. In both cases, the traffic structure is legitimateit's the amount of traffic that causes the problem. The general principle of using CAR to counter excessive traffic is as follows :

1. Define the traffic of interest with an access list.

2. Use the rate-limit command to control it:

    Cisco(config-if)# interface type [slot_number]port_number      Cisco(config-if)# rate-limit {input  output} access-group [acl_number] [bandwidth in bps]      [burst_normal in bps] [burst_max in bps] conform-action [action type]      exceed-action [action type] 

Thus, the rate-limit command is quite similar to the previously used police command, but there is no violation option. The supported action types include the following:

• Transmit The packet is transmitted and nothing is done to it.

• Drop The packet is dropped dead.

• Set precedence and transmit The IP precedence bits in the packet header's

• ToS field are rewritten. The packet is then transmitted.

• Set QoS group and transmit The packet is assigned to a specific QoS group and transmitted.

• Continue The packet is evaluated using the next available rate policy. If it does not exist, the packet is transmitted.

• Set precedence and continue A combination of set precedence and transmit and continue.

• Set QoS group and continue The packet is assigned to a specific QoS group and then evaluated against the next rate policy. If it does not exist, the packet is transmitted.

To use CAR for ICMP echo control ( ping -f floods and smurf attacks), you can do the following:

 ISP_router(config)# access-list 101 permit icmp any any echo      ISP_router(config)# access-list 101 permit icmp any any echo-reply      ISP_router(config)# interface serial0/0      ISP_router(config-if)# rate-limit output access-group 101 32000      4000 4000 conform-action transmit exceed-action drop 

Here we assign 32 kbps for ICMP echo and echo reply packets, with additional normal and excessive burst rates of 4 kbps; the packets are dropped if these rates are exceeded.

Tip 

In a specific case of limiting ICMP unreachable traffic generated by your router used as a reflector by crackers, you can also use the ICMP rate limit feature, available since Cisco IOS 12.1: Cisco(config)# ip icmp rate-limit unreachable [df] [milliseconds] . Since this feature limits all types of ICMP unreachable messages, it can also thwart UDP portscans against the router depending on the ICMP rate-limit configuration and UDP scan speed.

Implementing CAR against SYN flooding is also quite straightforward. First, we need to define the flood packets, for which the established command can be used:

 c3600(config)#access-list 101 deny tcp any any established      c3600(config)#access-list 101 permit tcp any any 

Then apply the rate-limit command to an involved interface, as in the previous example:

 c3600(config)# interface serial0/0      c3600(config-if)# rate-limit output access-group 101 64000 8000 8000      conform-action transmit exceed-action drop 

We have allowed more bandwidth and higher burst rates for TCP SYNs here, as compared to the ICMP ping and ping reply example. If the router belongs to a large organization or corporation and outside users actively connect to the organization networking resources, it may be necessary to allow a sufficiently fat pipe for initiating TCP connections.