Switching to Defense Mode

Defensive measures consist of blocking unwanted traffic. Usually, the admin filters out the attacked target IP address (or network block), either by creating access control lists (ACLs) on the routers or by defining a null route with the Border Gateway Protocol (BGP) [4]. This entry in the routing table rejects all packages trying to reach the attacked IP address on the router upstream. As a result, the attacked server is still offline, but the rest of the line remains free.

The BGP flowspec [5] extension, which allows admins to distribute ACLs containing target ports and protocols via the BGP protocol, is more surgical. If a Network Time Protocol (NTP) reflection attack sends many packets to UDP port 123 on the server and the upstream router only blocks it, third parties can still reach the server via ports 80 and 443 (TCP); however, few router manufacturers support this strategy.

Generally speaking, hardly any providers let a customer distribute filter rules of this kind to its routers. If the provider has a powerful DDoS appliance, it will route the customer's infected traffic through and enable matching rules so that only the desired data reaches the victim.

The defenses against flooding must be made at the thick end of the pipe (i.e., the provider side) or at the data center where your web pages are hosted. This begs the question as to the bandwidth of the data center's Internet connection. A 40Gbps connection may be completely sufficient for normal operation of a data center, but attacking it is child's play in the DDoS world. I have experienced an attack on a customer of more than 200Gbps against a single server, without any commercial interests being involved.

Data Scrubbing

Individual providers offer their customers DDoS protection for a charge. Some purchase expensive hardware that can do this and then rent it out to customers.

Cloud mitigation is most common, wherein a dedicated provider "scrubs" the traffic by running a farm of anti-DDoS appliances in a broadband-connected data center to which the victim's traffic is rerouted for cleaning and then routed back again to the target through a tunnel.

There are two options for redirecting the traffic. On the one hand, it can happen on the DNS level. If the attack is directed against www.example.com, you can redirect the DNS entry to an IP in the scrubbing system. However, it takes a while for the rest of the Internet to discover the change. Admins need to keep the time-to-live for DNS requests low, so name server caching does not delay the redirection.

On the other hand, routing protocols (usually BGP) can redirect traffic. Note that this does not work with individual IPs, but only with full network blocks. The advantage is that these path changes propagate more quickly on the network.

The Narrow End

Defenses against state exhaustion attacks can also be implemented on the narrow end of the line. If Netfilter is used as a firewall, the first step is to check the net.netfilter.nf_conntrack_max (or /proc/sys/net/netfilter/nf_conntrack_max) system parameter, which specifies the maximum number of connections. The default value varies between 32768 and 65536, which an attacker can exhaust relatively quickly.

You can use sysctl -w to increase this value up to 2GB. However, the machine does need to have enough physical memory to store this number of entries. An entry consumes a good 300 bytes (in reality, it is somewhat more complicated; a blog post [6] describes it more accurately), meaning that more than 700GB of RAM would be needed for the 2 billion entries. According to the cited page, the kernel can handle 1.7 million entries with around 512MB set aside for connection tracking, which is quite a few orders of magnitude greater than the default value.

The kernel can use SYN cookies to defend against SYN flooding. The server sends a response but does not create an entry in the table. In SYN flooding attacks, the third packet is missing. If it does arrive, the server recognizes the situation and creates the entry. To make this possible, the kernel constructs the sequence numbers so that it recognizes them in the ACK packet.

DDoS appliances can do this, too, but also offer the ability to work as TCP proxies, which means that they first complete the handshake acting as proxies and only open the connection to the server if it actually works. Most modern firewall systems can also use this approach.

Defenses against more powerful attacks also exist at the same level. For web applications, a reverse proxy, such as an Apache with mod_security, can fill the breech. The module makes it possible to provide rules for, and limit the number of, requests per source IP address. However, you have to configure this by hand for each URL.

DDoS appliances allow you to set limits at the transaction level, but you should first check with the manufacturers as to which protocols they support. A10 Networks [7] even offers to enable Captchas dynamically when a threshold is exceeded and then only allow further requests to the affected source address in question once a human user has been confirmed by the Captcha.