简介：在网络安全领域，拒绝服务攻击（DoS/DDoS）是威胁业务可用性的典型手段，其核心原理是通过大量请求或畸形报文耗尽目标系统的带宽、连接或计算资源。其中，SYN Flood利用TCP三次握手的半连接队列漏洞，以极小成本就能阻塞服务，是入门DDoS防御的最佳切入点。理解这类攻击的价值在于：从攻击视角识别资源瓶颈，进而制定有效的防护策略。通过hping3模拟压测、tcpdump抓包分析、内核参数调优（如tcp_syncookies）等实验手段，运维人员可以在隔离虚拟环境中直观掌握攻击特征与防御响应的完整链路。文章结合本地虚拟化环境，手把手演示拒绝服务攻击实验的搭建、观测与防御落地，适用于运维工程师、安全学习者快速建立实战化防护能力。

1. 拒绝服务攻击实验：先造事故，再学防御

半夜两点，运维群弹出一条告警：入口带宽打满，Nginx 全线超时。你打开流量图，只看到一条直线冲顶，连对方打的是哪一层都不知道。这种时刻，平时背过的拒绝服务攻击原理帮不上忙，我第一次值班遇到这事，连抓包都不知道从哪看起。后来带新人做安全训练，我坚持让他们从拒绝服务攻击实验入手：在隔离网络里拉两台虚拟机，一台当靶机跑 Nginx，一台发攻击流量，亲眼看着半连接队列被填满、业务挂掉。这个实验不是教你怎么使坏，而是用受控事故把“网络攻击”从概念变成可量化的指标——队列溢出数、重传比例、带宽曲线。适合刚接手运维的工程师、安全方向的在校生，以及所有想给线上服务加防护的人。

2. 从SYN洪水到HTTP慢速：拒绝服务攻击的四类打法与实验选型

拒绝服务攻击（DoS）的目标很单一：让目标设备或业务的资源耗尽，没法服务正常用户。按消耗的资源类型，可以分成带宽型、连接型和应用层型三类。真实世界看到的更多是分布式拒绝服务（DDoS），源IP分散在僵尸网络里；但实验阶段用单源IP去模拟，特征更干净，抓包和防御前后对比都容易做。下面按资源怎么被耗掉的角度拆四类打法，顺便说清为什么实验闭环要从 SYN Flood 开始。

2.1 SYN Flood：三次握手的半连接黑洞

TCP 握手要经过 SYN、SYN-ACK、ACK 三步。服务端收到 SYN 后，会分配一小块内存记录这个连接状态，并返回 SYN-ACK，等待客户端补一个 ACK。这个还没完成的连接叫半连接，存在内核的 syn queue 里，队列长度由 backlog 控制。很多人会把它和 accept queue 搞混：syn queue 管的是“没握完手的”，accept queue 管的是“握完手但应用还没 accept 的”。SYN Flood 盯着的是前者。

SYN Flood 的打法就是只发第一步：不断以随机或固定的源地址发 SYN 包，服务端回的 SYN-ACK 永远等不到 ACK。syn queue 被占满后，新到的 SYN（包括正常用户的）直接被内核丢弃。在内核日志里会看到 possible SYN flooding 的提示，抓包则表现为大量 SYN 包进来、后续没有对应 ACK。这里的重点是：攻击者不需要很大带宽，几千个半连接就能让一个小型服务器的 80 端口拒绝新连接。而且这些半连接不只是占一条记录，每一次分配和重传都要付出 CPU 和内存操作的开销，所以小包也能造成大伤害。

2.2 UDP反射放大与ICMP洪泛：带宽型攻击的粗暴力

带宽型攻击不跟你玩握手，直接用大流量打物理链路。ICMP Flood 最简单，用 hping3 发--icmp就能打，但如今网络设备普遍对 echo request 做限速，效果一般，更多是作为辅助手段压着你的出口带宽。真正让运营商头疼的是反射放大：攻击者伪造受害者的 IP，向开放的 DNS、NTP、memcached 服务发很小的查询包，应答包被放大几十倍后转发到受害者。一个 60 字节的 DNS ANY 查询可能触发超过 4000 字节的应答，放大比接近 70:1。

这类攻击的特征是入向带宽突然打满，抓包看到大量来自不同源 IP 和随机端口的数据报。实验里最难模拟的也是放大链路——你要先在本地跑一个有递归查询的 DNS 服务，再伪造源地址去发查询，多数人做到一半就放弃了。所以实验室验证带宽型攻击时，我会先用 ICMP Flood 感受带宽和延迟的对应关系，再直接去找真实的反射攻击抓包样本分析，而不是真的搭一套完整的 NTP 放大环境。这里要留个印象：带宽型攻击的防御通常不在单台服务器上，而在机房入口或云清洗设备上。

2.3 HTTP慢速攻击：应用层的低带宽绞杀

慢速攻击走的是另一条路：连接是正常的，就是不发完数据。最典型的是 Slowloris，客户端与服务器之间 TCP 握手已经是完整的，但它只发一个残缺的 HTTP 请求头，之后每隔几十秒补一个小片段，让服务器一直傻等。Nginx 的 worker 连接数是有限的，几千个这种“活着但不干活”的连接就能占满进程表，正常用户的请求排不上队。

这类攻击的阴险之处是带宽占用极低，防火墙基本看不到明显的流量异常，只能从“连接数上涨、请求数不动”的比值去发现。实验里用 Python 脚本模拟慢速请求头最方便，每隔 2 秒发一个字符，Nginx 的 active connections 会缓慢爬升。与 SYN Flood 相比，它干的不是内核协议栈，而是应用层的连接数上限，所以防御手段也从内核参数换到了 Nginx 的client_header_timeout和每 IP 连接数限制。

2.4 为什么实验首选SYN Flood

在实验室里，我向来先选 SYN Flood，而不是慢速攻击或 UDP 反射。理由很直接：它有一条最清晰的“攻击—观测—防御”闭环。攻击端一条 hping3 命令就能打；靶机上用 tcpdump 能直接看到半连接堆积，内核的 ListenOverflows 计数是现成的量化指标；调整 tcp_syncookies 和 backlog 后，同一条命令打过来，队列溢出数字立刻下降。这种眼见为实的反馈，对理解 TCP 协议栈的防御机制非常关键。

相比之下，慢速攻击要观察 Nginx 连接数变化，采样周期更长；反射放大要搭依赖服务，实验链路长。SYN Flood 至今仍然是现实攻击的标配，而且防御参数（syncookies、backlog、synack_retries）正好是你能在生产服务器上直接改的那几个，学它绝对不会学偏。所以后面三章的环境、命令和防御策略，都围绕 SYN Flood 展开。

3. 搭建本地对抗环境：两台虚拟机、三类工具与最小压测命令

3.1 虚拟网络拓扑：攻击机、靶机与抓包端如何分工

在 VirtualBox 或 KVM 里建两台 Linux 虚拟机，攻击机和靶机都用 Debian 系的发行版，省得在不同包管理器之间来回切换。网络模式不要用默认 NAT：NAT 下两台虚机共享宿主机的 IP，出来进去的包要转好几道，抓包会混入大量与实验无关的广播和网关流量。推荐 Host-Only 或内部网络模式，给两个网卡配同一个网段的静态 IP，比如靶机192.168.56.101/24，攻击机192.168.56.102/24。

这个拓扑的关键在分工：攻击机负责构造并发送原始 TCP 包，靶机负责承受攻击并提供抓包样本。不需要在中间再加一台交换机或做端口镜像，因为 SYN Flood 的攻击流量会直接到达靶机网卡，靶机上的 tcpdump 即可捕获全量。如果你在 Windows 宿主机上用 Wireshark 监听虚拟网卡也能看，但会同时收到 DHCP、ARP 这类噪声，不如在靶机上直接抓包干净。还有一点容易被忽略：不要用 Docker 容器代替靶机。容器共享宿主机内核，改sysctl或iptables会直接影响宿主机，黏贴命令时手一抖就可能把开发机网断掉。

3.2 安装工具与靶机服务：最小依赖清单

靶机上开一个普通 Nginx 就够了，不要开 HTTPS。TLS 握手本身有额外开销，它会掩盖 SYN Flood 对纯 TCP 半连接的冲击，初学者容易把 TLS 超时和队列溢出混在一起。攻击机上装 hping3 和 tcpdump，一条 apt 命令搞定。注意 hping3 需要 root 权限，因为它要用原始套接字构造包；普通用户执行会直接报 Operation not permitted。

# 攻击机：压测与抓包工具 sudo apt update && sudo apt install -y hping3 tcpdump # 靶机：Nginx 作为受攻击的目标服务 sudo apt install -y nginx iftop sudo systemctl enable --now nginx

命令说明：hping3 是构造和发送自定义 TCP/UDP/ICMP 报文的工具，这里只用它的 SYN 模式；tcpdump 是靶机上抓包的工具；iftop 用来实时观察带宽占用。Nginx 是占位服务，只要 80 端口处于 LISTEN 状态，SYN Flood 才会触发半连接队列逻辑。如果 80 端口没有服务监听，内核收到 SYN 后直接回 RST，半连接队列根本不会建立，攻击效果也看不出来。

装完后在靶机上确认 Nginx 状态，这一步别省，后面所有判断都建立在“靶机服务正常”这个基线上：

# 确认 80 端口在监听，并返回正常 HTTP 响应 ss -lnt | grep :80 curl -I -m 3 http://127.0.0.1

如果 curl 失败，先查 Nginx 是否启动、80 端口是否被防火墙挡掉，再做压测。攻击机的 hping3 也顺手确认一下版本，hping3 -V能跑出来就行。基线和工具状态都正常，后面抓包、看指标才有意义。

3.3 跑一次SYN Flood压测：hping3的最小命令与参数含义

第一次压测建议用固定源 IP，不要加--rand-source或--rand-dest。原因有两个：一是固定源 IP 时你能在抓包里看清“同一个源发来大量 SYN，服务端回了 SYN-ACK 但没有任何 ACK 跟回”，这是 SYN Flood 最直观的画面；二是固定源 IP 方便你用ss单独过滤它的半连接变化。加上随机源 IP 是真实 DDoS 的形态，但刚上手的阶段只会增加阅读抓包的难度。

# 在攻击机上执行，目标靶机 192.168.56.101 # -S 发送 SYN 包，-p 80 打 80 端口，--flood 快速连续发送，-c 50000 限制总包数 sudo hping3 -S -p 80 --flood -c 50000 192.168.56.101

参数说明：-S指定 TCP SYN 标志；-p 80是目标端口；--flood让 hping3 忽略攻击机收到的任何响应、以最快速度发包，此时屏幕不会刷新包计数；-c 50000限制发包总量为 5 万，防止把整个实验网络打瘫。首次实验不要把-c去掉，--flood不带-c会坚持发到攻击机自己停机，我在实验环境里翻过车，整台虚机像陷入死循环一样，只能重启。

另一个终端同时登录靶机，抓取攻击特征。建议把 tcpdump 命令提前写好，一发压测命令立刻开始抓，因为 5 万个 64 字节的包在内网千兆环境下几秒就跑完了：

# 在靶机上抓取目的端口为 80 的 SYN 包，存到 pcap 文件后退出 sudo tcpdump -i eth0 'dst port 80 and tcp[13] & 0x02 != 0' -c 1000 -w /tmp/syn_flood.pcap

过滤条件说明：tcp[13] & 0x02 != 0是 TCP 头标志位的字节判断。tcp[13] 对应 TCP header 第 14 个字节，0x02 是 SYN 位的掩码；-c 1000表示抓到 1000 个包就自动退出，避免 pcap 文件膨胀到几百 MB；-w落盘，方便后半段用 tcpdump -r 慢慢分析。压测跑完后，在靶机上执行curl -I -m 5 http://127.0.0.1，如果卡住或超时，说明攻击已经把 Nginx 的新连接挡掉了。

注意：实验用的 Host-Only 网段是隔离网络，压测流量不会出物理机。千万不要在办公网或对线上服务器执行同样的命令，否则会触发边界防火墙告警，也会给自己惹上麻烦。实验前把虚拟机快照存一份，调坏内核参数还能后悔药。

4. 从抓包到指标：判定攻击命中与评估伤害的四个观察点

4.1 tcpdump抓包判读：SYN重传与半连接的读法

压测结束回到靶机，用tcpdump -r /tmp/syn_flood.pcap回放抓到的包。先统计源 IP 和源端口分布，如果看到同一个源 IP 反复发 SYN 到 80 端口，且源端口固定不变或规律递增，这就是攻击流量。正常用户的握手不会这样成百上千次地重复连接同一端口。更关键的判据是重传：服务端收到 SYN 后会回 SYN-ACK，正常客户端收到后会回 ACK 完成握手；攻击者根本不回应，内核只能按tcp_synack_retries配置重发 SYN-ACK。所以抓包里会出现“SYN 包密集 + 大量 SYN-ACK 重传”的组合。

用命令统计一下比例更直观。把 pcap 里带有 SYN-ACK 标志的包数除一下总包数，如果 SYN-ACK 占比明显高于正常握手场景（正常约 30%，攻击场景会超过 60%），基本可以确认半连接堆积。注意 tcpdump 用-S参数会显示完整序列号，对比同一连接的四元组，能看到 SYN-ACK 的序列号原地增加，这就是重传的铁证。

4.2 ss与netstat：监听队列的实时状态

抓包是事后分析，判断当前是否正在被打，靠的是内核的实时计数器。靶机上执行ss -lnt | grep :80，看Send-Q那列。当 SYN 队列满时，Send-Q会显示当前排队的连接数，如果它持续大于Recv-Q且不再降下来，就是队列溢出的信号。更权威的是/proc/net/netstat里的ListenOverflows，netstat -s也会打印LISTEN OVERFLOWS计数。

由于它是累计值，不要只看一次。我一般这样采样：攻击开始前记一个值，攻击结束后再记一个值，两次的差值就是这次攻击塞进队列的总量。流量正常时差值保持在个位数，SYN Flood 跑 5 万个包时，这个差值会以千为单位增长，非常直观。这一步提供的是“攻击有没有打中协议栈”的硬证据，比看带宽曲线精确得多。实际操作时可以直接循环采样：

# 在靶机上连续采样三次，每次间隔1秒，观察OVERFLOWS累计值是否递增 for i in 1 2 3; do netstat -s | grep "LISTEN OVERFLOWS"; sleep 1; done

4.3 nginx日志与业务失败验证：服务到底挂没挂

协议栈被打满，最终要落到业务能不能访问。在攻击进行到一半时另开一个终端执行curl -I -m 5 http://192.168.56.101，如果命令卡到超时才返回或者直接显示Connection timed out，说明 Nginx 已经无法接受新连接。但要注意：如果 curl 是从攻击机发起，而攻击机的网卡正在被 hping3 全速发包占用，curl 超时可能是攻击机自己发送队列被挤满，不一定是靶机的问题。所以业务验证要么在靶机上对 127.0.0.1 自测，要么在第三台管理机上执行。

Nginx 的错误日志也是一个辅助佐证，在/var/log/nginx/error.log里会看到connect() failed (99: Cannot assign requested address)之类的记录，但它是 Nginx 主动向后端建立连接时才出现的，作为纯前端 Nginx 不太会触发。我更常看的是access.log里请求时间戳的断档：攻击期间少了大量正常请求，恢复后重新出现。判断标准是：抓包有 SYN、内核有 ListenOverflows 增长、Nginx 响应超时，三者同时满足，才算一次完整的命中。少任何一个，都说明防线或观测点有问题。

4.4 带宽与软中断交叉确认：流量去了哪一层

SYN Flood 用的包很小，很多新手看带宽曲线发现只有 1-2 Mbps，便怀疑攻击没生效。实际上小包攻击看的是 PPS（每秒包数）而不是带宽。靶机上用iftop看的是带宽，要结合top的%si（软中断）指标一起看：如果 si 涨到了 30% 以上而 Nginx 的 CPU 占用依然接近 0%，说明流量被内核协议栈截在内核态处理，属于典型的小包洪泛特征。这也解释了为什么你开一个大带宽的云主机照样被 SYN Flood 拖垮——瓶颈不在链路而在协议栈的处理能力。

如果你想看 PPS，可以用perf或tc统计，但对小实验来说top的 si 加netstat -s的 overflow 已经够用。这里把四个观察点放在一起做个对照表，方便你在实验记录里直接抄：

5. 防御落地与常见问题排查：sysctl、iptables与四个必调参数

5.1 sysctl调优：syncookies、backlog、synack_retries的权衡

防御的第一层，在协议栈本身。SYN Flood 打的是半连接队列，内核提供了三个直接相关的旋钮：net.ipv4.tcp_syncookies、net.ipv4.tcp_max_syn_backlog、net.ipv4.tcp_synack_retries。在靶机上先确认当前值再修改，Debian 系默认tcp_syncookies=1是开着的，但backlog默认只有 1024，synack_retries是 5。

# 靶机上临时调整TCP内核参数，压测后再考虑持久化 sudo sysctl -w net.ipv4.tcp_syncookies=1 sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048 sudo sysctl -w net.ipv4.tcp_synack_retries=2

参数说明：tcp_syncookies=1让内核在半连接队列满时把连接信息编码进 SYN-ACK 的序列号，不占队列，是 SYN Flood 的第一道兜底；tcp_max_syn_backlog=2048调大半连接队列容量，缓解突发压力，但每个半连接要占约 128 字节内存，调得太大反而拖慢系统；tcp_synack_retries=2迫使没有 ACK 的半连接在更短时间内被清理，相当于给队列里的“死连接”加速垃圾回收。这三个参数组合的效果是：队列变大、死连接活不久、实在不够还有 cookie 兜底。

注意它们不是万能的。syncookies 只在队列满时才启用，它保护的是新建连接不被拒绝，但攻击流量仍然在消耗 CPU 和带宽。所以协议栈调参只能作为第一层防线，后面要配 iptables 做速率限制。实验里我一般先把backlog调小到 256、让攻击先打满队列，再依次加回 cookie 和重传参数，观察 overflow 差值逐步回落，这样能清楚地看到每个参数各自的贡献。最后用sudo sysctl -p写入/etc/sysctl.conf才能在重启后保留，生产环境改这些参数前要评估对正常建连的影响，尤其是synack_retries调太低会让真实用户的弱网连接更脆弱。

5.2 iptables限速与SYN代答：把实验流量挡在第一公里

第二层防线是防火墙。iptables 用-m limit限制 SYN 包的到达速率，超过阈值的包直接丢弃。这个规则要放在 INPUT 链的前面，保证先于其他 ACCEPT 规则执行。

# 限制每 IP 每秒最多 20 个 NEW 状态的新连接，突发量 50 个 sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 20/sec --limit-burst 50 -j ACCEPT # 超出的 NEW 连接直接丢弃 sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j DROP

参数说明：--limit 20/sec是平均速率；--limit-burst 50是初始突发额度，用来吸收正常突刺；-m state --state NEW只匹配握手阶段的第一个包，已经建立的连接不受影响。生产环境里还会用到更复杂的 SYN Cookie 优化和分布式流量清洗，但实验室里 iptables 的 limit 已经足够展示限速效果。改完规则后重复第 3 章的压测命令，观察 OVERFLOWS 差值明显下降，就说明第一层协议栈参数和第二层限速一起生效了。

如果压测机源 IP 固定，你还可以用-s 192.168.56.102单独拒绝攻击机，但这种方式实用性不强，因为真实攻击的源 IP 是变化的；实验里观察一下“默认 ACCEPT 策略被 DROP 末尾兜住”的规规矩矩就能明白，防火墙规则的作用是将异常流量挡在业务之前，而不是事后救火。

5.3 实验中的四个踩坑记录：现象、原因、解决

1. 压测一开始，攻击机自己先掉线。现象：hping3 运行几秒后，SSH 断连，虚拟机的鼠标键盘都没反应。 原因：--flood不加-c，满速发包占满了攻击机自身网卡的发送队列，连它的 TCP 协议栈都被饥饿。这不是被靶机反打的，是把自己打死了。 解决：压测永远带-c限制总量，或者用timeout 30 hping3包一层；需要更低强度时改用--fast代替--flood，--fast的包间隔更温和。

2. 抓包看到几百个 SYN，但 Nginx 一直正常。现象：tcpdump 里全是 SYN，可curl 127.0.0.1秒回，netstat -s的 OVERFLOWS 也不涨。 原因：80 端口没监听，或者 backlog 默认值太大，攻击包的速率不足以填满队列。Debian 12 默认tcp_max_syn_backlog=1024，单个源发 5 万个包时队列只是短暂满，正常用户的握手在溢出之前就完成了。 解决：把tcp_max_syn_backlog临时调到 256，再用同样命令打，几秒内就能看到 OVERFLOWS 数上涨。

3. 开了 syncookies，OVERFLOWS 不涨了，但 curl 变慢。现象：第二次压测时 OVERFLOWS 保持不变，可正常请求在攻击期间的响应时间涨了十倍。 原因：syncookies 生效时，内核不保留半连接，需要客户端在收到 SYN-ACK 后再回来建连；攻击流量把靶机网卡的中断和内存带宽占掉了，正常 ACK 处理被拖慢，所以握手变慢。 解决：syncookies 是兜底不是扛流量，实验里应该叠加 iptables 限速或直接调小tcp_max_syn_backlog，让队列没机会满，syn queue 也不需要走到 cookie 分支。

4. iptables 限速规则加了，攻击流量还是全进来，OVERFLOWS 照涨。现象：规则明明在 INPUT 链上，压测后iptables -L -n -v显示匹配的包数是 0。 原因：Debian 精简内核没加载nf_conntrack模块，-m state匹配失效，规则被静默跳过；或者规则挂在了一条更宽的 ACCEPT 后面，iptables 按顺序匹配，先被放行了。 解决：先执行modprobe nf_conntrack，再用iptables -L -n --line-numbers检查规则顺序，把限速规则插到第 1 行，最后用iptables -Z清零计数再压测，确认-v里的匹配包数在增长。

6. 用三次小流量实验校准防御参数：验证与复盘

这里的验证思路，是把“攻击前、攻击中、恢复后”三个状态各采样一组指标，然后对比参数调整前后的差值。强烈建议做成一个脚本，而不是手动在终端里一条条戳。脚本会把采样过程固化下来，后面再测 UDP Flood 或慢速攻击时，只需要替换中间的压测命令，统计逻辑完全可以复用。

#!/bin/bash # 攻击前采样 echo "=== before ===" date netstat -s | grep "LISTEN OVERFLOWS" ss -lnt | grep :80 # 发起压测，限制 30 秒 timeout 30 sudo hping3 -S -p 80 --flood -c 60000 192.168.56.101 # 恢复后采样（等 10 秒让队列清理） sleep 10 echo "=== after ===" netstat -s | grep "LISTEN OVERFLOWS" curl -I -m 5 http://192.168.56.101

分别在不同防御配置下各跑一次，记录OVERFLOWS的增量：第一次用默认参数，第二次调tcp_max_syn_backlog=256并重启 hping3，第三次加上 iptables 限速。这样你手上就有三组可比数据，增量越小说明防御策略越有效。注意timeout命令要放在 hping3 前面，避免攻击机被--flood卡死时无人收场。

实验做完，按照下面这个表整理一次复盘记录，把攻击特征和防御参数对应起来：

我第一次做这个实验时，跟大多数新手一样只盯着攻击机的输出，看到屏幕上 hping3 一直在刷就以为成功了，结果靶机上的 Nginx 一直好好的，参数怎么调都不见变化。后来才发现是没在靶机上持续采样队列状态，攻击数据没留存，调参前后对比根本无从谈起。从那以后我养成了一个习惯：攻击前、攻击中、恢复后各采样一次，把三组数据贴进实验记录，再讨论调参效果。这个习惯一直沿用到现在排查真实 DDoS 时，它帮我把“流量到底打在哪一层”这个黑匣子撬开了一条缝。希望帮到你。

本文还有配套的精品资源，点击获取