Denial of Service Attacks

Denial of Service Attacks Overview

Denial of service is an attack that attempts to exhaust resources.

One denial of service attacks might attempt to exhaust network bandwidth. Another might target TCP connections since hosts are limited in the number of TCP connections that they can open to clients.

Alternatively, a denial of service attack might attempt to exhaust various server resources. For example, a victim web server might running complicated scripts to render web pages. If the web server suddenly becomes the target of a bunch of bogus requests, the server could spend a lot of resources rendering pages for requests that are not legitimate.

Before 2000, denial of service attacks were typically single-source. After 2000, with the rise of internet worms, these attacks became distributed, effectively being coordinated and launched from many different hosts simultaneously.

Three different types of defenses against denial of service attacks are

• Ingress filtering

• uRPF checks

• SYN cookies (TCP only)

Ingress filtering

Let's assume we have a stub AS whose IP prefix is 204.69.207.0/24.

If there are no other networks connected to this AS, and this is the only IP address space that the AS owns, then the router that is immediately upstream can simply drop all traffic for which the source IP address is not in 204.69.207.0/24.

This technique is fool-proof and works at the edges of the internet where it is very easy to determine the IP address range that is owned by a downstream stub AS.

Unfortunately it doesn't work well in the core, where a router might have a lot of difficulty determining whether packets from a particular source IP address could allowed on a particular incoming interface.

uRPF

In the core, it can be useful to use routing tables to determine whether a packet could feasibly arrive on an incoming interface.

uRPF says that if we see a packet with a particular source IP address on an incoming interface that is different from the interface we would have sent the packet in the reverse direction, then we should drop the packet.

For example, suppose we had a routing table that said that all packets destined for 10.0.1.0/24 should be destined for interface 1 and all packets destined for 10.0.18.0/24 should be destined for interface 2.

uRPF says that we should allow a packet with a source IP address of 10.0.1.3 to enter on interface 1, but not on interface 2.

The benefits of uRPF is that it is automatic, but the drawbacks are that it requires symmetric routing, which is often not the case in the internet.

TCP 3-Way Handshake Review

In a typical TCP 3-way handshake: 1. The client sends a SYN packet to the server 2. The server responds with a SYN-ACK packet 3. The client responds with an ACK packet 4. The connection is established

The problem in a typical TCP handshake is that the client can send a SYN packet and cause the server to allocate a socket buffer for that TCP connection.

This means that malicious clients can force the server to allocate a lot of socket buffers simply by sending a lot of SYN packets and never returning.

The client has no accountability and no obligation to return to send the final ACK, and yet can cause the server to allocate resources.

The solution to this problem is SYN cookies. In the TCP SYN cookie approach, the server keeps no state when it receives a SYN from the client.

Instead, the server picks an initial sequence number for the connection that is a function of the client's IP address and port, and the server's IP address and port, as well as a random nonce (to prevent replay attacks).

An honest client that returns can then reply with an ACK with the sequence number in the packet. The server can check the sequence number by rehashing the address/port information and determine if the incoming ACK corresponds to the previous SYN-ACK that it had sent the client, all without requiring the server to store any state.

Only if the sequence number sent by client matches the one generated by server does the server actually establish the connection.

Inferring Denial of Service using Backscatter

When an attacker spoofs a source IP - for example, in a TCP SYN flood attack - the replies to the initial SYN packets sent to the victim will go to the spoofed IP address.

These replies are known as backscatter.

We can set up a portion of our network where we could monitor this backscatter traffic coming back as SYN ACK replies to forged source IP addresses.

If we can assume that the source IP addresses are selected by the attacker at random, then the amount of traffic that we see as backscatter will be directly proportional to the magnitude of the overall attack.

For example, if we monitor n IP addresses, the number of backscatter packets that we observe represents (n / 2^32) of the total backscatter packets, and hence that fraction of the total attack rate.

If we want to compute the total attack rate, we can simply multiply the number of backscatter packets that we observe by the inverse of the fraction above.

For example, if our telescope is a /8, or 2^24 IP addresses, we would simply multiply our observed attack rate by 2^32 / 2^24, or 256.