Wireshark抓包定位SSDP内网攻击：从镜像口配置到MAC反查端口

简介这份资源面向网络运维工程师与网络故障排查初学者围绕Wireshark抓包定位并处理网络故障展开属于实战案例型技术文档。内容以锐捷交换机为背景涵盖VLAN端口流量异常、镜像端口配置、抓包文件分析、内外网IP攻击溯源等典型场景帮助读者掌握从发现异常到定位终端、恢复网络的完整排错思路。资源包共1个docx文档约385KB篇幅紧凑适合作为日常巡检与应急处理的参考手册。目前已有1548人学习下载说明其在网络运维群体中具有一定认可度。文档中详细记录了关闭端口安全策略、配置镜像口、通过MAC地址在核心交换机与接入层逐级定位异常设备、借助AC管理页面查找无线用户位置等具体操作并给出SSDP协议攻击导致端口流量飙升的真实案例与恢复验证数据读者可据此对照自身网络环境复现排查流程提升故障响应效率。1. 空载端口突然跑满 5000Kbps一次 SSDP 内网攻击的抓包定位巡检时发现一个平时只有 200 多 Kbps 的空载端口流量突然涨到好几千 KbpsAC 上所有无线网段 VLAN 的包量也集体超过 5000Kbps这种场景下 ping 和丢包率往往还正常用户端甚至没投诉但交换机背板和 AP 上行口已经在被无效流量持续冲刷。Wireshark 抓包在这里的价值不是看协议长什么样而是把哪个 IP、哪个 MAC、哪种协议在刷流量这三件事从几千 Kbps 的噪声里钉死。这篇内容面向日常做园区网运维、需要独立定位异常流量的工程师从交换机镜像口配置讲到抓包文件分析再到用 MAC 反查接入端口最后落到 SSDP 这类内网攻击的处置和复测。整套流程在锐捷交换机 AC 管理平台的校园网环境里跑通过换成华为、H3C 只是命令差异思路一致。2. 镜像口配置把异常 VLAN 的流量引到抓包机抓包的第一步不是打开 Wireshark而是让交换机把你要看的流量复制一份出来。园区网里 AP 上行口、汇聚口通常都是 Trunk直接在上面串一个 Hub 不现实标准做法是配 SPAN端口镜像。锐捷的写法是monitor session但配之前有个坑端口安全策略会拦掉镜像流量必须先关。2.1 为什么先关端口安全再配镜像被镜像口和镜像口上如果启用了 IP Source Guard 和 ARP Check镜像复制出来的报文会因为源 IP/MAC 校验不通过被丢弃抓包机看到的就是一片空白。所以配置顺序是先no掉这两条再建 session。# 进入被镜像口和镜像口所在接口的配置上下文前先全局关闭端口安全相关校验 no ip verify source port-security no arp-check # 建立镜像会话session 1源为 g0/1接 AP 的口双向抓 monitor session 1 source interface gigabitEthernet 0/1 both # 目的口为 g0/24抓包机接这个口 monitor session 1 destination interface gigabitEthernet 0/24 switchsource interface ... both里的both表示同时镜像收和发两个方向排查攻击流量时建议用both只抓rx可能漏掉设备主动外发的探测包。destination ... switch表示目的口工作在交换模式允许多个源口镜像到同一个目的口如果只镜像一个口去掉switch也行。配完用show monitor确认 session 状态是 up源口和目的口都对得上。2.2 抓包机的接入与网卡设置抓包机用网线直连 g0/24网卡不需要配 IP也不需要网关因为镜像口收到的是原始二层帧配了 IP 反而可能因为 ARP 或 DHCP 报文混进抓包结果里干扰判断。网卡驱动建议用 Npcap安装 Wireshark 时勾选即可抓包时在接口列表里选那块物理网卡不要选本地回环或虚拟网卡。提示如果抓包机是笔记本接镜像口前先把无线网卡禁用避免 Wireshark 默认抓到 Wi-Fi 接口的流量白抓一场。2.3 抓包前的过滤与捕获选项Wireshark 捕获选项里可以预设 BPF 过滤减少无关报文。排查流量异常时我一般先不设过滤抓 30 秒到 1 分钟的全量包因为异常协议事先不一定知道。但捕获缓冲区要设大一点比如 256MB避免高速流量下丢包。参数建议值说明捕获接口物理网卡不要选虚拟/回环缓冲区256MB5000Kbps 下 1 分钟约 37MB留余量混杂模式开启镜像口本身已是复制流量开启更稳捕获过滤先留空未知协议时全量抓抓包时长30~60s足够看出周期性攻击特征抓完保存为 pcapng文件名带上时间和端口比如g0-1_20240612_1030.pcapng后面复盘时不用再猜是哪次抓的。3. 抓包文件分析从流量统计锁定异常 IP 和协议拿到 pcapng 后先别急着逐包看用 Wireshark 的统计功能把谁在刷流量筛出来效率比手动翻高一个量级。3.1 用会话统计定位流量大头打开Statistics - Conversations切到 IPv4 标签按 Bytes 或 Packets 排序。异常流量通常表现为某个内网 IP 对某个组播地址或外网 IP 的单向大包量。这次案例里排在前面的是一条内网 IP 持续向239.255.255.250:1900发包的记录包量占比超过 80%。# Wireshark 显示过滤器直接筛 SSDP 流量 ssdp # 或者按 UDP 端口筛 udp.port 1900 # 只看某个可疑 IP 的收发 ip.addr 192.168.10.55ssdp是 Wireshark 内置的协议显示过滤器等价于udp.port 1900 httpSSDP 基于 HTTPU。筛出来后看Statistics - Protocol Hierarchy如果 SSDP 占比异常高基本可以确认是 SSDP 反射或设备异常广播。3.2 从包内容提取 MAC 和 IP 的对应关系定位到可疑 IP 后展开任意一个 SSDP 包在 Ethernet II 里能看到源 MAC在 IP 层能看到源 IP。把这对关系记下来这是后面反查物理端口的钥匙。# 显示过滤器筛出可疑 IP 且只看 SSDP 请求 ip.src 192.168.10.55 ssdp # 导出该 IP 的所有包到新文件便于单独分析 # File - Export Specified Packets - Displayed导出后可以用Statistics - Endpoints看这个 IP 一共发了多少包、平均包长多少。SSDP 攻击的典型特征是包长固定M-SEARCH 请求约 100 多字节、发送间隔极短、目标地址固定为组播地址。3.3 区分内网源和外网源的处理分支抓包结果里异常 IP 分两种内网 IP 和外网 IP处理路径完全不同。内网 IP走核心交换机show mac-address反查接入端口或通过 AC 用户管理页面按 IP 查 MAC 和关联 AP。外网 IP在防火墙上查 NAT 映射确认被攻击的映射端口能关就关不能关就切换映射端口持续被扫可提报运营商溯源必要时切备用 IP。这次案例是内网 IP所以走的是反查路径。4. 从 MAC 反查接入端口核心、汇聚、接入三层定位拿到异常设备的 MAC 后定位物理位置靠的是逐层show mac-address加show lldp这是园区网运维的基本功比任何网管软件都可靠。4.1 核心交换机上查下联端口在核心交换机上执行# 用 MAC 后几位查避免记错完整 MAC show mac-address | include 3c2e.ff # 输出示例 # 3c2e.ff12.3456 VLAN 10 GigabitEthernet 0/12include后面跟 MAC 的后几段即可锐捷的 MAC 显示格式是xxxx.xxxx.xxxx。拿到下联端口后用show lldp neighbors看这个端口对端是哪台汇聚交换机。show lldp neighbors interface gigabitEthernet 0/12LLDP 输出里会有对端设备的 System Name 和管理 IP远程登录到那台汇聚交换机重复同样的show mac-address | include操作找到再下一跳的接入交换机。4.2 接入层定位到具体端口到接入交换机后最后一次show mac-address | include会直接给出端口号比如GigabitEthernet 0/20。这个端口对应的就是异常设备实际插的网口去现场按端口号找设备即可。层级命令输出关键字段核心show mac-address | include MAC下联端口核心show lldp neighbors interface 端口对端设备名/IP汇聚show mac-address | include MAC下联端口接入show mac-address | include MAC终端端口号4.3 AC 平台按 IP 反查 AP 位置如果无线用户是异常源AC 管理页面比交换机命令更快。在用户管理里输入异常 IP能直接看到用户 MAC、关联 AP 名称和 AP 所在位置。这次案例里 AC 数据是实时更新的直接定位到某教室的 AP现场确认是一台教学一体机在发 SSDP 包。注意AC 平台数据如果没做实时同步按 IP 查可能查到旧记录这时以交换机命令查到的端口为准两者交叉验证。4.4 紧急处置先断网再排查如果异常流量已经影响业务不用等定位到物理设备直接在核心或接入交换机上按 MAC 做端口禁用或 ACL 封禁先恢复网络再慢慢找设备。# 接入交换机上关闭异常端口 interface gigabitEthernet 0/20 shutdown # 或在核心上用 ACL 封禁该 MAC 的流量 mac access-list extended BLOCK_ATTACK deny host 3c2e.ff12.3456 anyshutdown最直接但会影响该端口下所有设备ACL 更精细适合端口下还有其他正常终端的情况。5. 复测与验证SSDP 报文消失、流量回落到基线处置完不是结束必须复测确认攻击流量真的消失而不是被临时压制。5.1 复测抓包的对比方法重装异常设备系统后在同一个镜像口再抓一次 30 秒包用同样的ssdp过滤器看包量。这次案例里复测后 SSDP 报文从占比 80% 降到接近 0端口流量从 5000 多 Kbps 降到 400 多 Kbps。# 对比两次抓包的 SSDP 包数 # 第一次Statistics - Protocol HierarchySSDP 占比 80% # 第二次同一位置SSDP 占比 1%5.2 基线流量的判断400 多 Kbps 是不是正常要看设备启用了哪些协议。这个项目里交换机开了 SNMP默认轮询流量就在 400Kbps 左右如果没开 SNMP空载端口应该在 200Kbps 甚至更低。判断基线时把 SNMP、LLDP、STP 这些周期性协议的流量算进去不要拿零流量当标准。协议典型空载流量贡献说明SNMP200~400Kbps轮询频率决定LLDP几十 Kbps30s 一次STP极低拓扑稳定后很少SSDP异常数千 Kbps攻击特征5.3 长期监控的一个小技巧镜像口不用一直配着排查完no monitor session 1关掉避免长期占用端口。日常监控可以在核心交换机上配 sFlow 或 NetStream采样比 1:1000既能看流量趋势又不影响转发性能。下次再出现类似异常先用 sFlow 定位到异常 IP再临时开镜像口抓包比每次全量抓包省事得多。本文还有配套的精品资源点击获取