DDoS vs DoS: what is the difference?

02DoS vs DDoS at a glance

The table summarises the practical consequences of the single-source versus many-source split.

03What a single-source DoS looks like

Not every denial of service needs a botnet. RFC 4732, the Internet Architecture Board's denial-of-service considerations memo from 2006, notes that "there are also many cases where a single well-connected end-system can perpetrate a successful DoS attack". Two patterns do this without volume.

The first is an application bug or expensive operation: one request that makes the server do far more work than the request cost to send. Historic examples carry CVE identifiers — the 2011 Apache byte-range flaw (CVE-2011-3192) let Range headers listing many overlapping ranges exhaust memory and CPU, and a PHP hash-collision flaw the same year (CVE-2011-4885) let a POST body full of colliding parameter names burn CPU. One client, a handful of requests, a downed server.

The second is a slow attack. Slowloris (catalogued against Apache HTTP Server as CVE-2007-6750) opens many connections from one host and feeds each a trickle of bytes, holding worker slots open without ever completing a request. It is a denial of service from a single machine that uses almost no bandwidth — closer in spirit to a Slowloris-style connection attack than to a flood.

• Application-logic DoS: one expensive request (a heavy search, an unbounded export) repeated from one host
• Protocol abuse: a single malformed or oversized message that crashes or hangs the service
• Slow attacks: one host holding connections open indefinitely to exhaust worker slots
• Reflection off one powerful intermediary, which already starts to blur into the distributed case

04Why distribution changes everything

A single source has one uplink, so its maximum output is bounded. A distributed attack sums the output of every participating host, which is how modern floods reach hundreds of gigabits or terabits per second. The traffic also arrives from everywhere, so there is no single talker to pick out of the graph.

Much volumetric DDoS traffic relies on forged source addresses: randomised per packet in direct floods, or set to the victim's address in requests sent to reflectors. Because the attacker never needs a reply, the source field can be anything. RFC 2827 (BCP 38, from 2000) recommends network ingress filtering precisely to make spoofing harder, but it is not universally deployed, so spoofed floods remain common. A botnet of compromised devices supplies the real senders when spoofing is not used.

05Telling them apart from your own logs

You can often classify an incident in seconds by asking one question: is this one talker or many? A single source dominates the top-talker list; a distributed attack spreads thinly across thousands of addresses so no single one looks remarkable. Whether it is an attack at all, rather than a traffic spike or a fault, is a separate question covered in the signs of a DDoS attack.

These read-only commands summarise live sockets and a web access log. They identify the shape of the traffic, not the attacker — the source addresses in a spoofed flood are not trustworthy.

# Socket summary: established, closed and time-wait counts
ss -s

# Half-open TCP connections (SYN received, handshake not finished)
ss -Htn state syn-recv | wc -l

# Top source addresses in an nginx-style access log
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head

# Share of requests held by the single busiest source
awk '{c[$1]++; n++} END {for (ip in c) if (c[ip]>max){max=c[ip]; top=ip}; \
  printf "%s %.1f%%\n", top, 100*max/n}' access.log

# One source near 100% -> DoS.  Share spread thin over thousands -> DDoS.

06What actually defends against each

A single-source DoS is usually fixable at your own edge: patch the expensive endpoint, add rate limiting or connection limits, and block or throttle the one offender. These controls are cheap and effective because there is exactly one thing to stop.

A distributed attack is a capacity problem first. Once a flood saturates your uplink, nothing you configure on the server matters, because the packets are consuming the link before your machine sees them. The practical answer is to put a network with spare capacity in front of the origin — a reverse proxy for web traffic, routed transit for everything else — so the flood is absorbed away from you. That is the core of DDoS mitigation.

A rate limit that works against one source gives false comfort against a distributed one: if every source stays just under the per-IP limit, the limit never triggers while the sum still overwhelms the target. Per-source controls have to be paired with aggregate controls and upstream capacity. The same limit applies to a host firewall, as set out in can a firewall stop a DDoS attack.

07Both are illegal

Scale does not decide legality. Taking a service offline without authorisation is a criminal offence in most jurisdictions whether it comes from one machine or a million. Distributed attacks often attract heavier treatment because of the compromised machines, the organised nature, or the critical systems involved, but a single-source DoS is not a lesser crime for being small.

The specific statutes and penalties are covered in is a DDoS attack illegal, and the booter-and-stresser economy in what an IP stresser is.