To understand how a DDoS attack works, start with this: a distributed denial-of-service attack takes a website offline without breaking into it. Instead, many hijacked devices send so much traffic at once that the server can no longer answer real visitors. Nobody steals a password or changes a file. The site is simply buried.
This guide follows the attack in order. It starts with the first infected device, moves to the command server that directs the botnet and the flood itself, and ends with the moment real users stop getting responses. Along the way you will learn the three main attack types, the signs that one is happening, and the layered defences that keep a site standing.
- Malware turns poorly secured devices, such as routers with factory passwords, into bots.
- A command-and-control (C2) server sends a single order to the whole botnet.
- Floods exhaust one of three limits: bandwidth, connection tables, or server resources.
- A traffic spike, many source IPs, and timing-out users together point to a DDoS.
- Defend in layers: upstream filtering, a CDN, rate limiting, a response plan, and a firewall.
- 0:00Intro
- 0:28What you'll achieve and need
- 1:14Trace how devices become bots
- 2:06Follow how attackers command the botnet
- 2:54Compare the three attack types
- 3:55Watch the traffic converge
- 4:45Spot the signs of an attack
- 5:30Avoid the common mistakes
- 6:11Layer your defences
- 6:50The attack in five points
- 7:28A DDoS is a flood, not a break-in
Check the networking basics you need first
This is a conceptual walkthrough, so you do not need to install anything. The goal is to describe every stage of an attack and recognise the signs that one is under way. To get there, a few networking ideas help, because each one explains a limit that an attack tries to push past.
Most people start with one question: how can plain traffic take down a site that nobody hacked? Every server has limits. It can only receive so much data, hold so many open connections, and process so many requests at a time. A DDoS attack does not need a security hole. It only needs enough traffic to exceed one of those limits.
- IP addresses: what they identify on a network
- TCP handshakes: how a connection is opened
- DNS lookups: how names are turned into addresses
- Web server request handling: how each request is processed as it arrives
Trace how ordinary devices become bots
Every attack begins long before the flood, with the quiet work of building an army. Picture a home router whose login page at 192.168.1.1 still accepts the factory username and password, admin and admin. Malware scans the internet for devices like this, signs in, and installs itself. The owner notices nothing.
Weak defaults are the way in. Many IoT devices ship with shared passwords and rarely receive firmware updates, so one automated scan can find a huge number of them. The infection stays silent because the device keeps working. The camera still films and the router still routes, with a small extra program running in the background.
The device becomes a bot when that program starts listening for remote orders. At this stage nothing looks like an attack, and that is the point. Every unpatched device online is a potential recruit.
- Change factory usernames and passwords on routers, cameras, and DVRs
- Keep device firmware up to date
- Remember that a working device can still be infected
Follow how attackers command the botnet
Infected devices are useless to an attacker until they can be told what to do. That is the job of the command-and-control server, usually called C2. The attacker never talks to each device directly. They send orders to the C2 server, which passes them to the IoT cameras, home routers, and smart DVRs in the botnet, and each bot reports back.
Bots "phone home" by contacting the C2 server on a schedule and waiting for instructions. This keeps the network ready without producing any visible attack traffic. Because one command reaches every bot, a single order such as a target address can set thousands of devices moving at once, while the attacker stays far away from the target.
This structure also shows a weak point. The whole botnet depends on the C2 link, so blocking the command server breaks the chain between the attacker and the bots.
- Bots check in with C2 regularly
- One order reaches the entire botnet
- Cutting off C2 stops new commands from arriving
Compare the three types of DDoS attack
Once the botnet has its orders, the attacker chooses how to hurt the target. There are three main families, and each goes after a different limit. That choice decides what defenders will see. Volumetric floods target bandwidth at the network layer. A raw traffic flood sends more data than the link can carry, so nothing else gets through, and it shows up as an obvious surge.
Protocol attacks target connection tables at the transport layer. The classic example is a SYN flood, which abuses the TCP handshake. Bots send the first step of the handshake again and again but never finish it. The server holds each half-open connection open while it waits, until its table is full.
Application floods target server resources at the application layer. An HTTP request flood sends many valid-looking requests, often for heavy pages. These are the hardest to spot, because each request looks like it comes from a normal user.
- Volumetric: bandwidth, network layer, obvious surge
- Protocol (SYN flood): connection tables, transport layer, half-open connections
- Application (HTTP flood): server resources, application layer, normal-looking users
Watch the traffic converge on one target
When the botnet fires, traffic from every bot reaches the same target at the same moment. The server fails when one limit runs out. It is never hacked. The useful question is which limit gives way first.
Bandwidth is the first ceiling. When the network link is saturated, even a healthy server cannot receive requests, because they never arrive. Whatever gets through reaches the connection table. Once every slot holds a half-open connection, new visitors are refused, even though the server itself may be idle. The little traffic that remains reaches the server, where heavy application requests use up CPU and memory until nothing is left for real users.
In every case the result looks the same from outside. The site goes offline because it is busy, not because someone broke in.
- Saturated link: requests never reach the server
- Full connection table: new visitors are refused
- Exhausted CPU and memory: the server cannot respond
Spot the signs of a DDoS attack
A flood leaves recognisable traces, and if you can name them you can recognise an attack early. On the server, a packet capture shows connection attempts arriving. In the example below, three different source addresses all send a SYN flag to the same port, 443. Meanwhile, real users report that their requests are timing out.
The first sign is a traffic spike that is sudden, steep, and unexplained, with no campaign or news to account for it. The second is many source IPs. A normal surge has a pattern, while a flood arrives from thousands of addresses all over the world, all aimed at one target. The third is the real damage: legitimate visitors get no answer. If all three appear together, treat it as a DDoS, not a bug.
- Is there a sharp traffic climb with no obvious cause?
- Are requests coming from an unusually large spread of source IPs?
- Are many SYN packets arriving without completed connections?
- Are legitimate users reporting timeouts?
sudo tcpdump -nn -c 3 'tcp port 443'Avoid the common DDoS defence mistakes
Most failures come from planning too little, not from the attack itself. The biggest mistake is relying only on a firewall. A flood can fill your network link before the firewall ever sees the traffic, so it needs help further upstream. The fix is to add upstream filtering and a CDN.
Another mistake is setting no limits, so every client can make unlimited requests. That is easy to abuse, and the fix is rate limiting per client. A third is having no plan. When nobody knows who acts during a flood, time is lost, so write a response plan before you need one.
Finally, avoid the wrong guess. A flood looks like an outage, not an intrusion. Read the traffic graphs before hunting for a break-in, because they tell you which problem you face.
- Firewall only → add upstream filtering and a CDN
- No request limits → apply rate limiting per client
- No plan → write a response plan in advance
- Hunting for a hack → check the traffic graphs first
Layer your defences against a flood
No single tool stops every kind of flood, so the best practice is to stack defences, with each layer covering a gap in the others. The principle is simple: the further out you filter, the less your server has to absorb. Put protection upstream, where the flood is still far from you.
Upstream filtering removes junk traffic before it reaches your network. A CDN spreads the load across many locations, so no single link takes the full force. Rate limiting caps what any one client can ask for, which helps against application floods. A response plan says who does what when an attack starts. The firewall still has a role, handling whatever slips through the outer layers. Together, these make the attacker's job much harder.
- Upstream filter in place before traffic reaches you
- CDN distributing load across locations
- Rate limits set per client
- Written response plan with clear owners
- Firewall as the inner layer, not the only one
Key takeaways
- A DDoS is a flood, not a break-in: it overwhelms limits rather than exploiting a security hole.
- Botnets are built from devices with weak defaults and old firmware, infected silently.
- A C2 server lets one command reach the whole botnet, and blocking it breaks the chain.
- Volumetric, protocol, and application floods each exhaust a different limit and look different.
- A spike, many source IPs, and user timeouts together signal an attack.
- Defend in layers and filter upstream instead of relying on a firewall alone.
Frequently asked questions
Can a DDoS attack take down a site without hacking it?
Yes. A DDoS attack sends more traffic than the site can handle, so it runs out of bandwidth, connection slots, or CPU and memory. Nothing is broken into, but real users can no longer get a response.
What is a botnet in a DDoS attack?
A botnet is a group of infected devices, often IoT cameras, home routers, and DVRs, that an attacker controls remotely. Malware gets in through weak defaults such as factory passwords, and the devices keep working normally while they wait for orders.
What is the difference between a SYN flood and an HTTP flood?
A SYN flood is a protocol attack. It starts TCP handshakes and never finishes them, so the server's connection table fills up. An HTTP flood is an application attack that sends many valid-looking requests for heavy pages, which uses up server resources and is harder to tell apart from normal users.
How do I know if my site is under a DDoS attack?
Look for three signs together: a sudden, unexplained traffic spike, requests from a very large number of source IPs, and legitimate users timing out. A packet capture showing many SYN packets from different addresses to the same port is another clue.
Is a firewall enough to stop a DDoS attack?
Usually not on its own. A volumetric flood can fill your network link before the firewall sees the traffic. Combine it with upstream filtering, a CDN, rate limiting, and a response plan.
