Detect a DDoS Attack: Signs in Logs, Metrics and Traffic

Most site owners do not find out about an attack from a dashboard. They find out from a customer email saying checkout has been spinning for ten minutes. By then the question is not whether something is wrong but what: a broken release, a database lock, or someone deliberately flooding the server. Being able to detect a DDoS attack quickly is mostly about answering that question with data instead of guesses.

Signs of a DDoS attack: what actually changes

A fault usually moves one metric. An attack moves several at once, abruptly, and without an obvious trigger such as a newsletter or a press mention. Use the table as a starting point and calibrate it against your own baseline.

That last row is the cheapest test you have. Real people buy things. Botnets do not.

First commands when the server crawls

Spend two minutes looking before you start restarting services. These run on any current Linux distribution; iftop may need installing.

ss -s
ss -tan state syn-recv | wc -l
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

Typical ss -s output during a connection flood looks something like this:

Total: 52418
TCP:   51960 (estab 1033, closed 187, orphaned 4, timewait 176)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       11        7         4
TCP       51773     51751     22
INET      51784     51758     26
FRAG      0         0         0

A TCP total far above the established count means connections are stuck in other states. The second command counts the half-open ones. On a healthy web server that number is normally small; thousands point to a SYN flood. Check sysctl net.ipv4.tcp_syncookies while you are there. A value of 1 means SYN cookies are on, which lets the kernel keep answering without filling its backlog.

For bandwidth, run iftop -i eth0 -nNP. The flags turn off DNS and port name lookups and show port numbers. Heavy inbound UDP from source port 53 or 123, when your machine never sends DNS or NTP queries of that volume, is reflected traffic. The mechanism is covered in DNS amplification attacks.

Finally, dmesg -T | tail -50. If you see nf_conntrack: table full, dropping packet, the kernel is already discarding packets from everyone, legitimate visitors included.

Reading nginx access logs during an attack

For HTTP floods the access log tells you most of what you need. These one-liners assume the default combined format. On a busy server, pipe in only the last chunk with tail -n 100000 first.

Requests per minute, to see when it started:

awk '{print $4}' /var/log/nginx/access.log | cut -d: -f2-3 | sort | uniq -c | tail -30

Top client IPs:

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

Top paths and user agents:

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Patterns that usually mean a flood rather than an audience:

• one expensive endpoint (search, login, cart, an API route) dominating the count
• random query strings such as /?x7q2p, designed to miss the cache
• a handful of identical user-agent strings spread over thousands of IPs
• an empty referrer on almost every request
• lots of 499s, meaning clients hang up before the response arrives

If the load is spread across many pages and the referrers point at a news site or a viral post, you are probably looking at real people. The article on telling a DDoS or traffic spike apart goes through that decision in detail.

Behind a CDN, every request in the log comes from the CDN’s edge. Set set_real_ip_from for its published ranges and real_ip_header to its client-IP header (CF-Connecting-IP for Cloudflare) before you block anything.

Using CDN analytics for DDoS monitoring

If the domain is proxied through Cloudflare, the Security section lists mitigated events and the analytics views break traffic down by country, ASN, path and user agent. Two views earn their keep:

1. Traffic by ASN. Real users arrive through consumer ISPs and mobile carriers. Floods tend to cluster in hosting and cloud networks.
2. Cached versus origin requests. If edge traffic is flat but origin requests are climbing, someone is targeting content the cache cannot serve.

Settings worth adjusting ahead of time are in the guide to Cloudflare DDoS protection.

Which layer is under attack

Mitigation depends on where the pressure is. A rough map:

You cannot fix a saturated link from the server behind it. The packets have already clogged the pipe. A fuller breakdown is in types of DDoS attacks.

Evidence checklist while it is happening

Whatever you collect now will be needed by your provider, your insurer and possibly the police.

• start time, with time zone
• copies of access and error logs before rotation removes them
• ss -s and iftop output saved to a file
• a CDN analytics export for the period
• any ransom or threat emails, with full headers
• ticket numbers from your host and DNS provider

Once you know what you are dealing with, move on to the DDoS response steps.

Don’t forget the name servers

Some attacks skip the web server entirely and go after DNS. The origin is healthy; nobody can resolve it. Add an external check such as dig +short example.com A @ns1.your-provider.net every few minutes so you notice that case too.

How much you can do about it depends on your registrar. At betadomain you control name server management yourself, can switch on DNSSEC, and can script changes through the domain API for developers if you ever need to fail over to another DNS provider. Renewal stays at the price you registered at, which you can confirm on the price list. Set up the DNS check today, before you need it.