某运营商枢纽节点DNS网络中防火墙会话数接近饱和(in use count 达到900万)，绿盟科技ADS产品报警有DDoS***告警，监测发现域名解析延时增大，严重影响了DNS业务的正常运行。

6月15日上午，接某运营商网管中心互联网室通知，其枢纽节点DNS服务器疑似遭受DDoS***。绿盟科技服务团队启动应急响应，并协调绿盟科技云安全运营中心协助处理，响应工作随即启动。


1

2

3

4

1. 15日，绿盟科技服务团队接报，某运营商枢纽节点DNS疑似遭受DDoS***，立即启动应急响应机制；

2. 15日至16日，绿盟科技服务团队启动相关分析及数据汇总和ADS流量牵引注入工作，

3. 17日至19日，绿盟科技云安全中心服务团队及本地技术团队24小时监测其***变化并随时调整监测阀值；

4. 22日，将***事件分析和溯源信息汇总形成报告，报送某运营商信息安全中心、网管中心互联网室。

绿盟科技服务团队持续关注***事件的进展和变化。

事件概述

事件关键信息 ———————————–关键内容
事件现象某运营商枢纽节点DNS网络中防火墙会话数接近饱和(in use count 达到900万)，域名专项防护系统报警有DDoS***告警，监测发现域名解析延时增大，严重影响了DNS业务的正常运行。
事件原因DNS放大DDoS***：***主要是***源向枢纽节点DNS（*.*29.170）发送大量小字节的针对美国***网站 defcon.org 域名的 ANY 查询请求，从而使得DNS服务器返回大量大字节的数据包，导致DNS网络中防火墙会话数接近饱和，消耗大量DNS服务器的资源，正常的解析请求延时增大，解析成功率降低。***源大部分来自运营商某范围内的互联网专线IP。
开始处理时间2015年6月15日9点30分
处理结束时间2015年6月19日17点30分
处理结果6月15日上午10点10分至6月19日17点30分，绿盟科技本地服务团队开启防护系统的流量牵引注入策略，启动”流量牵引和注入”对其***流 量进行”清洗”，同时采用模式匹配（7层阻断）对其来自对defcon.org 的域名解析请求的数据包进行丢弃，有效的保障了某运营商DNS服务的高可用性。

事件处理过程

检测过程

2015年6月15日9点30分，绿盟科技DDoS防护系统发出DDoS***告警，同时接到某运营商网管中心互联网室通知其DNS疑似遭受DDoS***，域名解析延时增大，成功率低于90%，随即绿盟科技运营商服务团队启动了应急响应工作。从15日凌晨至19日，***一直在持续，初步统计次此***流量至少在10G 以上，其持续时间之长，***流量之大，当属近几年某运营商之最。

通过样本分析发现，此次***主要是通过控制肉鸡对美国***网站（Defcon.org）和僵尸网络（router.bittorrent.com、 router.utorrent.com）域名进行ANY查询请求和随机查询请求，导致某运营商DNS遭受拒绝服务***。***在短时间内发起了峰值大于 6Gbps的查询请求，造成某运营商枢纽DNS递归服务器延迟增大，核心解析业务受到严重影响。

使用ADS自带的抓包工具捕获数据包样本，并对捕获到的***样本进行分析，如下图所示：

p_w_picpath004

在ADS上监控到defcon.org这个域名的查询数量一直排在第一位，且查询数量较多，属于异常现象，如下图所示：

p_w_picpath005

查询数量最多的域名，一个国外的***网站。如下图所示：

p_w_picpath006

***原理

***者控制大量肉鸡发起针对多个域名（主要域名为defcon.org）的ANY放大查询（DNS Amplification attack，也叫反射***）和随机查询***，极大的消耗了防火墙的性能。这种***由来已久，2014年12月10至12月19日国内出现大规模针对运营 商DNS网络的恶性DDoS攻 击事件，当时的***者就是通过肉鸡对国外游戏厂商（arkhamnetwork.org、arkhamnetwork.com、 getfastinstagramfollowers.net）的域名随机查询进行拒绝服务***，造成各省的DNS递归服务器延迟增大，核心解析业务受到 严重影响。这种***模式成本低，效果好，追踪溯源困难。

p_w_picpath007

***特点：

  • ***开始时候都是采用ANY查询进行放大***，放大倍数达到50倍左右，基本特征不变，目前没有产生新的变种。

  • 基本上的***都是肉鸡、无线路由器，监控设备，也有一些源IP本身是DNS服务器。

  • ***时间不固定，下午多一些。

  • 最高流量峰值达到10G。

分析过程

通过结合域名专项防护系统ADS的告警日志和抓包分析发现有大量对defcon.org 的ANY查询，分析发现此次***事件的***源90%均来自省内IP，部分肉鸡存在弱口令，相对于过去的***，此次***中***源更加多样化，其中智能监控设 备和商用无线路由器（如：某厂商的路由器带有dnsmq服务）成为主力。

大量对defcon.org的ANY查询的恶意请求：

p_w_picpath008

DNS服务器返回的应答数据包，数据包比正常应答数据包大：

p_w_picpath009

大量对bittorren.com的随机域名查询：

p_w_picpath010

域名专项防护系统ADS上defcon.org的查询统计,查询数量一直排在第一位：

p_w_picpath011

处置阶段

根据告警情况，结合DNS防火墙的会话性能适用占比情况，及时调整域名专项防护设备的UDP检测阀值（其UDP阀值调整在8万pps-15万pps 之间）对***流量进行清洗。同时在域名专项防护系统开启模式匹配策略（7层丢弃），对查询Defcon.org 的域名的源IP的请求进行丢弃，这样有效的保障DNS的高可用性，截止6月19日下午在流量清洗和模式匹配的防护下，某运营商其DNS域名解析正常。

调整防护策略，UDP检测阀值调整范围在8万pps至15万pps之间：

p_w_picpath012

开启流量牵引，将访问DNS的流量牵引到域名专项防护系统ADS进行清洗，同时启动模式匹配-对恶意查询包进行丢弃：

p_w_picpath013

被清洗的流量日志:

p_w_picpath014

在防护措施实施以后，DNS业务解析状态逐渐恢复正常：

p_w_picpath015

***源回溯

通过抓包分析，大部分***源头来自如下：

*.*82.138 区域1 *.*82.27 区域1 ***.***83.202 区域1

*.*99.51 区域2 *.*82.107 区域1 ***.***82.136 区域1

*.*85.35 区域1 *.*84.65 区域1 ***.***75.137 区域1

*.*82.122 区域1 *.*83.19 区域1 ***.***82.96 区域1

*.*219.17 区域3 *.*82.121 区域1 ***.***87.194 区域1

*.*86.66 区域1 *.*85.90 区域1 ***.***20.231 区域1

通过查询其IP地址分配发现大部分***源头来自于区域1分公司给某银行架设的互联网专线，对其专线进行***测试发现其均开放了如下端口

PHP

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

PORT STATE SERVICE VERSION

53/tcp open domain dnsmasq 2.62

80/tcp open http LuCI Lua http config

135/tcp filtered msrpc

139/tcp filtered netbios-ssn

389/tcp filtered ldap

443/tcp open ssl/https?

444/tcp filtered snpp

445/tcp filtered microsoft-ds

593/tcp filtered http-rpc-epmap

1025/tcp filtered NFS-or-IIS

1434/tcp filtered ms-sql-m

2222/tcp open ssh Dropbear sshd 2011.54 (protocol 2.0)

4444/tcp filtered krb524

5800/tcp filtered vnc-http

6129/tcp filtered unknown

10000/tcp open snet-sensor-mgmt?

Service Info: OS: Linux

通过登录80和443端口发现该系统属于无线路由器，通过其集成商的配合调查发现其WEB登录存在弱口令,该设备AP是某厂商无线接入网关，其目前的登录账号属于弱口令。

p_w_picpath016

由于维护方不提供其ssh登录账号密码和网关登录的账号密码，另外针对defcon.org 的恶意查询已经消失，故无法继续深入调查。根据调查分析确认本次***来自于肉鸡、商业无线路由器，监控设备。

事件总结

本次***事件从2015年6月15日开始，至2015年6月19日未发现***。在此期间，某运营商网管中心互联网室协调绿盟科技等对***事件进行持续监控和分析，并采取有效的防护措施，最终有效的抵御了***，目前某运营商DNS业务已经恢复正常。

从2014年开始DDoS***方式出现了新的DDoS反射式放大***形式，该类***基于SSDP协议利用一些智能设备进行反射式***，***带宽放大倍数最高可达75倍，***方技术不断演进，将”以大欺小”（流量型***）与”以小博大”（资源耗尽型）两种***方式组合起来，利用逐渐提高的网络带宽增强***力等。

此次***事件持续时间长、***流量大、***技术复杂，对某运营商DNS业务的正常运行造成了严重影响，虽然采取了一系列的防护措施，达到了预期的效 果。但是，安全工作是一个长期持续性而非阶段性的工作，所以需要时刻保持一种警觉，认真总结这次***事件的应急处理过程，借此安全监控人员和管理维护人员 面对突发事件的应急处理能力，同时不断完善安全技术防护手段，不断更新安全制度，落实安全管理，从而更能有力地保障系统稳固健康地运行。