A reader-friendly model of how DDoS attacks actually work. Companion to ddactic/attack-effectiveness-matrix, which contains the per-vector effectiveness ratings.
The taxonomy is built around three claims:
- Every DDoS attack exhausts one of exactly 5 resources. Bandwidth, connections, streams, requests, or application logic. Lower levels need more volume; higher levels need less but hit harder. Section 01.
- The HTTP version is the single biggest variable in attack success. The same 10,000 RPS looks like 10,000 connections on HTTP/1.0 and 10 on HTTP/2. Section 02.
- There are 23 fundamental server-side mechanisms. The industry markets them as 3 categories. We split them into 23 because each one needs a different detection signal and a different mitigation. Section 03.
| File | What you get |
|---|---|
| 01-resources.md | The 5 resources to exhaust, with volume/damage trade-offs. |
| 02-http-versions.md | Why HTTP/2 and HTTP/3 hide attacks from L4 firewalls. |
| 03-mechanisms-index.md | Master index of the 23 mechanisms. Drills into the family files below. |
| families/volumetric.md | 3 mechanisms that fill the pipe. |
| families/state-protocol.md | 12 mechanisms that exhaust connection / stream state. |
| families/application.md | 8 mechanisms that exhaust application logic and parsers. |
| families/protocol-services.md | Non-HTTP protocol services (SIP, SMTP, SSH, LDAP, MQTT, Modbus, RTSP, XMPP). |
| mitigations/volumetric.md | Defender configurations for the volumetric family (M-01, M-02, M-17). |
| mitigations/state-protocol.md | Defender configurations for state and protocol attacks (M-03..M-12, M-14, M-23). |
| mitigations/application.md | Defender configurations for application-layer attacks (M-13, M-15..M-21). |
| mitigations/protocol-services.md | Defender configurations for non-HTTP protocols (M-22). |
| 04-detection-blind-spots.md | Where standard defenses are blind, by resource x HTTP version. |
| 05-ddos-formula.md | The 5-component model that decomposes any DDoS attack. |
| 06-protocol-paradox.md | Why better protocols are simultaneously safer AND more dangerous. |
| 07-vendor-findings.md | What aggregate testing of 10 cloud CDN/WAF vendors reveals about industry-wide blind spots. |
| 08-architecture-guide.md | Buyer's lens on each protection architecture (cloud CDN, on-prem WAF, DDoS appliance, hybrid). |
| glossary.md | One-line definitions for every term used in the taxonomy. |
| mechanism-to-matrix.md | Cross-link table: each M-XX mechanism mapped to specific vector IDs in the effectiveness matrix. |
| CITATIONS_USING_THIS.md | Papers, blogs, and reports that cite this taxonomy. |
Each mechanism page lists the vector IDs in the matrix that implement that mechanism. Example:
M-11 H/2 Stream Churn is implemented by the matrix vectors
l7_http2_rapid_reset,l7_http_2_rst_loop. Look up the per-architecture effectiveness ratings indata/attack_effectiveness_matrix.jsonundervectors.<id>.
The opposite direction also works: every vector in the matrix has a taxonomy_id field whose layer prefix (L3 / L4 / L7 / Protocol) and number anchor it back to a mechanism here.
The matrix also publishes (in v3.1) a defender-side architecture_modifiers section that captures 14 deployment dimensions beyond the 6 base architectures: always-on vs on-demand, API controllability, origin scaling class, rate-limit basis, private tunnels, IPv6 parity, behavioral baseline maturity, and others. Use those modifiers to compose a more accurate effective rating for your specific deployment than the base architecture column alone can give.
This taxonomy is derived from DDactic's research notes and from the ddos-anatomy.html interactive page on the commercial site. The Markdown form here is the canonical, citable version.
The text under this repository is licensed CC-BY-4.0. Code (none today, but reserved) under MIT. See LICENSE.
If you cite this in academic work, see CITATION.cff.
PRs welcome. New mechanisms, clarifications, additional cross-links to the matrix, and better diagrams are all in scope. See CONTRIBUTING.md.
This is a defensive reference. It explains what attacks do and where defenses are blind so that defenders can plan. It is not an offensive playbook. Do not test against systems you do not own or have permission to test.