Europol announced in December 2024 that another round of Operation PowerOFF had taken offline a batch of DDoS-for-hire platforms, the booter and stresser sites that rent out attack capacity by the month. Those takedowns matter for a reason that gets lost in most explainers: they target the supply of distributed capacity. And the difference between DoS and DDoS, once you move past the textbook line about one source versus many, is mostly a question of what that distribution does to your defences, your logs and your bill.
The definition itself takes a minute. What it changes on the ground takes rather longer, and that is where most guides stop.
DoS vs DDoS: the definition, settled in 60 seconds
A denial of service (DoS) attack comes from one source, or a small handful. A distributed denial of service (DDoS) attack comes from many hosts at once, typically a botnet of compromised machines, cameras and routers, or a rented booter service that owns or brokers that capacity on the attacker’s behalf.
Note what the word “distributed”does not mean. It is not a measure of size. A single misused reflector, pointed at you by one attacker on a laptop, can generate more traffic than a small botnet of a few hundred infected home devices. During the memcached reflection attacks of early 2018, Cloudflare reported amplification factors of up to roughly 51,000 times the attacker’s own outbound traffic; the 1.35 Tbps flood that hit GitHub on 28 February 2018 used the same technique. One attacker. Thousands of unwitting third-party servers doing the shouting.
Which is exactly where the clean definition frays. Reflection and amplification collapse the distinction: the traffic arriving at your edge is distributed across tens of thousands of source addresses, while the person responsible is a single operator. Your packet captures will say DDoS. The investigation, if there is one, is chasing one human.
What both shapes share is the objective. Neither is trying to steal data. Both are trying to exhaust a finite resource, and the resource varies: upstream bandwidth, the firewall’s connection table, application worker threads, database query capacity, or the queries-per-second your authoritative DNS servers can answer. Exhaust any one of them and the service is down, regardless of how healthy everything else looks.
What the difference between DoS and DDoS changes in practice
Traceability and what you can actually block
Single-source traffic is a problem you can often solve yourself. One address, one netblock, an access control list at the edge router, and the incident is over in minutes. Distributed traffic from forty thousand addresses spread across hundreds of autonomous systems is not a blocklist problem. By the time your team has scripted the first few thousand entries, the botnet has rotated, and you have spent your outage writing firewall rules.
Detection signatures differ in the same way. A DoS attack tends to look flat and repetitive: the same source, the same user agent, the same request pattern, hour after hour. A distributed attack looks like a sudden, broad rise across many geographies and networks at once, often with traffic that is individually unremarkable and collectively fatal.
Mitigation economics
A genuine single-source DoS rarely justifies paid scrubbing. You already have the tools. A distributed attack can saturate your upstream circuit before a single packet reaches the on-premises appliance you bought to stop it, which is the uncomfortable arithmetic behind most scrubbing contracts: if the pipe fills, nothing you own on your side of it is in the fight.
What you can hand to a lawyer, an insurer or the police
Be realistic here. A single-source attack gives you an IP address, timestamps and a traffic sample, which is something a law enforcement referral can work with, assuming the source is not itself a compromised third party. A distributed attack usually gives you an aggregate picture and little else; attribution tends to arrive later, through infrastructure takedowns and informants, not through your logs. Insurers and regulators generally want the same thing in both cases: timeline, impact, duration, and evidence that you had a response plan and followed it.
Three attack surfaces, two attack shapes
Here is the judgement most buyers get wrong. Protection gets assessed on one surface, usually the web tier, and signed off as if that covers the estate. It does not. Three surfaces get attacked, and each behaves differently depending on whether the traffic is single-source or distributed.
Network and transport layer
Volumetric floods, SYN floods and reflection using open UDP services. Distribution matters most here because the contest is about raw capacity, and capacity is what a botnet or a reflector swarm brings. Source address validation at the network edge, the practice set out in BCP 38 (RFC 2827), would strangle most reflection at birth if it were universally deployed. It is not, which is why the technique still works more than two decades on.
Application layer
This is the quiet one. A slow-read or slow-POST attack from a single host opens connections, sends headers at a crawl, and holds worker threads hostage at request rates so low that no volumetric threshold notices. Slowloris, published by Robert Hansen in 2009, is older than some of the kit sold to stop it. The modern variant is cheaper still: find the most expensive endpoint on the site, usually faceted search, a report generator or a checkout step that hits the database hard, and request it a few times a second from one machine. Modest traffic. Catastrophic cost per request.
Authoritative DNS
The layer most often left unmanaged, and the one that produces the strangest incident calls. A query flood against your authoritative DNS servers takes the site offline without a single packet reaching your web servers. Your monitoring shows normal CPU, normal memory, normal response times, and a support queue filling with customers who cannot resolve the name at all. The Dyn incident of 21 October 2016, driven by the Mirai botnet, put a long list of well-known services out of reach while their own infrastructure sat perfectly healthy.
Audit all three, and audit them separately. Ask who owns DNS, whether it is on the same provider as your scrubbing, how many distinct networks answer for your zone, and what happens if the registrar account holder is on annual leave. For the reflection side of the problem specifically, the mechanics and the realistic countermeasures are covered in more detail in this piece on what actually works against DNS amplification.
Why single-source attacks still get through modern defences
Thresholds are the first reason. Detection tuned for volumetric traffic, measured in gigabits or packets per second, will never trigger on a well-formed stream of a few hundred legitimate-looking requests a minute. The attack is invisible to the sensor because the sensor is watching the wrong dimension.
Origin exposure is the second. If your origin IP address is discoverable through old DNS records, mail headers, certificate transparency logs or a forgotten staging host, an attacker can step around the proxy entirely and hit the server directly from one machine. Plenty of organisations pay for a cloud service that never sees the traffic that takes them down.
Stateful devices are the third. Firewalls, load balancers and VPN concentrators hold a connection table, and connection tables are finite. They fail at a fraction of the traffic required to fill the circuit, which means the device bought to protect the service is frequently the thing that breaks first.
Then there is the blunt instrument. ISP blackhole routing, remotely triggered black hole filtering as described in RFC 5635, drops all traffic to the targeted prefix upstream. It protects the carrier’s other customers admirably. It also completes the attacker’s objective on their behalf, free of charge. Treat it as a last resort to save the wider network, never as your mitigation plan, and find out in advance whether your provider will apply it without asking you. Where a carrier’s protection stops is a conversation worth having before an incident, not during one, and the practical limits of ISP-provided DDoS protection are worth reading before that call.
Choosing protection when you cannot predict which you will face
Always-on or on-demand
On-demand mitigation diverts your traffic to a scrubbing centre once something trips a trigger. Always-on routes it through the scrubbing path permanently. The trade is time-to-mitigate against diversion cost and a little added latency, and the headline SLA number on the datasheet answers almost none of the real question.
Ask three things instead: what event starts the diversion, who is authorised to start it at three in the morning, and how many seconds pass between detection and clean traffic coming back. Then apply the point most vendors will not volunteer. Single-source application-layer attacks are precisely what on-demand handles worst, because the traffic never reaches the volume that starts the diversion in the first place. The attack that most needs scrubbing is the one least likely to summon it. For a walk through how the diversion mechanics work in practice, see this explanation of how cloud scrubbing services really operate.
What a Tbps figure does and does not tell you
Advertised scrubbing capacity is a network-wide aggregate. It is not the capacity of the point of presence that will actually take your traffic, and it is certainly not the capacity reserved for you during a multi-customer event. The useful questions are narrower: which scrubbing location serves your users, what it can absorb on its own, and how capacity is allocated when three customers are under attack simultaneously. Ask for the regional number in writing. How much Tbps capacity you genuinely need is a smaller figure than the marketing implies, and a more specific one.
Build the case from downtime, not from fear
Boards do not approve spend because a record attack happened to somebody else. They approve it against cost of downtime per hour, modelled from transaction value, contractual service credits, staff cost and the recovery tail. UK managed DDoS pricing is typically structured as a commitment plus overage, so the headline monthly figure is rarely the whole bill; model the clean-traffic allowance, the overage rate, the minimum contract term and any per-incident or emergency onboarding charges before signing anything. That modelling is set out in more detail in this board-ready DDoS protection business case.
A short readiness checklist
- A written runbook naming who declares an incident and who signs off diversion, with out-of-band contact details for your ISP and mitigation provider
- DNS TTLs short enough to re-point quickly, verified rather than assumed, and tested at least once
- Monitoring that watches DNS resolution and application response times, not just web server CPU
- An inventory of every public IP address, including legacy and staging hosts that expose the origin
- One rehearsal a year, ideally with the provider on the call, because escalation paths rot quietly
The National Cyber Security Centre publishes free denial of service guidance covering preparation and response, and it is a sensible baseline for the runbook.
Ransom threats, hacktivists and who launches which kind
Most serious incidents are distributed rather than single-source for a dull commercial reason: distributed capacity is cheap to rent. Booter and stresser services market themselves as stress-testing tools, take card and cryptocurrency payments, and require no skill at all from the buyer. The National Crime Agency went as far as running fake booter sites in 2023, collecting the details of would-be customers and warning them off, precisely because the entry price had dropped so low.
Extortion notes follow a pattern. A demand arrives claiming a devastating attack is imminent unless payment is made, sometimes with a short demonstration burst attached. Verify the demonstration before you take the demand seriously; a good proportion of these notes are sent speculatively to hundreds of organisations with no capability behind them, and the traffic logs will tell you whether anything actually arrived. Hacktivist campaigns behave differently again, announcing target lists publicly and favouring short repeated bursts across many sites, which makes the duration of an individual outage shorter but the recurrence higher.
On the law, the source count is irrelevant. Under the Computer Misuse Act 1990, section 3 covers unauthorised acts with intent to impair the operation of a computer, and it applies whether the traffic came from one laptop or a rented botnet. Section 3A covers making, supplying or obtaining articles for use in such offences, which is how buying a booter subscription becomes chargeable in its own right. Penalties under section 3 run to several years’ imprisonment on indictment. Intent is the offence, not the architecture.
Frequently Asked Questions
What is the main difference between DoS and DDoS attacks?
A DoS attack originates from one source or a very small number; a DDoS attack arrives from many hosts simultaneously, usually a botnet or a rented booter service. The practical consequence is that single-source traffic can often be blocked at your own edge, while distributed traffic cannot be handled with blocklists and frequently exceeds your upstream capacity before your own equipment sees it.
Can a single computer really take down a business website?
Yes, if it targets the right resource. Slow-read and slow-POST techniques hold application worker threads open at request rates low enough to look like ordinary browsing, and a single host hammering an expensive search or checkout endpoint can exhaust database capacity without producing noticeable bandwidth. Stateful firewalls and load balancers also fail on connection-table exhaustion long before the circuit fills.
Is a DDoS attack harder to stop than a DoS attack?
Usually, because you cannot filter tens of thousands of rotating sources manually and the volume may saturate your link upstream of anything you control. Single-source application-layer attacks are not the easier problem in every case, though; they often slip under detection thresholds entirely, which means nothing triggers and nobody is alerted.
Does a firewall protect against DoS and DDoS attacks?
Only partially, and it can make things worse. A firewall will drop traffic from a single identified source happily enough, but its connection table is finite and is itself a target; under a distributed flood the firewall is frequently the component that fails first. It also does nothing about a flood aimed at your authoritative DNS, where the traffic never reaches your network at all.
Are DoS and DDoS attacks illegal in the UK?
They are. The Computer Misuse Act 1990 makes unauthorised acts intended to impair the operation of a computer an offence regardless of how many machines were used, and obtaining or supplying tools for that purpose is separately chargeable, which includes paying for a booter service. UK agencies have pursued both operators and customers of DDoS-for-hire platforms through Operation PowerOFF.
If you are working out which of the three surfaces is least covered in your own estate, that audit is the better use of an afternoon than another definition. The ongoing DDoS news and analysis here tracks vendor changes, incidents and the enforcement side as they land.