IT技术互动交流平台

T级攻防:大规模DDOS防御架构

发布日期:2016-07-14 22:03:47

在讲防御之前简单介绍一下各类攻击,因为DDOS是一类攻击而并不是一种攻击,并且DDOS的防御是一个可以做到相对自动化但做不到绝对自动化的过程,很多演进的攻击方式自动化不一定能识别,还是需要进一步的专家肉眼判断。


 网络层攻击


 

SYN-FLOOD

 


 

利用TCP建立连接时3次握手的“漏洞”,通过原始套接字发送源地址虚假的SYN报文,使目标主机永远无法完成3次握手,占满了系统的协议栈队列,资源得不到释放,进而拒绝服务,是互联网中最主要的DDOS攻击形式之一。网上有一些加固的方法,例如调整内核参数的方法,可以减少等待及重试,加速资源释放,在小流量syn-flood的情况下可以缓解,但流量稍大时完全不抵用。防御syn-flood的常见方法有:syn proxy、syn cookies、首包(第一次请求的syn包)丢弃等。


 

ACK-FLOOD

 


 

对于虚假的ACK包,目标设备会直接回复RST包丢弃连接,所以伤害值远不如syn-flood。DDOS的一种原始方式。


 

UDP-FLOOD

 


 

使用原始套接字伪造大量虚假源地址的UDP包,目前以DNS协议为主。


 

ICMP-FLOOD

 


 

Ping洪水,比较古老的方式。


 

应用层攻击

 

CC

 


 

ChallengeCollapsar的名字源于挑战国内知名安全厂商绿盟的抗DDOS设备-“黑洞”,通过botnet的傀儡主机或寻找匿名代理服务器,向目标发起大量真实的http请求,最终消耗掉大量的并发资源,拖慢整个网站甚至彻底拒绝服务。


 

互联网的架构追求扩展性本质上是为了提高并发能力,各种SQL性能优化措施:消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗,而CC大有反其道而行之的意味,占满服务器并发连接数,尽可能使请求避开缓存而直接读数据库,读数据库要找最消耗资源的查询,最好无法利用索引,每个查询都全表扫描,这样就能用最小的攻击资源起到最大的拒绝服务效果。

word-wrap: break-word !important;" />  

互联网产品和服务依靠数据分析来驱动改进和持续运营,所以除了前端的APP、中间件和数据库这类OLTP系统,后面还有OLAP,从日志收集,存储到数据处理和分析的大数据平台,当CC攻击发生时,不仅OLTP的部分受到了影响,实际上CC会产生大量日志,直接会对后面的OLAP产生影响,影响包括两个层面,一个当日的数据统计完全是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担。


 

CC是目前应用层攻击的主要手段之一,在防御上有一些方法,但不能完美解决这个问题。


 

DNS FLOOD

 


 

伪造源地址的海量DNS请求,用于是淹没目标的DNS服务器。对于攻击特定企业权威DNS的场景,可以将源地址设置为各大ISP DNS服务器的ip地址以突破白名单限制,将查询的内容改为针对目标企业的域名做随机化处理,当查询无法命中缓存时,服务器负载会进一步增大。


 

DNS不只在UDP-53提供服务,同样在TCP协议提供服务,所以防御的一种思路就是将UDP的查询强制转为TCP,要求溯源,如果是假的源地址,就不再回应。对于企业自有权威DNS服务器而言,正常请求多来自于ISP的域名递归解析,所以将白名单设置为ISP的DNS server列表。对于源地址伪造成ISP DNS的请求,可以通过TTL值进一步判断。


 

慢速连接攻击

 


 

针对http协议,以知名的slowloris攻击为起源:先建立http连接,设置一个较大的content-length,每次只发送很少的字节,让服务器一直以为http头部没有传输完成,这样的连接一多很快就会出现连接耗尽。

目前出现了一些变种,http慢速的post请求和慢速的read请求都是基于相同的原理。
 

DOS攻击

 


 

有些服务器程序存在bug、安全漏洞,或架构性缺陷,攻击者可以通过构造的畸形请求发送给服务器,服务器因不能正确处理恶意请求而陷入僵死状态,导致拒绝服务。例如某些版本的app服务器程序存在缓冲区溢出,漏洞可以触发但无法得到shell,攻击者可以改变程序执行流程使其跳转到空指针或无法处理的地址,用户态的错误会导致进程挂起,如果错误不能被内核回收则可能使系统当掉。

这类问题效果也表现为拒绝服务,但本质上属于漏洞,可以通过patch程序的最新版本解决,笔者认为不属于DDOS的范畴。


 

攻击方式

 


 

混合型

 


 

在实际大流量的攻击中,通常并不是以上述一种数据类型来攻击,往往是混杂了TCP和UDP流量,网络层和应用层攻击同时进行。


 

反射型

 


 

2004年时DRDOS第一次披露,通过将SYN包的源地址设置为目标地址,然后向大量的


 


 

真实TCP服务器发送TCP的SYN包,而这些收到SYN包的TCP server为了完成3次握手把SYN|ACK包“应答”给目标地址,完成了一次“反射”攻击,攻击者隐藏了自身,但有个问题是攻击者制造的流量和目标收到的攻击流量是1:1,且SYN|ACK包到达目标后马上被回以RST包,整个攻击的投资回报率不高。


 

反射型攻击的本质是利用“质询-应答”式协议,将质询包的源地址通过原始套接字伪造设置为目标地址,则应答的“回包”都被发送至目标,如果回包体积比较大或协议支持递归效果,攻击流量会被放大,成为一种高性价比的流量型攻击。

反射型攻击利用的协议目前包括NTP、Chargen、SSDP、DNS、RPC portmap等等。

 

流量放大型

 

 

以上面提到的DRDOS中常见的SSDP协议为例,攻击者将Search type设置为ALL,搜索所有可用的设备和服务,这种递归效果产生的放大倍数是非常大的,攻击者只需要以较小的伪造源地址的查询流量就可以制造出几十甚至上百倍的应答流量发送至目标。


 

脉冲型

 


 

很多攻击持续的时间非常短,通常5分钟以内,流量图上表现为突刺状的脉冲。


 


 

之所以这样的攻击流行是因为“打-打-停-停”的效果最好,刚触发防御阈值,防御机制开始生效攻击就停了,周而复始。蚊子不叮你,却在耳边飞,刚开灯想打它就跑没影了,当你刚关灯它又来了,你就没法睡觉。


 

自动化的防御机制大部分都是依靠设置阈值来触发。尽管很多厂商宣称自己的防御措施都是秒级响应,但实际上比较难。


 

网络层的攻击检测通常分为逐流和逐包,前者根据netflow以一定的抽样比例(例如1000:1)检测网络是否存在ddos攻击,这种方式因为是抽样比例,所以精确度较低,做不到秒级响应。第二种逐包检测,检测精度和响应时间较短,但成本比较高,一般厂商都不会无视TCO全部部署这类方案。即便是逐包检测,其防御清洗策略的启动也依赖于阈值,加上清洗设备一般情况下不会串联部署,触发清洗后需要引流,因此大部分场景可以做秒级检测但做不到秒级防御,近源清洗尚且如此,云清洗的触发和转换过程就更慢了。所以利用防御规则的生效灰度期,在触发防御前完成攻击会有不错的效果,在结果上就表现为脉冲。


 

链路泛洪

 


 

随着DDOS攻击技术的发展,又出现了一种新型的攻击方式link-flooding attack,这种方式不直接攻击目标而是以堵塞目标网络的上一级链路为目的。对于使用了ip anycast的企业网络来说,常规的DDOS攻击流量会被“分摊”到不同地址的基础设施,这样能有效缓解大流量攻击,所以攻击者发明了一种新方法,攻击至目标网络traceroute的倒数第二跳,即上联路由,致使链路拥塞。国内ISP目前未开放anycast,所以这种攻击方式的必要性有待观望。


 


 

对一级ISP和IXP的攻击都可以使链路拥塞。


 

多层防御结构

 


 

DDOS攻击本质上是一种只能缓解而不能完全防御的攻击,它不像漏洞那样打个补丁解决了就是解决了,DDOS就算购买和部署了当前市场上比较有竞争力的防御解决方案也完全谈不上彻底根治。防火墙、IPS、WAF这些安全产品都号称自己有一定的抗DDOS能力,而实际上他们只针对小流量下,应用层的攻击比较有效,对于稍大流量的DDOS攻击则无济于事。


 

以2015年年中的情况为例,国内的DDOS攻击在一个月内攻击流量达到300G的就将近10-20次,这个数值将随着国内家庭宽带网速提升而进一步放大。对于200~500G的攻击流量该如何防御,下来将展示完整的防御结构,通常可以分为4层。


 


 

这4层不是严格意义上的纵深防御关系,也不是在所有的防御中4层都会参与,可能有时候只是其中的2层参与防御。但对于超大流量攻击而言,4层就是防御机制的全部,再没有其他手段了。跟厂商们的市场宣传可能有所不同,大流量攻击的防护并不是像某些厂商宣称的那样靠厂商单方面就能解决的,而是多层共同参与防御的结果。
 

ISP/WAN层

 


 

这一层通常对最终用户不可见,如果只是中小企业,那这一层可能真的不会接触到。但如果是大型互联网公司,公有云厂商,甚至是云清洗厂商,这层是必不可少的。因为当流量超过自己能处理的极限时必须要借助电信运营商的能力。大型互联网公司虽然自身储备的带宽比较大,但还没到达轻松抵抗大流量DDOS的程度,毕竟带宽是所有IDC成本中最贵的资源没有之一。目前无论是云计算厂商,大型互联网公司向外宣称的成功抵御200G以上攻击的新闻背后都用到了运营商的抗D能力,另外像第三方的云清洗平台他们实际上或多或少的依赖电信运营商,如果只依靠本身的清洗能力,都是非常有限的。


 


 

目前如中国电信的专门做抗DDOS的云堤提供了[近源清洗]和[流量压制]的服务,对于购买其服务的厂商来说可以自定义需要黑洞路由的IP与电信的设备联动,黑洞路由是一种简单粗暴的方法,除了攻击流量,部分真实用户的访问也会被一起黑洞掉,对用户体验是一种打折扣的行为,本质上属于为了保障留给其余用户的链路带宽的弃卒保帅的做法,之所以还会有这种收费服务是因为假如不这么做,全站服务会对所有用户彻底无法访问。对于云清洗厂商而言,实际上也需要借助黑洞路由与电信联动。


 


 

相比之下,对攻击流量的牵引,清洗,回注的防御方式对用户体验的挑战没那么大,但是跟黑洞路由比防御方的成本比较高,且触发到响应的延时较大。


 

在运营商防御这一层的主要的参与者是大型互联网公司,公有云厂商,云清洗厂商,其最大的意义在于应对超过自身带宽储备和自身DDOS防御能力之外的超大攻击流量时作为补充性的缓解措施。


 

CDN/Internet层

 


 

CDN并不是一种抗DDOS的产品,但对于web类服务而言,他却正好有一定的抗DDOS能力,以大型电商的抢购为例,这个访问量非常大,从很多指标上看不亚于DDOS的CC,而在平台侧实际上在CDN层面用验证码过滤了绝大多数请求,最后到达数据库的请求只占整体请求量的很小一部分。


 

对http CC类型的DDOS,不会直接到源站,CDN会先通过自身的带宽硬抗,抗不了的或者穿透CDN的动态请求会到源站,如果源站前端的抗DDOS能力或者源站前的带宽比较有限,就会被彻底DDOS。


 

云清洗厂商提出的策略是,预先设置好网站的CNAME,将域名指向云清洗厂商的DNS服务器,在一般情况下,云清洗厂商的DNS仍将穿透CDN的回源的请求指向源站,在检测到攻击发生时,域名指向自己的清洗集群,然后再将清洗后的流量回源。


 

检测方式主要是在客户网站前部署反向代理(nginx),托管所有的并发连接。在对攻击流量进行分流的时候,准备好一个域名到IP的地址池,当IP被攻击时封禁并启用地址池中的下一个IP,如此往复。


 

以上是类Cloudflare的解决方案,国内云清洗厂商的实现原理都相似。不过这类方案都有一个通病,由于国内环境不支持anycast,通过DNS引流的方式需要比较长的生效时间,这个时间依赖于DNS递归生效的时长,对自身完全不可控。同时CDN仅对web类服务有效,对游戏类TCP直连的服务无效。


 

网上很多使用此类抗D服务的过程可以概括为一句话:更改CNAME指向,等待DNS递归生效。


 

DC层

 


 

Datacenter这一层的DDOS防御属于近目的清洗,就是在DC出口的地方部署ADS设备。


 


 

目前国内厂商华为的Anti-ddos产品的最高型号支持T级高达1440Gbps带宽的防护。原理大致如下图所示,在DC出口以镜像或分光部署DDOS探针(检测设备),当检测到攻击发生时,将流量牵引到旁路部署的DDOS清洗设备,再将经过清洗的正常流量回注到业务主机,以此完成一轮闭环。
 


 

部署设备本身并没有太大的技术含量,有技术含量的部分都已经被当做防御算法封装在产品盒子里了。不过要指出的一点是,目前市场上的ADS盒子既有的算法和学习能力是有限的,他仍然需要人的介入,比如:


 

  • 对业务流量基线的自适应学习能力是有限的,例如电商行业双11大促日子的流量模型可能就超越了ADS的学习能力,正常流量已经触发攻击判定

  • 自动化触发机制建立在阈值之上,就意味着不是完全的自动化,因为阈值是一个经验和业务场景相关的值

  • 全局策略是通用性策略,不能对每一个子业务起到很好的防御效果,有可能子业务已经被D了,全局策略还没触发

  • 常见的DDOS类型ADS可以自动处理,但变换形式的DDOS类型可能还需要人工识别

  • 默认的模板策略可能不适用于某些业务,需要自定义


     

    DDOS防御除了整体架构设计外,比较需要专业技能的地方就是在上述例子的场景中。目前在ADS设备里覆盖了3-4,7这三层的解决方案。


     


     

    一般情况下ADS设备可以缓解大部分常见的DDOS攻击类型,相对而言3-4层的攻击手法比较固定,而7层的攻击,由于涉及的协议较多,手法变化层出不穷,所以ADS有时候对7层的防护做不到面面俱到,比如对CC,ADS提供了http 302,验证码等,但还是不能很好的解决这个问题。应用层的防护需要结合业务来做,ADS则在能利用的场景下承担辅助角色,比如对于游戏封包的私有协议,通过给packet添加指纹的方式,ADS在客户端和服务端中间鉴别流入的数据包是否包含指纹。


     

OS/APP层

 


 

这是DDOS的最后一道防线。这一层的意义主要在于漏过ADS设备的流量做最后一次过滤和缓解,对ADS防护不了的应用层协议做补充防护。比如NTP反射,可以通过服务器配置禁用monlist,如果不提供基于UDP的服务,可以在边界上直接阻断UDP协议。


 

互联网在线服务中最大的比重就是web服务,因此有些互联网公司喜欢自己在系统层面去做应用层的DDOS防护,例如对抗CC,有时这些功能也能顺带关联到业务安全上,比如针对黄牛抢单等。


 


 

实现方式可以是web服务器模块,也可以是独立部署的旁路系统,反向代理将完整的http请求转发给检测服务器,检测服务器根据几方面的信息:

Tag标签: 架构   大规模  
  • 专题推荐

About IT165 - 广告服务 - 隐私声明 - 版权申明 - 免责条款 - 网站地图 - 网友投稿 - 联系方式
本站内容来自于互联网,仅供用于网络技术学习,学习中请遵循相关法律法规