拒绝服务攻击实验：从SYN Flood原理到防御调优

简介在网络安全领域拒绝服务攻击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 系的发行版省得在不同包管理器之间来回切换。网络模式不要用默认 NATNAT 下两台虚机共享宿主机的 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里的ListenOverflowsnetstat -s也会打印LISTEN OVERFLOWS计数。由于它是累计值不要只看一次。我一般这样采样攻击开始前记一个值攻击结束后再记一个值两次的差值就是这次攻击塞进队列的总量。流量正常时差值保持在个位数SYN Flood 跑 5 万个包时这个差值会以千为单位增长非常直观。这一步提供的是“攻击有没有打中协议栈”的硬证据比看带宽曲线精确得多。实际操作时可以直接循环采样# 在靶机上连续采样三次每次间隔1秒观察OVERFLOWS累计值是否递增 for i in 1 2 3; do netstat -s | grep LISTEN OVERFLOWS; sleep 1; done4.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 已经够用。这里把四个观察点放在一起做个对照表方便你在实验记录里直接抄观察点命令命中信号抓包tcpdump -r xx.pcap大量SYN出现SYN-ACK重传比例高队列netstat -s | grep OVERFLOWS累计值两次采样差值以千为单位增长业务curl -I -m 5 127.0.0.1超时access.log 时间戳断档系统top 看 %si、iftop 看带宽带宽不高但 %si 超过 30%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_syncookies1是开着的但backlog默认只有 1024synack_retries是 5。# 靶机上临时调整TCP内核参数压测后再考虑持久化 sudo sysctl -w net.ipv4.tcp_syncookies1 sudo sysctl -w net.ipv4.tcp_max_syn_backlog2048 sudo sysctl -w net.ipv4.tcp_synack_retries2参数说明tcp_syncookies1让内核在半连接队列满时把连接信息编码进 SYN-ACK 的序列号不占队列是 SYN Flood 的第一道兜底tcp_max_syn_backlog2048调大半连接队列容量缓解突发压力但每个半连接要占约 128 字节内存调得太大反而拖慢系统tcp_synack_retries2迫使没有 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_backlog1024单个源发 5 万个包时队列只是短暂满正常用户的握手在溢出之前就完成了。 解决把tcp_max_syn_backlog临时调到 256再用同样命令打几秒内就能看到 OVERFLOWS 数上涨。3. 开了 syncookiesOVERFLOWS 不涨了但 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_backlog256并重启 hping3第三次加上 iptables 限速。这样你手上就有三组可比数据增量越小说明防御策略越有效。注意timeout命令要放在 hping3 前面避免攻击机被--flood卡死时无人收场。实验做完按照下面这个表整理一次复盘记录把攻击特征和防御参数对应起来攻击类型核心观测指标实验室最小防御闭环SYN FloodListenOverflows、SYN-ACK 重传率tcp_syncookies backlog iptables limitUDP/ICMP Flood入向带宽、softirq %si入口限速、流量清洗HTTP 慢速攻击active connections 上涨、带宽低client_header_timeout、每 IP 连接数限制我第一次做这个实验时跟大多数新手一样只盯着攻击机的输出看到屏幕上 hping3 一直在刷就以为成功了结果靶机上的 Nginx 一直好好的参数怎么调都不见变化。后来才发现是没在靶机上持续采样队列状态攻击数据没留存调参前后对比根本无从谈起。从那以后我养成了一个习惯攻击前、攻击中、恢复后各采样一次把三组数据贴进实验记录再讨论调参效果。这个习惯一直沿用到现在排查真实 DDoS 时它帮我把“流量到底打在哪一层”这个黑匣子撬开了一条缝。希望帮到你。本文还有配套的精品资源点击获取