EMZETT.
Login

DDoS

In short: “Distributed denial of service” — an attack in which a target (server, service) is overloaded with a huge number of requests from many different sources at the same time, until it can no longer be reached by regular users.

In more detail: “Distributed” means that the requests don’t come from a single computer but from many — often a botnet of previously hijacked, infected devices. This makes DDoS attacks hard to block, since you can’t simply block a single IP address. Protective measures include specialised DDoS protection services (e.g. Cloudflare), rate limiting and redundant infrastructure that can absorb load peaks.

In Depth

DDoS attacks are roughly distinguished by the level at which they operate:

Volumetric attacks        - simply flood raw bandwidth (e.g. UDP flood,
                             DNS amplification attacks, measured in Gbit/s)
Protocol attacks          - overload the network/transport layer, e.g. SYN flood
                             (open many half-open TCP connections, never complete them)
Application-layer attacks - specifically request expensive server operations (e.g. repeatedly
                             trigger an expensive search/database query), measured in
                             requests/second rather than bandwidth

A botnet for DDoS attacks usually comes about like this: attackers spread malware that infects vulnerable devices (often poorly secured IoT devices such as routers or cameras) and makes them remotely controllable, without their owners noticing anything. On command, thousands or millions of these hijacked devices then send requests to a target at the same time.

The distinction from a simple DoS (denial of service, without “distributed”) is important: a DoS attack comes from a single source and can usually be fended off by simple IP blocking. A DDoS attack with thousands of distributed sources makes this practically impossible — that’s why protection services rely instead on behavioural analysis (recognising suspicious request patterns) and massive, geographically distributed infrastructure that can absorb and filter the attack traffic before it reaches the actual server.

Amplification attacks in detail

A particularly effective type of volumetric attack is DNS amplification: the attacker sends a small request to an open DNS server, but forges the sender IP address to that of the victim (IP spoofing) — the DNS server then sends its (much larger) response to the victim instead of to the actual sender. Because DNS responses can be many times larger than the original request (amplification factor often 20 to 80-fold), an attacker can generate many times more attack traffic with comparatively little bandwidth of their own. Similar amplification techniques exist for NTP, Memcached and other UDP-based services that respond to small requests with large responses.

Scale of real attacks

The record sizes of DDoS attacks have risen dramatically in recent years: while early large attacks (e.g. against the security researcher blog “Krebs on Security” in 2016, carried out via the Mirai botnet of hijacked IoT devices) reached around 620 Gbit/s, cloud providers such as Google, AWS and Cloudflare have since reported fending off attacks in the range of several terabits per second — made possible by ever larger botnets and more efficient amplification techniques.

Protection strategies in detail

Besides specialised DDoS protection services (which “absorb” attack traffic via their own huge network and only let legitimate traffic through), operators rely on several complementary measures: anycast routing automatically distributes incoming traffic across several geographically distributed data centres, so that a single attack never hits the entire infrastructure at once. Rate limiting restricts how many requests a single source may make in a short time. SYN cookies are a special technique against SYN flood attacks: instead of reserving memory immediately for every incoming connection request (which an attacker could exploit with thousands of forged requests), the server encodes the necessary state cryptographically in the response itself and doesn’t have to store anything in advance.

See also: Malware, Firewall