本文已参与「新人创作礼」活动，一起开启掘金创作之路。

前言

案例来自于 Sharkfest 2017 《Digging Deep - Exploring real-life case studies》其中的 case00，作者是 Sake Blok ，一位 Wireshark 核心开发者和网络协议故障分析专家。也是和朋友聊天，提醒告知有这个案例，并提供了相关数据包，所以就此分析并分享下。

原始文件为 PDF ，case00 也仅有两页，一描述问题，二描述解决方式，实际并没有分析过程。

问题背景

客户在周日晚上打电话，说他们的整个网络基础设施都出故障了，作者作为 F5 负载均衡设备的工程师进行了故障分析和处理。

文章分享的图示如下：

客户反映的基础设施都出故障，为引用的案例描述。结合图示，从我个人理解，作者简要表达的应该是客户的 Web 服务网站打不开的故障。

问题分析

数据包跟踪文件基本信息如下：

$ capinfos case00.pcapng
File name:           case00.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Packet size limit:   inferred: 104 bytes
Number of packets:   2593
File size:           243 kB
Data size:           179 kB
Capture duration:    25.932148 seconds
First packet time:   2013-04-22 03:09:01.023908
Last packet time:    2013-04-22 03:09:26.956056
Data byte rate:      6921 bytes/s
Data bit rate:       55 kbps
Average packet size: 69.22 bytes
Average packet rate: 99 packets/s
SHA256:              e37150bc622eb9c27d26ee694dedef28ec33ed97c3cc2ddbeb1d00e5ce207070
RIPEMD160:           34196064244bf3df09825d5f508b813ec5bf7fd5
SHA1:                74506abbff434e7b9d5149001122d9f5e8d911b7
Strict time order:   False
Capture comment:     Sanitized by TraceWrangler v0.6.2 build 799
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Number of stat entries = 0
                     Number of packets = 2593

$

基本判断数据包捕获应该是 tcpdump，并做了相应截断，大小为 104 字节。数据包数量为 2593 ，捕获时长约 26 秒，平均速率 55 kbps，数据包文件经过匿名化工具所处理。

专家信息所提示的信息较多，Error 和 Warning 等级别，包括提示 IPv4 长度超出、非 SYN 数据包包含 MSS 选项、校验和错误、会话使用同一个端口等问题，其中最后所提示的 SYN 数据包数量 1396 ，超出了捕获数据包总数的 50%，基本疑似 SYN Flood 攻击现象。

实际数据包信息主要如下：

TCP DUP ACK 、TCP Out Of Order、TCP Retransmission

跟踪文件中首先可以看到的就是有大量的 TCP DUP ACK、乱序和重传现象，包括右侧边栏所显示的大量红黑颜色标记，确实存在很多问题。但实际上是不是有问题呢？实际上并不是问题。

仔细看出现 TCP DUP ACK、乱序和重传现象的这些数据包上下文，会发现它们都是成对出现的，而且信息基本一样，结合描述中作者说是 F5 负载均衡的工程师，说明该跟踪文件是在 F5 设备上所捕获，且抓的是进出双方向的数据包，这就会使得同一个数据包，在进的时候抓取一次，在出的时候又抓取了一次，这样就会造成 Wireshark 提示说有 TCP DUP ACK、乱序和重传现象，但实际上可以理解是数据包重复抓取了。

以 No.1 和 No.2 数据包展开说明，实际上在经过 F5 设备传输时，只有源和目的 MAC 地址以及 ip.ttl 等少数字段有了变化，一样的 ip.id 也说明了实际上就是同一个数据包。

TCP SYN Flood

在专家信息中提示 TCP: Connection establish request (SYN): server port 80有 1396 个之多，通过 tcp.connection.syn 显示过滤条件可一次性过滤出所有有问题的 SYN 数据包。

会话统计信息同样如此，来自于众多不同的源 IP 发起对 Web 服务 31.151.1.21 80 端口的请求。

其实眼尖的同学在上面应该可以看出这个 SYN 数据包的异常，它并没有像常见的 TCP 三次握手数据包中带有的 TCP Options 字段。

同时通过 tcp.seq_raw == 0 过滤可知，高达 1391 个数据包的 TCP Seq Num 真的为 0 ，而不是相对为 0，再加上一层不变的 Win 窗口大小 5840 ，种种现象可判断为 SYN Flood 攻击，皆为伪造的非常规的 SYN 数据包。

案例中最终是如何解决该攻击问题的？作者是根据跟踪文件中 TCP SYN 数据包的特征，在 F5 设备上做了安全过滤，过滤条件如下：

host 31.151.1.21 and tcp[13]=2 and tcp[12]&0xf0=0x50

host 31.151.1.21 表示为目的 IP。
tcp[13]=2 表示为 tcp flags syn 位置1的值，也就是 2。
tcp[12]&0xf0=0x50 表示为 TCP 首部长度20字节，也就是没有 TCP Options。

经过上述处理后，客户的 Web 服务恢复正常。

问题总结

当然，因为 SYN Flood 实际攻击的方式很多，自然安全防护也不是仅靠本案例所提到的方式就能解决的，只能具体问题具体分析。本案例主要从网络数据包分析角度入手，经过层层判断解析，最终成功解决。

Wireshark TS | SYN Flood 攻击案例

前言

问题背景

问题分析

问题总结