System & Network Attacks · Lesson 32
DoS Attacks
A denial of service attack has one goal: make something unavailable. No data theft, no persistence, no escalation — just disruption. Understanding how each type works, how defenders detect them, and how pen testers assess them without causing real outages is what this lesson covers.
DoS vs DDoS — scale changes everything
A denial of service from a single source is relatively easy to handle — block the source IP and the attack stops. A distributed denial of service attack comes from thousands or millions of sources simultaneously. The source-blocking approach becomes useless because the traffic arrives from real machines, most of them compromised household devices that their owners have no idea are participating in an attack.
The 2016 Dyn DNS attack makes this concrete. The Mirai botnet compromised hundreds of thousands of internet-connected CCTV cameras and home routers — not through sophisticated exploitation, but by scanning for devices still using their factory-default credentials. Each device contributed a small amount of outbound traffic. Collectively they generated 1.2 terabits per second directed at Dyn's DNS infrastructure. Twitter, Reddit, Netflix, GitHub, and Spotify went offline for large portions of the United States and Europe for the better part of a day. The attack required no coding skill, no zero-day vulnerability, and no advanced infrastructure — just a credential scanner and a list of known default username-password combinations that millions of device owners had never changed.
That is the lesson Mirai taught the security industry: default credentials on internet-connected devices are not just a misconfiguration affecting the device owner. They are a public infrastructure risk. When enough of them are compromised, the aggregate damage falls on completely unrelated third parties.
The three categories of DoS attacks
DoS attacks are not all the same. They target different parts of the infrastructure stack, require different defence mechanisms, and produce different detection signatures. Understanding which category an attack falls into is the first step in choosing the right defence — and in assessing whether a client's existing controls would handle it.
Volumetric attacks — saturate the connection
Most common DDoS type
Generate enough traffic to fill the target's internet connection — consuming all available bandwidth so legitimate traffic simply cannot get through. The most basic form is a UDP flood: send enormous volumes of UDP packets to random ports, forcing the target to respond with ICMP "port unreachable" messages to each one. At sufficient scale the link is saturated. No sophisticated exploit required — just raw volume.
Amplification attacks are considerably more efficient. Certain protocols return a much larger response than the request that triggered them — DNS, NTP, Memcached, and SSDP all have amplification characteristics. Attackers send small spoofed packets to public servers running these protocols, with the victim's IP as the source address. The servers respond with large replies directed at the victim. A 60-byte DNS query can generate a 3,000-byte response — a 50x amplification factor. With Memcached, the 2018 GitHub attack achieved 51,000x amplification. Attackers achieve terabit-scale attacks without owning terabit-scale infrastructure.
Defence: Upstream scrubbing at the ISP or CDN level. Traffic is redirected to scrubbing infrastructure that absorbs the volume before it reaches the customer's connection. Anycast distribution spreads attack traffic across a global network rather than concentrating it at a single point.
Protocol attacks — exhaust connection state tables
Targets infrastructure limits
These attacks target the connection state tables in firewalls, load balancers, and servers rather than the bandwidth. The SYN flood is the classic example. TCP connections begin with a three-way handshake: the client sends SYN, the server responds with SYN-ACK and allocates memory to track the half-open connection, then waits for the client's ACK. In a SYN flood, the attacker sends SYN packets with forged source addresses. The server sends SYN-ACK to the fake source, gets no ACK back, and holds the half-open connection in memory until it times out — typically 30 to 120 seconds.
Send enough SYN packets and the connection table fills completely. Legitimate connections are refused — not because the bandwidth is saturated, but because the server ran out of memory to track new connections. A modestly sized attack that would barely register as bandwidth anomaly can take down a server by exhausting its state table.
Defence: SYN cookies — the server generates a cryptographic token as the initial sequence number rather than allocating state immediately. Connection state is only allocated once the ACK arrives and the token validates. SYN floods become ineffective because no state is consumed by half-open connections.
Application-layer attacks — exhaust server resources
Hardest to distinguish from legitimate traffic
Target the application itself rather than the network or protocol layer. HTTP floods send rapid requests to resource-intensive endpoints — search pages, login forms, database-backed queries — forcing the application to generate expensive responses for each one. The packets themselves are valid HTTP. The attack is indistinguishable from a flash crowd of real users at the protocol level.
Slowloris is the most elegant application-layer DoS tool ever written. It sends HTTP request headers extremely slowly — just one header every few seconds, just fast enough to avoid connection timeouts — without ever completing the request. Each connection holds open one of Apache's worker threads without doing anything. Apache has a limited number of concurrent threads. Fill all of them with Slowloris connections and legitimate requests cannot connect — even though the total bandwidth consumed is negligible. A single laptop on a home broadband connection can take down a default Apache installation. When Moxie Marlinspike demonstrated Slowloris in 2009 at DEF CON, the room went quiet.
Defence: The Apache mod_reqtimeout module — enforces minimum rates for request header delivery, closing connections that stall below the threshold. Connection limits per IP address. Reverse proxies that handle connection management differently from Apache's thread model (nginx handles this inherently through its event-driven architecture).
Three incidents that changed how the industry thinks about DoS
2016 — Dyn DNS — 1.2 Tbps from kitchen appliances
Volumetric
The Mirai botnet did not exploit software vulnerabilities. It found IoT devices — cameras, DVRs, routers — that still used their factory default credentials and logged into them directly. These devices had enough outbound internet bandwidth that collectively, when pointed at a single target, they generated 1.2 terabits per second. Because Dyn provided DNS infrastructure for major platforms, the effect cascaded: users could not resolve domain names, so they could not reach any site that relied on Dyn's nameservers.
The lesson was uncomfortable. The attack required no skill, no expensive botnet rental, and no sophisticated tooling. Anyone with the Mirai source code — which was published publicly by its author — could replicate it. The actual vulnerability was the security culture of IoT manufacturers who shipped products with admin:admin as the default and no mechanism to force users to change it. That culture has slowly improved since 2016 but has not been solved.
2018 — GitHub — 1.35 Tbps Memcached amplification
Amplification
Attackers sent small UDP packets to approximately 50,000 Memcached servers — a caching service that should never be internet-accessible — with GitHub's IP address spoofed as the source. Each Memcached server responded with dramatically larger packets directed at GitHub. The amplification factor was approximately 51,000 to 1. Each byte the attackers sent generated 51,000 bytes of attack traffic. The resulting 1.35 terabits per second peaked as the largest DDoS ever recorded at that time.
GitHub survived because they had a relationship with Akamai's Prolexic scrubbing service. Within 10 minutes of the attack beginning, they rerouted their traffic through Akamai's network, which absorbed the volume before it reached GitHub's own infrastructure. Total downtime was roughly 10 minutes for a 1.35 terabit attack. The Memcached servers that were abused had no business being internet-accessible — they were misconfigured production systems whose operators had no idea they were amplifiers. The remediation across the industry was UDP port 11211 blocking at ISP level.
2009 — Slowloris — a laptop vs Apache
Application-layer
When Slowloris was demonstrated at DEF CON in 2009 the reaction was disbelief — the tool used almost no bandwidth and required no botnet, yet could take down any Apache server running the default configuration. The mechanism was so simple it felt like it should not work. Apache allocated a thread for each incoming connection and held it until the request completed. Slowloris held requests open by trickling headers in one at a time, just fast enough to avoid timeout. Fill Apache's thread pool and it becomes unresponsive to all new connections — including legitimate ones.
The long-term effect of Slowloris on web server architecture was significant. nginx — which uses an event-driven, non-blocking model rather than a thread-per-connection model — is inherently resistant to Slowloris because it does not allocate significant resources per connection. The Apache mod_reqtimeout module was added specifically in response. But fifteen years later, Slowloris still works against servers that have not applied the fix — which is why it appears in the NSE vuln script category and surfaces regularly in pen test findings.
DoS in a pen test — assessment without causing outages
Testing for DoS vulnerabilities requires a fundamentally different approach from every other technique in this course. Every other attack can demonstrate a vulnerability while leaving the system functional. DoS testing, by definition, involves disrupting availability. That creates a risk of real service outage that must be carefully managed — and often means the finding gets reported based on detection evidence rather than live exploitation.
The professional approach splits DoS assessment into two distinct phases. Detection without exploitation — using scanner-based checks to identify whether a service exhibits the conditions that make it vulnerable, without triggering the attack. The Slowloris Nmap script returning "LIKELY VULNERABLE" from Lesson 17 is this phase in action. The second phase — actual DoS testing — requires explicit written authorisation that most standard engagement contracts do not include by default.
Three non-negotiable requirements before any DoS test
1. Explicit written authorisation naming the specific service and attack type
"Full compromise testing" does not cover DoS. The scope document must specifically authorise the attack type — Slowloris, SYN flood, UDP flood — against a named service or IP address. Generic language does not protect the pen tester if something goes wrong.
2. Testing window agreed in advance — off-peak, with a rollback plan
DoS tests against production services must happen during maintenance windows or agreed low-traffic periods. The client must have a documented recovery procedure ready to execute before the test begins — not drafted after the outage starts. A Slowloris test that takes down an e-commerce site at 2pm on a Friday without a recovery plan is a career-defining incident for the wrong reasons.
3. Direct line to whoever can stop the test and restore the service
Before starting, confirm that stopping the attack requires nothing more than ending the process on your machine and that recovery can begin immediately. If restoring the service requires waiting for someone to respond to a message, the test should not run. The immediate-stop requirement is non-negotiable.
Defence architecture — why perimeter controls alone are insufficient
By the time a volumetric DDoS attack reaches your firewall, it has already consumed your internet connection. No firewall rule can help when the pipe is full. Effective DoS defence must begin upstream — at the ISP and CDN level — before traffic reaches the organisation's own infrastructure. This is the insight that separates organisations who survive large-scale attacks from those who do not.
LAYERED DoS DEFENCE — from ISP to application server
1
ISP-level scrubbing
Attack traffic is identified and absorbed at the internet exchange before it reaches the customer's connection. Services like Cloudflare, Akamai Prolexic, and AWS Shield Advanced operate scrubbing centres that absorb attack traffic and forward only clean traffic. GitHub's ten-minute recovery from a 1.35 Tbps attack was entirely because this layer was already in place before the attack began.
2
CDN and anycast
Distributing the service across hundreds of global points of presence means attack traffic is automatically spread across the CDN's aggregate capacity rather than concentrated at a single data centre. What would overwhelm one location is absorbed across the network. Organisations serving significant public traffic should assume they will be targeted and architect accordingly — anycast is not an upgrade, it is a baseline for public-facing infrastructure.
3
Firewall and OS controls
SYN cookies at the OS level defeat SYN floods by deferring state allocation until the handshake completes. Rate limiting per source IP at the firewall limits the impact of any single compromised host. Connection tracking limits prevent state table exhaustion from protocol attacks. These controls handle attacks that pass the upstream filter but target connection infrastructure — they are not a substitute for upstream scrubbing, they are a complement to it.
4
WAF and application limits
Web Application Firewalls detect anomalous request patterns — excessive request rates from one IP, incomplete HTTP requests, repeated targeting of the same resource. Connection timeout enforcement defeats Slowloris at the application level. CAPTCHA on computationally expensive endpoints prevents automated flooding of database-backed operations. nginx's event-driven architecture handles Slowloris-style attacks inherently, which is one of the structural reasons it replaced Apache as the default web server for high-traffic deployments.
Each layer handles a different attack category. ISP scrubbing handles volumetric. SYN cookies handle protocol attacks. WAF rules handle application-layer attacks. A client who has layer 4 but not layer 1 is exposed to volumetric attacks that their excellent application-layer defences cannot touch. This is the argument pen testers make in reports when clients ask whether they really need all four controls — and it is a more persuasive argument when the Dyn, GitHub, and Slowloris incidents are referenced alongside it.
Teacher's Note: DoS vulnerabilities found through scanning — like the Slowloris "LIKELY VULNERABLE" result — belong in the report with a specific remediation recommendation regardless of whether they were confirmed through live exploitation. The remediation is concrete: add mod_reqtimeout to Apache, configure minimum header delivery rates. That specificity is what turns a scanning result into an actionable finding that gets fixed rather than deferred.
Quiz
Up Next · Lesson 33
Wireless Attacks
WPA2 handshake capture, aircrack-ng, evil twin access points, and why wireless security is harder to get right than most organisations assume.
