franckferman/Floodles
GitHub: franckferman/Floodles
一款模块化的 DoS 与 DDoS 压力测试工具集，覆盖 OSI 多层协议，旨在通过模拟攻击来评估网络基础设施的防御韧性。
Stars: 5 | Forks: 1
# FloodKit v4 — 研究文档
## 目录
1. [概述](#1-overview)
2. [网络基础](#2-network-fundamentals)
- 2.1 [TCP/IP 工作原理](#21-how-tcpip-works)
- 2.2 [什么是网络数据包](#22-what-is-a-network-packet)
- 2.3 [什么是 PPS](#23-what-is-pps)
- 2.4 [带宽与 PPS](#24-bandwidth-vs-pps)
3. [FloodKit 架构](#3-floodkit-architecture)
- 3.1 [协议栈层](#31-stack-layers)
- 3.2 [Native 后端](#32-native-backends)
- 3.3 [为什么使用多种语言](#33-why-multiple-languages)
4. [Layer 3/4 模块 — 网络和传输层](#4-layer-34-modules--network-and-transport)
- 4.1 [SYN Flood (UFOSYN)](#41-syn-flood-ufosyn)
- 4.2 [ACK Flood (UFOACK)](#42-ack-flood-ufoack)
- 4.3 [RST/FIN Flood (UFORST)](#43-rstfin-flood-uforst)
- 4.4 [XMAS Flood](#44-xmas-flood)
- 4.5 [UDP Flood (UFOUDP)](#45-udp-flood-ufoudp)
- 4.6 [ICMP Flood (PINGER)](#46-icmp-flood-pinger)
- 4.7 [SYN-ACK Flood (TACHYON)](#47-syn-ack-flood-tachyon)
- 4.8 [IP 分片 (DROPER)](#48-ip-fragmentation-droper)
- 4.9 [分片重叠 (OVERLAP)](#49-fragment-overlap-overlap)
5. [放大模块 — DRDoS](#5-amplification-modules--drdos)
- 5.1 [理解放大攻击](#51-understanding-amplification)
- 5.2 [SNMP 反射 (SNIPER)](#52-snmp-reflection-sniper)
- 5.3 [NTP 放大 (MONLIST)](#53-ntp-amplification-monlist)
- 5.4 [DNS 放大](#54-dns-amplification)
- 5.5 [Smurf 攻击](#55-smurf-attack)
- 5.6 [Fraggle 攻击](#56-fraggle-attack)
- 5.7 [多向量 (SPRAY)](#57-multi-vector-spray)
6. [Layer 7 模块 — 应用层](#6-layer-7-modules--application)
- 6.1 [HTTP Flood (LOIC L7)](#61-http-flood-loic-l7)
- 6.2 [Slowloris (LORIS)](#62-slowloris-loris)
- 6.3 [Slow POST (RUDY)](#63-slow-post-rudy)
- 6.4 [TCP 饥耗 (NUKE)](#64-tcp-starvation-nuke)
7. [调整攻击威力 — 实战指南](#7-tuning-attack-power--practical-guide)
8. [审计方法论](#8-audit-methodology)
9. [安装与构建](#9-installation-and-build)
10. [完整 CLI 参考](#10-full-cli-reference)
11. [Docker 实验室](#11-docker-lab)
12. [日志与报告](#12-logging-and-reporting)
## 1. 概述
FloodKit 是一个模块化工具包，用于测试网络基础设施抵御拒绝服务条件的韧性。它覆盖了 OSI 模型所有层级的 19 个攻击向量。
### 审计语境下的目的
在网络渗透测试中，DoS 测试回答了具体的问题：
- 保护机制是否启用并真正有效？
- 目标在多大的流量下开始降级？
- 内部设备是否可作为反射器攻击其他目标？
- IDS/IPS 是否针对已知攻击模式触发警报？
- 饱和后的恢复时间是多少？
这些不是理论问题。如果不进行测试，你无法在报告中诚实地声称防护是有效的。
## 2. 网络基础
### 2.1 TCP/IP 工作原理
所有互联网通信都依赖于两个核心协议：
**IP (Internet Protocol)** — 网络层 (L3)
负责路由。每个 IP 数据包包含源地址和目的地址。IP 是无连接的：它发送数据包但不保证交付或顺序。
**TCP (Transmission Control Protocol)** — 传输层 (L4)
构建于 IP 之上。TCP 保证数据按序、无错到达。为此，它通过一个称为 **三次握手 (three-way handshake)** 的 3 步机制建立连接：
```
Step 1 — SYN:
Client -> [SYN, seq=1000] -> Server
"I want to connect, my sequence number is 1000"
Step 2 — SYN-ACK:
Client <- [SYN-ACK, seq=5000, ack=1001] <- Server
"OK, my sequence is 5000, I acknowledge your 1000"
Step 3 — ACK:
Client -> [ACK, ack=5001] -> Server
"Confirmed, we are connected"
```
完成这 3 步后，连接变为 **ESTABLISHED**（已建立），数据即可流动。
大多数 L4 攻击利用此握手机制或服务器为每个连接维护的数据结构。
### 2.2 什么是网络数据包
网络数据包是一个具有分层结构的数据单元，就像嵌套的信封：
```
+------------------------------------------+
| Ethernet Header (14 bytes) | <- MAC addresses
| +--------------------------------------+ |
| | IP Header (20 bytes) | | <- IP addresses
| | +----------------------------------+ | |
| | | TCP/UDP Header (20/8 bytes) | | | <- Ports, flags, seq
| | | +------------------------------+ | | |
| | | | Payload (data) | | | | <- Actual content
| | | +------------------------------+ | | |
| | +----------------------------------+ | |
| +--------------------------------------+ |
+------------------------------------------+
```
一个攻击用的 SYN 数据包没有有效载荷：它几乎完全由头部组成。典型大小：40-60 字节。
无分片情况下的最大以太网数据包大小 = **1500 字节** (MTU, Maximum Transmission Unit)。
### 2.3 什么是 PPS
**PPS = Packets Per Second** —— 每秒发送或处理的数据包数量。
这是一个不同于带宽 的指标。SYN flood 以极高频率发送非常小的数据包（60 字节）。其目标不是饱和带宽，而是饱和服务器的处理能力。
```
Conversion example:
1 SYN packet = 60 bytes = 480 bits
100,000 PPS x 480 bits = 48,000,000 bits/s = 48 Mbps
-> 100k PPS only consumes 48 Mbps of bandwidth
-> But generates 100,000 connection processing operations/sec on the server
```
这就是为什么服务器可以在带宽很小的情况下不堪重负：饱和的是连接处理 CPU，而不是网络链路。
### 2.4 带宽与 PPS
| 指标 | 衡量内容 | 适用场景 |
|--------|----------|------------|
| Mbps/Gbps | 每秒比特数 | 带宽饱和 (UDP 容量型) |
| PPS | 每秒数据包数 | CPU 饱和 (SYN flood, ACK flood) |
| RPS | 每秒请求数 | 应用层饱和 (HTTP flood) |
实际上，你的上行链路限制取决于两者：
```
Estimating your link capacity:
Uplink bandwidth: 100 Mbps
SYN packet size: 60 bytes = 480 bits
Theoretical max PPS = 100,000,000 / 480 = ~208,000 PPS
Practical (60-70% efficiency due to overhead):
-> ~130,000 PPS realistic for 60-byte packets
For 1400-byte UDP packets:
Max PPS = 100,000,000 / (1400 x 8) = ~8,900 PPS
-> Near bandwidth saturation
```
规则：**小包 = 高 PPS 但低 Mbps**，**大包 = 低 PPS 但高 Mbps**。
## 3. FloodKit 架构
### 3.1 协议栈层
```
+----------------------------------------------------------+
| CLI (Click) | Dashboard (Rich TUI) | Logger |
+----------------------------------------------------------+
| Modules (19 attack vectors) |
| syn_flood / http_flood / slowloris / sniper / ... |
+----------------------------------------------------------+
| native_bridge.py -- backend detection and selection |
+--------------+----------------+-------------------------+
| C sender | Rust packets | Go engine |
| sendmmsg() | zero-copy | goroutines |
| 1-8M PPS | builder | HTTP / Slowloris |
+--------------+----------------+-------------------------+
| Python fallback (Scapy) -- always available |
+----------------------------------------------------------+
```
### 3.2 Native 后端
**C — 高性能发送器**
Python flood 的瓶颈在于系统调用的数量。每次 `sendto()` = 1 次系统调用 = 数百纳秒的固定开销。
`sendmmsg()` 是一个 Linux 系统调用，可在单次调用中发送多条消息。FloodKit 以 256 个数据包为批次使用它：
```
// Instead of 256 x sendto() = 256 syscalls:
sendmmsg(sock, msgs, 256, 0); // = 1 syscall for 256 packets
// Gain: ~10x the PPS at the same CPU frequency
```
**Rust — 数据包构建器**
数据包构建（填充 IP/TCP 头部，计算校验和）在栈上完成（局部函数内存，无堆分配）。每个数据包在栈上正好占用 1500 字节，绝不多，且不经过 `malloc()`。
IP/TCP 校验和计算 (RFC 1071) 是 16 位整数的求和。在 `-O3 -march=native` 优化下，Rust 编译器会自动将其向量化为 SIMD 指令 (SSE2/AVX2)，同时计算多个字。
**Go — HTTP 引擎**
Go goroutine 的初始栈仅为 2KB（而 OS 线程为 8MB）。你可以毫无问题地启动 10 万个。这使得在单台机器上维持数千个并发 HTTP 连接成为可能，而 Python aiohttp 在大约 2-5k 有效协outine 时就会进入平台期。
### 3.3 为什么使用多种语言
| 语言 | 优势 | 用途 |
|----------|-----------|---------|
| C | 直接 Linux 系统调用访问，零开销 | `sendmmsg()`, raw socket, 速率控制 |
| Rust | C 级性能且无未定义行为，零拷贝 | IP/TCP/UDP 数据包构建 |
| Go | 原生并发 (M:N goroutines)，成熟的 `net/http` | HTTP flood, 大规模 Slowloris |
| Python | 开发速度快，库丰富 | CLI, dashboard, YAML config, profiler, logging |
Python 负责编排一切。性能关键部分（发送、数据包构建）通过 `ctypes` (C, Rust) 或 `subprocess` (Go) 委托给 native 库。
## 4. Layer 3/4 模块 — 网络和传输层
### 4.1 SYN Flood (UFOSYN)
#### 详细机制
在正常的 TCP 握手过程中，收到 SYN 后，服务器必须：
1. 为此半开连接分配一个内存结构：**TCB (Transmission Control Block)**
2. 在 **SYN 队列**（也称为不完整积压）中注册该连接
3. 发送 SYN-ACK
4. 等待最终 ACK 约 75 秒（默认 TCP 超时时间）
SYN 队列大小有限（`/proc/sys/net/ipv4/tcp_max_syn_backlog`，默认 128 到 1024，视发行版而定）。当队列满时，新的 SYN 会被丢弃。合法连接无法再建立。
```
Attack:
Attacker -> [SYN src=1.2.3.4] -> Server (allocates TCB, puts in SYN queue)
Attacker -> [SYN src=5.6.7.8] -> Server (allocates TCB, puts in SYN queue)
Attacker -> [SYN src=9.10.11.12] -> Server (allocates TCB, puts in SYN queue)
... x 10,000 ...
SYN queue full -> legitimate clients get ECONNREFUSED or timeout
```
IP 源欺骗至关重要：服务器将 SYN-ACK 数据包发送给从未请求过的 IP。这些 IP 会响应 RST（未知连接），从而移除 SYN 队列中的条目 —— 但相对于注入速率而言太慢了。
#### SYN Cookies —— 对策
启用 `net.ipv4.tcp_syncookies=1` 后，服务器改变策略：不再分配 TCB，而是将连接状态编码进 SYN-ACK 的序列号（即四元组 src/dst IP/port + 时间戳的加密哈希）。不分配内存。当 ACK 到达时，服务器验证哈希并重建状态。
结果：SYN flood 对服务器几乎无成本。它发送 SYN-ACK（CPU 成本）但不分配内存。SYN 队列永不满。
```
# 在目标服务器上验证（需要 SSH 访问权限）
sysctl net.ipv4.tcp_syncookies
# 1 = 已启用 -> SYN Flood 无效
# 0 = 已禁用 -> 存在漏洞
# 检查 Backlog 大小
sysctl net.ipv4.tcp_max_syn_backlog
# 典型值：128 到 4096
```
#### 审计中的使用时机
- 针对任何开放 TCP 端口的服务器 (80, 443, 22, 3306...)
- 验证 `tcp_syncookies` 是否激活
- 测量降级阈值（在多少 PPS 时合法连接会超时）
- 测试上游抗 D (Cloudflare, Arbor, F5...) 的有效性
#### 调优
```
# 启动轻量级 -- 观察而不产生影响
sudo floodkit syn 192.168.1.100 80 -t 2 --pps 5000 -d 30
# 逐步增加
sudo floodkit syn 192.168.1.100 80 -t 8 --pps 50000 -d 30
# 全负荷 -- 观察降级情况
sudo floodkit syn 192.168.1.100 80 -t 32 -d 60
# 攻击期间在服务器上进行监控
watch -n1 'ss -s'
# 观察：SYN-RECV（等待连接）应该上升
```
#### 成功指标（易受攻击服务器）
```
# 在服务器上：
ss -s | grep "SYN-RECV"
# 应迅速攀升至 tcp_max_syn_backlog
netstat -s | grep "SYNs to LISTEN"
# 计算因 Backlog 已满而丢弃的 SYN
# 从合法客户端：
curl --connect-timeout 5 http://192.168.1.100/
# -> 连接超时
```
### 4.2 ACK Flood (UFOACK)
#### 详细机制
ACK 数据包通常由客户端发送以确认接收到的数据。它属于一个已存在的 TCP 连接。
一个带有随机序列号的欺骗性 ACK 数据包到达一台没有相应连接的服务器。服务器必须：
1. 遍历 TCP 栈以在其状态表中搜索该连接
2. 查找失败
3. 发送 RST (reset) 作为响应
此 RST 被发送到被欺骗的源 IP。该 IP 收到一个它不理解的 RST。它可能会忽略它或做出响应。
#### 它真正测试的是什么：防火墙，而非服务器
ACK flood 在审计中的主要价值是测试**服务器前的防火墙**是有状态还是无状态的。
```
STATELESS firewall:
Rule: "accept inbound TCP port 80"
-> Sees an ACK toward port 80 -> rule matched -> let it through
-> Server processes the packet -> CPU overhead
STATEFUL firewall:
Maintains a table of established connections (connection tracking)
-> Sees an ACK without prior SYN -> unknown connection -> DROP
-> Server never sees the packet
```
```
# 测试：ACK 是否通过了防火墙？
sudo floodkit ack 192.168.1.100 80 -t 4 --pps 10000 -d 30
# 在服务器上观察：
# 如果你看到生成的 RST -> ACK 通过了 -> 无状态防火墙
iptables -n -v -L | grep REJECT
# 或者使用 tcpdump：
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0' -n
```
#### 对 Web 服务器的影响
nginx 或 Apache 服务器每秒可以处理数十万个无效 ACK 而不会饱和（在内核级别处理）。ACK flood 主要用于：
1. 测试防火墙的状态性
2. 生成可能影响 IDS 检测的网络噪声
3. 针对性能较弱的设备（嵌入式、IoT），每个数据包的成本更高
### 4.3 RST/FIN Flood (UFORST)
#### 详细机制
RST (Reset) 数据包告诉目的地“立即忘记此连接”。FIN (Finish) 数据包启动干净的关闭。
在 flood 模式下，发送带有随机序列号的 RST 数据包。如果碰巧某个 RST 序列号落在真实已建立连接的**接收窗口**内，内核会立即关闭它。每个数据包的概率很低（~1/65536），但在数百万个数据包下，真实连接可能被切断。
```
TCP sequence space = 2^32 (4 billion values)
Typical receive window = 65,535 bytes
Hit probability = 65,535 / 4,294,967,296 ~= 0.0015%
But with 1,000,000 RST/sec:
Expected hits = 1,000,000 x 0.0015% ~= 15 connections cut/sec
```
#### 定向变种 (TCP 会话劫持)
通过（嗅探）获知活动连接的确切序列号，你可以伪造一个能 100% 精确切断该特定连接的 RST。这被用于 BGP 会话拆除攻击 (BGP RST injection, CVE-2004-0230)。
#### 审计中的使用时机
- 测试长寿命连接的韧性（SSH 会话、数据库连接）
- 验证网络不接受伪造的 RST（PAWS 保护, RFC 4953）
- 结合嗅探以演示切断特定会话的能力
### 4.4 XMAS Flood
#### 详细机制
正常的 TCP 数据包使用有效的标志组合。RFC 793 基于这些组合定义了一个有限状态机。一个带有**所有标志同时置位**（FIN + SYN + RST + PSH + ACK + URG + ECE + CWR）的数据包在逻辑上是不可能的：你不能同时打开（SYN）、关闭（FIN）和重置（RST）一个连接。
现代 OS 对 XMAS 数据包的行为：
- **Linux**: 对关闭端口发送 RST，对开放端口忽略
- **Windows**: 通常忽略
- **BSD**: 系统性发送ST
- **嵌入式 / IoT 自定义栈**: 不可预测的行为（可能崩溃）
#### 主要价值：IDS 检测测试
```
# 发起 XMAS Flood
sudo floodkit xmas 192.168.1.100 80 -t 4 -d 30
# 问题：IDS 告警了吗？
# 典型的 Snort/Suricata 规则：
# alert tcp any any -> any any (flags:SFRPAUEC; msg:"XMAS scan"; sid:1000001;)
# 如果 30 秒后没人收到告警 -> IDS 未检测到它
```
#### 端口扫描技术 (nmap -sX)
XMAS 也被用作端口扫描技术：在**开放**端口上，服务器忽略数据包（根据 RFC）。在**关闭**端口上，它响应 RST。这允许在不发送 SYN 的情况下进行扫描（在日志中不太可见）。
```
# nmap 正是这么做的：
nmap -sX 192.168.1.100
# 无响应的端口 = 开放
# 响应 RST 的端口 = 关闭
```
### 4.5 UDP Flood (UFOUDP)
#### 详细机制
UDP 是无连接且无状态的。当 UDP 数据包到达一个端口时：
1. 内核检查是否有进程正在监听该端口
2. 如果是：数据包被传递给应用程序
3. 如果否：内核向源地址生成一个 **ICMP Port Unreachable**
在随机端口的 UDP flood 中：
- 大多数端口没有服务 -> 产生大量 ICMP Port Unreachable
- 这些 ICMP 会饱和服务器的出站网络接口（附带影响）
- 内核 CPU 忙于处理入站 UDP 和生成出站 ICMP
通过 IP 源欺骗，ICMP 消息会去往随机 IP（而不是攻击者）。服务器向第三方产生寄生流量。
#### 有效载荷大小 —— 战术选择
```
Small UDP packet (64 bytes):
-> More packets/sec for same bandwidth
-> More kernel processing/sec -> CPU pressure
-> Stays within MTU -> no fragmentation
Near-MTU UDP packet (1400 bytes):
-> Fewer PPS but more Mbps
-> Saturates upstream bandwidth
-> Maximizes bytes/sec toward the target
```
#### 在 Web 服务器上 (端口 80)
Web 服务器监听 TCP 80，而不是 UDP 80。端口 80 上的 UDP flood 会生成 ICMP Port Unreachable 消息。其价值不在于破坏 Web 服务，而在于：
1. 饱和网络链路（带宽饱和）
2. 测试内核的 ICMP 速率限制
3. 验证防火墙过滤未请求的 UDP
#### 在 DNS 服务器上 (端口 53)
DNS 服务器响应 UDP 端口 53。带有畸形查询的 UDP/53 flood 强制 DNS 服务器处理每个数据包。这是 UDP flood 直接与服务相关的场景。
### 4.6 ICMP Flood (PINGER)
#### 详细机制
ICMP echo request (type 8) 期望得到 echo reply (type 0)。对于每个接收到的数据包，内核必须：
1. 验证 ICMP 校验和
2. 为响应分配缓冲区
3. 构建并发送 echo reply
**倍增效应**：攻击者产生 X 字节/秒的入站流量，目标产生 X 字节/秒的出站响应。消耗的总带宽 = 2X。通过 IP 欺骗，回复去往随机 IP（而不是攻击者），产生发往第三方的寄生流量。
#### ICMP 速率限制 —— 标准保护
Linux 内置 ICMP 速率限制器：
```
sysctl net.ipv4.icmp_ratelimit # Delay between ICMP responses (default 1000ms)
sysctl net.ipv4.icmp_ratemask # ICMP types subject to rate limiting
```
当 `icmp_ratelimit=1000` 时，内核每秒最多生成一个 ICMP 响应。如果此参数配置正确，ICMP flood 无法耗尽出站带宽。
在审计中：flood 揭示此速率限制是否处于活动状态。
#### 实战中的有效载荷大小
```
# 标准（56 字节负载，像普通 ping 一样）
sudo floodkit icmp 192.168.1.100 -s 56 -t 4 -d 30
# 接近 MTU（1400 字节）——最大化带宽饱和度
sudo floodkit icmp 192.168.1.100 -s 1400 -t 8 -d 30
# 在目标上验证：
iptables -n -v -L | grep icmp # Any ICMP rate limit rules?
sysctl net.ipv4.icmp_ratelimit # Configured value
```
### 4.7 SYN-ACK Flood (TACHYON)
#### 直接模式
欺骗性 SYN-ACK 数据包直接发送到目标。未请求的 SYN-ACK 会触发 RST 响应（内核拒绝不对应任何已发起连接的 SYN-ACK）。成本：内核为每个数据包生成 RST。
对独立服务器不如 SYN flood 有效，但有趣的是测试防火墙如何处理入站 SYN-ACK 数据包（一些无状态防火墙会放行，因为它们看起来像合法响应）。
#### 反射模式 —— 更复杂的技术
```
Normal (direct SYN flood):
Attacker -> SYN (src=spoofed_IP) -> Target
Target -> SYN-ACK -> spoofed_IP (lost in the void)
TACHYON reflected:
Attacker -> SYN (src=victim_ip) -> Public_Server_1
Public_Server_1 -> SYN-ACK -> victim_ip <- traffic toward target!
Attacker -> SYN (src=victim_ip) -> Public_Server_2
Public_Server_2 -> SYN-ACK -> victim_ip <- traffic toward target!
```
受害者从**真实合法服务器**（CDN、公共 Web 服务器）接收 SYN-ACK。这些源 IP 是有效的且信誉良好。IP 信誉过滤或黑名单在此无效。
放大因子约为 1x（与请求大小相同），但来源的多样性使得缓解非常复杂。
### 4.8 IP 分片 (DROPER)
#### IP 分片工作原理
当数据包大于 MTU（以太网 1500 字节）时，它被拆分为多个较小的数据包。每个分片共享一个共同的**分片 ID** 和一个指示其在原始数据包中位置的**偏移量**。
接收方必须在处理数据包之前按正确顺序重组所有分片。这需要在内存中保留一个**重组缓冲区**（Linux 上的 `ipq hash table`）。
```
Relevant kernel parameters:
net.ipv4.ipfrag_max_dist : max fragments before dropping
net.ipv4.ipfrag_time : reassembly timeout (default: 30s)
net.ipv4.ipfrag_high_thresh : max memory for reassembly (bytes)
```
#### Flood 变种 (标准 DROPER)
发送数千个带有随机 ID 的微小分片（8 字节）。每个 ID 组在 ipq 哈希表中占用一个槽位。当表满时，新分片（以及需要重组的合法数据包）会被丢弃。
#### 仅末尾变种 —— 最有效
仅发送**最后一个分片**（MF=0, offset>0），而不发送第一个。内核分配一个重组缓冲区，等待永远不会到达的第一个分片，并维护此缓冲区 30 秒（默认超时）。
```
1 last_only packet -> buffer maintained 30s
10,000 last_only packets/sec -> 10,000 x 30s = accumulating buffers
-> ipfrag_high_thresh reached -> reassembly refused for everyone
```
这是一种低 PPS 但具有高持续影响的攻击。
#### 目标上的监控
```
# 实时观察重组失败
watch -n1 'grep "Reasm" /proc/net/snmp'
# ReasmFails 上升 = 缓冲区耗尽或分片被丢弃
# 重组使用的内存
cat /proc/sys/net/ipv4/ipfrag_high_thresh # limit in bytes
```
### 4.9 分片重叠 (OVERLAP)
#### Teardrop —— 历史性漏洞
CVE-1999-0015。两个分片，其中第二个与第一个重叠。
```
Fragment 1: offset=0, length=68 (covers bytes 0-67)
Fragment 2: offset=24, length=48 (covers bytes 24-71)
^-- overlaps fragment 1 bytes 24-67
Vulnerable kernel during reassembly:
remaining = frag1_len - frag2_offset = 68 - 24 = 44
memcpy(buf + offset, frag2_data, frag2_len - 44)
= memcpy(buf + 24, data, 48 - 44) = memcpy(buf + 24, data, 4) OK
But with a crafted variant:
remaining = -(negative value)
memcpy(buf + offset, data, negative_value)
-> Writes into arbitrary memory -> crash / possible RCE
```
已在 Linux 2.0.32+ 和 Windows NT SP3+ 中修补。但在以下系统上仍易受攻击：
- 嵌入式 TCP/IP 栈
- 未修补的路由器固件
- 具有专有 OS 的 OT/SCADA 设备
#### Tiny 变种 —— 无状态防火墙绕过
如果第一个分片仅包含 TCP 数据包的 8 个字节，则该分片中的 TCP 头部是不完整的。检查 TCP 端口的无状态防火墙只能从第一个分片读取端口。
```
Fragment 1 (8 bytes): IP header + first 8 bytes of TCP header
-> Contains src_port and dst_port (offset 0 and 2 in TCP header) OK
-> Does NOT contain TCP flags (offset 13)!
Firewall:
"I see TCP port 80, rule matched" -> passes fragment 1
"Fragment 2: continuation of fragmentation ID X -> passes"
-> Both fragments arrive, reassembly -> complete TCP packet
with flags the firewall never checked
```
## 5. 放大模块 — DRDoS
### 5.1 理解放大攻击
DRDoS (Distributed Reflective Denial of Service) 攻击利用**合法的第三方服务器**作为反射器和放大器。
```
General schema:
Attacker --(1 Mbps)--> Reflectors (NTP/SNMP/DNS...)
|
| (amplification x 650)
v
Victim <--(650 Mbps)--
```
**对攻击者的优势：**
- 指向受害者的流量来自合法 IP（真实服务器）
- 攻击者只需要最终带宽的一小部分
- 反射者是无辜的（它们只是在履行职责）
**在审计语境中：**
目标不是针对目标进行放大。而是验证**审计范围内**的设备（内部 NTP 服务器、SNMP 交换机、DNS 解析器）是否配置为可作为反射器。这是一个需要报告的已记录漏洞。
### 5.2 SNMP 反射 (SNIPER)
#### SNMP v2c — 网络管理协议
SNMP (Simple Network Management Protocol) 允许监控和配置网络设备（交换机、路由器、打印机、UPS...）。版本 v2c 使用“community string”作为唯一的认证 —— 通常保留为默认值“public”。
**GetBulkRequest** 是一个 SNMP 命令，要求服务器一次返回大量数据。当 `max-repetitions=255` 时，服务器必须返回每个请求 OID 的 255 个实例。如果你请求 MIB-II root OID（包含设备的整个数据树），响应可达 65,507 字节（UDP 限制）。
```
GetBulk request : ~60 bytes
Response : up to 65,507 bytes
Factor : 65,507 / 60 ~= 1,092x
Practical factor: ~650x average (incomplete response for small devices)
```
#### 在审计中检测易受攻击设备
```
# 扫描子网寻找 SNMP agents
nmap -sU -p 161 --script snmp-info 192.168.1.0/24
# 测试 Community String
snmpwalk -v2c -c public 192.168.1.50 .1.3.6.1.2.1
# 如果返回数据 -> 存在漏洞
# 检查响应量（放大因子的指标）
snmpbulkget -v2c -c public -Cn0 -Cr255 192.168.1.50 .1.3.6.1.2.1 | wc -c
```
#### 通常易受攻击的企业设备
- 网络打印机 (Brother, HP, Xerox): 默认 "public" community
- 未修补的管理型交换机
- 具有 SNMP v2c 的 UPS (APC, Eaton)
- 工业/SCADA 设备
- 配置陈旧的 Cisco 路由器
#### 建议报告的缓解措施
```
1. Disable SNMP v1/v2c, migrate to SNMPv3 (auth + encryption)
2. Change the "public" community string
3. Filter inbound UDP/161 from the outside
4. SNMP ACL: only allow IPs from the monitoring station
```
### 5.3 NTP 放大 (MONLIST)
#### NTP Mode 7 — monlist
NTP (Network Time Protocol) 同步时钟。`monlist` 命令（mode 7, code 42）要求服务器提供最近查询过它的 600 个客户端列表。
```
monlist request : 8 bytes
Response : 600 entries x ~72 bytes = ~43,200 bytes (multiple UDP packets)
Factor : ~550x
```
补丁：NTPd 4.2.7p26 (2013) 默认禁用了 monlist。但数百万设备仍运行旧版本。
```
# 检查 NTP 服务器是否易受攻击
ntpdc -c monlist 192.168.1.1
# 如果返回数据 -> 存在漏洞
# 或者使用 nmap
nmap -sU -p 123 --script ntp-monlist 192.168.1.1
```
#### 在内部审计实践中
公司内部 NTP 服务器（通常是 Windows 服务器或专用设备）经常易受攻击，因为它们从未更新。这是网络审计中首先要检查的事项之一。
### 5.4 DNS 放大
#### DNS ANY 查询 —— 问题所在
类型为 ANY（或 DNSSEC 区域的 DNSKEY）的 DNS 查询要求解析器返回域名的**所有**可用记录。DNSSEC 签名的域可能有大量的 RRSIG 记录。
```
DNS ANY query for isc.org : ~50 bytes
Full response : ~2,000-4,000 bytes (with DNSSEC)
Factor : ~60x typical, up to ~100x
```
RFC 8482 (2019) 建议解析器停止响应 ANY 查询。许多现代解析器遵守此规。但旧解析器和配置不当的权威服务器仍然易受攻击。
#### 开放解析器 —— 配置问题
**开放 DNS 解析器**接受来自任何源 IP 的查询，而不仅仅是其合法客户端。大多数企业 DNS 服务器应配置为仅响应内部 IP。
```
# 测试内部 DNS 服务器是否为开放解析器
dig @192.168.1.53 isc.org ANY
# 如果响应 -> 开放解析器 -> 可用作反射器
```
### 5.5 Smurf 攻击
#### 广播 ICMP —— 网络放大
每个 IP 子网都有一个广播地址（/24 上的最后一个八位字节 = 255）。发送到广播地址的数据包会被传送到**子网上的所有主机**。
```
Attacker -> ICMP echo request (src=victim_ip, dst=192.168.1.255)
Host_1 -> ICMP echo reply -> victim_ip
Host_2 -> ICMP echo reply -> victim_ip
Host_3 -> ICMP echo reply -> victim_ip
... x 254 hosts on a /24 ...
```
放大因子 = 子网上活动主机的数量。
#### 现代保护
```
# Linux 默认忽略广播 ping：
sysctl net.ipv4.icmp_echo_ignore_broadcasts
# 1 = 忽略（现代 Linux 默认）
# 0 = 响应广播 -> 存在漏洞
# Cisco IOS（默认自 IOS 12.0 起禁用）：
no ip directed-broadcast # on each interface
```
在审计中，价值在于验证旧主机或嵌入式设备是否响应广播 ping。
### 5.6 Fraggle 攻击
原理同 Smurf，但使用 UDP echo（端口 7）而不是 ICMP。
```
Attacker -> UDP dst=broadcast:7 (src=victim_ip)
Each host with UDP echo enabled -> replies to victim_ip:src_port
```
自 2000 年代以来，UDP echo 服务（端口 7）在所有现代 OS 上默认禁用。但是：
- 某些网络打印机仍启用它
- 旧工业设备
- 网络测试设备
Chargen 变种（端口 19）：服务器不进行 echo，而是生成连续的 ASCII 字符流 -> 响应比请求大，更好的放大因子。
### 5.7 多向量 (SPRAY)
SPRAY 通过 YAML 配置文件同时协调多个放大模块。
```
# config/examples/spray.yaml
vectors:
- type: snmp
reflectors: ["10.0.0.1", "10.0.0.2"]
threads: 4
- type: ntp
reflectors: ["10.0.0.3"]
threads: 4
- type: dns
reflectors: ["10.0.0.4"]
threads: 4
```
组合向量的价值：每个协议使用具有不同源 IP 的不同反射器。阻止 UDP/123 (NTP) 的防火墙规则不会阻止 UDP/161 (SNMP)。缓解必须逐协议进行。
## 6. Layer 7 模块 — 应用层
### 6.1 HTTP Flood (LOIC L7)
#### 为什么 L7 不同
SYN flood 在内核级别处理 —— 非常高效，但也容易被网络设备过滤。HTTP flood 必须由应用程序本身处理：Web 服务器必须解析头部，查找路由，可能还要进行数据库查询。
合法 HTTP 请求的成本比 SYN 数据包高得无法比拟：
```
SYN packet : kernel processing in a few microseconds, no memory allocated
HTTP request : header parsing, logging, route matching, possible DB query
-> thousands of times more expensive in CPU and memory
```
#### 缓存破坏 —— 绕过 CDN
如果没有缓存破坏，CDN/反向代理会对所有相同的请求返回相同的缓存响应。源站（应用服务器）什么都看不到。
有了缓存破坏：
```
http://target.com/search?q=test&_=1234567890
http://target.com/search?q=test&_=9876543210
http://target.com/search?q=test&_=1111111111
```
每个 URL 都是唯一的 -> 保证缓存未命中 -> 源站必须处理每个请求。
#### User-Agent 轮换和 X-Forwarded-For
基本 WAF 和速率限制器通过 IP 或 User-Agent 工作。FloodKit 在每个请求中变化这两者，还有 Accept-Language、Cache-Control 和 Referer 头部。
基于 IP 的速率限制器看到一个 IP（攻击者的）-> 容易阻止。
基于 X-Forwarded-For 的速率限制器在每个请求中看到不同的 IP -> 无法关联请求。
#### HTTP POST Flood —— 比 GET 成本更高
GET 处理很快（路由 + 静态或缓存响应）。带有 4096 字节正文的 POST 强制服务器：
1. 读取并缓冲完整正文
2. 解析内容（JSON、表单数据...）
3. 验证数据
4. 可能写入数据库
CPU 和 I/O 成本远高于 GET。
### 6.2 Slowloris (LORIS)
#### 概念 —— 在不发送任何内容的情况下占用 Worker
像 Apache prefork 这样的 HTTP 服务器维护一个线程或进程池，每个活动连接一个。此池有最大大小（`MaxRequestWorkers`，Apache 上默认为 256）。
HTTP/1.1 规定请求以空行 (CRLF CRLF) 结束。在服务器收到此行之前，它必须保持连接打开并等待更多数据。
Slowloris 利用这一点：
```
1. Open a TCP connection to the server
2. Send the beginning of an HTTP GET request without terminating it:
"GET / HTTP/1.1\r\nHost: target.com\r\nUser-Agent: ...\r\n"
(no final \r\n = incomplete request)
3. Every 10 seconds, send an additional useless header:
"X-Custom-Header-1234: randomvalue\r\n"
(to prevent the connection from timing out)
4. Never terminate the request
-> The Apache thread is blocked, waiting indefinitely
```
有 300 个此类套接字，所有 256 个 Apache worker 都会忙碌。合法连接会收到 ECONNREFUSED。
#### 为什么 nginx 有抵抗力
nginx 是事件驱动和异步的。一个 nginx worker 通过 epoll() 处理数千个并发连接。慢速连接不会阻塞其他连接。服务器只是维护一个计时器，并在 `client_header_timeout` 延迟（默认 60 秒）内没有进展的连接。
Apache 缓解配置：
```
# 启用 mod_reqtimeout
RequestReadTimeout header=20-40,MinRate=500
RequestReadTimeout body=20,MinRate=500
```
#### 在审计中确定 socket_count
```
# 在目标服务器上查找 MaxRequestWorkers
grep MaxRequestWorkers /etc/apache2/mods-enabled/mpm_prefork.conf
# 默认：150-256
# 以该值的 110% 启动
floodkit slow target.com -s 280 -d 120
# 观察影响：
# 合法连接：curl --connect-timeout 5 http://target.com/
# -> 如果超时 -> Slowloris 有效 -> MaxRequestWorkers 未受保护
```
### 6.3 Slow POST (RUDY — R-U-Dead-Yet)
#### 与 Slowloris 的区别
Slowloris：**头部**不完整（没有最后的 CRLF CRLF）。
Slow POST：**头部** **完整**但**正文**不完整。
--ntp
|
+-- Port 80/443 open?
| +-- Apache/IIS detected -> slowloris + slow_post + nuke
| +-- nginx -> http_flood (resists Slowloris)
| +-- WAF/CDN in front -> http_flood POST + cache_bust=true
|
+-- Any TCP port?
| +-- No SYN cookies -> syn_flood
| +-- Firewall present -> ack_flood (stateful?)
| +-- IDS in scope -> xmas_flood (detects?)
| +-- Any TCP service -> nuke (connection table)
|
+-- UDP services?
| +-- DNS port 53 -> udp_flood + dns_amp test
| +-- NTP port 123 -> ntp_amp test
|
+-- Amplifiers in scope?
| +-- SNMP community public -> sniper (~650x)
| +-- NTP monlist -> ntp_amp (~550x)
| +-- DNS open resolver -> dns_amp (~60x)
| +-- Active broadcast /24 -> smurf + fraggle
| +-- Multiple present -> spray (multi-vector)
|
+-- Legacy/OT/IoT equipment?
+-- Old kernel -> overlap (teardrop)
+-- Reassembly buffers -> ip_frag (last_only)
```
## 9. 安装与构建
### 9.1 Python 要求
```
pip install -r requirements.txt
# scapy>=2.5.0 : 原始包构造
# aiohttp>=3.9.0 : 异步 HTTP Flood
# click>=8.1.0 : CLI
# rich>=13.7.0 : TUI Dashboard
# pyyaml>=6.0 : YAML 配置
# 以开发模式安装（将 'floodkit' 添加到 PATH）
pip install -e .
```
### 9.2 构建 Native 后端
```
# 使用单个命令构建所有内容
make
# 或按组件
make c # libsender.so (requires gcc)
make rust # libfloodkit_packets.so (requires cargo)
make go # floodkit-engine (requires go)
# 检查可用内容
floodkit detect
```
### 9.3 安装工具链
```
# Debian/Ubuntu
sudo apt install gcc build-essential
# Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.cargo/env
# Go
sudo apt install golang-go
# 或来自 go.dev/dl/ 的最新版本
```
## 10. 完整 CLI 参考
### 攻击前扫描
```
# 带 NTP 探测的完整扫描
floodkit scan 192.168.1.100 --ntp
# 特定端口
floodkit scan 192.168.1.100 --ports 80,443,53,123,161,3306
# 快速扫描（100 workers，0.5s 超时）
floodkit scan 192.168.1.100 --workers 100 --timeout 0.5
```
### Layer 3/4 (需要 root)
```
# SYN Flood
sudo floodkit syn [-t threads] [--pps N] [-d seconds] [--no-spoof]
# ACK Flood
sudo floodkit ack [-t threads] [--pps N] [-d seconds]
# RST Flood
sudo floodkit rst [--flag R|F|RF] [-t threads] [-d seconds]
# XMAS Flood
sudo floodkit xmas [-t threads] [--pps N] [-d seconds]
# UDP Flood
sudo floodkit udp [-p port] [-s payload_size] [-t threads] [-d seconds]
# ICMP Flood
sudo floodkit icmp [-s payload_size] [-t threads] [-d seconds]
# SYN-ACK Flood
sudo floodkit tachyon [--port P] [--mode direct|reflected] [-r reflectors]
# IP 分片
sudo floodkit frag [--variant flood|last_only] [-d seconds]
# 分片重叠
sudo floodkit overlap [--variant teardrop|rose|tiny] [-d seconds]
```
### 放大 (需要 root)
```
# SNMP 反射
sudo floodkit sniper -r [--community public]
# NTP monlist
sudo floodkit ntp -r
# DNS 放大
sudo floodkit dns -r [--qtype ANY|DNSKEY]
# Smurf
sudo floodkit smurf -b
# Fraggle
sudo floodkit fraggle -b [--port 7|19]
# 多向量
sudo floodkit spray -c config/examples/spray.yaml
```
### Layer 7 (无需 root)
```
# HTTP Flood
floodkit http [-c concurrency] [-m GET|POST] [--post-size N] [-d seconds]
# Slowloris
floodkit slow [-p port] [-s sockets] [-i interval] [-d seconds] [--ssl]
# Slow POST
floodkit slowpost [-p port] [-s sockets] [--cl content_length]
# TCP 饥饿
floodkit nuke [-p port] [-s sockets] [--variant hold|window0|persist]
```
### YAML 配置
```
# 生成模板
floodkit gen http_flood my_profile.yaml
floodkit gen syn_flood test_syn.yaml
# 使用 Profile 运行
floodkit profile my_profile.yaml
# 检查可用的 Backends
floodkit detect
floodkit detect --compile # auto-compile if toolchain is present
```
### 通用选项
| 选项 | 描述 | 默认值 |
|--------|-------------|---------|
| `-d / --duration` | 持续时间（秒）(0 = 无限) | 30 |
| `-t / --threads` | Worker（仅 L3/L4） | 8-16 |
| `--pps` | 数据包/秒上限 (0 = 无限) | 0 |
| `--no-spoof` | 禁用 IP 欺骗 | off |
| `--no-log` | 禁用 JSONL 日志 | off |
## 11. Docker 实验室
### 架构
```
10.0.0.10 floodkit_attacker Python + tools + NET_RAW capability
10.0.0.20 target_apache Apache 2.4 (default config, Slowloris-vulnerable)
10.0.0.21 target_nginx nginx (Slowloris-resistant, good HTTP flood target)
10.0.0.99 monitor netshoot (iftop, tcpdump, ss, nload)
Network: isolated bridge 10.0.0.0/24 -- no internet access from containers
```
### 启动
```
cd lab/
docker compose up -d
# 攻击者 Shell
docker compose exec attacker bash
# 监控 Shell（单独终端）
docker compose exec monitor iftop -i eth0 -n
docker compose exec monitor watch -n1 'ss -s'
docker compose exec monitor tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0'
```
### 典型实验室测试
```
# Apache 上的 SYN Flood 测试
sudo python3 -m floodkit.cli.main syn target-apache 80 -t 8 -d 60 &
# 监控：ss -s -> 观察 SYN-RECV 攀升
# Apache 上的 Slowloris 测试
python3 -m floodkit.cli.main slow target-apache -s 300 -d 120 &
# 从监控端测试：curl --connect-timeout 5 http://target-apache/
# -> 如果 Slowloris 有效应超时
# 与 nginx（具有抵抗力）对比
python3 -m floodkit.cli.main slow target-nginx -s 300 -d 120 &
# curl http://target-nginx/ -> 仍然响应
```
## 12. 日志与报告
### JSONL 格式
每个会话自动创建一个 `logs/_.jsonl` 文件。
```
{"ts": 1710000000.0, "event": "start", "module": "syn_flood", "target": "192.168.1.100", "params": {"port": 80, "threads": 16, "duration": 60}}
{"ts": 1710000015.0, "event": "metrics", "packets": 212000, "avg_pps": 14133.0, "live_pps": 15200.0}
{"ts": 1710000030.0, "event": "metrics", "packets": 440000, "avg_pps": 14666.0, "live_pps": 15100.0}
{"ts": 1710000060.0, "event": "stop", "summary": {"packets": 888000, "avg_pps": 14800.0, "errors": 0, "backend": "c_sendmmsg"}}
```
### 汇总结果
```
# 所有会话摘要
for f in logs/*.jsonl; do
echo "=== $f ==="
cat "$f" | python3 -c "
import sys, json
for line in sys.stdin:
e = json.loads(line)
if e['event'] == 'stop':
s = e['summary']
print(f\" packets={s.get('packets',0):,} avg_pps={s.get('avg_pps',0):,.0f} backend={s.get('backend','?')}\")
elif e['event'] == 'start':
print(f\" target={e['target']} module={e['module']} params={e['params']}\")
"
done
# 导出 CSV 用于报告
python3 -c "
import json, glob, csv, sys
rows = []
for f in glob.glob('logs/*.jsonl'):
session = {}
for line in open(f):
e = json.loads(line)
if e['event'] == 'start':
session.update(e)
if e['event'] == 'stop':
session.update(e.get('summary', {}))
rows.append(session)
writer = csv.DictWriter(sys.stdout, fieldnames=['module','target','packets','avg_pps','errors','backend'])
writer.writeheader()
writer.writerows(rows)
" > report.csv
```
*FloodKit v4 — 研究文档*
*仅在签署合同约定的范围内使用。*
标签：ACK泛洪, AES-256, ASM汇编, Bash, DAST, DDoS攻击, DNS放大, DoS工具, DRDoS, Fraggle攻击, Go, HTTP Flood, ICMP泛洪, IP分片, Layer 3, Layer 4, Layer 7, LOIC, NTP放大, Perl, Python, Ruby工具, RuleLab, Rust, Slowloris, Smurf攻击, SNMP反射, SYN Flood, SYN泛洪, TCP/IP, UDP Flood, XMAS攻击, 代码生成, 内核驱动, 压力测试, 反射攻击, 可视化界面, 多语言, 带宽消耗, 应用安全, 应用层攻击, 恶意软件分析, 拒绝服务, 攻击向量, 放大攻击, 无后门, 日志审计, 洪水攻击, 渗透测试工具, 漏洞评估, 网络包构造, 网络协议, 网络安全, 网络层攻击, 网络流量审计, 请求拦截, 资源耗尽, 逆向工具, 配置错误, 隐私保护, 黑盒测试