Flooding Attack — DoS / DDoS
1. What is a DoS Attack?
Denial of Service (DoS) is an attack whose goal is to make a network, host, or service unavailable or significantly degraded for legitimate users.
The core idea is resource exhaustion.
The exhausted resource may be:
- Network bandwidth
- Router/interface packet-processing capacity
- Queue/buffer space
- TCP connection state
- CPU
- Memory
- Application workers
- Database connections
- Other application resources
A DoS does not necessarily mean that the attacker simply sends a huge amount of traffic.
2. DoS vs DDoS
DoS
A single source (or a small number of sources) attempts to exhaust a target's resources.
Attacker
|
| traffic
v
Victim
DDoS
A Distributed Denial of Service (DDoS) attack uses many distributed systems/sources to generate traffic or requests toward the victim.
+---- Source 1 ---\
+---- Source 2 ----\
+---- Source 3 -----\
+---- Source 4 ------> Victim
+---- Source 5 -----/
+---- Source 6 ----/
The advantage to the attacker is:
- Greater aggregate capacity
- More distributed traffic sources
- Greater difficulty in blocking traffic based only on source IP
Kurose & Ross discusses this distributed model using compromised machines, often referred to as zombies, and illustrates the DDoS model in Figure 1.25.
3. Kurose & Ross Classification of DoS Attacks
Source: Kurose & Ross, Computer Networking: A Top-Down Approach, 8th ed., Chapter 1, §1.6 — Networks Under Attack.
Kurose & Ross describes three broad categories.
3.1 Vulnerability Attacks
A relatively small number of specially constructed packets/messages exploit a vulnerability and cause the target system to crash or stop functioning.
The important point:
High traffic volume is not required.
Conceptually:
Malformed / malicious input
|
v
Vulnerable software
|
v
Crash
|
v
Service unavailable
3.2 Bandwidth Flooding
The attacker sends enough traffic to consume the victim's access-link capacity.
Example
Legitimate traffic = 300 Mb/s
Attack traffic = 1.5 Gb/s
Victim link = 1 Gb/s
The link becomes the bottleneck.
Consequences
Queue grows
↓
Delay increases
↓
Buffer fills
↓
Packets are dropped
↓
Legitimate traffic is affected
The primary resource being exhausted is:
Network bandwidth
3.3 Connection Flooding
The attacker attempts to consume the target's connection-handling resources by creating huge numbers of TCP connections.
This can include large numbers of incomplete or half-open connections.
Possible exhausted resources:
- TCP connection state
- Connection backlog
- Memory
- CPU
- Socket resources
A classic example is a TCP SYN flood.
4. Why Flooding Works
A network is made of components with finite capacity.
Internet
|
v
[Access Link]
|
v
[Router / NIC]
|
v
[Kernel]
|
v
[TCP / UDP]
|
v
[Application]
|
v
[Database]
Every stage has a finite processing capacity.
A flooding attack succeeds when traffic/work arrives faster than the relevant resource can handle it.
General Model
Let:
λ = arrival/work rate
μ = service/processing rate
If:
λ > μ
the queue tends to grow.
If this continues:
Queues grow
↓
Delay increases
↓
Buffers fill
↓
Packets/requests are dropped
↓
Legitimate users experience degradation
↓
Denial of Service
This connects flooding directly to Kurose & Ross Chapter 1 §1.4, which covers:
- Delay
- Queuing
- Packet loss
- Throughput
5. Bandwidth Flooding
The attacker attempts to saturate the victim's network path.
Legitimate traffic
|
v
+-----------+
| Internet |
+-----------+
|
| 1 Gb/s link
v
+-----------+
| Victim |
+-----------+
^
|
huge traffic
|
+------+------+
| DDoS sources|
+-------------+
Suppose:
Victim link capacity = 1 Gb/s
Incoming traffic = 2 Gb/s
The link cannot carry all incoming traffic.
The excess traffic must effectively be:
- Queued
- Dropped
Eventually the service becomes unavailable or severely degraded.
Key Resource
Link capacity
Typical Measurements
bits/sec
packets/sec
interface utilization
packet drop rate
6. Packet Rate vs Bandwidth
A flood should not be judged only by bits/sec.
Two traffic streams can have the same bandwidth but very different packet rates.
Traffic A
Large packets
Low packets/sec
Traffic B
Small packets
Very high packets/sec
Traffic B may put much more pressure on:
- Packet-processing CPU
- Interrupt handling
- Router/NIC processing
- Firewall rule evaluation
Therefore a network engineer should monitor both:
bits/sec
and:
packets/sec
7. TCP SYN Flood
7.1 Normal TCP Three-Way Handshake
A normal TCP connection starts with a three-way handshake.
Client Server
| -------- SYN ------------> |
| |
| <------ SYN + ACK -------- |
| |
| -------- ACK ------------> |
| |
| Connection established |
Important TCP concepts:
SYNSYN-ACKACK- Sequence numbers
- Connection state
Primary source: Kurose & Ross, 8th ed., Chapter 3, §3.5.1 and §3.5.6.
7.2 What Happens in a SYN Flood?
The attacker sends many SYN requests without completing the normal handshake.
Attacker Victim
| -------- SYN ------------> |
| -------- SYN ------------> |
| -------- SYN ------------> |
| -------- SYN ------------> |
| -------- SYN ------------> |
| -------- SYN ------------> |
| ... |
The victim must maintain state for these connection attempts.
Conceptually:
Incoming SYNs
|
v
+--------------+
| TCP listener |
| backlog |
| |
| [SYN] [SYN] |
| [SYN] [SYN] |
| [SYN] [SYN] |
+--------------+
|
fills up
|
v
Legitimate connections
are affected
The attack therefore targets:
TCP connection state
TCP backlog
Memory
CPU
rather than necessarily saturating the network link.
Core Relationship
SYN arrival rate
>
connection completion / cleanup rate
for a sufficient period can cause resource exhaustion.
Prevention - SYN Cookie
A SYN Cookie is an identifier that allows the server to establish stateless connection to prevent SYN Flood. In this case the server calculates a hash value using timestamp, destination ip, source ip and other necessary details and provides a 32-bit Initial Sequence Number (ISN). The server completely ignores the state instead of allocating space on receiving initial SYN request.
- Client sends the SYN request (*seq: 1000000)
- Server calculates the ISN and sends it along SYN-ACK (ack: 1000001, seq: 38712312)
- Client sends ISN+1 along with ACK (seq: 1000001, ack: 387123123).
- The server calculates new hash value using IP, ports, extracted timestamps and its secret key and compares it with the received cookie. If matched, connection is legitimate and space is allocated.
8. Why SYN Floods Differ from Bandwidth Floods
Bandwidth Flood
Primary target:
Bits/sec
Packets/sec
Link capacity
SYN Flood
Primary target:
TCP pending connection state
Connection backlog
Socket resources
Therefore:
A SYN flood can cause serious service degradation even when the external network link is not completely saturated.
9. UDP Flooding
UDP is connectionless.
Unlike TCP, it does not require a three-way handshake before sending datagrams.
Conceptually:
Attacker
|
+---- UDP ----\
+---- UDP -----\
+---- UDP ------> Target
+---- UDP -----/
+---- UDP ----/
Potential bottlenecks include:
- Bandwidth
- Packets/sec
- CPU
- UDP/socket processing
- Application processing
Primary source: Kurose & Ross, 8th ed., Chapter 3, §3.3.
Nmap's TCP/IP Reference also provides UDP header details useful when analyzing UDP traffic.
10. ICMP Flooding
ICMP can also be used to generate large volumes of traffic.
DDoS sources
|
+---- ICMP ----\
+---- ICMP -----\
+---- ICMP ------> Victim
+---- ICMP -----/
+---- ICMP ----/
A historical DDoS example discussed by Kurose & Ross involved large quantities of ICMP ping messages directed toward DNS root-server infrastructure.
Possible exhausted resources include:
- Bandwidth
- Packet-processing capacity
- Server resources
- Router resources
Source: Kurose & Ross, 8th ed., §1.6, discussion of DDoS and ICMP flooding.
11. Smurf Attack
A classic historical attack is the Smurf attack.
It combines:
- IP source-address spoofing
- ICMP
- Broadcast amplification
Conceptual Flow
Attacker
|
| ICMP request
| Source IP = Victim
v
Broadcast network
|
+------ Reply ------\
+------ Reply -------\
+------ Reply -------> Victim
+------ Reply -------/
+------ Reply ------/
The attacker causes many systems to send responses toward the victim.
The important networking concept is:
Traffic generated by attacker
<
Traffic delivered to victim
The difference occurs because intermediary systems amplify the traffic.
Source: Wenliang Du / SEED Labs TCP/IP Attack material.
12. Application / Resource Exhaustion
Flooding does not have to be purely volumetric.
A service can be attacked by making each request expensive.
For example:
Normal request = 10 ms CPU
Expensive request = 500 ms CPU
An attacker sending expensive requests can consume CPU much faster than ordinary traffic would.
Attacker
|
| Expensive requests
v
+--------------------+
| Application server |
| |
| CPU → 100% |
+--------------------+
|
v
Legitimate requests
become slow/rejected
13. Forshaw's Resource-Exhaustion Perspective
James Forshaw, Attacking Network Protocols, Chapter 9 — The Root Causes of Vulnerabilities, explicitly discusses:
- Denial-of-Service
- Memory Exhaustion Attacks
- Storage Exhaustion Attacks
- CPU Exhaustion Attacks
- Algorithmic Complexity
This broadens the definition:
DoS = Exhaustion of a critical resource
rather than simply:
DoS = High network bandwidth
A service can therefore be taken down through:
High bandwidth
OR
High packet rate
OR
High connection state
OR
High CPU usage
OR
High memory usage
OR
High storage usage
OR
Expensive computation
14. Memory Exhaustion
A network interaction may cause the server to allocate memory.
Network request
↓
Memory allocation
↓
Many requests
↓
Memory consumption grows
↓
Memory exhausted
↓
Service failure
Potential causes include:
- Oversized inputs
- Too many simultaneous operations
- Retained connection state
- Poorly bounded buffers
- Protocol implementation bugs
Source: Forshaw, Chapter 9, "Memory Exhaustion Attacks".
15. CPU Exhaustion
A protocol or application may require significant computation.
An attacker can exploit this by repeatedly causing expensive processing.
Request
↓
Expensive computation
↓
Repeat
↓
CPU saturation
↓
Legitimate requests delayed
Forshaw specifically discusses:
- CPU Exhaustion Attacks
- Algorithmic Complexity
in Chapter 9.
16. Storage Exhaustion
Network requests can cause logs or other persistent data to be written.
Requests
↓
Logs
↓
Logs
↓
Logs
↓
Disk fills
↓
Service/system problems
Therefore network traffic can indirectly cause a storage-based DoS.
Source: Forshaw, Chapter 9, "Storage Exhaustion Attacks".
17. Nmap's Role
Nmap is not primarily a DoS textbook.
Its value here is understanding how actual network packets behave.
Official Nmap TCP/IP Reference
Provides packet-level references for:
- IPv4
- TCP
- UDP
- ICMP
Chapter 3 — Host Discovery
Relevant concepts:
- ICMP probing
- TCP SYN probing
- TCP ACK probing
- UDP probing
- ARP scanning
Chapter 5 — Port Scanning Techniques
Relevant concepts:
- SYN behavior
- SYN/ACK response
- RST response
- UDP behavior
- TCP flags
These concepts are useful when identifying and analyzing flooding traffic in packet captures.
18. Purdy: Linux Firewall Perspective
Gregor N. Purdy's Linux iptables Pocket Reference is primarily about:
- Netfilter
- iptables
- Packet filtering
- Connection tracking
- Accounting
- NAT
- Stateful/stateless firewalls
- Matches and targets
Conceptual Packet-Filtering Path
Packet
↓
Netfilter
↓
Table
↓
Chain
↓
Rule
↓
Match
↓
Target
↓
ACCEPT / DROP / REJECT / ...
Source: Purdy, Linux iptables Pocket Reference, "Concepts," p. 2 onward.
19. Rate Limiting
A firewall can sometimes reduce the effect of a flood by limiting the rate of packets or connections accepted by a service.
Incoming traffic
|
v
+--------------+
| Rate limiter |
+--------------+
|
v
Service
Purdy's iptables reference includes the limit match and discusses limiting connection attempts.
Important limitation
A local firewall cannot restore bandwidth that has already been consumed by a saturated upstream access link.
For example:
Internet
|
| 10 Gb/s attack
v
[1 Gb/s Victim Link]
|
v
[Firewall]
|
v
[Server]
Even if the firewall drops most packets, the 1 Gb/s access link is still the bottleneck.
20. Why DDoS Is Harder to Defend Against
Single-source DoS
Attacker A
|
v
Victim
A simple defense might be:
DROP source A
DDoS
A \
B \
C \
D \
E ---> Victim
F /
G /
H /
I /
Blocking one source does little.
The defender must distinguish:
Legitimate distributed traffic
vs
Malicious distributed traffic
This is much harder.
Source: Kurose & Ross, 8th ed., §1.6.
21. Why Defense Location Matters
Consider:
Internet
|
| 10 Gb/s attack
v
[Victim access link]
|
v
[Firewall]
|
v
[Server]
Suppose:
Access link = 1 Gb/s
Attack = 10 Gb/s
The firewall may successfully drop most attack packets.
However, the access link has already become the bottleneck.
Therefore:
Host / Local Mitigation
Useful for:
- TCP state exhaustion
- CPU exhaustion
- Application overload
- Connection limiting
- Rate limiting
Upstream Mitigation
Necessary when the problem is:
- Access-link saturation
- Large volumetric floods
This is one reason DDoS mitigation is often performed in upstream network infrastructure rather than solely on the victim host.
22. How to Recognize a Flood
A network specialist should examine multiple dimensions.
Traffic Volume
bits/sec
packets/sec
Packet Distribution
Source IPs
Destination IPs
Source ports
Destination ports
Protocol
TCP Behavior
For SYN-related problems:
SYN/sec
SYN-ACK/sec
ACK/sec
RST/sec
Pending connections
Resource Utilization
CPU
Memory
Socket/connection state
Queue depth
Packet drops
Interface utilization
Application Behavior
Requests/sec
Response latency
Error rate
Active workers
Database connections
23. Flooding as a Queueing Problem
A useful mathematical model is:
λ = arrival rate
μ = service rate
If:
λ < μ
the system can generally keep up.
If:
λ > μ
the queue tends to grow.
If the queue is finite:
Qmax
then eventually:
Q → Qmax
and packets/requests begin to be discarded or rejected.
Therefore:
High traffic
↓
Queue growth
↓
Higher latency
↓
Packet/request loss
↓
Service degradation
↓
Denial of Service
Primary source: Kurose & Ross, 8th ed., §1.4.
24. Layer-by-Layer View of Flooding
Think about an end-to-end network path:
Application
↑
|
Transport (TCP/UDP)
↑
|
Network (IP)
↑
|
Link (Ethernet/Wi-Fi)
↑
|
Physical / NIC
Different attacks stress different resources.
| Attack | Typical Layer / Resource |
|---|---|
| ICMP flood | Network layer / bandwidth / packet processing |
| UDP flood | Transport + network / bandwidth / packet processing |
| SYN flood | TCP state / connection backlog |
| TCP connection flood | Connection state / CPU / memory |
| HTTP/application flood | Application CPU / workers / database |
| Memory exhaustion | Host memory |
| Storage exhaustion | Disk/storage |
| CPU exhaustion | Host CPU |
| Vulnerability DoS | Software availability |
25. DoS Is Not Always DDoS
DDoS is a distributed form of denial of service.
Therefore:
All DDoS attacks are DoS attacks
but:
Not all DoS attacks are DDoS
26. DoS Is Not Always Flooding
Also remember:
A vulnerability-based DoS may require very few packets.
Example:
Malformed input
↓
Software vulnerability
↓
Crash
↓
Service unavailable
No massive traffic volume is necessary.
27. Key Differences to Memorize
| Concept | Main Resource Exhausted |
|---|---|
| Bandwidth flood | Link capacity |
| Packet-rate flood | Packet-processing capacity |
| SYN flood | TCP pending connection/state |
| Connection flood | Sockets/state/CPU/memory |
| Application flood | CPU/workers/database |
| Memory exhaustion | RAM |
| Storage exhaustion | Disk |
| CPU exhaustion | CPU |
| Vulnerability DoS | Software availability |
28. Specialist Mental Model
Do not memorize:
"DDoS = many computers sending lots of packets."
Demand} > Capacity
for some critical resource.
Whenever you analyze a flooding attack, ask these four questions:
1. What is arriving?
TCP?
UDP?
ICMP?
HTTP?
DNS?
2. At what rate?
bits/sec?
packets/sec?
connections/sec?
requests/sec?
3. Which resource is exhausted?
Bandwidth?
Queue?
TCP state?
CPU?
Memory?
Application workers?
4. Where can it be stopped?
Host?
Firewall?
Router?
ISP?
Upstream DDoS mitigation?
29. One-Page Revision Sheet
FLOODING DoS / DDoS
====================
Goal:
Exhaust a finite resource and deny legitimate service.
Core equation:
Demand > Capacity
DoS:
One/few sources
DDoS:
Many distributed sources
Kurose & Ross categories:
1. Vulnerability attack
2. Bandwidth flooding
3. Connection flooding
Bandwidth flood:
Consume link capacity
Measure:
bits/sec
packets/sec
interface utilization
Packet-rate flood:
Overwhelm packet processing
Measure:
packets/sec
CPU
SYN flood:
Many SYNs
↓
Incomplete handshakes
↓
TCP pending state/backlog consumed
↓
Legitimate connections affected
UDP/ICMP flood:
High packet/traffic volume
↓
Bandwidth / packet-processing exhaustion
Application/resource exhaustion:
Expensive requests
↓
CPU/memory/workers/database exhausted
Important:
Not every DoS is a flood.
Not every flood is DDoS.
Defense:
Host-level:
Rate limits
State controls
Connection controls
Resource limits
Upstream:
Filtering
Scrubbing
Traffic diversion
Required when access link is saturated
Key diagnostic questions:
1. What is arriving?
2. At what rate?
3. Which resource is exhausted?
4. At what network layer?
5. Where can traffic be filtered?
30. Exact Textbook Sources
Kurose & Ross
James F. Kurose and Keith W. Ross, Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2020
Relevant Sections
- Chapter 1, §1.4 — Delay, Loss, and Throughput in Packet-Switched Networks
- Queueing delay
- Packet loss
-
Throughput
-
Chapter 1, §1.6 — Networks Under Attack
- Vulnerability attacks
- Bandwidth flooding
- Connection flooding
-
DDoS
-
Chapter 3, §3.3 — Connectionless Transport: UDP
-
Chapter 3, §3.5.1 — The TCP Connection
-
Chapter 3, §3.5.6 — TCP Connection Management
Useful page references
- §1.4: approximately pp. 35–43
- §1.6: approximately pp. 54–57
- DDoS discussion / Figure 1.25: approximately pp. 55–56
Gordon Lyon / Nmap
Gordon Lyon, Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning, Nmap Project, 2009
Relevant Sections
TCP/IP Reference
- IPv4 header
- TCP header
- UDP header
- ICMP header
Chapter 3 — Host Discovery
- TCP SYN probing
- TCP ACK probing
- UDP ping
- ICMP ping
- ARP scanning
Chapter 5 — Port Scanning Techniques
- SYN behavior
- SYN/ACK response
- RST response
- UDP behavior
- TCP flags
Official book:
https://nmap.org/book/
James Forshaw
James Forshaw, Attacking Network Protocols: A Hacker's Guide to Capture, Analysis, and Exploitation, No Starch Press, 2017
Chapter 9 — The Root Causes of Vulnerabilities
Relevant sections:
- Denial-of-Service
- Memory Exhaustion Attacks
- Storage Exhaustion Attacks
- CPU Exhaustion Attacks
- Algorithmic Complexity
This chapter is particularly useful for understanding DoS as resource exhaustion beyond simple bandwidth flooding.
Gregor N. Purdy
Gregor N. Purdy, Linux iptables Pocket Reference, O'Reilly Media, 2004
Relevant Sections
- Concepts — p. 2 onward
- Connection Tracking — p. 14
- Accounting — p. 16
- Network Address Translation — p. 17
- Source NAT and Masquerading — p. 18
- Destination NAT — p. 19
- Stateless and Stateful Firewalls — p. 20
The command reference also covers:
limitstate- TCP matching
- UDP matching
- ICMP matching
Wenliang Du
Wenliang Du, Computer & Internet Security: A Hands-on Approach, 2nd ed.
Relevant associated material:
- TCP/IP attacks
- SYN flooding
- TCP attacks
- Smurf attacks
- Packet sniffing/spoofing
- Firewall / Netfilter / iptables
The SEED Labs TCP/IP Attack Lab specifically covers SYN flooding and the TCP three-way handshake/resource-exhaustion mechanism.