DDoS: What it is, how it works, and how to test your defenses

What is a DDoS attack and how does it work? Learn about DDoS types, attack techniques, authorized testing, and how to verify the effectiveness of your defenses.
- Posted on 2026-09-22
- Reading time: 8 min
DDoS: What is a DDoS attack and how is it tested? #
A Distributed Denial of Service (DDoS) attack attempts to make a service slow or unreachable by overloading it with a high volume of traffic, requests, or connections, generated from many different sources at the same time.
DDoS penetration testing involves simulating this type of pressure in an authorized environment to verify whether the infrastructure, applications, and mitigation systems can maintain service availability. It goes beyond simply measuring "how much traffic the server can handle": it also tests detection, filtering, failover, alerts, and mitigation times.
What is a DDoS attack? #
DoS vs DDoS : A DoS (Denial of Service) attack comes from a single source; a DDoS (Distributed Denial of Service) attack uses many sources—often thousands of compromised devices organized into a botnet —making the attack more difficult to block by filtering out a single IP address.
Some terms that will be used frequently in this article:
- Flood: flood the target with a huge volume of packets or requests of the same type
- Amplification: exploit a third-party service (e.g. a public DNS server) to make a small request from the attacker correspond to a much larger response, addressed to the victim
- Volumetric: an attack that aims to saturate the available network bandwidth, regardless of what the application is doing
- Application: an attack that aims to exhaust the application's resources (threads, connections, CPU) with requests that appear legitimate
How a DDoS works #
Attaccanti / botnet → Internet → rete e firewall / CDN → applicazione → utentiThe bottleneck can be found at different points in the chain: the available incoming bandwidth, the firewall's connection handling capacity, the resources of the application server or database behind it. A serious DDoS test must understand where it would fail first, not just if it fails.
Types of DDoS attacks #
| Layer | What is it about? | Example |
|---|---|---|
| L3 (network) | IP packets, network bandwidth | ICMP flood |
| L4 (transport) | TCP/UDP Connections | SYN flood, UDP flood |
| L7 (application) | Application requests | HTTP flood, Slowloris |
Layer 3 — Volumetric #
SYN flood : The attacker sends numerous TCP SYN (connection initiation) packets, often with a spoofed source IP. The server allocates memory for each connection waiting to be completed; if the number of half-filled connections (SYN backlog) fills up, the server stops accepting new ones.
UDP flood : UDP packets sent to random high ports. The server responds with ICMP "port unreachable" messages for each one: the combined incoming and outgoing traffic saturates the network.
ICMP flood (Smurf) : a historical technique, little used today, based on ping requests with a spoofed source IP addressed to a broadcast network, which generates a wave of responses to the victim.
Layer 4 — Protocol #
Flood on TCP connection states: similar to SYN flood, but aims to exhaust the resources that the operating system dedicates to tracking connection states (e.g. TIME_WAIT).
DNS flood : A high volume of queries to a DNS server, causing it to run out of CPU or memory and stop responding.
Layer 7 — Application #
HTTP floods : GET/POST requests that look exactly like legitimate traffic, but are so large that they exhaust the application server's available threads or connections. Because they look like normal traffic, they are more difficult to distinguish and block than a network flood.
Slowloris : The attacker opens many HTTP connections and keeps them open by sending headers very slowly, without ever completing them. The server, waiting for completion, keeps the connection slots occupied until they are full. It requires little traffic to be effective.
RUDY (RU-Dead-Yet) : A variant that sends the body of a POST request one byte at a time, with the same goal as Slowloris.
Reflection and amplification #
In an amplification attack, the attacker sends a request to a third-party service (DNS, NTP, SSDP, CLDAP) by spoofing the source IP address with the victim's. The third-party service responds to the victim with a packet much larger than the original request—hence the term "amplification." Some well-known examples: DNS amplification, NTP amplification (via the command monlist, now disabled on most up-to-date servers), SSDP amplification (exploits exposed UPnP devices, often routers or out-of-date home printers), CLDAP amplification (exploits LDAP directory servers over UDP).
Multi-vector #
A multi-vector attack combines multiple techniques simultaneously (e.g. SYN flood + UDP flood + HTTP flood), to hit multiple layers of the defense chain at the same time and complicate mitigation.
How to Perform a DDoS Penetration Test #
Authorization and scope #
Before generating any traffic, written authorization is required that defines: the exact target (IP or domain), the agreed-upon time window, the escalation contact that can be reached during the test, maximum traffic limits, and success criteria (uptime, latency, false positives to be measured).
=== Autorizzazione Test DDoS ===
Target: 203.0.113.100 (staging)
Data/ora: 2026-06-21, 22:00-23:00 UTC
Durata max: 60 minuti
Vettori: SYN flood (max 10 Gbps), HTTP flood (max 50k RPS)
Escalation: soc@azienda.it, reperibile durante il test
Stato: autorizzato dal responsabile sicurezzaTesting environment #
A DDoS test in production is high risk: without a formal procedure, explicit authorization, coordination with the provider, and an immediate shutdown mechanism, the risk of causing a real disruption is real. Whenever possible, it's best to start with an isolated staging environment, as close to production as possible, and only move to production with a controlled test plan and the active participation of the mitigation provider.
Baseline #
Before generating any load, measure normal behavior: bandwidth used, packets per second, requests per second, average latency, error rate. Without a baseline, it's impossible to determine whether a significant decline during the test is true.
iperf3 -c 10.0.0.50 -t 10 # banda disponibile in condizioni normaliIncreasing load test #
The load should be increased gradually, not all at once, to precisely identify the threshold at which a component begins to degrade.
# SYN flood a intensità crescente (solo in ambiente autorizzato)
hping3 --syn -p 80 -i u10000 10.0.0.50 # ~100 Mbps
# HTTP flood con Vegeta
echo "GET http://10.0.0.50/" | vegeta attack -duration=60s -rate=1000 | vegeta reportMonitoring during the test #
iftop -i eth0 # traffico in tempo reale
tail -f /var/log/syslog | grep -i "ddos\|attack\|flood" # log applicativi/sistemaStop conditions #
A well-planned test includes pre-agreed immediate termination criteria (e.g., exceeding an error threshold on live users, escalation by the customer), not just a maximum time.
How to validate DDoS defenses #
This is the most practical part of a test: it's not enough to know that the service has handled a certain volume of traffic, you need to verify that each layer of defense has actually done its job.
Rate limiting : Ensures that the system discards excess traffic beyond a configured threshold, rather than letting it all pass.
watch 'cat /proc/net/dev | grep eth0' # osserva se ci sono pacchetti scartati durante il caricoFiltering : Verify that malicious traffic is actually blocked upstream (firewall, WAF) and not just slowed down.
CDN and scrubbing center : If your infrastructure includes an external mitigation service (Cloudflare, Akamai, and the like), verify that traffic is actually redirected there during an attack.
dig target.com +noall +answer # confronta l'IP risolto prima, durante e dopo il testFailover : Verify that the transition to the mitigation infrastructure occurs on time and that legitimate traffic continues to be served in the meantime.
Alerting : Verify that the configured alerts (SIEM, email, live chat) actually fire during the test, and not just exist on paper.
Recovery : Verify that, once the load is complete, the system returns to normal conditions without manual intervention, and if so, how long it will take.
Metrics to measure #
- Band (Mbps/Gbps) and packets per second (pps): for volumetric attacks
- Requests per second (RPS) e latency: for application attacks
- Error rate: percentage of legitimate requests that failed during the test
- MTTD (Mean Time To Detect): average time taken by the system to detect the anomaly
- MTTR (Mean Time To Mitigate/Recover): average time to mitigate or return to normal
Instruments #
Load generation: hping3 for network traffic (SYN/UDP/ICMP), scapey to build custom packages (also useful for demonstrating the amplification mechanism in the lab, without targeting unauthorized third-party services), Vegeta or Apache Bench for HTTP load, iperf3 for bandwidth testing.
Analysis and monitoring : Wireshark for attack pattern recognition, tcpdump for raw capture, NetFlow tools for flow analysis, mitigation provider APIs (e.g., Cloudflare, Akamai) to read real-time statistics during testing.
Common mistakes during a DDoS test #
- Skipping the baseline phase and not having a basis for comparison
- Increasing the load too quickly instead of gradually
- Testing only one vector (e.g. SYN flood only) and concluding that “the defense holds”, without having verified the application layer and amplification
- Do not involve the mitigation provider, risking false alarms or unexpected blockages
- Do not define clear stopping conditions in advance
Recent statistics #
Cloudflare reports approximately 47,1 million DDoS attacks mitigated in 2025 , a 121% increase over the previous year. In Q4 2025, a record-breaking 31,4 Tbps attack was recorded, lasting approximately 35 seconds , attributed to the Aisuru-Kimwolf botnet . Cloudflare estimates that the total number of infected devices affected was between 1 and 4 million (a mix of IoT devices tied to the Mirai/Aisuru ecosystem and Android devices compromised via ADB for the Kimwolf component).
Another notable finding: in Q3 2024, Cloudflare observed a 4.000% increase in SSDP amplification attacks compared to the previous quarter, linked to the exploitation of out-of-date home routers and UPnP devices.
DDoS penetration testing in production #
Testing in production isn't impossible, but it should be treated as a high-risk operation: it requires a detailed plan, explicit authorization from those responsible for the service, direct coordination with the mitigation provider, agreed-upon traffic limits, and a pre-tested immediate shutdown mechanism. In the absence of these conditions, it's best to start with a staging environment that's as realistic as possible.
Operational checklist #
- Written authorization with defined scope, time and escalation
- Staging environment ready, as close to production as possible
- Normal traffic baseline recorded
- Test with increasing load on each layer (L3, L4, L7)
- Testing of at least one amplification vector, only in a controlled laboratory
- Checking rate limiting and filtering
- Verifying failover to the mitigation system
- Verify that the configured alerts actually go off
- Measurement of MTTD and MTTR
- Post-test analysis shared with the infrastructure management team
FAQ #
What is a DDoS attack? An attack that aims to slow down or make a service unavailable by generating a high volume of traffic or requests from many different sources simultaneously.
What's the difference between DoS and DDoS? DoS comes from a single source, while DDoS comes from many distributed sources, often a botnet, making it more difficult to block by filtering a single IP address.
What's the difference between volumetric and application-based DDoS? A volumetric attack aims to saturate available network bandwidth; an application attack aims to exhaust the application's resources (threads, connections, CPU) with seemingly legitimate requests.
What is a SYN flood? An attack that sends numerous TCP SYN packets to fill a server's queue of pending connections, preventing it from accepting new ones.
What is an HTTP flood? A high volume of seemingly legitimate HTTP requests, designed to exhaust the application server's resources.
What is an amplification DDoS attack? A technique that uses a third-party service to send the victim a response that is much larger than the request sent by the attacker, who spoofs the source address.
How is DDoS resilience measured? With metrics such as bandwidth, packets per second, requests per second, latency, error rate, time to detection (MTTD), and time to mitigation (MTTR).
How do you test DDoS protection without interrupting service? Increase the load gradually, starting from staging when possible, defining shutdown conditions in advance, and coordinating with the mitigation provider.
Does Cloudflare (or a similar service) protect against all DDoS attacks? It greatly reduces the risk, but it doesn't eliminate the need to check your configuration: overly permissive or poorly configured rate limiting rules can still allow malicious traffic to pass through.
Recommendations for those who protect an infrastructure #
- Know your normal traffic baseline (averages and peaks)
- Configure rate limiting on pps/bps per source
- Consider a DDoS mitigation service (Cloudflare, Akamai, Fortinet, or similar) with automated response
- Monitor the exposure of IoT/UPnP devices on your network: they are among the favorite targets for botnet recruitment
- Prepare a DDoS-specific incident response playbook (escalation, failover, communication)
- Schedule periodic resilience tests, with clear scope and authorization
External resources #
- Cloudflare – 2025 Q4 DDoS Threat Report: 31,4 Tbps attack data source and 2025 statistics
- Cloudflare – DDoS Threat Report Q3 2024: Source of data on 4.000% increase in SSDP amplification attacks
- Cloudflare – What is the Aisuru-Kimwolf botnet?: further information on the botnet mentioned in the article
- Yuri Kan – DDoS Testing: Testing System Resilience: A practical guide to validating rate limiting, WAF, and auto-scaling
- BlackNeuron – DDoS Resilience Testing: analyzing the difference between load testing and true DDoS resilience testing








