浅谈DDos攻击与防御

最近重新拜读了道哥的经典力作《白帽子讲Web安全》一书,发觉好书看一遍是不够的,每次品味都有不同的味道。道哥此书侧重于企业安全,即所讲所写偏重企业内部的安全建设,而不是针对某些漏洞大书特书。再次细读,深感需要做点笔记加强加强记忆,于是便以本篇开始,记录一些曾经看过的经典书籍的笔记。本篇主要用于记录《白帽子讲Web安全》读后感之DDos攻击与防御相关的知识。本篇记录的绝大部分内容来自《白帽子讲Web安全》,感谢道哥!

DDOS攻击
DDOS攻击

DDos简介

DDos又叫分布式拒绝服务,全称Distributed Denial of Service,利用DDos造成的攻击称为拒绝服务攻击,其原理就是利用大量的请求造成资源过载,导致服务不可用。
DDos攻击从层次上可分为网络层攻击与应用层攻击,从攻击手法上可分为快型流量攻击与慢型流量攻击,但其原理都是造成资源过载,导致服务不可用。

网络层DDos攻击

网络层DDos攻击包括SYN flood、UDP flood、ICMP flood等。

SYN flood攻击

SYN flood攻击主要利用了TCP三次握手过程中的bug,我们知道TCP三次握手过程是要建立连接的双方发送SYN,SYN+ACK,ACK数据包,而当攻击方随意构造源ip去发送SYN包时,服务器返回的SYN+ACK就不能得到应答(因为ip是随意构造的),此时服务器就会尝试重新发送,并且会有至少30s的等待时间,导致资源饱和服务不可用,此攻击属于慢型dos攻击。

UDP flood攻击

由于udp是一种无连接的协议,因此攻击者可以伪造大量的源IP地址去发送udp包,此种攻击属于大流量攻击。正常应用情况下,UDP包双向流量会基本相等,因此在消耗对方资源的时候也在消耗自己的资源。

ICMP flood攻击

此攻击属于大流量攻击,其原理就是不断发送不正常的ICMP包(所谓不正常就是ICMP包内容很大),导致目标带宽被占用,但其本身资源也会被消耗。并且目前很多服务器都是禁ping的(在防火墙在可以屏蔽icmp包),因此这种方式已经落伍。

网络层DDos防御

  • 网络架构上做好优化,采用负载均衡分流。
  • 添加抗DDos设备,流量清洗。
  • 限制单ip请求频率。
  • 防火墙等防护设置禁止icmp包等

网络层的DDos攻击究其本质其实是无法防御的,我们能做得就是不断优化自身的网络架构,以及提升网络带宽。

应用层DDos攻击

应用层DDos攻击不是发生在网络层,是发生在TCP建立握手成功之后,应用程序处理请求的时候。

CC攻击

CC攻击还有一段比较有趣的来历,据说当时绿盟为了防御DDos攻击研发了一款产品,叫做“Collapasar”,能够有效的防御SYN flood攻击。然而黑客为了挑衅,研发了一款Challenge Collapasar工具(简称CC)。
CC攻击的原理,就是针对消耗资源比较大的页面不断发起不正常的请求,导致资源耗尽。因此在发送CC攻击前,我们需要寻找加载比较慢,消耗资源比较多的网页,比如需要查询数据库的页面、读写硬盘文件的等。通过cc攻击,使用爬虫对某些加载需要消耗大量资源的页面发起http请求。

slowloris

这是由于webserver中间件漏洞引发的拒绝服务攻击,其原理是以极低的速度往服务器发送HTTP请求。apache等中间件默认会设置最大并发链接数,而这种攻击就是会持续保持连接,导致服务饱和不可用。slowloris有点类似基于HTTP协议的SYN flood攻击。

poc

构造以下畸形http请求包

GET / HTTP/1.1\r\n

Host: Victim host\r\n

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n

Content-Length: 42\r\n

完整的http请求头结尾应该是两次的\r\n\r\n,这里少了一次,因此服务器将会一直等待。

HTTP POST DOS

其原理是在发送HTTP POST包时,指定一个非常大的Content-Length值,然后以极低的速度发包,保持连接不断,导致服务饱和不可用。

poc

构造以下畸形http请求包

GET / HTTP/1.1\r\n

Host: Victim host\r\n

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n

Content-Length: 9999999999\r\n\r\n

Slow Read attack

Slow Read attack攻击方式是采用调整TCP协议中的滑动窗口大小,来对服务器单次发送发送的数据大小进行控制,使得服务器需要对一个回应分成很多个包来发送。

Server Limit Dos

这是由于cookie导致的dos攻击,当然其原理还是基于webserver的特性。apache默认最大的http包头长度为8192字节,如果超出此长度,则会返回4xx错误。如果我们利用存储型xss漏洞,将一个超长的cookie写入客户端页面,则用户再访问此页面后,由于请求头加载了恶意的超长cookie,导致其不能访问该站的页面(除非清空cookie)

ReDos

这是由于代码写得有缺陷,导致使用正则时,会出现大量占用资源的情况,导致服务不可用,这是利用了正则表达式在匹配时的某些特性决定的。

应用层DDos防御

  • 判断User-Agent字段(不可靠,因为可以随意构造)
  • 网页中镶嵌js代码(不可靠,因为爬虫也可携带浏览器引擎,或者执行js代码)
  • 针对ip+cookie,限制访问频率(由于cookie可以更改,ip可以使用代理,或者肉鸡,也不可靠)
  • 关闭apache最大连接数等,合理配置中间件,缓解ddos攻击。
  • 页面中添加验证码,比如搜索数据库时。
  • 编写代码时,尽量实现优化,并合理使用缓存技术,减少数据库的读取操作。

应用层的防御有时比网络层的更难,因为导致应用层被dos攻击的因素非常多,有时往往是因为程序员的失误,导致某个页面加载需要消耗大量资源,有时是因为中间件配置不当等等。而应用层DDos防御的核心就是区分人与机器(爬虫),因为大量的请求不可能是人为的,肯定是机器构造的。因此如果能有效的区分人与爬虫行为,则可以很好地防御此攻击。

无线DDOS

@更新于2017年5月31日
参考:http://www.freebuf.com/articles/wireless/135598.html

Auth Flood攻击

Auth Flood攻击:即身份验证洪水攻击。该攻击目标主要针对那些处于通过验证、和AP建立关联的关联客户端,攻击者将向AP发送大量伪造的身份验证请求帧(伪造的身份验证服务和状态代码),当收到大量伪造的身份验证请求超过所能承受的能力时,AP将断开其他无线服务连接。

Deauth Flood攻击

Deauth Flood攻击即为取消验证洪水攻击,它旨在通过欺骗从AP到客户端单播地址的取消身份验证帧来将客户端转为未关联/未认证的状态。对于目前的工具来说,这种形式的攻击在打断客户无线服务方面非常有效和快捷。一般来说,在攻击者发送另一个取消身份验证帧之前,客户端会重新关联和认证以再次获取服务。攻击者反复欺骗取消身份验证帧才能使所有客户端持续拒绝服务。

Association Flood攻击

Association Flood攻击即为关联洪水攻击。在无线路由器或者接入点内置一个列表即为连接状态表,里面可显示出所有与该AP建立连接的无线客户端状态。它试图通过利用大量模仿和伪造的无线客户端关联来填充AP的客户端关联表,从而达到淹没AP的目的。
由于开放身份验证(空身份验证)允许任何客户端通过身份验证后关联。利用这种漏洞的攻击者可以通过创建多个到达已连接或已关联的客户端来模仿很多客户端,从而淹没目标AP的客户端关联表。

Disassociation Flood攻击

Disassociation Flood攻击即为取消关联洪水攻击,和deauthenticaiton flood攻击表现方式很相似。它通过欺骗从AP到客户端的取消关联帧来强制客户端成为未关联/未认证的状态。一般来说,在攻击者发送另一个取消关联帧之前,客户端会重新关联以再次获取服务。攻击者反复欺骗取消关联帧才能使客户端持续拒绝服务。
Disassociation Broadcast攻击和Disassociation Flood攻击原理基本一致,只是在发送程度及使用工具上有所区别,前者很多时候用于配合进行无线中间人攻击,而后者常用于目标确定的点对点无线DOS,比如破坏或干扰指定机构或部门的无线接入点等。

RF Jamming攻击

RF Jamming攻击即为RF干扰攻击。该攻击是通过发出干扰射频达到破坏正常无线通信的目的。而前面几种攻击主要是基于无线通信过程及协议的。RF为射频,主要包括无线信号发射机及收信机等。

原文:https://thief.one/2017/05/10/1/