利用Wireshark轻松应对DDoS攻击！

免责声明~

任何文章不要过度深思！

万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；

不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。

怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」

1 前言

MTU、 传输速度、 拥塞控制，还是各种重传，TCP传输相关的核心概念：

• 学习了RFC规范和具体的Linux实现
• 通过案例，把这些知识灵活运用了起来

这种种还是在协议规范这大框架内的讨论，默认前提就是通信两端是遵照TCP规定工作，都是君子协定。

若不遵TCP规范，甚至找漏洞攻击，这种小人行为也很常见，如 DDoS攻击。

2 NTP反射攻击案例

游戏业务遭DDoS多见。有次，一个游戏客户发现，他们游戏服务器无法登录被投诉。客户的工程师做了tcpdump抓包，赶紧把抓包文件传给我们。

Expert Info

从抓包文件概览看是不正常。先看Analyze​​→​​Expert Information：

游戏业务一般基于TCP，但这没啥TCP信息。

看具体报文

全是NTP Version 2, Private, Response, MON_GETLIST_1报文。客户根本没对外提供啥NTP服务，这些报文哪来的，是攻击吗？这就是DDoS攻击的一种类型：NTP反射放大攻击。

NTP

Network Time Protocol，通过网络服务来同步时间。有个功能Monlist，在一些老设备默认启用，会返回与NTP服务器进行过时间同步的最后600个客户端的IP。

响应包按每6个IP分割，最多有100个响应包。一个简单的NTP Monlist响应，就可能是请求的200多倍。如请求1Gbps，那这次反射攻击就可达200Gbps以上！

Wireshark展开UDP部分，看这种Monlist响应报文的细节：

每个Monlist item占用72字节：

选中一个Monlist item后，3种方式找到长度：

• 字段Size of data item值72，协议本身提供的元数据
• 下方字节码部分，数一下有底色的字节数，是72
• 窗口底部对我们选中的字段有提示字节数72bytes

用Wireshark解读抓包文件，特别是要核对字段的具体信息时很有用。

Aplly as Column

现在Wireshark窗口里解读UDP报文长度不直观，因为 Wireshark默认没有显示UDP长度的列，但可自行添加。UDP详情里选中Length，然后右单击，选中Aplly as Column：

在主窗口看到UDP报文长度Length：

看着UDP报文长度都不大，为啥？MTU一般1500字节，去掉IP头20字节和UDP头8字节，最多还有1500-20-8=1472字节，远大于448字节，为啥不用足1472字节？涉及UDP一个概念：UDP报文的载荷最好不要＞512字节。

这限制来自IPv4协议。IPv4协议规范 RFC791 建议虽然IP报文长度字段2个字节，最大65535，但网络不允许传输这么大的报文，所以IPv4规范建议，报文长度应控制在相对小的范围内，这个范围是576字节，相应的UDP载荷在512字节以内：

The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

很多应用程序都做这部分逻辑处理，即控制UDP载荷在512字节内，如这次NTP Monlist长度就是NTP协议实现，而非内核UDP实现。像DNS解析，如数据量超512字节，也会自动切换为TCP模式，根本原因也是这个很早以前规定。

检查了载荷，“这里咋只有NTP回复，没NTP请求？”正是1Gbps能放大为200多Gbps原因。背后就是反射攻击核心技巧：利用IP协议“不对源IP做验证”的不足，构造一个IP报文，其源IP为被攻击站点的IP，使NTP服务器回复的报文也被发往被攻击站点。大量响应报文被引到被攻击站点这。而且过程中，NTP服务器被利用了还不知道。

示意图：

面临这种攻击咋办？

• NTP服务器是自己的，就升级版本，避免自己成“帮凶”
• 我们是单纯的被攻击者，就要上些手段。游戏客户就是上了高防后，扛住攻击

3 SSDP反射型攻击案例

“肉机”，被黑客掌握系统权限的主机。可被黑客集中调动起来发起攻击。如一个黑客组织掌握1万台“肉机”，只要每台“肉机”发起哪怕只有1Mbps攻击流量，乘以1万，就是10Gbps流量。

但拿到这么多“肉机”不易。黑客想到：借力打力。借协议的“ 响应是请求的很多倍”力。NTP反射攻击就是这。这种攻击的英文叫reflection attack with amplification。amplication就是放大的意思。只需很少“肉机”，就可发起巨大攻击流量。

客户案例。当时遭受攻击，做了抓包。看抓包文件Expert Information：

没TCP握手报文，上来就是HTTP/1.1 200 OK，这HTTP“自来熟”。既然这有94100个HTTP 200响应报文，应该至少有几十个TCP连接，而这一个SYN、FIN都没。

看HTTP 200具体啥样：

为啥看不到srcPort和dstPort？原来用了UDP。上面的srcPort和dstPort列是指TCP的端口号，所以空了。HTTP为啥用了UDP作传输协议？这就是

SSDP反射放大攻击

SSDP在UDP传输层协议上，用HTTP协议格式传送信息。2014人们发现SSDP可被攻击者利用。启用SSDP协议的主要是家用路由器，在它们的UPnP软件有漏洞，被攻击者利用后，这些路由器会从端口1900返回响应报文。显然这些响应报文的目的地址，是被攻击站点的IP，而不是攻击发起者自己的IP。攻击过程类似NTP反射攻击里面的图。

当时应对方法也是上高防系统。

著名网络服务公司Cloudflare把SSDP戏称为 S tupidly S imple DDoS P rotocol。你可以在 这里 看到Cloudflare对SSDP攻击的更多解释。

路由器自测。访问 https://badupnp.benjojo.co.uk/ 这个站点，会对你的出口IP（家用路由器的出口IP）探测，看是否有1900端口可被利用。如没有漏洞，网页提醒你：

抓包的概览。

新命令：capinfos。

Wireshark自带工具集中的。

查看抓包文件的时长、总包量等信息。直接运行 capinfos文件名：

$ capinfos SSDP_attack_example.pcap
File name:           SSDP_attack_example.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 65535 bytes
Number of packets:   100 k
File size:           36 MB
Data size:           34 MB
Capture duration:    1.916902 seconds
First packet time:   2016-05-08 10:25:02.721642
Last packet time:    2016-05-08 10:25:04.638544
Data byte rate:      18 MBps
Data bit rate:       145 Mbps
Average packet size: 348.38 bytes
Average packet rate: 52 kpackets/s
SHA256:              8fa365f01c62023576623116410a6ca289915db4717e4805120009a575fdfb57
RIPEMD160:           5ab83442a5178b5f34bee1009a58ddb351bd292b
SHA1:                52a2c52644bc2753f9a11b7bf71eb1144f2c9a30
Strict time order:   True
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
                     Number of stat entries = 0
                     Number of packets = 100000

重点关注：

Number of packets:   100 k
Capture duration:    1.916902 seconds
Average packet rate: 52 kpackets/s

这次抓包一共抓取10万个报文，耗时1.9s，平均包率为52kpackets/s，5万2千个包/s。都是SSDP协议响应报文，是DDoS。

平时了解一个抓包文件的包率、时长、平均报文大小等信息都可用capinfos命令快速获得。

回顾完两个具体的案例，想必你对于DDoS有了感性的认识了，接下来我们就来系统地认识一下DDoS。

4 啥是DDoS攻击？

DDoS跟DOS密切联系。DOS（Denial of Service），服务拒绝，黑客通过各种手段使被攻击者无法正常提供服务。DOS攻击早已存在，而DDoS（Distributed DOS）是升级版：调动分布在各地的客户端发起攻击，使得被攻击站点无法正常服务。

DDoS是“攻击”，不是“入侵”：

• 攻击是破坏服务
• 入侵可能不破坏，但会窃取资料、劫持勒索等

DDoS是要破坏计算资源

资源

一般计算机资源是CPU、内存。耗尽CPU和内存资源是早期攻击形式。当时攻击和病毒，主要是让被攻击站点失去服务能力。随安全加固技术和意识增强，攻破系统成本越来越高，攻击者转换方向。他们不需想法攻入对端，只要在前面的网络环节搞破坏，同样可让对方服务瘫痪。服务瘫痪原因已不是之前服务本身不可用，而变成网络通道不可用！

这就是DDoS核心目标：耗尽网络带宽。

假设被攻击的站点的带宽为1Gbps，攻击者只要让到达这站点的流量超过1Gbps，就可让这站点失去正常服务能力。这些报文是否属于被攻击站点正在监听的有效流量，没关系。它的目的直接：把你家门口路堵死，让正常流量没机会进。

示意图

如何产生巨大流量？

常见实现方式反射型攻击。利用：

• 一些协议的“响应是请求的很多倍”特点
• 同时“IP协议不验证源IP”不足

把流量引到被攻击站点。

NTP反射攻击和SSDP都是。

NTP反射攻击依托UDP，很多DDoS类型也是利用UDP。为啥是UDP？

5 为啥UDP易被用做DDoS？

TCP也可被DDoS用，但同样成本，反射型攻击更高效。反射型攻击主要基于UDP

5.1 UDP报文简单易构造

UDP头部。RFC768 定义UDP头部的格式：

UDP头部仅8字节：

• 2字节源端口
• 2字节目的端口
• 2字节报文长度
• 2字节校验和

Wireshark看UDP报文：

TCP头部复杂多，还有序列号、确认号、各种标志位、各种TCP扩展选项。UDP报文头部因简单，减少攻击者伪造难度，只要做到：

• 伪造一个源IP
• 找到NTP等有反射攻击漏洞的服务器
• 向这些服务器发送构造好的虚假的UDP报文

5.2 UDP是无状态的

更关键 原因。UDP无状态的，不需握手。像NTP反射攻击、SSDP反射攻击，都是“一问一答”，攻击者只需伪造一个请求报文，后续响应报文自然就发给被攻击站点。

但TCP先要三次握手，如攻击者SYN报文源地址是伪造成【被攻击站点IP】，SYN+ACK报文就直接回复到那个站点IP，而非攻击者。然后被攻击站点收到一个莫名其妙SYN+ACK，直接被RST，TCP握手结束，攻击中止。

跳过TCP握手，直接发应用层请求（源地址还是伪造成【被攻击站点的IP】）给反射服务呢？直接被RST，因为连握手都没做过。

即使通过握手，后续通信双方还有对序列号和确认号进行校验等机制。虽然这些技术上都可实现，但难度大很多，而选择UDP不需考虑这些。

所以， 用TCP就是直接攻击，不是反射攻击。如SYN攻击、半连接攻击、全连接攻击、CC攻击等。“性价比”反射攻击优势大。

6 对抗DDoS？

以后发现服务异常，如客户端请求十分卡顿，就在服务端抓包分析，就能快速定位是否DDoS攻击。

更简单直接证据，你的公网接口带宽使用图，如图上有明显突增，甚至达到了接口带宽的上限，那也基本可以判定是遭遇DDoS。

6.1 高防

服务架在公有云，考虑使用云商或其他专业安全服务商的高防产品。

高防需放置在源站前面的一类安全防护和清洗系统。它利用自身足够大带宽及强大防护清洗集群，实现流量清洗，最终把攻击流量拦截，清洗过后正常流量进入源站：

源站，就是被攻击的站点。

高防按时计费费用高昂，一般平时不接入高防。只有探测到被攻击，才自动或手动转高防。“接入高防”就是把站点域名指向高防域名，就把流量先流向高防，再经清洗后回到源站。

如攻击者不通过域名解析，盯IP攻击呢？把老IP解绑，让攻击流量进入路由黑洞，然后绑定新IP。不要暴露新IP信息，它只能给高防回源用，不能让更多人知道。

从防护的生效点，高防作用在 服务端侧。如我们能 在攻击的源头就做防护，效果更好？另一类DDoS防护产品的设计思想，典型产品电信云堤。

6.2 云堤

运营商自己系统，而无论被攻击站点还是肉机，都依托运营商公网线路才能进因特网，所以云堤 具有“地理”上的天然优势。可作用在肉机攻击流量进入骨干网之前，所以很可能这些攻击都没有机会走到被攻击站点的跟前了，相当于“扼杀在摇篮里”。

6.3 anycast和多POP

我们知道了DDoS的本质是挤占网络带宽，那么对付它的核心策略就是：

• 用更大的带宽来接纳，先解决正常流量被挤出网络的问题。
• 在接纳后进行清洗，把正常流量识别出来，发回给源站，让业务继续进行。

前面介绍了高防和云堤，两者分别在被攻击站点的近端和远端起到了作用，也都是商业服务。那么，另外一种方式是自己搞定，这也是一些 自身规模比较大的网站会部署的架构，它就是anycast和多POP。

anycast是网络术语，是指 多个地点宣告同一个网段或者同一个IP地址的行为。比如，最典型的电信的DNS服务地址114.114.114.114，还有谷歌的DNS服务8.8.8.8，就是在全国乃至全球各处做了anycast的IP地址。与这个词类似的，还有unicast和multicast，分别是指单播和多播。

比较大型的网站都会在各地部署POP点（也就是多POP），然后这些POP点会宣告相同的IP段。一旦有DDoS攻击，因为它的目标IP是属于anycast网段的，所以会被因特网的路由策略，相对均匀地分布到这些POP。

假如你有20个POP点宣告同一个网段，那么你就有机会把DDoS攻击化整为零，平均每个POP点承受1/20的攻击流量，大大降低了危害性。在攻击流量不高的时候，仅依靠自己的多个POP就可以吸收掉这些攻击流量，然后用自己的设备进行清洗就可以了。

anycast+多个POP+自有的清洗设备，这一整套做好以后，相当于自己建设了一个中小型的高防系统。

补充：这里的anycast一般是作用在网段级别。而在单个IP级别的anycast应用还较局限，目前主要还是主要应用在基于UDP的服务，比如DNS服务上。基于anycast的HTTP是比较前沿的领域，目前有少数公司已经开始实践，相信在不久的将来，应该会看到越来越多的公司应用HTTP over anycast。

6.4 CDN

前一点类似，CDN也通过“多点分布”防护或缓解DDoS。CDN服务商一般也采用anycast等策略混合使用，使其防护DDoS能力更出色。

7 总结

NTP反射攻击和SSDP反射攻击这两个典型的DDoS案例，了解反射放大攻击特点，主要利用：

• IP协议不对源IP进行校验，可伪造源IP，把它设定为被攻击站点的IP，这样就可以把响应流量引向被攻击站点。
• UDP协议是无连接的，可直接进行应用层一问一答，这就使得IP欺骗可以奏效。
• 某些服务具有“响应报文的大小是请求报文的很多倍”特点，使攻击“四两拨千斤”

系统性地分析了DDoS核心方法，“ 耗尽网络带宽”让被攻击站点无法正常提供服务。在排查方面，当我们发现服务异常时，在服务端做抓包分析，可以快速定位是否有DDoS攻击。也可以直接根据带宽使用图，关注到突发的巨型流量时也可以直接判定是DDoS攻击。

应对DDoS攻击的策略：

• 高防产品，可以防护非常巨大的攻击流量。
• 如对防护效果有更高需求，可以使用运营商的云堤类的产品。
• 自身条件足够，部署多POP和anycast，平均吸收攻击流量。
• 也可CDN，让CDN天然分布式布局减轻DDoS影响

新命令 capinfos快速获取到抓包文件的整体信息，包括抓包时长、总报文量、平均报文大小等信息。关于如何在Wireshark里解读出报文字段的长度，你也要知道至少下面这两种方法：

• 选中要解读的报文字段，然后在下面的字节码部分，数一下有底色的字节个数。
• 还是选中要解读的报文字段，在底边栏里也有对应的字节数的显示。

UDP载荷最好不要超过512字节，IPv4协议规范建议，NTP和DNS这些基于UDP的协议都实现这规范。

8 FAQ

• “肉机”发出100Mbps的攻击流量，到达被攻击站点的时候，仍然是100Mbps吗？为什么呢？
• 为什么CDN可以达到缓解DDoS的效果呢？

​​https://www.wangan.com/docs/1231​​

写在最后

​​公众号​​​：​​JavaEdge​​​ 专注分享软件开发全生态相关​​技术文章​​​、​​视频教程​​​资源、热点资讯等，如果喜欢我的分享，给 🐟🐟 点一个​​赞​​​ 👍 或者 ➕​​关注​​ 都是对我最大的支持。

文章转载自公众号： JavaEdge