DDoS attacks: how they work and how to defend

A DDoS attack, short for Distributed Denial of Service, is an attempt to make a system, service, or network unavailable by flooding it with traffic from many sources at once. The attacker directs a large number of compromised devices to send requests at the same instant, until the target runs out of bandwidth, connections, or processing capacity and stops responding to real users. The attack does not break into anything or read any data. It simply takes the service away. For a regulated company running banking portals, patient systems, trading APIs, or a SaaS product, that absence of service is the damage: every minute offline is lost revenue, broken contracts, and lost trust.

Availability is one of the three pillars of security, alongside confidentiality and integrity, and DDoS is the cleanest attack on that pillar. It matters to regulated firms for a second reason. Under the NIS2 Directive (EU) 2022/2555 and the DORA Regulation (EU) 2022/2554, keeping essential services running is a legal duty, and a significant outage can be a reportable incident. So a DDoS attack is not only an operations problem for the network team. It is a security event, a continuity event, and potentially a regulatory event at once. This guide explains how DDoS works, how it differs from a simple DoS, the three layers attackers hit, how to tell an attack from a legitimate spike, how to build layered defense, and how to respond.¹

DDoS is one of the most common ways an online service is knocked offline, and it is rarely a lone problem. We build the detection, absorption, and response that keep it under control through threat detection and response.

DDoS versus DoS: what the extra D changes

A DoS attack, plain Denial of Service, comes from a single source. Because the traffic comes from one place, defense is straightforward: identify the source address and block it, and the attack ends. A single attacker also has limited bandwidth and connections to throw at you, so the ceiling on the damage is low.

A DDoS attack is distributed. The traffic comes from hundreds, thousands, or millions of devices at once, coordinated by the attacker. You cannot block one address, because the traffic arrives from countless addresses scattered across the world, many belonging to innocent owners. The combined bandwidth of a large botnet dwarfs what any single machine could produce, so it can saturate even well-provisioned links, and every blocked source is replaced by ten more.

The devices in a botnet are rarely owned by the attacker. They are ordinary machines, often poorly secured home routers, cameras, and other connected devices, taken over without their owners noticing. Worse, DDoS is now sold as a service. Anyone with a grievance and a small budget can rent an attack against almost any target, with no technical skill required, which removes the comforting idea that you are too small to be hit.

The three attack layers

DDoS attacks are grouped by the layer of the stack they target, and the distinction is not academic. Each layer calls for a different defense, and many real attacks combine two or three layers at once to overwhelm the defenses that handle each in isolation.¹

Volumetric attacks are the loudest and easiest to recognize, because they simply try to fill your connection, and they are absorbed upstream before the traffic ever reaches your own links. Protocol attacks are quieter. Instead of filling the bandwidth, they exhaust the finite resources of firewalls, load balancers, and servers, for example by opening half-open connections faster than the server can clear them.

Application-layer attacks, at Layer 7 of the OSI model, are the hardest to handle. Each request can look exactly like something a real customer would send, a search query, a login attempt, a product page request, so blunt volume filtering risks blocking paying customers along with the attack. They also need far less traffic to do damage, because a single expensive request such as a complex database search costs the server far more than it costs the attacker. Telling friend from foe here takes behavioural analysis, not just packet counting.

Why attackers do it

Understanding the motive helps you read an attack and respond proportionately. DDoS is launched for a handful of recurring reasons that call for different reactions.

• Extortion: the attacker proves it can take you offline, then demands payment to stop. This is sometimes called a ransom DDoS or RDoS, and it often arrives with a deadline and a threatening note.
• Competition or grudge: a competitor, a former employee, or an activist takes your service down during a critical window such as a product launch, a sale, or a market open, to cause direct commercial harm.
• Cover for another intrusion: the flood is a smokescreen. While your team is consumed by the outage and your logs are buried in noise, the attacker carries out a quieter, more damaging breach elsewhere.
• Disruption for its own sake: hacktivism, intimidation, or proving a point against a chosen target, with no demand attached.

The third motive is the one regulated firms underestimate most. Treating a DDoS purely as a network nuisance, and pulling every analyst onto the outage, is exactly what an attacker using it as a distraction wants. A DDoS event should always raise the question of what else is happening while attention is elsewhere, which is one reason it connects directly to ransomware and other intrusions where the flood is the opening move, not the whole attack.

Attack or legitimate traffic spike?

Not every surge is an attack. A marketing campaign, a press mention, a viral post, or a flash sale can all send genuine traffic far above baseline. Reacting to legitimate demand as if it were hostile, by aggressively rate limiting or blocking regions, turns a good day into a self-inflicted outage. So the first job when traffic spikes is to read the signals and decide which it is.

Legitimate spikes have a story behind them and a recognizable shape. The traffic ramps up rather than appearing instantly, it comes from your expected markets and real browsers, it follows referrers you can identify such as a campaign link or a news site, and the requests spread naturally across your pages while conversions still look human. There is a business reason you can name.

An attack reads differently. It often appears suddenly with no campaign or event behind it. The sources are unusual: large volumes from regions you do not serve, from data-centre and cloud IP ranges rather than home and mobile networks, or from outdated user agents. The requests concentrate on one expensive endpoint, or repeat an identical pattern no real user would, and engagement collapses while raw request counts climb. When the traffic has no business explanation and the shape is mechanical, treat it as an attack until you have ruled it out.

Layered defense

There is no single product you switch on to stop DDoS. A real defense is layered, with each layer covering what the others cannot, and it is built before the attack arrives. Once the flood is pouring in, there is no time to procure a service, reconfigure architecture, or learn the tools. The work is done in advance so the response is execution, not improvisation.²

• CDN and traffic scrubbing: route traffic through a content delivery network and a scrubbing provider with the capacity to absorb volumetric floods upstream, then clean the traffic and forward only the legitimate part to you.
• Rate limiting: cap how many requests a single client can make in a window, and throttle or challenge sources that exceed sane thresholds, to blunt protocol and application-layer floods.
• Resilient architecture: remove single points of failure, spread services across multiple regions and providers, and design so the loss of one path does not take the whole service down.
• Autoscaling: let critical paths scale out under load where the platform supports it, so a moderate surge is met with capacity, while keeping cost controls so scaling is not itself abused.
• Web application firewall (WAF): inspect Layer 7 traffic, apply behavioural rules, and filter the malicious requests that look like real users, which volume-based defenses cannot distinguish.

None of these layers work alone. Edge scrubbing without monitoring leaves you blind to whether it is holding. A WAF with no tuned rules either lets attacks through or blocks customers. Autoscaling without cost controls turns an availability attack into a budget attack. The layers reinforce each other, which is why DDoS resilience belongs inside threat detection and response rather than being treated as one appliance. It overlaps with how you defend against malware on the same edge, since the infected devices that form botnets are the supply chain for these attacks.

You cannot build a DDoS defense during a DDoS attack. The capacity, the rules, and the decisions all have to exist before the first packet arrives.

A response plan and who is involved

Even with strong defenses, a large or novel attack can still cause disruption, so you need a rehearsed plan for the moment one lands. The plan should name people and decisions, not just tools, so that under pressure nobody is improvising about who has the authority to act. The steps below describe a workable sequence, and the people who carry them out should be agreed in advance as part of your incident response plan.

1. 01
   Detect and confirm

   Monitoring or an on-call engineer flags the availability drop and confirms it is an attack rather than a spike or a failure, by checking traffic sources, shape, and business context.
2. 02
   Declare and assemble

   The incident lead declares an incident and pulls in the network and security operations team, the application owners, and a communications contact, with one person clearly in charge.
3. 03
   Engage mitigation

   Activate the scrubbing service or CDN protection, tighten rate limits and WAF rules, and route traffic through the defenses, keeping a record of every change made.
4. 04
   Communicate

   Tell customers honestly through a status page, and keep internal stakeholders and, where the threshold is met, regulators informed in line with NIS2 and DORA reporting duties.
5. 05
   Watch for the real target

   While the flood is mitigated, watch the rest of the environment for the quieter intrusion the DDoS may be covering, rather than pulling every analyst onto the outage.
6. 06
   Recover and review

   Confirm service is fully restored, then run a blameless review to capture what worked, what was missing, and which defenses to harden before the next one.

What not to do

Some reactions make a DDoS worse. Two stand out. First, do not pay the extortion demand. Paying funds the next attack, marks you as a paying target, and gives no real guarantee the attack stops. Security agencies are consistent that paying is not a reliable route out, and it strengthens the criminal economy behind the attack. Engage your defenses and your plan instead.

Second, do not panic and shut the service down yourself. Pulling the plug achieves exactly what the attacker wanted: your service is offline, by your own hand. The aim is to keep critical services available through the flood, not to confirm the outage. Avoid sweeping blocks under pressure too, such as banning whole countries or all cloud ranges, because that often cuts off real customers and partners.

Availability, continuity, and NIS2

A DDoS attack is, at its core, an availability problem, the same ground covered by business continuity and disaster recovery. The plan that defines how you keep critical services running through disruption should account for a deliberate flood of traffic, not only hardware failure or a data centre going dark. Availability is part of security, not separate from it, and an attacker who can take your service offline can do real harm without ever touching your data.

For regulated firms the duty is explicit. The NIS2 Directive (EU) 2022/2555 requires essential and important entities to manage risks to the availability of their services and to report significant incidents, and a serious DDoS outage can meet that threshold. DORA places parallel obligations on the financial sector. So DDoS resilience is not discretionary; it is part of demonstrating that you can keep services running and report when you cannot. Our guide to NIS2 compliance sets out how availability fits the wider obligations, and NIS2 explained covers who is in scope.

How Raptoric helps

We help regulated companies build layered DDoS defense and a rehearsed response, so an attack is absorbed rather than allowed to take the business offline, through threat detection and response. When an attack is already underway, our incident response team helps you mitigate, communicate, and watch for the quieter intrusion behind it. Book a scoping call.