就在2016年底,也就是七天之前,我们的网络系统记录下了一次650Gbps的DDoS分布式拒绝服务攻击,这也是我们首次遇到流量如此之大的DDoS攻击。我们通过研究发现,此次大流量的DDoS攻击依旧是由物联网僵尸网络发动的,其中还涉及到某种新型的恶意软件。不过请不用担心,此次攻击已经被我们的网络防御系统轻松地“解决”掉了。
攻击描述
此次DDoS攻击大概开始于12月21日上午10点55分,针对的是Imperva Incapsula网络中的多个IP地址。目前我们仍然不清楚此次攻击为什么针对的不是特定的用户,但是根据我们的推测,这很有可能是由于攻击者无法解析真正目标的IP地址所造成的,因为客户真正的IP地址已经由Incapsula的代理服务器进行了隐藏处理。因此,攻击者便失去了最佳的攻击目标,所以他们只能将注意力转移到Imperva Incapsula上。
下图显示的是攻击流量的相关数据:
我们可以从上图中看到,第一波DDoS攻击流量持续了将近20分钟,流量峰值在400Gbps左右。然后流量迅速减少,产生了一个凹槽,接下来攻击者便发动了第二波攻击。这一次,攻击者所控制的僵尸网络生成了一波650Gbps的DDoS攻击流量,这波攻击每秒钟的数据包数量(Mpps)已经超过了1亿5000万个。
下图显示的是每秒钟的数据包数量(150+Mpps):
第二波攻击持续了大约17分钟,但是我们的网络防御系统仍然可以轻松应对这些恶意流量。当然了,攻击者也十分聪明,当他发现攻击效果不明显之后,他也打消了继续攻击的念头。
我们的安全技术人员通过分析发现,这两波DDoS攻击流量来源于伪造的IP地址,所以我们几乎无法定位到这个僵尸网络的真实地理位置,而且也很难去确定发动攻击的设备是什么。
下图显示的是此次攻击中僵尸网络的部分IP地址:
虽然无法通过IP地址来定位僵尸网络,但是我们可以对攻击payload来进行分析,然后从中发现一些蛛丝马迹,最后成功识别此次攻击背后的僵尸网络。
Payload分析
通过研究发现,此次攻击中的恶意流量由两种不同的SYN payload生成:
1. 常规大小的SYN数据包,大小从44字节到60字节不等;
2. 不正常的大型SYN数据包,大小从799字节到936字节不等;
第一种数据包是为了达到一个较高的Mpps,而第二种数据包是为了将攻击能力放大到650Gbps。
实际上,这种将小型和大型payload结合起来发动网络攻击的情况越来越常见了。在此之前,我们还发现有攻击者曾尝试利用这种手段来堵塞目标的网络通信线路,并意图拖垮网络交换机和路由器等设备。
在对这两种payload进行了深入分析之后,我们发现了一些非常有意思的东西。
我们所发现的第一样东西,就是攻击者在常规大小的SYN数据包中所留下的“签名”。在这些恶意数据包中,其header中TCP选项的值(“1337″)是专门修改过的,这个值代表的是“leet”或“elite”。
具体如下图所示:
第二个吸引我们眼球的东西就是大型SYN payload中的内容。某些payload中的内容似乎是一些随机字符串,而另一些payload中似乎零零散散地夹杂着一些IP地址,具体如下图所示:
我们可以从这些零散的IP地址中找出这些恶意payload内容的生成方式。经过分析之后我们发现,我们所面对的这个恶意软件可以访问目标设备的本地文件(日志文件和iptable列表等等),并利用这些文件中的数据来生成恶意payload。
基本上我们可以这样认为,攻击者从成千上万台被入侵的设备系统中提取出了大量文件数据,并利用这些数据生成了攻击所用的payload。
但是,使用这种攻击方法的人一般都有准确的目的。具体来说,这种方法可以算得上是一种十分有效的混淆技术,攻击者可以通过这项技术来生成无限数量的随机payload。接下来,攻击者就可以利用这些随机程度非常高的恶意payload来绕过基于签名的安全防护系统,并实施进一步的攻击活动。
Mirai的对手,Leet僵尸网络
就此看来,此次攻击似乎为我们的2016年画上了一个“圆满”的句号。成功地缓解此次攻击也是网络安全防御领域的一个里程碑,因为这不仅标志着我们的网络防御技术踏上了一个新的台阶,而且也显示出了我们的网络系统足够强大的应变能力。但是,我们仍要从中吸取经验和教训,并为迎接2017年更多未知的安全风险做好准备。
直到目前为止,2016年所有的大规模DDoS攻击事件都与Mirai恶意软件有关。但是,这些payload的特性足以表明,此次攻击与Mirai僵尸网络及其变种没有任何的关系。
证据如下:
1. 安全专家在对Mirai的代码进行了分析之后发现,Mirai对SYN payload数据包的大小进行了硬编码,这也就意味着Mirai恶意软件无法使用大型SYN数据包来发动攻击。相关代码如下所示:
1
|
iph->tot_len = htons(sizeof (struct iphdr) + sizeof (struct tcphdr) + 20); |
2. Mirai对TCP选项(MSS、SACK、TSVAL、WSS)同样进行了硬编码,而在此次攻击中,99.99%的payload中都没有出现这些数据,只有0.01%属于特例(纯属巧合)。相关代码如下所示:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
// TCP MSS *opts++ = PROTO_TCP_OPT_MSS; *opts++ = 4; *((uint16_t *)opts) = htons(1400 + (rand_next() & 0x0f)); opts += sizeof (uint16_t); // TCP SACK permitted *opts++ = PROTO_TCP_OPT_SACK; *opts++ = 2; // TCP timestamps *opts++ = PROTO_TCP_OPT_TSVAL; *opts++ = 10; *((uint32_t *)opts) = rand_next(); opts += sizeof (uint32_t); *((uint32_t *)opts) = 0; opts += sizeof (uint32_t); // TCP nop *opts++ = 1; // TCP window scale *opts++ = PROTO_TCP_OPT_WSS; *opts++ = 3; *opts++ = 6; |
3. Mirai payload是由随机字符串生成的,但是此次攻击中的payload其内容是由目标系统的文件内容所构成的。
综上所示,这肯定是一个新型的僵尸网络,但是我们目前只能通过攻击者在TCP header中留下的签名(“1337″)来识别恶意软件作者的身份。
恶意流量达到了650Gbps,Leet僵尸网络可以称得上算是Mirai僵尸网络的第一个对手了。但是,它显然不是最后一个。2016年,DDoS攻击的规模和杀伤力已经上升了好几个台阶,而杀伤力更强的僵尸网络扑向我们也只是时间问题,2017年肯定还会出现各种各样更加可怕的僵尸网络。