一起典型DDoS事件的应急处置

admin 2020年12月16日17:26:46评论49 views字数 2494阅读8分18秒阅读模式

一起典型DDoS事件的应急处置

一、缘起


前面写了一系列关于应急响应的文章,欠了一些文章,准备这段时间来补一个系列的文章。那么就从这篇文章开始吧这篇文章大概两年前就写好了但是因为某些原因一直没有发出来正好这段时间进行完善并作为这一系列文章的开篇。


二、DDOS


关于DDOS攻击,大家在日常的安全工作中肯定会多多少少遇到过一些。关于DDOS相关的技术,网络有大佬的总结,对于DDOS不太了解的童鞋,大家可以从网上找找相关系列文章自己学习学习关于DDOS攻击主要有以下几种方式


2.1 以量取胜


这个很好理解,你的带宽为500Mbps,攻击者打个600Mbps的量,肯定你的出口都拥堵了,这种攻击需要手上有各种肉鸡资源,这些对于专业的DDOS团伙来说都不是事。各种Iot设备、云平台,一个漏洞就很多资源上线。网上看到1Tbps的攻击量都有。常见的攻击技术有UDP Flood


2.2 以巧取胜


比较典型的就是慢速攻击,如Slowloris攻击、Hash冲突攻击等,需要特定环境机缘巧合下才能出现。


2.3 混合攻击


这种攻击一方面利用协议、系统和设备的漏洞与缺陷,另一方面以具备海量的流量,比较典型的攻击方式有DNS Query Flood攻击。


三、实战


3.1  第一波攻击


当时用户第一次遇到的时候,刚开始很慌,网站被打的几乎是瘫痪状态。通过日志和流量来看,的确很猛。一图胜千言,大家感受一下。入网流量3.49Mbps,出网流量5643Mbps。


一起典型DDoS事件的应急处置


看一下日志,访问了哪些资源。

主要访问了mp4、zip、doc等大流量的资源,怪不得出网流量这么大。


一起典型DDoS事件的应急处置


看了一下,访问都是相关的zip文件名,不过后面还有?随机数字,看来攻击者还是很聪明的,加个?随机数据来强制刷新缓存。这样的话即使访问的是同一个zip文件,加个?随机数字以后还是会强制从源服务器取数据,以达到DDOS最大化的效果。


一起典型DDoS事件的应急处置


攻击IP和频率看了一下,一是攻击源很多是同一IP,二是其访问很高的。用户那边由于前期部署了云防护产品,临时开个抗DDOS,本地还有硬件抗DDOS,云端和本地策略调整一段时间,封了大量IP,最终效果还不错,流量基本上下来了。


3.2 第二波攻击


本来以为这样就结束了。没想到安静不到几天,用户又反馈攻击流量又上来了,网站基本上又瘫痪状态了。难道是云防护没有生效,当时看了一下流量 下行流量的确很大,通过平台看了一下日志,这个时候攻击者不像前面那样 一个IP地址访问大量的资源了,这个时候的攻击者改变了攻击方式,同一个IP每次仅攻击1-2次,然后就不攻击了。并且IP的地理位置没有任何规律、国内外,各个国家和省份都有。


一起典型DDoS事件的应急处置


流量一直在打,云防护和本地设备显的有些吃力。攻击IP每次访问1-2次就不访问了,当时考虑的是使用验证码来做人机识别,但是用户是门户网站,又不是业务系统,打开一个门户网站输入验证码这种方式用户接受不了,后面用户只能协调云平台厂商来优化策略。


就在这种状态中持续了一段时间,最后梳理一下,我们大概评估了一下攻击者手上的肉鸡估计有几十万级别的。最后网站还是在不太稳定的状态中持续一段时间。


四、溯源


这波攻击从7月份持续到10月份,攻击时间之久也是第一次遇到。并且攻击者基本上都是有利益出发点的,但是这波攻击我到现在都没有想明白攻击原因。因为被打的是一个政府的门户网站,还不是业务系统,门户网站被打了大不了打不开,对被攻击者来说也没有影响到其业务系统,还是可以接受的。


既然不能完全防得住,那么来溯源看看是谁在攻击吧。于是便有了下面的分析,由于防护主要在云端防护,便从云防护厂商那面要了一面攻击者IP的列表,当时思路是这样的,通过IP分析其指纹信息,通过共同的指纹来分析黑客可能利用的攻击方式。


因为这么多IP,当时想到这些源IP肯定是肉鸡,既然是肉鸡那么肯定有恶意程序在指挥肉鸡进行攻击那么如果把这些肉鸡控制了说不定可以分析出攻击者。


4.1 提取攻击IP


这一步比较好操作,直接通过云平台导出来攻击IP即可。这里面只需要IP


一起典型DDoS事件的应急处置

4.2  提取指纹

有了IP,那么需要来分析这些IP的指纹信息,当时直接使用的傻蛋(shodan.io),fofa也非常推荐,github上有相关的脚本,跑完以后,看了一下指纹的结果,发现很多使用的是MikroTik,当时对这个指纹还不太了解网上找了一下,是路由器。


一起典型DDoS事件的应急处置


一起典型DDoS事件的应急处置


4.3 关联漏洞


既然发现攻击者很多是这个路由器,那么有没有可能是路由器是肉鸡呢?如果是肉鸡的话,肯定会有漏洞来利用的。于是从网上找了一下,果然关联到两个漏洞

  • Winbox任意目录文件读取(CVE-2018-14847)

  • Webfig远程代码执行漏洞


对于第一个漏洞CVE-2018-14847,利用这个漏洞可以直接读取到MikroTik路由器的账号密码。


4.4 漏洞利用


通过Github找了一下发现相关利用的脚本https://github.com/BasuCert/WinboxPoC,跑了一下,读取到相关路由器的账号密码:


一起典型DDoS事件的应急处置


4.5 入侵后分析


利用前面获取的账号密码登录到路由器来看看路由器的功能,不看不知道 一看吓一跳,这个路由器的功能还是真的强大,有很多功能:


4.5.1 Socks代理


第一感觉是攻击者是利用路由器的代理进行DDOS的,但是因为这个漏洞只能获取到管理界面的权限,无法获取到底层权限,也找了一下,没有找到相关的代理相关的日志,故也没有定位到真实的攻击者。


一起典型DDoS事件的应急处置


4.5.2   流量监听


一起典型DDoS事件的应急处置


4.5.3   Web Proxy


一起典型DDoS事件的应急处置


4.6 关联分析


由于在前面我们看到很多攻击IP都是MikroTik路由器,并且我们对MikroTik路由器进行分析,发现其存在漏洞,利用漏洞可以读取到其账号密码,从而进行对路由器进行代理、流量监听等,因此我们推测本次的攻击IP也是被代理进行DDOS的,但是因为通过路由器日志无法定位到相关真实的IP地址,因此本次分析只能分析至此,大佬们有精力可以分析一下怎么通过代理定位真实的攻击者。


五、结尾


这次应急是一次针对攻击->指纹->漏洞->溯源的一次实践,里面的分析有些不完善,但是个人认为这种思路还是不错的,后期在真实应急实战中也可以实践一下。


一起典型DDoS事件的应急处置

本文始发于微信公众号(疯猫网络):一起典型DDoS事件的应急处置

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2020年12月16日17:26:46
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   一起典型DDoS事件的应急处置https://cn-sec.com/archives/205745.html

发表评论

匿名网友 填写信息