Mitigating the Effects of DoS Attacks

As we stated at the beginning of this chapter, performance is an important requirement for a secure network. This includes maintaining performance during network attacks. Denial of service (DoS) attacks have become common on the Internet and can be devastating to unprepared organizations. To consider your network properly protected, you need to include DoS protection as part of your perimeter.

An attacker can use many methods to launch a DoS attack against your site. Most are either based on bandwidth consumption or resource consumption. In a bandwidth consumption attack, the attacker continuously sends a large volume of spoofed packets into your network, filling up your WAN connections and potentially overwhelming the routers and firewalls that the traffic needs to pass through. A resource consumption attack, on the other hand, attempts to consume vital resources on the servers that make up your network. Any resource that, if exhausted, will stop the server from functioning can be targeted. This includes resources such as CPU cycles, hard disk space, and the TCP half-open connections buffer.

The type of defense needed to protect your network will vary based on the type of attack. To illustrate this, we are going to cover a couple classic DoS attacks and provide advice on how you can defend against them. The attacks we will cover are ICMP flooding and SYN flooding.

ICMP Flooding

ICMP flooding is a type of bandwidth consumption attack where a large amount of ICMP packets is sent to your network in an attempt to consume all your network bandwidth. The ease at which this can be done is dependent on how big your network circuits are. There are two main methods attackers use to create ICMP floods. The first uses distributed denial of service (DDoS) techniques. With DDoS, the attacker gains the ability to control a large number of computer systems on the Internet. These are referred to as zombie systems. All the zombies can be controlled simultaneously by the attacker. To launch the ICMP flood, the attacker instructs all the zombies to begin sending spoofed ICMP packets to the target (see Figure 17.5). If the attacker has enough zombies, this can cause a devastatingly large amount of traffic to reach the target network. DDoS attacks have been responsible for taking down the largest sites on the Internet, including eBay and Yahoo! They can be used for many types of DoS attacks, not just ICMP floods.

Figure 17.5. DDoS attacks use a network of zombie servers to send overwhelming volumes of packets to a target network.

The second common ICMP flooding technique is called smurfing. This method, named after the first tool to popularize the technique, relies on spoofing and TCP/IP broadcast addresses.

If you send a ping packet to the broadcast address of many networks, the packet will be received by every host on the network. Many operating systems will reply to these broadcast pings. Put another way, for the cost of one ICMP packet to a broadcast address, you may receive many reply ICMP packets. To use this in an attack, all the attacker needs to do is find a network where many hosts respond to a broadcast ping. He then spoofs a stream of pings destined to the broadcast address of this network using the target's IP address as the source address (see Figure 17.6). The result will be a much larger stream of ping packets heading toward the target. It is not that hard to find a network that contains hundreds of hosts that reply to the broadcast ping. Assume the attacker is using a 56K dial-up line to send the broadcast pings. The typical maximum upload transfer speed for 56K modems is around 4Kbps, but for highly compressible data, the speed can get as high as 10Kbps. Also assume that the attacker has found a broadcast network that has 200 responding hosts. The attacker can create an ICMP flood at a rate of 2000Kbps (2Mbps). This is sufficient to take down a site that is being serviced by a single T1 line.

Figure 17.6. Smurfing uses broadcast pings to amplify the attacker's bandwidth.

So, how do we defend against the flood? A good start is to make sure you are not a potential source of an ICMP flood. As we discussed in Chapter 6, "The Role of a Router," you should make sure you have disabled directed broadcasts. This will prevent your site from participating in a Smurf attack.

If you are the recipient of the flood, you need to be able to stop it before it reaches the circuit that will become saturated. For many sites, this will be the WAN circuit to their ISP. This presents you with a problem. You could perfectly filter out the extraneous ICMP packets at your perimeter router, but still be down because all your WAN circuit bandwidth has already been consumed. This means that it will be your ISP, not you, who will need to take action. This makes having a responsive ISP an important part of your network's perimeter security.

The type of filter your ISP will need to install depends on the type of flood. Smurf attacks can often be handled by filtering out all packets coming from the source network being used by the attacker to launch the attack. This assumes that the source network is not one that you need to communicate with! DDoS attacks though can be harder to defend against than Smurf attacks.

In a DDoS attack, all the packet source addresses will likely be random, making it impossible to use source address as our filter criteria. We may still be able to use a filter, though, if we don't need the packet type that is being used to attack us or if there is some other unique aspect to the attack packets that would allow us to differentiate them from our normal traffic. For example, most networks do not absolutely need to support ping traffic. If all the DoS packets are pings, we can safely block ping packets to bring the attack under control. If the DoS packets are a type we must accept (such as HTTP packets heading toward your public web servers or SMTP packets heading toward your mail servers), there may be some other unique feature of the packets we can use to discriminate them from normal traffic (such as excessive size).

If the DoS traffic is a type we must support, and we can not easily discriminate it from normal traffic, our next best defense is rate limiting. With rate limiting, we instruct the filtering router to only allow so much bandwidth to a particular category of traffic (for example, ICMP). Any traffic above this limit is discarded. This prevents the traffic category from consuming all the available bandwidth. Although you will likely be throwing out some good traffic with the bad, at least your network will be back up.

SYN Flooding

SYN flooding uses the session handshake required to set up a TCP connection against us. As we discussed in Chapter 2, three packets are required to set up a TCP connection. These are the SYN, SYN-ACK, and ACK packets. When a server receives a SYN packet from a client, it needs to have a way of remembering that it has been asked to establish a connection to the client while waiting for the client to respond to its SYN-ACK packet. The server does this by recording the SYN request in its half-open connections buffer. Normally requests are cleared from the half-open connections buffer when the server receives the ACK packet from the client, thus finishing the three-way handshake. If no ACK is received, the server will eventually time out the connection and remove the entry. As a last option, a TCP reset packet is sent to the server to clear the entry.

The half-open connections buffer has a limited size and, when it fills up, the server is no longer able to accept new connections. The SYN flood attack abuses this feature by sending SYN packets to the server with no intention of finishing the handshake. As long as the attacker can send SYN packets faster than the server times out the half-open connections, the buffer will quickly fill up and the server will be unable to respond to new requests.

Two methods are commonly used to protect against SYN flood attacks: TCP half-open connection monitoring and TCP establishment proxying. With TCP half-open connection monitoring, your firewall (or router) watches the amount and/or age of half-open connections received by internal servers. When a preconfigured threshold is exceeded, the firewall begins sending TCP resets to the server to clear the half-open connections from the buffer. This frees up new slots in the buffer, allowing the server to continue receiving requests. Even though some of the half-open connections that will be cleared are going to be for valid connections, this is better than being completely offline.

A more sophisticated answer, though, is available in TCP establishment proxying. With this solution, the firewall responds to all SYN packets for internal servers by sending out a SYN-ACK packet on behalf of the server. If an ACK packet is eventually received from the client, indicating a normal three-way handshake, the firewall creates a connection to the server on behalf of the client and then binds the two connections together. If no ACK packet is received, the firewall will eventually drop the SYN packet, thus preventing the server from ever seeing the connection. As long as the firewall has sufficient memory to hold all the half-open connections, this is a very effective strategy for protecting against SYN floods.

Firewalls are not the only devices used to prevent DoS attacks, though. As we discussed in Chapter 11, "Intrusion Prevention Systems," IPS is becoming more popular and more powerful. Vendors such as Juniper, Radware, TippingPoint, and Top Layer Networks offer system that are very effective at blocking SYN floods and other types of DoS attacks.