DDoS protection basics: recognise, mitigate, report

A distributed denial-of-service (DDoS) attack sends so much traffic, or so many requests, from many machines at once that a server or network can no longer answer real users. This guide explains the types, how to recognise an attack, what protects you and what to do while it happens.

Before you start

• Check whether your plan includes DDoS protection: the plan card on our website and the DDoS protection page show it.
• Know your normal traffic. Without a baseline, an attack and a successful campaign look alike.

The three kinds of attack

Network protection deals with the first two. Application-layer floods also need measures on your side.

Step 1: Is it an attack or a busy day?

A traffic peak after a campaign brings real visitors who browse several pages and place orders. An attack often shows a sudden jump in one kind of traffic, from unusual sources, to a single URL or port, without more orders or sign-ups. Look at the server:

ss -s
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 20
sudo awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 20

ss -s summarises connections; thousands of connections in SYN-RECV or TIME-WAIT suggest a flood. The two awk lines show the client addresses and the URLs with the most requests in the access log.

Step 2: Protect the application

If the attack targets your website, limit how fast a single address may make requests. In nginx, define zones in the http block:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=peraddr:10m;

and apply them in the server or location block:

limit_req zone=perip burst=20 nodelay;
limit_conn peraddr 20;

Test and reload with sudo nginx -t and sudo systemctl reload nginx. Requests over the limit get status 503 by default. Also:

• Cache pages that do not change per user, so floods hit the cache instead of PHP and the database.
• Put a CDN or proxy in front of the site, such as Cloudflare, which absorbs and filters HTTP floods at its edge; see Cloudflare in front of your site.
• Hide the origin. Attackers who know your server's real IP address can bypass the proxy. Point every public record through the proxy, do not send mail from the same IP and allow web traffic only from the proxy's addresses.

Step 3: Report it

Open a ticket right away with:

• the affected IP addresses and services,
• the time the problem started, with time zone,
• what you observe: graphs, ss -s output, log excerpts, the URLs attacked.

Keep a record of what you see; it helps to tell an attack from a configuration problem or a real traffic peak.

Null routing

When an attack is larger than a network can filter, operators can null-route the targeted IP address for a while: all traffic to it is dropped to protect every other service on the network. The address is offline during that time. DDoS protection exists to filter attack traffic before it comes to that, which is why it matters for services that are likely targets, such as game servers and busy shops.

DDoS protection is not a firewall

DDoS protection deals with floods that try to make a service unreachable. It does not patch software, stop password guessing or remove malware. Keep the system updated, open only the ports you use, protect logins with keys and keep backups current.

Troubleshooting

Legitimate users get 503 after enabling rate limits. The limit is too low, or many users share one address (offices, mobile networks). Raise rate and burst, and exclude assets such as images from the limited location.

The site is slow but traffic looks normal. It may not be an attack. See high CPU or memory usage and website 502, 503 and 504 errors.

The server is completely unreachable. See server unreachable and check Support › Network Status.

Next steps

• Shield your website: Cloudflare in front of your site.
• Block password guessing: Fail2ban and CrowdSec.