某运营商枢纽节点DNS网络中防火墙会话数接近饱和(in use count 达到900万)，绿盟科技ADS产品报警有DDoS攻击告警，监测发现域名解析延时增大，严重影响了DNS业务的正常运行。
6月15日上午，接某运营商网管中心互联网室通知，其枢纽节点DNS服务器疑似遭受DDoS攻击。绿盟科技服务团队启动应急响应，并协调绿盟科技云安全运营中心协助处理，响应工作随即启动。
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自带的抓包工具捕获数据包样本，并对捕获到的攻击样本进行分析，如下图所示：
在ADS上监控到defcon.org这个域名的查询数量一直排在第一位，且查询数量较多，属于异常现象，如下图所示：
查询数量最多的域名，一个国外的黑客网站。如下图所示：
攻击原理
攻击者控制大量肉鸡发起针对多个域名（主要域名为defcon.org）的ANY放大查询（DNS Amplification attack，也叫反射攻击）和随机查询攻击，极大的消耗了防火墙的性能。这种攻击由来已久，2014年12月10至12月19日国内出现大规模针对运营商DNS网络的恶性DDoS攻击事件，当时的攻击者就是通过肉鸡对国外游戏厂商（arkhamnetwork.org、arkhamnetwork.com、getfastinstagramfollowers.net）的域名随机查询进行拒绝服务攻击，造成各省的DNS递归服务器延迟增大，核心解析业务受到严重影响。这种攻击模式成本低，效果好，追踪溯源困难。
攻击特点：
攻击开始时候都是采用ANY查询进行放大攻击，放大倍数达到50倍左右，基本特征不变，目前没有产生新的变种。
基本上的攻击都是肉鸡、无线路由器，监控设备，也有一些源IP本身是DNS服务器。
攻击时间不固定，下午多一些。
最高流量峰值达到10G。
分析过程
通过结合域名专项防护系统ADS的告警日志和抓包分析发现有大量对defcon.org 的ANY查询，分析发现此次攻击事件的攻击源90%均来自省内IP，部分肉鸡存在弱口令，相对于过去的攻击，此次攻击中攻击源更加多样化，其中智能监控设备和商用无线路由器（如：某厂商的路由器带有dnsmq服务）成为主力。
大量对defcon.org的ANY查询的恶意请求：
DNS服务器返回的应答数据包，数据包比正常应答数据包大：
大量对bittorren.com的随机域名查询：
域名专项防护系统ADS上defcon.org的查询统计,查询数量一直排在第一位：
处置阶段
根据告警情况，结合DNS防火墙的会话性能适用占比情况，及时调整域名专项防护设备的UDP检测阀值（其UDP阀值调整在8万pps-15万pps之间）对攻击流量进行清洗。同时在域名专项防护系统开启模式匹配策略（7层丢弃），对查询Defcon.org 的域名的源IP的请求进行丢弃，这样有效的保障DNS的高可用性，截止6月19日下午在流量清洗和模式匹配的防护下，某运营商其DNS域名解析正常。
调整防护策略，UDP检测阀值调整范围在8万pps至15万pps之间：
开启流量牵引，将访问DNS的流量牵引到域名专项防护系统ADS进行清洗，同时启动模式匹配-对恶意查询包进行丢弃：
被清洗的流量日志:
在防护措施实施以后，DNS业务解析状态逐渐恢复正常：
攻击源回溯
通过抓包分析，大部分攻击源头来自如下：
*.*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
PORT STATE SERVICE VERSION53/tcp open domain dnsmasq 2.6280/tcp open http LuCI Lua http config135/tcp filtered msrpc139/tcp filtered netbios-ssn389/tcp filtered ldap443/tcp open ssl/https?444/tcp filtered snpp445/tcp filtered microsoft-ds593/tcp filtered http-rpc-epmap1025/tcp filtered NFS-or-IIS1434/tcp filtered ms-sql-m2222/tcp open ssh Dropbear sshd 2011.54 (protocol 2.0)4444/tcp filtered krb5245800/tcp filtered vnc-http6129/tcp filtered unknown10000/tcp open snet-sensor-mgmt?Service Info: OS: Linux
通过登录80和443端口发现该系统属于无线路由器，通过其集成商的配合调查发现其WEB登录存在弱口令,该设备AP是某厂商无线接入网关，其目前的登录账号属于弱口令。
由于维护方不提供其ssh登录账号密码和网关登录的账号密码，另外针对defcon.org 的恶意查询已经消失，故无法继续深入调查。根据调查分析确认本次攻击来自于肉鸡、商业无线路由器，监控设备。
事件总结
本次攻击事件从2015年6月15日开始，至2015年6月19日未发现攻击。在此期间，某运营商网管中心互联网室协调绿盟科技等对攻击事件进行持续监控和分析，并采取有效的防护措施，最终有效的抵御了攻击，目前某运营商DNS业务已经恢复正常。
从2014年开始DDoS攻击方式出现了新的DDoS反射式放大攻击形式，该类攻击基于SSDP协议利用一些智能设备进行反射式攻击，攻击带宽放大倍数最高可达75倍，攻击方技术不断演进，将”以大欺小”（流量型攻击）与”以小博大”（资源耗尽型）两种攻击方式组合起来，利用逐渐提高的网络带宽增强攻击力等。
此次攻击事件持续时间长、攻击流量大、攻击技术复杂，对某运营商DNS业务的正常运行造成了严重影响，虽然采取了一系列的防护措施，达到了预期的效果。但是，安全工作是一个长期持续性而非阶段性的工作，所以需要时刻保持一种警觉，认真总结这次攻击事件的应急处理过程，借此安全监控人员和管理维护人员面对突发事件的应急处理能力，同时不断完善安全技术防护手段，不断更新安全制度，落实安全管理，从而更能有力地保障系统稳固健康地运行。
