What is a DDoS attack? How it works, what it looks like on a server, and what to do

Short answer: a DDoS attack — distributed denial of service — is an attempt to make a website, server or network unavailable by flooding it with more traffic or requests than it can handle, sent from many machines at once. Because the traffic comes from thousands of sources, usually hijacked computers and devices in a botnet, blocking a single address does not stop it. A DDoS does not break into anything; it exhausts something — bandwidth, connection tables, CPU — until legitimate users can no longer get through.

A plain DoS comes from one source and is easy to block. The extra D, for distributed, is what makes these attacks hard: the attacker borrows the combined capacity of every machine they control, or tricks innocent servers into sending the traffic for them.

What kinds of DDoS attack are there?

Volumetric attacks simply fill the pipe. If a server has a 1 Gbit/s port and 20 Gbit/s arrive, nothing the server does matters — the packets are dropped before they reach it. These have to be filtered upstream, in the network, by whoever has more capacity than the attack.

Protocol attacks are smaller but cleverer. A SYN flood sends connection requests and never completes the handshake, so the server keeps half-open connections until its table is full. Stateful firewalls and load balancers in front of a server are often the first thing to fall over.

Application-layer attacks look like real visitors. Each request is valid HTTP — a search, a login, a page with a random query string that bypasses the cache — and each one costs the application real work. A few thousand requests per second can take down a site that would shrug off gigabits of junk packets, and they are the hardest to tell apart from a traffic spike.

How do amplification attacks work?

Many UDP services answer a small question with a large reply, and UDP does not verify who is asking. The attacker sends small requests to thousands of open servers with the victim’s IP address forged as the sender. Every server replies — to the victim. The attacker spends a little bandwidth and the victim receives many times as much.

The factor is reply bytes per request byte, as listed in CISA’s alert on UDP-based amplification attacks. Memcached’s figure is why exposed memcached servers produced record-breaking attacks in 2018, and why memcached has shipped with UDP disabled by default since version 1.5.6.

Where does the traffic come from?

• Botnets — computers, routers, cameras and other devices infected with malware and controlled remotely. The Mirai botnet, made of insecure IoT devices, knocked out the DNS provider Dyn in October 2016 and with it many large websites.
• Reflectors — misconfigured but otherwise legitimate servers abused for amplification, as above.
• Rented capacity — “booter” or “stresser” services sell attacks by the minute. Ordering one against a target you do not own is a crime in most countries, and police regularly seize these services along with their customer lists.

Motives range from extortion and competition to revenge over a game match. Game servers, small shops and community sites are frequent targets precisely because they are rarely protected.

What does a DDoS attack look like on a server?

• The site or game server becomes slow or unreachable, often for everyone at once.
• The network graph in the provider’s panel or your monitoring jumps far above normal.
• Huge numbers of connections in SYN-RECV state, or from addresses all over the world.
• Web server logs filling with near-identical requests to one URL, or to random query strings.
• SSH itself lags or times out, because the link is full.

ss -s                                         # connection totals by state
ss -tan state syn-recv | wc -l                # half-open connections
ss -tan | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
nload eth0                                    # live traffic per interface (apt install nload)
tail -f /var/log/nginx/access.log             # what the requests look like

Not every outage is an attack. A link to your site on a big forum, a misbehaving crawler or your own cron job hammering the database produce the same symptoms. If the traffic comes from a handful of addresses, it is not distributed and a firewall rule fixes it. If high CPU is the main symptom, rule out your own processes first.

What should you do during an attack?

• Tell your hosting provider what you see, with times and examples. Volumetric floods can only be filtered in the network upstream of your server.
• Do not move to a new IP address in public — attackers follow DNS changes. If you put a proxy or CDN in front, keep the origin address secret and allow only the proxy’s ranges to reach it.
• Turn on what you have: stricter rate limits, caching of everything cacheable, a challenge page for suspicious traffic.
• Keep logs and timestamps for the provider and for a possible police report.
• Do not pay ransom demands — paying marks you as a customer for the next round.

How do you defend against DDoS attacks?

Defence works in layers, and no single layer covers all three categories:

• Network-level mitigation at the provider absorbs and filters volumetric and protocol floods before they reach your port. This is the part you cannot do yourself.
• A CDN or reverse proxy in front of websites spreads load, caches, and can challenge suspicious clients — a CDN is the usual answer for layer 7 floods against public websites.
• Your own server settings keep application-layer attacks cheap to survive: rate limits, connection limits, timeouts and caching.

# in the http block
limit_req_zone  $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conns:10m;

# in the server or location block
limit_req  zone=perip burst=20 nodelay;
limit_conn conns 20;
client_body_timeout 10s;
client_header_timeout 10s;

sysctl net.ipv4.tcp_syncookies     # 1 = enabled

SYN cookies let the kernel answer connection requests without keeping state until the handshake completes, which defuses simple SYN floods against the server itself. Rate limits return 429 or 503 to clients that exceed them, so set them above what a real user with many tabs produces, and exempt monitoring and API clients that legitimately send more.

Choosing a host with mitigation that fits your workload, and the settings to add on top, is the subject of our guide to DDoS-protected VPS hosting — including what to ask a provider and how game servers differ from websites.

DDoS protection at VMHeaven

Every VMHeaven server and hosting plan includes always-on, automatic DDoS mitigation in both locations, Amsterdam and Frankfurt, at no extra cost and with nothing to switch on. It works at the network level, so the application-layer measures above — rate limits, caching and a CDN for public websites — remain your part. Pick the line for the workload: Standard KVM for websites and general servers, Hi-CPU KVM for game servers.

Frequently asked