DDos攻击防御策略

DDOS攻击防御策略
DDOS(DDOS:Distributed Denial of Service) 分布式拒绝服务攻击.
在信息安全三要素里面—保密性,完整性,可用性,中DDOS(分布式拒绝服务攻击),针对的是目标机器的可用性,这种攻击方式是利用目标系统网络系统功能的的欠缺或者直接消耗其资源,是目标机器木法正常提供服务.
拒绝服务攻击示意图:
DDOS是一类攻击而不是一种攻击类型,并且DDOS的防御是一个可以做到相对自动化但是做不到绝对的自动化,很多攻击过程自动化并不能识别.
网络层的攻击
Syn-flood
利用TCP建立连接时3次握手的”漏洞”,通过原始套接字发送源地虚假地址SYN报文,使用目标主机永远无法完成3次握手,占满了系统的协议队列,资源得不到释放,进而形成拒绝服务攻击,是互联网中最主要的DDOS攻击形式之一.网上有一些加固的方法,例如调整内核参数的方法,可以减少等待重试,加速资源释放,在小流量的syn-flood的情况下可以缓解,单流量稍大时完全不抵用.防御syn-flood的常见方法有:syn-proxy,syn cookies.首包(第一次请求的syn包)丢弃等.
ACK-flood
对于虚假的ACK包,目标设备会直接回复RST包丢弃连接,所以伤害值远不如syn-floo.DDOS的一种原始方式.
UDP-flood
使用原始套接字伪造大量虚假源地址的UDP包,目前DNS协议为主.
ICMP-flood
Ping洪水,比较古老的方式.
应用层攻击
CC
ChallengeCollapsar的名字源于挑战国内知名的安全厂商绿盟的抗DDOS设备”黑洞”,通过boenet的傀儡机或寻找匿名代理服务器,向目标发起大量真实的http请求,最终消耗掉大量的并发资源,拖慢整个网站甚至彻底的拒绝服务.
互联网的架构追求扩展性本质是没了提高并发能力,各种SQL性能优化措施:消除慢查询,分表分库,索引,优化数据结构,限制搜索频率等本质都是为了解决资源消耗,而CC攻击大有反其道而行之的意味,占满服务器并发连接数,尽可能使请求避开缓存而直接读取数据库,读数据库要找对耗费资源的查询,最好无法利用索引,每个查询都全表扫描,这样就能用最小的攻击资源起到最大的拒绝服务效果
互联网产品和服务依靠数据分析来驱动改进和持续运营,索引除了前段的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 service列表.对于源地址伪造成ISP DNS的请求,可以通过TTL值进一步判断.
慢速连接攻击
针对http协议,以知名的slowloris攻击为起源:先建立一个http连接,设置一个比较大的content-length,每次只发送很少的字节,让服务器一直以为http头没有传输完成,这样的连接一多很快就会出现连接耗尽.
目前出现了一些变种,http慢速的post请求和慢速的read请求都是基于相同的原理.
DOS攻击
有些服务器程序存在bug.安全漏洞或架构缺陷,攻击者可以通过构造的畸形请求发送给服务器,服务器因不能正确处理恶意请求而陷入僵死状态,导致拒绝服务攻击.例如某些版本app服务器中存在缓存区溢出,漏洞可以触发但无法拿到shell,攻击者可以改变程序执行流程使其跳转到空指针或无法处理的地址,用户态的错误会导致进程挂起,如果错误不能被内核回收则可能使系统当掉.
这类问题效果也表现为拒绝服务攻击,但本质上属于漏洞,可以通过patch程序的新版本解决,我认为这不属于DDOS的范围.
攻击方式
混合型
在实际大流量的攻击中,通常并不是上述一种数据类型来攻击的,往往是混杂了TCP和UDP流量,网络层和应用层攻击同时进行.
反射型
2004年时DRDOS(是英文Distributed Reflection Denial of Service的缩写,中文意思是分布式反射服务攻击,与DOS和DDOS不同,该方式考的是发送大量带有被害者IP地址的数据包给攻击攻击主机,让后攻击主机对IP地址源做出大量的回应,形成拒绝服务)
通过将SYN包的原地址设置为目标地址,然后向大量的真实TCP服务器发送的SYN包,而这些收到SYN包的TCP service为了完成3次握手包SYN|ack包”应答”给目标地址,完成一次”反射”攻击,攻击者隐藏了自身,但有个问题是攻击者制造的流浪和目标收到的攻击量是1:1的,且SYN|ack包导弹目标后被回以rst包,整个攻击的投资回报率不高.
反射型攻击的本质是利用”咨询-应答”式协议,将质询包的原地址通过套接字伪造设置为目标地址,则应答的”回包”都被发送至目标,如果回包提交比较大或协议支持递归效果,攻击流量会被放大,成为一种高性价比的流量型攻击.
反射型攻击利用的协议有NTP,chargen,SSDP,DNS,RPC portmap等等.
流量放大型
以上面提到的DRDOS中常见的SSDP协议为例子,攻击者将search type设all,搜索所有可用的设备和服务,这种壁柜效果产生的放大背书是非常大的,攻击者只需要以较小的伪造源地址的查询流浪就可以制造出几十甚至上百倍的回应流量发送到目标.
脉冲型
很多攻击持续时间非常短,通常5分钟以内,流浪图上表现为突出状的脉冲.
所以这种攻击流行是因为”打打停停”效果比较好,刚触发防御阀值,防御机制开始生效就停止攻击,周而复始.蚊子不叮你,却在你耳边非,刚开灯打他他就没影了,当你关灯他有出来了.
自动化的防御机制大部分都是依靠设置阀值来触发的.尽管很多厂商宣称自己的防御措施都是秒级响应,但实际上比较难.
网络层的攻击检测通常分为逐流和逐包,前者是根据netflow以一定的抽样比例(例如1000:1)检测网络是否存在doos攻击,这种方式因为是抽样比例,所以精确率会比较低,做不到秒级响应,第二种逐包检测,检测精度和响应时间比较短但是成本比较高,一般厂商都不会无视TCO全部部署这类方案,其防御清洗策略的启动也依赖与阀值,加上洗流设备一般情况下不会串联部署,触发清洗后需要引流,因此大部分场景可以做秒级检测但是做不到秒级防御,近源洗流尚且如此,云清洗的触发和转换过程就更慢了,所以利用防御规则的生效过度期,在触发防御前完成攻击会有不错的效果,在结果上表现为脉冲.
链路泛洪
随着DDOS攻击技术的发展,有出现了一种新型的攻击方式link-flooding attack,这种方式不直接攻击目标网络traceroute的倒数第二跳,即上联路由,致使链路拥塞.国内ISP目前未开放anycast,所以这种攻击方式的必要性有待观望.
对一级ISP和IXP的攻击都可以使链路拥塞.
多层防御结构
DDOS攻击本质上是一种只能缓解而不能根本防御的攻击,它不像漏洞那样打个补丁就把问题解决了,DDOS就算购买和部署了当前市场上比较有竞争力的防御解决方案也谈不上彻底防御.防火墙,IPS,waf这些安全产品都号称自己有一定的抗D能力,而实际上他们只针对小流浪下,应用层的攻击比较有效,对于稍大流浪的DDOS攻击则无济于事.
以2015年年中的情况威力,国内的DDOS攻击在一个月内攻击流量到达300G的就将近10-20次,这个数值将随着国内家庭宽带网速提升而进一步放大.对于200-500G的攻击流量该如何防御.完整的防御模型有四层.
这四层不是严格意义上的宗申防御关系,也不是在所有的防御中4层都会参与,可能有时候只是其中的2层参与防御,但对于超大流量的攻击而言,4层就是防御急着的全部,在没有其他解决手段.跟厂商的市场宣传可能有所不同,大流量攻击的防护并不是像某些厂商宣称的那样靠单方面就能解决的,而是多层共同参与防御的结果.
ISP/WAN层
这一层通常是对用户不可见,如果只是中小企业,那这一层可能真的不会决出到.但如果是大型互联网公司或者云厂商,甚至云洗流厂商,这层是必不可少的.因为当前流量超过自己能处理的极限时必须要借助电信运用商的能力.大型互联网公司虽然自身储备的带宽比较大,但还没有达到轻松抵抗大流量DDOS的程度,毕竟带宽是所有IDC成本中最贵的资源没有之一.无论是云计算厂商,大型互联网公司对外宣称的成功抵御200G以上攻击的新闻背后都有运用到了运营商的抗D能力,另外像第三方云清洗平台他们实际上或多或少的依赖电信运营商,如果只靠自身的清洗能力,都是非常有限的.
目前如中国电信的专门做抗D的云堤提供了(近源洗流)和(流量压制)的服务,对于购买其服务器的厂商来说可以自定义需要黑洞路由的IP与电信的设备联动,黑洞路由是一种简单粗暴的方法,处理攻击流量,部分真实用户的访问也会被黑洞吃掉,对于用户体验大打折扣的行为,本质上属于为了保障留给其余用户的链路框框的弃卒保帅的做法,之前还会有这种收费服务是因为加入不这么做,全站服务器会对所有用户彻底无法访问.对于云清洗厂商而言,实际上也需要借助黑洞路由与电信联动.
相比之下,对攻击流量的牵引,清洗,回注的防御方式对用户体验的敲诈你没那么大,但是跟黑洞路由比防御方成本比较高,且触发到响应的延时较大.
在运营商防御这一层的主要的参与者是大型互联网公司,公有云厂商,云清洗厂商,其最大的意义在于应对超过自身带宽储备和自身DDOS防御能力之外的超大攻击流量时作为补充性的缓解措施.
CDN/intent层
CDN并不是一种抗D的产品,但对于web类服务而言,他却正好有一定的扛D能力,以大型电商的抢购为例,这个王文量非常大,从很多指标上看不言语DDOS的CC,而在平台侧实际上在CDN层面用验证码过滤了绝大多数请求,最后到达数据库的请求只占整体请求量的很小一部分.
对http CC类型的DDOS,不会直接到源站,CDN会先通过自身的带宽硬抗,抗不了的或者穿透CDN的动态请求会到元湛,如果源站前段的抗D能力或者源站前的带宽比较有钱,就会被彻底的D崩.
云清洗厂商提出的策略是,预先设置好网站的CNAME,将域名指向云清洗的DNS服务器,在一般情况下,云清洗厂商的DNS仍将穿透CDN的回源的请求指向源站,在检测到攻击发生时,域名指向自己的清洗集群,然后在将清洗后的流浪回源.
阿里云服务与知道创于抗D
点击回溯模式将自己的域名跟IP写好
将CNAME修改到阿里的云DNS上面之后点击修改选择云端模式
检测方式主要是在客户网站前部署反向代理(nginx),托管所有的并发连接.在对攻击流浪进行分流的时候,准备好一个域名到IP的地址池,当IP被攻击时封禁并启用地址池中的洗衣柜IP,如此往复.
以上是类Cloudflare的解决方案,国内云洗流厂商的实现原理都相似.不过这类方案有一个通病,由于国内环境不支持anycast,通过DNS引流的方式需要比较长的生效时间,这个时间依赖与DNS递归生效的时长,对自身完全不可控.同时CDN仅对web类服务有效,对游戏类tcp直接的服务无效.
网上很多使用此类抗D服务的过程可以概括为一句话:更改CNAME指向,等待DNS递归生效.
DC层
目前国内厂商华为的Anti-ddos产品的最高型号支持T级高达1440G带宽的防护.原理大致如下,在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层
这是DDOSD最后一道防线,这一层的意义主要在于漏过ADS这杯的流量做最后一次过滤和缓解,对ADS防护不了的应用层协议做补充防护.比如NTP反射,可以通过服务器配置禁用monlist,如果不提供基于UDP的服务,可以在边界上直接阻断UDP协议.
互联网在在线服务中最大的比重就是web服务,因此有些互联网公司喜欢自己在系统层面去做应用层的DDOS防护,例如对抗CC,有时这些功能也能顺带关联到业务安全上,不然针对黄牛抢单等.
实现方式可以是web服务器模块,也可以是独立部署的旁路系统,反向代理将完整的http请求转发给检测服务器,检测服务器根据几方面的信息:
来自于相同IP的并发请求
相同ip+cookies的请发请求
相同http头部可设置字段
相同的request URL
然后保存客户端的连接信息计数表,例如单位时间内相同IP+cookies再次发起连接请求则此客户端IP的计数器+1,知道触发阀值,然后服务器会进行阻断,为了避免误杀,也可以选择性的弹出验证码.
以上是拿CC防御举例子,ADS设备本身提供了http 302跳转,验证码.Javascript解析等防御方式,尽管os和应用层可以做更多的事情,但毕竟有自己去开发和长期维护的代价,这个收益腰间具体情况.

链路带宽
增加带宽,大部分极少DDOS防御策略的文章里似乎很少提及这一点,但确实以上所有防御的基础,例如第二层次的cdn实际上就是拼接带宽,很多大型企业选择自建cdn,本质上就是紫荆增加带宽的行为.处理cdn之外,要保障dc出口的多ISP链路,备份链路,到下层交换机的宽带都不存在明显的单点瓶颈,否则抗DDOS的处理性能够了,但是流量流经狗哥节点时突然把一个杂牌交换机压垮,最后的结果还是表现为有问题.
对运维经验成熟的互联网公司而言,一般都有能容管理,对于促销活动,高峰时段的带宽,IDC资源的波峰波谷都有预先的准备,DDOS防御主要是消除这些网络方案中内在的单点瓶颈.
不同类型的企业
DDOS的防御本质上属于资源的对抗,完整的4层防御效果虽好,但有一个明显问题就是TCO,这种成本开销处理互联网行业排名前十的公司以外的公司都是吃不消的.或者就算是付的起钱,子啊IT整体整体投资的占比会显得过高,付得起不代表这种投资是正确的,所以针对不同的企业分别描述DDOS缓解方案的倾向和选择性.

大型平台
这里的大是有几层意思的:
​公司很有钱,可以子啊补贴具体的业务上不”太”计较投入,对土豪来说之选效果最好的方案
公司不一定处于赚钱的阶段,但IDP投资规模足够大,这样为了保障既有的投入,安全的总投资维持一个固定百分比也是非常重要的,在IDC盘子很大的时候没有必要省”小钱”
与潜在的由于服务终端造成的损失比,DDOS防御的投资可以忽略不计
映射到现实中的与这几条相关的公司:
市值在100亿美金以上的互联网企业
大型公有云厂商,iaas,paas平台
IDC规模多大算大,这个问题其实很难判断,1w台物理服务器算多嘛,现在只能算中等.
利润比较高的业务,比如游戏,在线支付被DDOS的频率很高
对于IDC规模比较大有有钱的公司来说,房DDOS的口诀是”背靠运营商,大力建机房”,在拥有全部的DDOS防御机制
中小型企业
资源的对抗肯定不是中小型企业的强项,所以追求ROI是主要的抗D策略,第一种极度省钱模式,平时裸奔,知道受攻击才找抗D厂商临时引流,这种方案效果差一点,绝大多数企业都应该是这种新浪,得过且过,能省就省,也无可厚非,不过关键时间知道上哪儿去招谁,知道做那些事.
第二种追求效果,希望有性价比.如果本身业务运行于公寓云平台,可以直接使用云平台提供的抗d能力,对于web类可以考虑提前购买云清洗厂商的服务.
不同类型的业务
不同的类型的服务器需要的DDOS防御机制也是不一样的,所以不能直接拿前述4层生搬硬套.
Web
对于web类服务,攻击时发生时终端用户可以有一定的延迟容忍,在防御机制上4层全部适用,大型平台的一般都是4层全部拥有.规模小一点的企业一般购买云清洗,cloudflare类的服务即可.
游戏类
Web api形式的轻游戏跟web服务类似,而对于TCP socket 类型的大型网游,稍有延迟很影响用户体验,甚至很容易掉线.云waf,CDN等措施因为是针对web的所在,在该场景下无效,只有用过DNS引流和ADS来清洗流量,ADS不能完美防御的部分可以通过修改客户端,服务端的通信协议做一些辅助性的小动作,例如封包加tag标签,标签到没有tag的包一律丢弃,防御机制基本上都是依赖与信息不对称的小技巧.DNS引流的部分对于有httpdns的厂商可以借助其缓解DNS递归生效的时间.
服务策略
分级策略
对于平台而言,有限服务被DDOS会导致全站服务不可用,例如DNS不可用则相当于全线不可用,对于强账号体系应用例如电商,游戏等.如果SSO登录不可用则全线服务不可用,攻击者只需要击垮这些服务就能”擒贼先擒王”,所以安全上也需要考虑针对不同的资产使用不同等级的保护策略,根据BCM要求,先将资产分类分级,划分出不同的可用SLA要求,然后根据不同的SLA实施不同级别的防护,在具体防护策略上,能造成平台级SPOF(单点故障)的服务或功能应投入更高成本的防御措施,所谓更高成本不仅指购买更多的ADS设备,同事可能建立多灾节点,并且在监控和响应优先级上应该更高.巫师没有女朋友认识美女的介绍
Fallover机制
DDOS防御不只是依赖与DDOS防御的那4层手段,同时依赖与基础设施的强大,例如做分流,就需要多点异地灾备,mirror Site & standby System,云上的系统需要跨AZ部署,这些可以随时切换的基础,把鸡蛋放是技术形式上的基础,到一个篮子里会导致没什么选择.
基础设施和应用层面建立冗余,惯有这些还远远不够,需要有与值配套的DRP&BCP策略集,并且需要真实的周期性的演练,遇到超量攻击时能狗从容应对.
有损服务
在应用服务设计的时候,应该尽量避免”单点瓶颈”,避免一个点被DDOS了整个产品就不好用了,而是希望做到某些服务即使关闭或者下线仍然不影响其他在线的服务(或功能),能在遇到需要弃卒保帅的场景时可以做”割肉”的选择,不要除了”0”就是”1”,还是要存在灰度,比如原来10个服务器在线,遇到攻击时我们只要保底重要的3个服务在线即可.
补充手段
DDOS攻击的目的不一定完全是处于想出于想崩服务,比如之前在做游戏时遇到玩家DDOS服务器的目的竟然是因为没抢到排在第一的房间,这种因素通过产品设计就可以根治,而有很多应用层DDOS只是为了达成另外一种目的,都跟上述四层防御机制无关,而跟产品设计有关.所以防御DDOS这事得看动因,不能盲目应对
NIPS场景
本质上是一个包过滤设备,虽然功能不同但是却跟IPS有点类似,之前也提到有时候需要提供全站的虚拟补丁功能,ADS设备就可以充当这一角色,只是条目不宜太多,只上有限的条目.
如果安全团队能力能说的过去,可以通过运行POC exploit ,庵后抓包找出攻击payload的特征,编辑16进制的匹配规则,即可简单的实现人工指定.

破防和反制
从安全管理者的角度看,即便是拥有完整的4层防御机制也并非无懈可击,号称拥有400-500G防护能力的平台是完全有可能被打垮的,完全的防护能力是建立在人,策略,技术都生效的情况下才有用的,如果这些环节出了问题,anti-ddos的整个过程可能会失败,例如下面的问题
超大流浪攻击时需要用到黑洞路由,但黑洞路由的IP需要由防御方制定和联动,”联动”的过程就是向上游设备发送封禁IP的通知,如果接口不可用,那么这些功能就会失效,所以ISP级的防御是由失效的可能性的.
CDN云洗流服务一俩与清洗的服务器厂商接管域名解析,如果云清洗服务厂商本身的DNS不可用,也导致这一层面的防御失效,抗D厂商并不是无懈可击.
ADS平时不一定串联部署,但攻击引流后一定是部署在前端设备,假如这个设备本身存在DOS的可能,即使时触发了bypass也相当于防御完全失效,另一方面策略下通常是ADS设备跟管理节点想通,如果管理节点出现可用性能问题,也将导致ADS防御的一系列问题.
超大流量攻击需要人工干预,最基本的需要是安全或运维人员能在办公网络连接到ADS的管理节点,能远程运维ADS设备,如果此时办公网络的运维管理链路出现故障,不仅切断了人员操作,还会把现场应急的紧张气氛提升一个星级,使人手忙脚乱.
以上并不在于提供攻击思路,而是在与想Anti-ddos方案的制定者提供另类视角以便于审计方案中的短板.
立案与追踪
目前对于流量2g以上的攻击都是可以立案的,这笔过去幸福得多,过去没有本土特色的资源甚至没发立案,但是立案只是万里长征的第一步,如果逆向找到人,就必须完成一下步骤:
在海量的攻击中,寻找倒推线索,找出可能是CC服务器的IP或者是相关域名
黑吃黑,断掉CC服务器
通过登录IP或借助第三方apt的大数据资源(如果你能得到的化)物理定位攻击者
陪警察叔叔上门抓捕
上法庭诉讼
如果这个人没什么特殊身份,也许你能如愿以偿,但假如你遇到一些特殊人物,你几个月都白忙乎了.而黑吃黑的能力就比较依靠你们安全团队的渗透攻击能力了,而且你们安全团队还得有时间,这个过程对于很多企业来说成本还是比较高的,关有实力的安全团队就可以砍掉绝大对数公司.很巧的是我一个人能做整个团队的事情