如何抓包分析报文防护 DDoS 攻击?

[SeedMssP]

由于 DDoS 攻击越来越频繁，如何对抗 DDoS 攻击成为不少企业的难题。

x86 君与多名行业客户[这些客户业务基本上都是出于发展期或爆发期]交流后发现，大部分用户遭受 DDoS 攻击时往往发现他们所采用的 DDoS 攻击防护服务商都可以清洗 3-4 层 Volume(流量型) DDoS 攻击，但是在防护具有针对性的 Volume 或 Application 型 DDoS 攻击却毫没有特别有效的方案。

其原因在于 DDoS 攻击防护服务商无法非常了解用户业务特性或对针对性的 DDoS 攻击采用了粗放式的防护方法(粗放式的防护算法对用户正常的业务流量误杀率极高)。

例如目前大部分 DDoS 攻击防护服务商针对 UDP 协议或 ICMP 协议或者私有协议的 DDoS 攻击防护采用阈值触发方式对这类触发阈值的流量进行直接拦截。

还有一种针对 UDP 或 ICMP 协议或私有协议的 DDoS 攻击防护算法，那就是 TCP 反向源认证。

采用 TCP 反向源认证的 UDP 防护算法采用 TCP 反向源认证的 UDP 防护算法

采用 TCP 反向源认证的 UDP 防护算法

采用 TCP 反向源认证的 DDoS 防护算法防护 UDP 协议的攻击可能会让部分不支持 TCP 协议的客户端被误杀，并且会导致反弹认证的流量过高，通常会高达 8 倍，这也会让大部分 DDoS 攻击防护服务商无法支撑巨额的上行带宽费用！(10Gbps 的纯 64 字节小包攻击，会导致防火墙反弹 80Gbps 的 TCP 报文)

这里 SeedMssP 采用了较为先进 Machine learning(机器学习)方式对 UDP 和 ICMP 或私有协议流量进行学习并防护，能够较为有效的防护 UDP 和 ICMP 以及私有协议的 DDoS 攻击，并能够保障对用户正常流量误杀率始终处于最低水平(误杀率平均在 5%左右)。

回到话题，抓包分析报文来防护 DDoS 攻击对大型 IT 企业(例如 BAT 这类规模的)来说非常有效，因为大型 IT 企业往往都配备超高性能的路由器，和超高性能的防火墙。

那如果我的企业是个初创型的 IT 企业怎么办？我买不起数十万数百万元的路由器和高性能防火墙，那我该如何防护这类具有针对性的 DDoS 攻击呢？

很简单，首先你要有个抓包工具，当你遭受此类 DDoS 攻击的时候，你可以使用 TCPDUMP 或 Wireshark 来抓取当前设备的网络报文。

然后将抓取的报文利用报文分析工具分析，例如使用 Wireshark 。

下面 x86 君简单介绍下，如果攻击者采用大量的肉鸡攻击一个网站，攻击使用一个固定的 URI 参数，且这个 URI 参数对正常访客来说并无用处的情况下的 DDoS 攻击防护方法。

首先黑客攻击了 http://123.1.1.2/test.php?mynameis=ddos

那么我们在被攻击的服务器内使用抓包工具抓取一定数量的报文，然后利用 Wireshark 对这组报文进行分析。

我们可以看到报文内有一组 GET /test.php?mynameis=ddos 的字符。那么我们只需要提取 mynameis=ddos 这组 URI 参数作为特征。

如果你使用 Nginx 作为 Web Server ，那么你可以在 Nginx 的配置文件中加入如下参数即可防护：

if ($args ~* "mynameis=ddos") {

            return 444;

        }

但是，如果攻击请求每秒高达数万次或数千万次的情况下， Nginx 可能就顶不住了，或许你需要把 DDoS 攻击流量在进入你服务器之前拦截掉。

此时 x86 君建议客官试一试 SeedMssP 独有的 V-ADS 细粒度清洗模型了。 V-ADS 虚拟防火墙(细粒度清洗部分)V-ADS 虚拟防火墙(细粒度清洗部分)

V-ADS 虚拟防火墙(细粒度清洗部分)

V-ADS 虚拟防火墙能够为客官提供报文级别的 DDoS 攻击防护，客官可以自行定义 DDoS 攻击的防护特征模型，而 V-ADS 会根据客户提供的报文指纹特征以及频率或相关模型行为对符合特征的报文进行拦截，放行，限速。

刚才的 DDoS 攻击黑客采用了 mynameis=ddos 的 uri 参数对 Web 服务器发起 DDoS 攻击，此时用户可以通过开启 V-ADS 的 Http Flood 防护模块进行一键防护，如果客官是个 Geek ，那么客官可以利用 V-ADS 的清洗粒度模型清洗此类 DDoS 攻击。

mynameis=ddos 的十六进制是： 6D796E616D6569733D64646F73 TCP 报文的标志位信息 TCP 报文的标志位信息

TCP 报文的标志位信息

TCP 报文中的 Flags 是 0x18 ，那么意味着 TCP 的标志位就可以勾选 PSH 和 ACK(勾选后将只对包含 PSH 和 ACK 标志位的报文进行匹配)，如果客官不勾选的话 V-ADS 会对所有报文进行匹配。

那么客官可以在 V-ADS 清洗粒度模型中填写如下内容：

此时点击保存后，再一次访问 http://123.1.1.2/test.php?mynameis=ddos 的时候， V-ADS 就会立即拦截包含此特征的报文。 访问被拦截掉了访问被拦截掉了

访问被拦截掉了如果客官您脑洞开的大，您还会可以利用这 V-ADS 的细粒度清洗模型来完全贴合您的业务特性，将误杀率降低到最低甚至零误杀！

最后 x86 君要说下的是， V-ADS 清洗是线速的哟~~~

简单回答下部分 V 友的问题

1. 特征匹配是 V-ADS 的一部分，我们只是将特征匹配在主机的上层网络去做了，用户的主机如果有这个性能去做的话我们就没必要将这个功能实现了，如果用户能力够强大，完全可以利用 V-ADS 的自定义防护模型和特征结合，目前可以对所有报文特征进行逻辑关系判断(报文内容， Offset ，时间，频率，累加器，标志位，包字节，包长度，判断， RET 等等)，实现一个非常贴合用户业务的防护体系。

2. V-ADS 实现了流量清洗系统对租户的虚拟化，租户能够利用 V-ADS 对云主机网络进行自动防护或手工开启防护方式防护，租户也可以利用 V-ADS 自定义清洗模型，清洗规则，清洗特征的定义，也允许租户自行调整 V-ADS 的攻击防护模式(算法)，来达到最优防护。

3. V-ADS 的底层采用了 DPDK 框架和自主研发的 TCP/IP 协议栈和高性能 DDoS 攻击防护算法实现。

[denghongcai]

我想知道这个“细粒度清洗“和 netfilter 的 https://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html 有什么区别？
达到线速是什么配置下？ netfilter 在正常配置下也能随便达到线速

[lhbc]

几个问题：
1. https 怎么处理？
2. 随机的 args 怎么办？
3. 发起 http 请求之前，已经建立了 TCP 连接，攻击特征包直接丢弃了，服务器上的连接只能等超时了吗？

[nilai]

一看就知道你是个广告帖，

如果攻击者 直接打 http://123.1.1.2/test.php 这个地址 后面不加任何参数，是不是都正常的访问都封掉呢？

其次，入口带宽就那么大点的情况下， 纯流量来了你能防住？

个人感觉目前靠谱点的还得云防火墙或者考虑自建云防火墙，

看了下资料，感觉不喜。

[nilai]

还有就是你举的 nginx 的例子， 别忘记了 nginx 的 openresty 分支， 在你提到的这个简单 CC 攻击例子， 在可扩展性，性能，易用性，可维护性，秒秒钟超过你， 真的。

[nilai]

刚看了下官网， 发现也是主要卖云主机的， 不知道你们跟阿里云有什么优势？

[bugmenein]

现在在 V2EX 看到长文带图技术文章我都会先看下面。

[canglaoshi]

我关心价格

[canglaoshi]

貌似是阿里云的 api 么

[des]

感觉没啥软用，上 cc 攻击马上 gg ，感觉和 iptables 一个原理。
应用层的攻击还是得到应用层解决。
另外广告太硬。

[des]

另外如果攻击者一直盯着一个地址攻击极有可能就是为了让这个地址无法访问，就和 github 被攻击那次一样，当你屏蔽了这个地址，那么攻击者的目的也达到了

[MiguelValentine]

@denghongcai 才才发问了

[SeedMssP]

@denghongcai NetFilter 的所有流量都是需要通过 Kernel TCP/IP Stack ， V-ADS 完全基于 User Spaces TCP/IP Stack ，能够实现 10Gbps / 14Mpps - 200Gbps / 280Mpps 的清洗性能(Layer 3 ， 4 ， 7)。
另外据我所知 iptables 在七层上无法达到线速，而 V-ADS 是可以达到线速

[SeedMssP]

@lhbc
1. https 流量需要用户证书配合。
2. 随机的 args 目前 V-ADS 可以通过 Redirect 和 验证码方式对此类攻击进行有效防护(大约 95%以上的 CC 攻击)
3. V-ADS 会向 Server 发送 Rst 重置。

[SeedMssP]

@nilai 针对这类攻击， V-ADS 可以通过学习攻击特征进行自动防御，或者租户自行设定防护方式。
大部分 CC 攻击的 Slave 是无法解析跳转和 JS 以及 Cookie 或验证码，所以防御这类攻击是比较简单，而目前 95%以上的攻击都无法逃过这三类防护方式。

[SeedMssP]

@nilai 如果每秒连接数达到数百万的情况下，我觉得 Nginx 就很吃力了， V-ADS 设计当初就是高性能的清洗系统，单台新建 TCP 能力超过 150 万每秒，我相信跑在 Kernel TCP/IP Stack 下的 Nginx 做不到。

[SeedMssP]

@canglaoshi 和阿里云没有任何关系

[SeedMssP]

@des 如果和 iptables 一样的话，我觉得这个产品不叫产品，因为 iptables 的处理能力在我们看来应该还是幼儿园级别的。

[SeedMssP]

@des 针对这类攻击， V-ADS 可以通过学习攻击特征进行自动防御，或者租户自行设定防护方式。
大部分 CC 攻击的 Slave 是无法解析跳转和 JS 以及 Cookie 或验证码，所以防御这类攻击是比较简单，而目前 95%以上的攻击都无法逃过这三类防护方式。

[SeedMssP]

@des 另外 V-ADS 并不是在云主机上运行，而是构建在 V-ADS Cluster 中，单个 V-ADS Cluster 拥有 400Gbps / 640Mpps 的异常流量清洗能力。

[blackboar]

我的圈子里了解到现在搞纯流量攻击的可以打到 200G 往上，实际上比这个高的很多，一个朋友让我给他介绍高防，要能 150G+的，我直接让他弄阿里云试试，结果回复说已经试过，还是挂掉了。

我这边其中一个机房每月遭受流量攻击都在 100 多次， 70%都是超过 10G 的，这么大的量没法抗，只能城域网出口封掉。

特别是那些过百 G 的，防火墙已经没意义了，最大的问题在机房出口或者城域网出口上了。

如果是正规业务，还是建议走法律途径，“沟通到位”的话会帮解决。

[9hills]

看完全文发现就是一个特征匹配。。和 ML 有什么关系？

[denghongcai]

那是走 DPDK 的咯，特征匹配的防火墙

[CayenneS]

@9hills 就是讲了一个特征匹配的防护方式

[CayenneS]

@nilai 见过眼瞎没见过你这么瞎的。。。。一看就是卖高防的。不信我可以和你赌 10 块。纯流量攻击谁用云防火墙谁脑残。。 where amazing happened

[wafm]

纯流量过来 你什么墙都没用了

[SeedMssP]

@wafm 解铃还须系铃人， DDoS 既然是分布式发起最后通过 ISP 路由汇聚并成为巨型攻击，那么解决方案同样就是分布式的对抗，足够好的带宽资源并能够有效利用各大 ISP Peer 和 eXchange 来平衡 DDoS 防护成本，提高 DDoS 攻击难度。
到底还是需要分布式的清洗中心和强大的清洗系统。

[millken]

DPDK 我也测试过 10G 环境，如果加上包处理的话，达到线速是不可能的（大概 7-9Mpps ）。
现在我用 snabb 来收发包（直接操作网卡），性能和 DPDK 差不多。不像 DPDK 那样独占网卡，并且 lua 写起来那叫一个爽。

针对 cc 攻击做 JS 以及 Cookie 或验证码，利用 js 引擎突破 js 和 cookie 应该没问题，暴力点用 phantomjs 。

不知道你这里提的 ”学习攻击特征“是怎么个学习办法？是否具备智能模式？还是简单的利用阈值来进行识别？

[SeedMssP]

@millken
1. 这个和你的硬件有关系， DPDK 达到 10Gbps-40Gbps 线速很轻松，但是 DPDK 的性能增长到后面的硬件成本会很高，因为性能增长并不会随着核心的增多而线性增长，而 DPDK 的核心多了之后也会有争用问题。

2. 我们的网卡用了基于 FPGA 的 Netcope NFB-100G2 ，所以相对来说会比纯 DPDK 灵活一些。

3. 学习攻击特征是基于包特征学习，并非简单的阈值判断。

[SeedMssP]

@millken

1. 第一个问题我在回答的稍微详细一点， 10Gbps - 40Gbps 包处理线速的代价是需要多核(主要还是硬件设计，我们测试过不同主板和工控厂商的硬件，每家的数据都不一样，所以性能和主板设计也有一定关系)，但是 DPDK 的性能增长并不会随着核心的增多而线性增长，所以这个对代码质量要求很高。

2. 攻击器如果能用 JS 引擎计算 JS 验证码或者跳转的情况下， V-ADS 还有通过频率限制或采用验证码方式对此类攻击进一步防护。

[usernametoolong]

TCP 攻击防护的效率在于识别和过滤。

任何攻击和防御都有上限值，目前情况下很多攻击还达不到一些大厂的应用级别。。。。。

小学生无误。

[SeedMssP]

@usernametoolong 主要看哪层的攻击，三四层的 TCP 协议攻击防护基本都不难(算法基本上可以过滤掉 99.99%的异常流量)，七层针对性比较强，所以需要更细粒度的模型去定义防护。七层也有针对 WEB DNS GAME 的通用算法，但是遇到针对性的攻击基本上都歇菜了