DDoS防护实现概述

Posted vinsent

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了DDoS防护实现概述相关的知识,希望对你有一定的参考价值。

这一篇文章描述DDoS流量清洗实现的一些思路。

假设有这样一种场景:一个武林高手和一个基本没有功底的人切磋武艺,胜负如何是无需多言;换另一种场景,如果是十个普通人和武功高手对招,虽然可能费点力气,但是武功高手还是可以再拿下一城;更进一步假设,一百个毫无底子的成年人一拥而上,和这名高手对打,如果高手的武艺有如当年镇守襄阳城的郭靖,还是有胜算的;最后,如果是一千名、一万名普通人对武林高手群殴的话,我猜就算是达摩祖师,估计也难以抵挡得住。
DDoS攻击,就像上面扫描的场景:一个恶意IP的请求到达服务器,应该掀不起什么波浪;但如果是成千上万台恶意肉鸡对同一个域名发起DDoS攻击,威力是绝对不容小觑的。更何况,现在几十万恶意肉鸡发起的攻击,都已经司空见惯,以后随着入网的物联网设备增多,参与攻击的肉鸡数量相比如今,可能数量级还会再往上升一级。

再回到刚才假想的最后一种场景,如果武林高手想要夺回主动权,他应该怎么办?可能会有几个办法:第一,请帮手,拉更多的人加入对抗;第二,找一个狭长的地方,一夫当关,万夫莫开,纵然对方人再多,也只能一个一个过来挨揍;第三,找一个很高或者说普通人很难上去的地方,一般人爬不上去,提升这一批人和高手过招的门槛。

对应到DDoS的攻击防护中,处理的思路颇有相似之处:第一,对服务器做横向扩容。如果后端源站数量足够多,处理性能足够强劲,再加上如果能够弹性扩容,这样对方想把应用搞瘫,也绝非易事。当然这种方法成本太高,对于传统未上云的企业来说,会造成资源的浪费。第二,对访问流量做限流。按平时的业务访问情况进行评估,针对单个访问用户实施限流,避免出现一些异常访问源的请求量过大,影响业务。同时如果到达目标服务器的流量太高,可能会超出服务的处理性能,通过对目标进行限速,可以保证服务器不挂,至少业务是不会完全中断的;第三,对于不合法的流量实施过滤。事实上,互联网上的很多攻击流量,特别是SYN Flood攻击,都会携带比较大的payload,这样一方面可以消耗服务器的连接性能,同时也可以堵塞带宽,造成网络拥塞;对于这种畸形报文的攻击,清洗设备是可以直接将其过滤掉的。第四,对访问源做认证,提高对服务器的访问门槛。只有经过认证的请求,才可以被送到后端的服务器。按照理想的情况,所有的肉鸡均是异常IP,理论上都不应该通过清洗设备的认证。

DDoS防护实现的具体思路

不合法流量过滤

第一种思路是对不合法的流量实施过滤。具体的过滤手段比较多,在以太网中正常传输的数据报文,会有以太帧头、IP头部、TCP头部、应用层payload信息。对于不同层次的协议字段,都可能作为流量过滤的依据。首先,针对IP协议、TCP/UDP协议、或者一些常见的应用层协议如HTTP,都会有RFC文档说明,进行通信协议标准的定义,描述各个协议字段的具体含义以及合理的取值范围。如果报文内容不符合RFC协议规范,或者报文中的不同字段,出现了本不应该出现的组合方式,我们就认为这些报文是畸形报文,可以将其过滤掉。最常见的是SYN畸形包,正常的TCP三次握手的第一个SYN报文,是不应该携带payload内容的。(当然如果在协议中开启了了TCP fast open,可能也会携带有payload信息。不过在现网流量中,目前还没有遇到这种类型的访问流量,应该来说,应用还是极少数)而现有的很多压测工具,例如hping,发出来的SYN压测流量,就是典型的畸形报文,是可以做为不合法报文进行过滤的:

技术图片

其次,客户端发送到服务器的请求报文符合RFC描述的协议规范,但是在实际的应用场景中是不应该出现的。举个例子,从IP协议层来说,运营商网络中应用的uRPF配置,可以阻断掉虚假源ip发起的攻击;在很多场景下,一个应用可能只允许某些IP,或者某些区域的IP地址访问,那我们可以根据源IP地址及其来源地区实施过滤,这就是很多网络设备或者安全设备都具备的ACL功能。从应用层的识别来说,如果一个WEB类型的应用,只接受GET、POST请求,那就可以把HEAD、PUT等请求过滤掉。诸如此类的阻断思路,我都把它们归于不合法流量的精准匹配过滤这种场景当中。

基于源的认证

身份认证在信息安全领域,应用范围相当广泛,认证技术也多种多样:口令认证、密钥认证、手机短信认证、生物特征认证等等。而在DDoS防护领域,认证也是很重要的一种识别攻击者的手段。但是DDoS的认证又相对特殊:正常的认证是服务器和客户端之间的互动行为,服务器询问客户端知道什么,或者拥有什么;客户端提供相对应的内容,就能通过服务器的认证。DDoS防护设备的特殊之处在于它处理的是网络层的攻击,它所处的位置决定了它不能像服务器一样,和客户端进行互动。现在很多认证手段是在客户端植入SDK,用于和服务器进行认证。但是一些使用标准客户端的程序,是没办法集成SDK的,比如使用浏览器访问服务器网页,或者使用微信H5页面访问服务器。这些场景下,客户端都是没办法植入SDK的,但是服务器照样可能遭受ddos攻击。DDoS防护设备,当然还需要对这种场景下的服务器进行防护。

从上面的描述来看,DDoS场景下的认证大致可以分为两种:如果没办法集成SDK的,可以使用基于网络协议的反向探测认证;如果用户有自己的客户端,可以可以接受嵌入SDK的,则可以使用基于加解密算法的认证方式。基于网络协议的反向探测,粒度会相对比较粗,思路是对客户端的网络层行为进行认证。清洗设备截获客户端发往服务器的请求报文,并构造特定的响应报文回给客户端,以观察客户端的这些报文做出的响应动作。如果响应行为符合预期,则将客户端地址加白,放行该IP地址的后续报文;如果不能通过认证,则直接把请求报文丢弃或者直接把源IP拉黑。

技术图片

举两个实际使用场景中的例子:在SYN Flood防护中对源ip地址的探测、首包丢弃等,就是利用了TCP协议的可靠传输及超时重传特性。

技术图片

对第一个包丢弃处理,等待TCP握手的重传。

技术图片

对于应用层来说,也有着类似的检测机制。例如截获客户的GET请求,对客户端回送302跳转报文,或者通过setcookie要求客户端携带随机的cookie值,亦或是给客户端回应一段JS代码,需要客户端能够返回对应的验证结果,这些手段,都是利用网络层或者应用层协议的特性,对客户端进行粗粒度的认证。

利用网络层协议特性进行认证,它的好处在于适用性比较强,只要是采用了TCP通信协议,就可以使用SYNCookie的验证手段;只要是HTTP客户端,就应该能够响应302跳转。另外一个好处就是这种验证手法对于客户端是无侵入的,不需要对服务器和客户端做任何改造,只要服务器、客户端遵循对应的网络协议,就能够使用这种认证方法。不好的地方是对网络通信是有损的,增大了网络报文的交互。因此在对时延要求比较敏感的情况下,这种认证方式使用面不广。而且正是因为这种手法的适用面太广,如果肉鸡也具备对应网络协议栈的行为,就能够突破清洗设备的认证。

使用SDK是另外一种认证手法,在客户端接入我们提供的SDK,和清洗设备进行认证。通过鉴权的客户端能够正常和服务器建立连接,没有通过认证的客户端则被阻断掉。这种方式是比较安全可靠的手段,但是缺点是需要被防护的用户对自己的客户端做改造,接入SDK,提高了成本。目前在大流量防护领域,这种方式的使用不是很广,可能在更精细化的攻防对抗领域,会有更多的应用场景。

限流

还有一种防护思路,就是实施限流。限流的对象可以是请求源,也可以是被访问目标。限流的维度也比较多,比如可以是源/目的ip地址、源/目标新建频率、源/目标会话数、URI的访问次数、cookie出现频率等等。无攻击时,可以基于单个源ip,或者单个源用户做基线统计,评估正常的业务水位。在被攻击时, 设置限流的门限值,超过门限值时即采取指定的动作。这种方式可以认为是一种兜底的方式,特别是基于目标的限流,可以保障服务器不挂,但是难免会出现对正常的访问请求产生误杀,这种方式对正常业务是会有一定影响的,在实际使用过程当中需要根据具体情况进行取舍。

后记

随着攻防对抗技术的不断演进,防护也在慢慢朝着自动化、智能化的趋势发展。智能化防护依托于底层设备丰富的数据支撑,自动识别攻击用户的恶意行为,实施自动化防护。目前智能防护在阿里云高防产品的攻击防护中,已经普遍使用,并且也取得了不错的效果。

以上是关于DDoS防护实现概述的主要内容,如果未能解决你的问题,请参考以下文章

转发 DDoS攻防战 : 概述

DDoS 攻击与防护:如何识别 DDoS 攻击?DDoS 防护 ADS 服务有哪些?

DDoS 攻击与防护:如何识别 DDoS 攻击?DDoS 防护 ADS 服务有哪些?

DDoS 攻击与防护:DDoS 防护购买和使用入门指南,DDoS 防护服务有哪些应用场景?

DDoS 攻击与防护:DDoS 防护购买和使用入门指南,DDoS 防护服务有哪些应用场景?

iOS应用安全防护框架概述