Wireshark抓包分析实战：从数据包发现攻击痕迹

摘要：# Wireshark抓包分析实战：从数据包发现攻击痕迹 我前两天帮一个做电商的朋友看他们服务器，他跟我说最近总觉得网站“卡”，但看监控CPU、内存都正常。我让他抓了半小时流量，用Wireshark一筛——好家伙，同一秒里冒出来几十个SYN包，源IP还全…

我前两天帮一个做电商的朋友看他们服务器，他跟我说最近总觉得网站“卡”，但看监控CPU、内存都正常。我让他抓了半小时流量，用Wireshark一筛——好家伙，同一秒里冒出来几十个SYN包，源IP还全是乱编的。这要不是有人在试探性搞SYN Flood，我把键盘吃了。

这种场景你应该不陌生吧？服务器没瘫，但就是不对劲。很多运维同学第一反应是去查日志，其实流量本身才是最诚实的目击者。今天咱们就聊聊，怎么用Wireshark这个老伙计，从海量数据包里揪出那些不怀好意的“小动作”。

一、先泼盆冷水：别指望“一键报警”

很多新手以为装个Wireshark，设置个告警规则，攻击来了就会滴滴响——想多了。这工具更像法医的解剖刀，不是防盗报警器。它的价值在于事后复盘和深度排查。真遇到大规模DDoS，流量把网卡都打满了，你抓包都抓不到。

（说真的，很多安全厂商的演示视频里，攻击流量都像幼儿园排队一样整齐，实际战场哪有那么讲武德。）

所以咱们今天聊的，主要是针对那些低频、慢速、伪装好的攻击，比如：

• 业务突然变慢，但资源使用率不高
• 后台出现零星异常登录
• 某个API接口响应时间诡异飙升
• ……总之，就是那种“感觉不对，又没证据”的时候。

二、实战开始：从这三类包入手

打开Wireshark，面对瀑布般刷新的数据流，别慌。咱们先盯住几个关键点，它们往往是攻击的“签名”。

1. SYN包泛滥——半连接攻击的烟头

SYN Flood太经典了，但现在的攻击者也不傻，很少用真实IP狂轰滥炸。更多是低频率、分布式的SYN试探。

怎么看？ 在Wireshark里用这个过滤表达式：

tcp.flags.syn==1 and tcp.flags.ack==0

然后统计一下目标IP和端口（Statistics -> Conversations -> TCP）。如果你发现某个服务器端口（比如80、443）收到了来自成百上千个不同IP的SYN请求，但后续几乎没有完整的TCP三次握手——恭喜，你很可能被盯上了，对方在测你的端口状态和抗压能力。

更隐蔽的一种：SYN包间隔规律，比如每分钟来一波。这可能是攻击脚本在“礼貌性”扫描。我见过一个案例，攻击者用云函数每30秒发几个SYN，持续了三天，才突然加大力度。

2. HTTP请求的“鬼影”——CC攻击的脚印

CC（Challenge Collapsar）攻击专打应用层。它不像DDoS那么暴力，而是模拟真实用户，疯狂请求你网站最耗资源的页面（比如搜索、登录、复杂报表）。

抓包特征很明显：

• 请求频率非人类：用 http.request 过滤器。如果一个IP在几秒内对同一个URL（比如 /search?q=xxx）发起几十次GET请求，速度远超人手点击，那基本是机器人。
• User-Agent雷同或异常：大量请求使用相同的、冷门的，或者明显是脚本生成的User-Agent。
• 盯着一个接口薅：在Statistics -> HTTP -> Requests里，看看哪个URL被请求次数断层第一。如果是登录接口或验证码接口，那意图就很明显了——撞库或者打瘫你的认证服务。

有个坑要注意：别把CDN的回源请求误杀了。有时候看起来同一个源IP狂请求，其实是CDN节点，记得先排除。

3. 畸形包与协议异常——漏洞利用的前戏

这种攻击比较“技术流”，目的是利用协议栈或应用漏洞。

• 碎片化攻击：在Edit -> Preferences -> Protocols -> IP 里，看看有没有大量“Fragment overlap”之类的警告。攻击者可能发送畸形的分片数据包，试图绕过防火墙或搞垮老式设备。
• 异常协议交互：比如DNS查询突然暴涨（过滤 dns），且查询域名都是随机字符串，这可能是DNS反射放大攻击的反射源在被利用；或者SMTP、RDP等协议出现大量连接尝试，说明有人在暴力破解。
• TCP标志位“鸡尾酒”：过滤 tcp.flags 找那些标志位组合奇怪的包，比如 SYN+FIN（同时要求建立和关闭连接），这种包在正常通信里极少见，通常是扫描器或攻击工具在“搞行为艺术”，试探系统响应。

三、我的排查流水账（举个真实例子）

上个月，一个游戏服主找到我，说玩家间歇性掉线。日志干干净净。我让他抓了段高峰期的包。

第一步，整体观感。 打开捕获文件，第一眼就看见Time列不对劲——数据包不是均匀来的，而是一坨一坨地涌进来。这本身就暗示可能有流量脉冲。

第二步，找“最忙”的IP。 进Conversations，按包数排序。排第一的不是游戏服务器IP，而是一个陌生的外网IP，和服务器在疯狂交换UDP小包。游戏主要用TCP，这UDP流量哪来的？

第三步，深挖这个会话。 右键Follow -> UDP Stream。内容是一堆乱码和少量可读字符，反复发送类似“getstatus”的字符串。明白了，这是有人在利用该游戏引擎一个老的查询协议漏洞，发送大量状态查询请求（UDP协议，无连接，服务器都得回应），把服务器带宽和CPU给“磨”没了。这本质上是一种低成本的UDP反射/放大攻击变种。

第四步，定位源头。 虽然攻击IP可能是伪造的，但结合包到达的时间规律和少量真实源IP，我们最终在防火墙层面加了规则，把这种特征异常的UDP包在入口就给限速了。问题解决。

整个过程中，Wireshark没告诉我“这是攻击”，但它把证据都摆在我眼前了。

四、给你的几个“私货”建议

1. 抓包位置是关键。在服务器本机抓，能看到所有流量；在网关或镜像口抓，能看到南北向全貌。问题定位阶段，尽量靠近源服务器抓。
2. 过滤表达式是你的手术刀。别生记，多用Wireshark的“Expression…”按钮勾选，慢慢就熟了。常用几个记住：ip.src==x.x.x.x, tcp.port==80, http contains "admin"。
3. 别忽视“Conversations”和“Endpoints”。这两个统计视图（Statistics菜单下）是发现异常通信的捷径，比肉眼刷瀑布流高效十倍。
4. 保存证据。发现可疑流量，记得用 File -> Export Specified Packets 把相关包单独存下来，方便后续分析和留档。
5. 工具链结合。Wireshark很强，但不是万能的。复杂攻击分析可以结合 tcpdump（命令行抓包）、tshark（Wireshark命令行版）写脚本做自动化初筛，再用Wireshark图形界面深度分析。

五、说点大实话

指望靠Wireshark 7x24小时防护网站？不现实。它是个诊断工具，不是防护设备。真正的安全防护，是靠合理的架构（比如加高防CDN、隐藏源站）、靠谱的WAF、以及完善的监控告警体系。

但当你感觉“哪里不对”，又找不到原因时，静下心来抓个包，用上面说的方法过一遍——数据包永远不会说谎。那种从混沌流量里亲手揪出攻击线索的感觉，比看一百篇安全报告都来得实在。

行了，工具给你了，思路也讲了，下次遇到“玄学”问题，别光挠头，知道该干嘛了吧？