您的位置:首页 > 其它

DNS DDoS***事件分析

2016-01-22 11:21 246 查看
某运营商枢纽节点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自带的抓包工具捕获数据包样本,并对捕获到的***样本进行分析,如下图所示:

在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

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是某厂商无线接入网关,其目前的登录账号属于弱口令。

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

事件总结

本次***事件从2015年6月15日开始,至2015年6月19日未发现***。在此期间,某运营商网管中心互联网室协调绿盟科技等对***事件进行持续监控和分析,并采取有效的防护措施,最终有效的抵御了***,目前某运营商DNS业务已经恢复正常。从2014年开始DDoS***方式出现了新的DDoS反射式放大***形式,该类***基于SSDP协议利用一些智能设备进行反射式***,***带宽放大倍数最高可达75倍,***方技术不断演进,将”以大欺小”(流量型***)与”以小博大”(资源耗尽型)两种***方式组合起来,利用逐渐提高的网络带宽增强***力等。此次***事件持续时间长、***流量大、***技术复杂,对某运营商DNS业务的正常运行造成了严重影响,虽然采取了一系列的防护措施,达到了预期的效 果。但是,安全工作是一个长期持续性而非阶段性的工作,所以需要时刻保持一种警觉,认真总结这次***事件的应急处理过程,借此安全监控人员和管理维护人员 面对突发事件的应急处理能力,同时不断完善安全技术防护手段,不断更新安全制度,落实安全管理,从而更能有力地保障系统稳固健康地运行。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  DNS DDoS***事件分析