Floodles
Modular DoS/DDoS testing toolkit for authorized security audits. 19 attack vectors across L3/L4/L7. Python + C + Rust + Go.
Install / Use
/learn @franckferman/FloodlesREADME
Floodles
Modular DoS/DDoS testing toolkit. 19 attack vectors across L3/L4/L7.
Table of Contents
- Overview
- Network Fundamentals
- Floodles Architecture
- 3.1 Stack Layers
- 3.2 Native Backends
- 3.3 Why Multiple Languages
- Layer 3/4 Modules — Network and Transport
- Amplification Modules — DRDoS
- Layer 7 Modules — Application
- 6.1 HTTP Flood (LOIC L7)
- 6.2 Slowloris (LORIS)
- 6.3 Slow POST (RUDY)
- 6.4 TCP Starvation (NUKE)
- Tuning Attack Power — Practical Guide
- Audit Methodology
- Installation and Build
- Full CLI Reference
- Logging and Reporting
- Performance Benchmarks
- Limitations
- Related Work
- References
1. Overview
A Denial-of-Service (DoS) attack exhausts a target's resources — CPU cycles, memory, connection tables, or network bandwidth — until it can no longer serve legitimate requests. The attacker and the target are typically one-to-one.
A Distributed Denial-of-Service (DDoS) attack coordinates multiple sources against a single target, multiplying the traffic volume and making source-based filtering impossible. A special subclass — Distributed Reflected DoS (DRDoS) — exploits third-party servers as unwitting amplifiers: the attacker sends spoofed requests to open reflectors, which send their (much larger) responses to the victim.
Floodles covers all three models across three OSI layers:
- L3/L4 — raw TCP and UDP packet floods (9 vectors, raw socket, root required)
- Amplification — SNMP, NTP, DNS, Smurf, Fraggle, multi-vector (6 vectors, spoofing required)
- L7 — HTTP flood, Slowloris, Slow POST, TCP starvation (4 vectors, no root required)
Total: 19 attack vectors implemented across four language runtimes (Python, C, Rust, Go) with automatic backend selection.
What DoS tests answer
Passive scanning identifies open ports and software versions. It cannot answer the questions that matter most:
- Can an attacker make our services unavailable, and how easily?
- At what traffic volume does the target degrade, and at what volume does it become completely unreachable?
- What is the actual impact — partial degradation, full outage, data corruption, cascading failures?
- Are rate limiting and scrubbing mechanisms enabled and genuinely working, or just configured on paper?
- Can internal equipment (printers, switches, UPS, NTP servers) serve as amplification reflectors against other targets?
- Do IDS/IPS alerts trigger on known attack signatures, or do attacks pass silently for hours?
- What is the recovery time after traffic stops — seconds, minutes, manual intervention required?
- Does the upstream anti-DDoS scrub the load before it reaches the origin, or does it leak through?
- Are we actually vulnerable, or are the mitigations we believe are in place sufficient?
These questions have no passive answers. You either test or you assume — and assumptions in a security report are not findings. A "we have anti-DDoS" statement without evidence of what it absorbs is not a security posture.
Lab Environment
For a purpose-built test environment, see DOSArena — the first DoS/DDoS training platform with live proof-of-impact scoring. DOSArena provides 8 attack scenarios across multiple difficulty levels, 15 pre-configured Docker containers (vulnerable targets, judge, monitoring), an automated scoring engine that validates attacks every 5 seconds and issues time-windowed flags, and a Terraform/AWS deployment mode for cloud-scale testing. Floodles is the recommended attack toolkit for DOSArena scenarios.
2. Network Fundamentals
2.1 TCP — Connection-Oriented Protocol
TCP (RFC 793) guarantees reliable, ordered, error-checked delivery. Every byte sent is acknowledged; lost packets are retransmitted; the receiver controls the rate via the window size. This reliability comes at a cost: TCP maintains state for every connection.
The Three-Way Handshake
Client Server
| |
|-- SYN (seq=ISN_c) -------------->| Client picks a random Initial Sequence Number
| | Server allocates a TCB, enters SYN_RECEIVED
|<-- SYN-ACK (seq=ISN_s, | Server picks ISN_s, acknowledges ISN_c+1
| ack=ISN_c+1) --------|
| |
|-- ACK (ack=ISN_s+1) ------------>| Server moves to ESTABLISHED
| |
|<========= Data Transfer =========>|
| |
|-- FIN --------------------------->| Client initiates close
|<-- FIN-ACK ----------------------|
|-- ACK --------------------------->| Both enter TIME_WAIT -> CLOSED
The TCB — Transmission Control Block
For every connection in SYN_RECEIVED or ESTABLISHED state, the kernel allocates a TCB in memory. A TCB contains:
- Source IP / Destination IP
- Source port / Destination port
- Send sequence number (SND.NXT)
- Receive sequence number (RCV.NXT)
- Receive window size (RCV.WND)
- Congestion window (cwnd)
- Retransmission timer
- Current state (SYN_RECEIVED, ESTABLISHED, FIN_WAIT_1...)
On Linux, each TCB consumes approximately 280-350 bytes of kernel memory. The SYN queue (incomplete backlog) holds half-open connections waiting for their final ACK. Its capacity is controlled by:
sysctl net.ipv4.tcp_max_syn_backlog # default: 128-1024 depending on distro
The accept queue (complete backlog) holds fully established connections awaiting accept() from the application. Its capacity is the backlog parameter of listen() (typically 128 by default in most server configs).
TCP State Machine
CLOSED
-> listen() -> LISTEN
-> connect() -> SYN_SENT -> SYN_RECEIVED -> ESTABLISHED
|
FIN sent -> FIN_WAIT_1
|
FIN-ACK recv -> FIN_WAIT_2
|
FIN recv -> TIME_WAIT (2*MSL = 60-120s)
|
CLOSED
ESTABLISHED -> FIN recv -> CLOSE_WAIT -> FIN sent -> LAST_ACK -> CLOSED
TIME_WAIT lasts 2 * MSL (Maximum Segment Lifetime), typically 60-120 seconds. During TIME_WAIT, the 4-tuple (src_ip, src_port, dst_ip, dst_port) cannot be reused. A connection exhaustion attack that fills the TIME_WAIT table continues to deny service for up to 2 minutes after the attack stops.
TCP Flags
The 8-bit flags field in the TCP header is the primary lever for attack shaping:
Bit 0 (0x01): FIN — no more data from sender
Bit 1 (0x02): SYN — synchronize sequence numbers (initiates connection)
Bit 2 (0x04): RST — reset connection immediately
Bit 3 (0x08): PSH — deliver data to application without buffering
Bit 4 (0x10): ACK — acknowledgement field valid
Bit 5 (0x20): URG — urgent pointer valid
Bit 6 (0x40): ECE — ECN echo
Bit 7 (0x80): CWR — congestion window reduced
Each Floodles module manipulates these flags to produce a specific server reaction:
| Module | Flags set | Server reaction | |--------|-----------|-----------------| | UFOSYN | SYN (0x02) | Allocates TCB, sends SYN-ACK, waits for ACK that never comes | | UFOACK | ACK (0x10) | Walks connection table, finds nothing, sends RST | | UFORST | RST (0x04) | Closes matching established connections | | XMAS | ALL (0xFF) | Undefined behavior per RFC 793 — varies by OS | | TACHYON | SYN-ACK (0x12) | RST genera
