What happens during a DDoS event

Nothing gets switched on

There is no button. Scrubbing runs permanently in front of every site, from four terabits a second at the smaller locations to twelve at the largest, and the decision to drop a packet is taken in hardware at the edge on the way in. The first thirty seconds of an attack are therefore filtered exactly like the last thirty, which is not true of any system that has to detect an attack, redirect a prefix, and wait for the announcement to propagate.

What you see from inside

Usually nothing whatsoever. Reflected UDP, a SYN flood, a set of amplified DNS responses: a volumetric attack of any shape is dropped upstream and never reaches your port. The graph in the panel shows it. Your interface counters do not.

What can reach you is anything indistinguishable from real traffic: a slow HTTP flood, a stream of requests to your most expensive endpoint, a credential-stuffing run. Layer 7 is where the edge cannot help without knowing your application, which is what the DDoS Pro add-on exists for: custom signatures, rate limits by path, and a person to write them with while it is happening.

Check your own limits before concluding anything

A good half of the attacks reported to us are a conntrack table filling up or a listen queue overflowing under ordinary Monday traffic.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
nstat -az TcpExtListenOverflows TcpExtSyncookiesSent
ss -s
journalctl -k --since "15 min ago" | tail -50

nf_conntrack: table full, dropping packet in the kernel log is your firewall talking about itself, not the network reporting an attack.

What we do

Detection is flow-based and per-destination. A signature match drops the matching traffic within seconds and leaves the rest of yours alone. Where the volume exceeds what a site can absorb, which is rare and has happened, the destination address is filtered wholesale for a stated window instead of letting the site degrade for everybody on it. You get an email naming the window, and it is measured in minutes.

Attack traffic is never counted against fair use. It is not your traffic and you did not ask for it.

What we can tell you afterwards

Vector, peak bit rate, peak packet rate, duration, and the rough geography of the sources. That is what flow counters hold.

What we cannot hand over is a packet capture, because there is not one. We do not record the traffic crossing your instance, and that policy has no exception that switches itself on when the traffic turns hostile. The detail is on what we log. People occasionally find this frustrating mid-incident, and it is the same property that makes the rest of the policy worth anything.

What not to do

• Do not change the address. The attack follows it inside a minute and now your DNS is wrong as well.
• Do not reboot. A rebooting instance is a slower instance, not a filtered one.
• Do not paste a thousand-line nftables ruleset in a panic. Anything you drop on the instance has already crossed the expensive part of the network.
• Do check /status first. If the site itself has an incident, it is published there before your ticket is written.

Open the ticket anyway

Instance ID, timestamps with a timezone, what the symptom actually was, and whether the service was reachable from a second network. Median first response is eleven minutes at every hour of the day, and during a live event the reply comes from somebody already watching the graph.