DDoS Attacks: How They Work and Why They Cause Website Downtime
A DDoS attack overwhelms server or network resources with traffic from distributed sources, making the target unable to respond to legitimate users. The attack type — volumetric, protocol, or application-layer — determines what gets exhausted and which defenses work.
Every server has finite resources: bandwidth (Gbps), packets per second (Mpps), TCP connection table size, CPU cycles, and application thread pool slots. A DDoS attack targets one or more of these limits by sending more than the server can process. When any resource is exhausted, legitimate requests are either dropped (connection refused) or queue indefinitely (timeout). The result is identical to the server being down — users cannot reach the service.
The Three Layers of DDoS Attacks (L3/L4 Volumetric, L4 Protocol, L7 Application)
DDoS attacks are classified by which OSI layer they target, because the targeted layer determines the exhausted resource, the attack volume required, and the mitigation approach. A Layer 3/4 volumetric attack needs enormous bandwidth to saturate the target’s internet uplink. A Layer 7 application attack needs only enough request rate to exhaust the server’s CPU or database connections — achievable with far less bandwidth but far harder to distinguish from legitimate traffic.
Volumetric Attacks — Bandwidth Exhaustion
Flood the target’s internet uplink with raw packet volume (UDP floods, ICMP floods, DNS/NTP/memcached amplification). When inbound bandwidth exceeds the server’s upstream capacity, the ISP drops packets before they reach the server. Legitimate traffic is dropped alongside attack traffic.
Mitigation requires upstream scrubbing (traffic routed through scrubbing centers that filter attack traffic before delivery) or anycast distribution (Cloudflare, Akamai spread attack volume across 300+ PoPs).
Protocol Attacks — Connection State Exhaustion
Exploit TCP handshake mechanics to exhaust the server’s connection state table. SYN flood: attacker sends TCP SYN packets with spoofed source IPs; server allocates state for each half-open connection waiting for the ACK that never arrives; connection table fills up; new legitimate connections are refused.
Mitigation: SYN cookies (server encodes state into the sequence number, requiring no allocation until the handshake completes), stateful firewall rate limiting, upstream volumetric filtering at the CDN or ISP level.
Application-Layer Attacks — CPU & Thread Pool Exhaustion
Send legitimate-looking HTTP requests at a rate that exhausts server CPU, database connection pool, or application thread capacity. A GET request to a search endpoint that executes a complex database query costs 50ms of CPU. 200 concurrent such requests saturate an 8-thread server’s thread pool. Each subsequent request queues, increasing response time until the server becomes non-responsive to all users.
The attack requires no amplification factor and no high bandwidth — a moderate botnet of 10,000 devices each sending 10 requests/second generates 100,000 req/s, easily overwhelming most application servers. Mitigation requires distinguishing attack traffic from legitimate traffic: behavioral analysis, IP reputation, JavaScript challenges, CAPTCHA, rate limiting per IP or session.
DDoS Attack Types: UDP Flood, SYN Flood, HTTP Flood, Slowloris, Amplification
Each DDoS attack type exploits a specific protocol weakness or resource constraint. Understanding the mechanism of each attack type explains why standard defenses work against some attacks but not others, and why application-layer attacks are disproportionately difficult to mitigate without affecting legitimate users.
UDP Flood
Attacker sends massive volumes of UDP packets to random ports on the target. The server must process each packet to determine there is no application listening on that port, then send an ICMP “Port Unreachable” reply. Both incoming and outgoing bandwidth are saturated.
UDP is connectionless and source IPs can be spoofed trivially, making attribution impossible without upstream ISP cooperation.
DNS / NTP / memcached Amplification
Attacker sends small requests with the victim’s spoofed source IP to open reflectors (DNS resolvers, NTP servers, memcached instances). Reflectors send large responses to the victim.
Amplification factors: DNS ANY queries: ~50× | NTP monlist: ~556× | memcached: ~51,000×. The 2018 GitHub DDoS (1.35 Tbps) used memcached amplification.
SYN Flood
Exploits the TCP 3-way handshake. Attacker sends SYN packets with spoofed source IPs. Server allocates a Transmission Control Block (TCB) for each SYN and sends SYN-ACK, waiting for the final ACK. TCBs never complete; the connection table fills; new legitimate TCP connections are refused with RST or silently dropped.
SYN cookies mitigate this: the server encodes connection state into the sequence number, requiring no memory allocation until the full handshake completes.
HTTP Flood (GET/POST)
Attacker sends valid HTTP GET or POST requests at high rate. GET floods target expensive endpoints (search, product listings, API calls) that trigger database queries. POST floods target login or form submission endpoints, exhausting application threads and database write capacity.
Uses real or rotating user agents and distributed IPs to bypass simple rate limiting. Indistinguishable from a traffic surge without behavioral analysis.
Slowloris
Opens many HTTP connections to the server and sends headers slowly — one byte every 15–20 seconds — keeping connections alive without completing any request. The server’s maximum concurrent connection limit is exhausted by these idle slow connections; new legitimate connections are refused.
Requires minimal bandwidth (under 1 Mbps). Very effective against web servers without connection timeout configuration. Apache is more vulnerable than nginx; nginx limits connection duration by default.
SSL / TLS Exhaustion
Repeatedly initiates TLS handshakes without completing them, forcing the server to perform expensive asymmetric cryptography (RSA/ECDH key exchange) for each request. A single server can only perform ~1,000–5,000 TLS handshakes per second; an attacker can generate far more handshake requests with modest resources.
CDN TLS termination at the edge eliminates this attack vector for CDN-proxied sites — the CDN handles TLS, and the origin only sees completed connections.
How DNS Amplification Works
60-byte query
spoofed src: victim IP
3,000-byte response
Notable DDoS Incidents and Their Scale
Historical DDoS records have grown by three orders of magnitude over two decades, driven by the proliferation of IoT botnets, amplification technique discovery, and the commercialization of DDoS-for-hire services. Each landmark incident revealed a new attack vector or exceeded previous assumptions about achievable attack volume, prompting infrastructure upgrades by major CDNs and ISPs.
Dyn DNS DDoS — Twitter, GitHub, Reddit, Spotify Offline
Mirai botnet (600,000+ IoT devices: cameras, DVRs, routers with default credentials) launched 1.2 Tbps of DNS query floods against Dyn’s authoritative DNS infrastructure. Because Dyn was the DNS provider for Twitter, GitHub, Reddit, Spotify, and hundreds of others, none of those domains could resolve for users globally. Highlighted the concentration risk of shared DNS providers and the IoT security crisis.
GitHub DDoS — 1.35 Tbps via memcached
The largest DDoS at the time, targeting GitHub with memcached amplification (51,000× amplification factor). GitHub’s upstream DDoS scrubbing provider (Akamai Prolexic) absorbed and mitigated the attack in 8 minutes. GitHub experienced ~10 minutes of intermittent degradation. Accelerated the patching and firewall deployment of publicly accessible memcached instances globally.
Cloudflare Record L7 DDoS — 71 Million Requests/Second
The largest HTTP DDoS attack recorded, targeting Cloudflare-protected websites. The attack used 30,000 IP addresses from cloud and VPS hosting providers. Peak 71 million requests per second using HTTP/2 multiplexing (multiple requests per connection). Cloudflare mitigated it automatically using rate limiting and IP reputation at the edge, with no customer impact. Demonstrated that L7 attacks are scaling into the range previously only achievable by L3/L4 volumetric attacks.
HTTP/2 Rapid Reset — 398 Million rps (CVE-2023-44487)
A zero-day vulnerability in HTTP/2 (rapid stream reset) allowed attackers to generate unprecedented L7 attack volumes. By opening and immediately canceling streams on persistent HTTP/2 connections, attackers generated 398 million requests per second with a small botnet. Google, Cloudflare, and AWS all mitigated variants of this attack, with coordinated disclosure in October 2023. Required server patches across all major web server implementations (nginx, Apache, Go, Node.js).
How to Tell If You’re Under DDoS Attack vs an Organic Traffic Spike
A DDoS attack and a genuine viral traffic spike produce identical symptoms from the server’s perspective — resource exhaustion, high response times, and probe timeouts — but require opposite responses. A traffic spike requires scaling infrastructure (auto-scaling, CDN caching, database read replicas). A DDoS requires blocking traffic (rate limiting, IP blocks, CAPTCHA). Misdiagnosing a spike as DDoS and blocking traffic destroys real users’ access; misdiagnosing DDoS as a spike and scaling infrastructure wastes resources and may still fail against sustained attack.
| Signal | ⚠ DDoS Attack | ✓ Organic Spike |
|---|---|---|
| Ramp-up pattern | Instant full volume in seconds | Gradual ramp from a referral, news story, or social post |
| User agent distribution | Identical or rotating synthetic user agents; curl, Python requests, empty UA strings mixed with spoofed browsers | Normal distribution: Chrome, Safari, Firefox, mobile browsers matching your typical user demographics |
| Request path distribution | Concentrated on one or a few endpoints (often the most expensive: search, login, API); identical query strings | Spread across pages matching the source content (all requests to the article that went viral, then navigation) |
| Geographic distribution | Concentrated in ASNs/countries not in your normal user base; unusual AS numbers (cloud VPS providers, residential proxy networks) | Matches the geography of the traffic source (US traffic spike after Reddit post; Asian traffic spike after Product Hunt feature) |
| Referrer headers | Empty, spoofed, or all direct traffic | Referrer matches the source: reddit.com, news site, twitter.com |
| CDN response | Cloudflare may activate Under Attack Mode automatically; high 403 rate in CDN logs | CDN cache hit rate spikes (same page cached and served to thousands of new users without origin requests) |
| Conversion / engagement | Zero conversions; zero page depth; bounce rate 100%; sessions last <1 second | Normal or elevated engagement metrics; users scrolling, navigating, converting |
The diagnostic workflow: check your CDN’s analytics dashboard first. Cloudflare Analytics shows requests per country, top source ASNs, bot vs browser traffic classification, and the breakdown of challenged vs passed requests. A legitimate traffic spike will show high cache hit rates and normal browser fingerprint distributions. A DDoS will show low cache hit rates (attack traffic deliberately bypasses cache with unique URLs), high bot classification rates, and geographic concentrations in unusual ASNs.
How CDNs Protect Against DDoS — and Where They Fail
CDNs are highly effective against volumetric L3/L4 DDoS and moderately effective against L7 HTTP floods, but sophisticated application-layer attacks that mimic legitimate user behavior can bypass CDN mitigations entirely. Understanding the protection model helps set realistic expectations: a CDN is not a magic shield against all DDoS, it is a set of specific mitigations effective against specific attack types.
L3/L4 Volumetric Attacks (UDP floods, ICMP, amplification)
CDN anycast distributes attack traffic across 300+ PoPs globally. No single PoP receives the full attack volume. Cloudflare’s network capacity exceeds 100 Tbps — more than any observed DDoS. Traffic reaching PoPs is processed at the network edge before reaching origin. Legitimate traffic is served from cache. Origin is never exposed to the attack at all because its IP is not public.
L4 Protocol Attacks (SYN flood, TLS exhaustion)
CDN PoPs terminate TCP connections and TLS at the edge. The origin only receives complete, verified HTTP requests — it never sees raw TCP SYN packets or incomplete TLS handshakes. SYN floods and TLS exhaustion attacks are absorbed at the CDN edge without any impact on origin server connection tables.
L7 HTTP Floods (high-rate valid requests)
CDN rate limiting (Cloudflare Rate Limiting rules, WAF rules) blocks requests exceeding per-IP or per-path thresholds. Browser challenges (JavaScript fingerprinting, managed challenge) block scripted clients that cannot execute JavaScript. IP reputation blocks known malicious ASNs. Effective against unsophisticated L7 attacks. Less effective against botnets using residential IPs with real browsers that pass JS challenges.
Sophisticated L7 Application Attacks (low-and-slow, credential stuffing)
Attacks using residential proxy networks (real IPs, real browsers, realistic request timing) are statistically indistinguishable from legitimate traffic at the CDN layer. A botnet sending 5 requests/second per IP from 50,000 residential IPs generates 250,000 req/s total without triggering per-IP rate limits. Credential stuffing attacks using valid usernames/passwords bypass WAF and reach the authentication system. These require application-layer defenses: anomaly detection, session behavior analysis, multi-factor authentication.
Origin IP exposure nullifies CDN protection. If your origin server’s real IP is known to the attacker (from historical DNS records, mail server A records, or SSL certificate transparency logs), the attacker can target the origin directly, bypassing the CDN entirely. Always restrict your origin server’s firewall to accept HTTP/HTTPS only from Cloudflare’s published IP ranges. Rotate your origin IP if it has been previously exposed.
How DownCheck Detects DDoS-Caused Downtime
DownCheck does not detect DDoS attacks directly — it detects the availability impact DDoS causes and provides probe result patterns that distinguish DDoS-caused downtime from other failure types. Because DDoS attacks ultimately manifest as failed probe responses (timeouts, connection refused, 5xx errors), the same probe infrastructure that detects any downtime also captures DDoS-caused downtime.
The probe result patterns during a DDoS incident reveal the attack’s characteristics. During a volumetric L3/L4 attack without CDN protection: both Railway HTTP and Cloudflare Edge probes fail with connection timeouts (the target’s upstream bandwidth is saturated and packets are dropped). DNS probes may still succeed if the attack targets only HTTP ports. During an L7 attack with Cloudflare’s Under Attack Mode active: the Railway HTTP probe receives a Cloudflare challenge page (503 or JS challenge requiring browser execution) which DownCheck records as a non-200 response; the Cloudflare Edge probe (which runs from a Worker, a trusted Cloudflare entity) may receive a 200 from the CDN cache. This pattern — Railway fails + CF Edge succeeds — suggests a CDN protection mode is active, not an origin failure.
For users of DownCheck’s service monitoring dashboard, a DDoS against a major provider (AWS, Cloudflare, Akamai) appears as simultaneous downtime across all services hosted on that provider — the telltale correlated failure signature that distinguishes a provider-level incident from isolated service issues. Compare DownCheck’s real-time probe results against the provider’s own status page and independent probes to confirm whether the downtime is attack-caused or infrastructure-caused.
Immediate actions when you suspect DDoS: (1) Enable Cloudflare Under Attack Mode (Security → Settings → Under Attack). (2) Check Cloudflare Analytics for request source distribution and bot classification. (3) Enable rate limiting on your most expensive endpoints. (4) If attack traffic is bypassing CDN, restrict origin firewall to Cloudflare IP ranges only. (5) Contact your CDN provider’s security team if the attack is sustained at enterprise scale.
Frequently Asked Questions
Is the downtime DDoS or infrastructure?
DownCheck’s multi-probe results distinguish DDoS-caused failures from origin failures, CDN outages, and DNS issues in seconds.
Run a probe now →