DDoS Attack: What to Do in the First Hour (8 Steps)

The first hour of an attack tends to go the same way everywhere. Someone restarts the server three times, someone else deletes old logs to free disk space, and the hosting provider hears about it forty minutes in. Restarts do nothing against traffic that keeps arriving. The deleted logs are the evidence you will want later. The order below puts the people who can actually filter traffic at the front of the queue.

DDoS attack, what to do: the first 15 minutes

1. Diagnose before you touch anything

Five minutes of looking saves an hour of guessing. You need to know whether the link is full, the connection tables are full, or the application is drowning.

ss -s
ss -tan state syn-recv | wc -l
iftop -i eth0 -nNP
tail -n 20000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

How to read the output is explained in how to detect a DDoS attack. Spend thirty seconds ruling out a genuine rush of visitors, too. The signals are listed in DDoS or traffic spike.

2. Get your provider involved

A saturated link or a large SYN flood can only be stopped upstream of you. The more precise your report, the faster the response. Something like this works well:

Server: web01, IP 203.0.113.10
Start: 18 Oct, 13:02 UTC
Inbound ~3 Gbps UDP, source port 123, 1 Gbps port saturated
Requesting filtering/scrubbing for this IP

Some providers null-route an attacked IP to protect the rest of their network. Your server goes fully offline, everyone else stays up. Ask whether that is on the cards and for how long.

How to stop a DDoS attack at the edge

3. Raise the challenge level at your CDN

If the site already sits behind Cloudflare, Under Attack mode is the fastest lever. It is in the Quick Actions panel on the zone overview. Every visitor gets a JavaScript check, which Cloudflare says decides within five seconds. Cloudflare itself calls the mode a last resort: it skews analytics and blocks clients that cannot run JavaScript, which includes mobile apps and webhooks calling your API. A configuration rule that enables it only for the paths under attack is usually the better trade. The guide to Cloudflare DDoS protection covers the settings.

If you have no CDN yet, moving behind one mid-attack is possible but slower: name servers have to change and your origin IP is already known. See step 5.

4. Rate-limit the expensive endpoints

For layer 7 floods, cap the paths that dominate your log. A minimal nginx example:

limit_req_zone $binary_remote_addr zone=hot:10m rate=2r/s;
limit_req_status 429;

server {
    location /search {
        limit_req zone=hot burst=5 nodelay;
        proxy_pass http://app;
    }
}

The zone directive belongs in the http block. According to the nginx docs one megabyte holds about 8,000 states on 64-bit platforms, so 10 MB covers roughly 80,000 client addresses. Behind a CDN, configure the realip module first or you will be limiting the CDN’s addresses instead of the attackers’. More patterns are in the guide to rate limiting.

At the same time, lengthen page cache lifetimes for logged-out visitors and switch off features that always bypass the cache, such as full-text search.

5. Lock down the origin

A CDN does nothing if the attacker knows your real IP and goes around it. Allow ports 80 and 443 only from your CDN’s published ranges. If the IP is already public, the only fix is a new one that exists nowhere except in the CDN configuration. Check MX records, forgotten subdomains and outgoing mail headers, which leak origin addresses more often than people expect.

DDoS incident response: evidence and reporting

6. Preserve evidence

Copy logs before rotation eats them and record checksums so you can show they were not altered:

mkdir -p /root/ddos-2026-10-18
cp /var/log/nginx/access.log* /var/log/nginx/error.log* /root/ddos-2026-10-18/
sha256sum /root/ddos-2026-10-18/* > /root/ddos-2026-10-18/SHA256SUMS

Add CDN exports, screenshots of graphs, any threat emails saved as original files with headers, and every ticket number.

7. Communicate

A status note hosted somewhere other than the server under attack keeps customers calm and support queues shorter. Two sentences are enough: what is happening and when the next update comes. Internally, one person decides. Not five.

8. Report it and review

DDoS attacks are a criminal offence in most jurisdictions. Report to your local police or national cybercrime unit, and to your national CERT or CSIRT if it accepts reports from your type of organisation. In the EU, entities covered by NIS2 have formal deadlines, starting with an early warning within 24 hours. What to include is covered in how to report a DDoS attack.

Mistakes that make it worse

• restarting the server every few minutes
• deleting logs to free space
• forwarding the ransom email instead of saving it with headers
• paying
• publishing the new origin IP in DNS
• leaving Under Attack mode on for a week and forgetting about it

After the attack: build what was missing

When things go quiet, work out what the outage cost. The cost of a DDoS attack article walks through the arithmetic. Then add the layers you lacked: a CDN in front, rate limits on expensive routes, and on the DNS side name servers at more than one provider, as described in secondary DNS.

That last part needs a registrar that lets you set name servers freely. At betadomain you handle name server changes for your domains yourself, can register a .com with DNSSEC, and can script failovers through the registrar API. Print the eight steps above and put them where whoever is on call will find them.

Step by step

1. Diagnose the layerUse ss -s, iftop and the web server access log to decide whether the link, connection tables or the application is saturated, and note the start time with time zone.
2. Contact your hosting or upstream providerOpen an urgent ticket or call, giving the target IP, start time and measured traffic, and ask for filtering or scrubbing.
3. Tighten protection at the edgeRaise the challenge level at your CDN, for example Cloudflare's Under Attack mode for the whole zone or only for the paths being hit.
4. Rate-limit expensive endpointsThrottle search, login and API routes with nginx limit_req or a WAF rule, and extend page caching for anonymous visitors.
5. Lock down the originAllow ports 80 and 443 only from your CDN's published IP ranges so attackers cannot bypass the proxy.
6. Preserve evidenceCopy and hash access and error logs, export CDN analytics, keep threat emails with headers and record every ticket number.
7. CommunicatePost a short status update on a separately hosted page or social channel and name one person who makes decisions.
8. Report and reviewFile a report with police or the national cybercrime unit, notify any regulator your sector requires, then build the protection that was missing.