On this page
Key points
- Separate incident from attackDetecting a DDoS means correlating service symptoms with network evidence.
- Watch PPS, Gbps and errorsEarly detection reduces downtime and avoids panic decisions.
- Trigger mitigation early, PPS, flows, top destinations, source distribution, protocol mix, SYN rates, UDP rates, packet sizes…
Definition of the problem
Detecting a DDoS means correlating service symptoms with network evidence. A single metric is rarely enough: high bandwidth can be legitimate, and a small high-PPS flood can still break infrastructure.
The detection problem is also timing. If the team confirms the attack only after blackholing, the customer has already lost availability. The goal is to trigger investigation and mitigation early enough.
Why early detection matters
Early detection reduces downtime and avoids panic decisions. Without clear signals, teams often reboot servers, change application settings or block legitimate users while the attack continues upstream.
For hosting providers, early detection also protects other customers. For gaming services, it preserves player trust. For enterprises, it prevents a technical incident from becoming a sales and reputation issue.
What to monitor
Monitor Gbps, PPS, flows, top destinations, source distribution, protocol mix, SYN rates, UDP rates, packet sizes, retransmissions, failed handshakes and application errors. The useful view is a timeline that connects network traffic to service impact.
Alarms should be different for each service. A web platform, a DNS service, a Minecraft server and a FiveM proxy do not have the same normal behaviour. Baselines prevent false positives and make attack detection faster.
- detecting a DDoS requires correlating traffic, application errors, PPS, saturation and user complaints.
Concrete use case
A game community sees players timing out while the server process is still running. Network graphs show moderate Gbps but an unusual PPS spike and repeated UDP queries to the same destination. This points to a flood rather than a simple application bug.
A B2B platform sees failed TLS handshakes and firewall CPU spikes. The web application is not the first bottleneck; mitigation must protect the TCP edge before the app receives clean sessions.
Common mistakes
The main mistake is waiting for total outage before acting. The second is looking only at bandwidth and ignoring PPS, failed connections and packet loss.
Another mistake is treating every spike as an attack. Good detection compares traffic to normal behaviour, customer activity, deployment changes and known monitoring events.
