如何应对DDoS直接攻击和DDoS放大攻击 绿盟科技给的DDoS攻击应急指南

昨天安全加的文章《由浅入深解读DDoS直接攻击与放大攻击 用地址段平面图展示攻击挺有意思》,介绍了DDoS直接攻击和DDoS放大攻击,今天这篇文章由绿盟科技的资深服务人员介绍,如何应对DDoS直接攻击和DDoS反射放大攻击,还包括应用型DDoS攻击

推荐阅读:

常见的DDoS攻击类型及DDoS攻击场景

这位长年奋斗在DDoS防护一线的资深服务人员介绍,DDoS攻击场景通常包括这些,下图为针对典型DDoS攻击通过攻击特征进行的分类:

转换为攻击场景:

DDoS攻击场景

现象

流量型(直接)

SYN\ACK\ICMP\UDP\Connection FLOOD等DDoS告警

流量型(反射)

NTP\DNS\SSDP\ICMP FLOOD等DDoS告警

CC

流量变化可能不明显,业务访问缓慢,超时严重,大量访问请求指向同一个或少数几个页面

HTTP慢速

流量变化可能不明显,业务访问缓慢,超时严重,大量不完整的HTTP GET请求,出现有规律大小(通常很小)的HTTP POST请求的报文

URL反射

流量变化明显,业务访问缓慢,超时严重,大量请求的Referer字段相同,表明均来自同一跳转页面

各种DOS效果漏洞利用

入侵检测防御设备可能出现告警,DDoS攻击检测设备告警不明显

这方面的更多信息可以参阅这篇文章《写给十九大安保应急的兄弟们 来看看DDoS攻击应急预案》,下面切入正题,如何应对DDoS直接攻击和DDoS放大攻击。

流量型(直接)DDoS攻击防御

首先我们针对流量型(直接)DDoS攻击的判断以及清洗来做说明,此类型攻击比较有代表性的攻击有SYN-FLOOD、ACK-FLOOD、ICM-FLOOD、UDP-FLOOD攻击等。首先在发生DDoS攻击的时候在DDoS攻击检测设备上面就会有对应的告警,通常我们可以在检测设备上获取第一手的信息,不论是自动清洗还是手动清洗,当发生了DDoS攻击的时候想要对攻击进行防御,就需要把流量牵引到DDoS攻击的清洗设备上(串联部署除外)。不论是何种方式,当流量已经被牵引到清洗设备上以后,我们就可以通过抓包来进一步分析当前DDoS攻击的特征。

一般情况下,当我们抓到的数据包某类型的数据包的流量占到了整个包数的80%以上我们就确认攻击了。

SYN-FLOOD

  1. TCP-SYN包的数量占到整个抓包文件的80%左右

  1. 、服务器连接数查看

netstat –an | find “SYN_RECEIVED”,检查TCP连接,发现大量连接处于SYN_RECEIVED即SYN半开状态下,可断定为正在遭受SYN Flood攻击。

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

ACK-FL00D

对于ACK-FLOOD攻击,一般情况大多数是为了消耗带宽,当我们通过分析抓包发现大量的没有建立TCP连接的大量的TCP-ACK的数据包,并且伴随着大量的重传的TCP-ACK的数据包的时候,基本就可以确定当前攻击为ACK-FLOOD攻击

ICMP-FLOOD

正常网络流量模型当中是会极少出现大量ICMP类型的数据包的,当我们抓包到的包超过20%的数据包为ICMP包的时候,有可能不是ICMP-FLOOD攻击,单至少表明当前网络环境中出现了问题。一个最典型的例子:当核心传输网络出现故障,某种情况下路由器会通过ICMP封装那些无法及时传输到目的地的数据包到服务器,导致ICMP-FLOOD的DDoS攻击告警。另外一个判断是否为真实ICMP-FLOOD攻击的特征是ICMP包的大小,一般情况ICMP的包大小是低于100byte的(除了某些特殊功能的ICMP探测包),那么,如果你抓的数据包中充斥这大量的ICMP的包,并且包大小都大于1000byte,甚至有的时候你会发现大量的分片的ICMP数据包的时候,基本就可以确认是ICMP-FLOOD攻击了。

UDP-FLOOD

由于UDP Flood攻击主要目的是导致带宽阻塞,单位时间内肯定会有大量的UDP包。同时这些UDP包的内容填充部分都十分相似。使用wireshark抓包观察,虽然UDP包来自于不同的源地址,访问的目的端口也不固定,但是Data字段部分都比较相似。

对于这类流量型(直接)DDoS攻击,DDoS攻击流量清洗设备的一般算法的防御效果就很好。关于设备的具体配置在这里就不做详细描述了。

流量型(反射)DDoS攻击防御

对于流量型(反射)DDoS攻击当前比较有代表性的攻击类型见下图:

攻击类型

放大倍数

被利用的弱点

NTP Amplification Attack

556.9

Monlist query

DNS Amplification Attack

28 to 54

Text query

SSDP Amplification Attack

30.8

SEARCH request

Charger Amplification Attack

358.8

Character generation request

SNMP Amplification Attack

6.3

GetBulk request

NetBIOS Amplification Attack

3.8

Name resolution

QOTD Amplification Attack

140.3

Quote request

大家都知道,反射型DDoS攻击的最大的两个特点:1、攻击流量往往大到惊人 2、溯源困难。由于反射的原因,导致背后真实的攻击源(即使是僵尸网络,当然大多数也都是僵尸网络)被隐藏起来,使得使用这类攻击的攻击者往往是肆无忌惮。

对于这类攻击在排查的时候特征都很明显,就笔者以往的应急经验来说,当遭遇此类攻击的时候,不论是在清洗设备上抓包,还是在网络的探针设备上抓包。攻击流量基本都能达到整理网络流量的90%以上,有时候甚至达到99%(毕竟反射型的攻击唯一的目的就是消耗网络带宽,把入口链路的带宽堵死)

此类攻击发生的时候,在DDoS攻击检测设备上基本出现的告警都是UDP-FLOOD

以下为此类告警抓包特征:

DNS反射攻击

NTP反射攻击

SSDP反射攻击

针对这些反射型DDoS攻击,其实防御起来也很容易。如果攻击流量超过了链路的带宽(一般表现为带宽多少,攻击流量就多少。因为多余的流量在运营商被丢弃了,这个丢弃是基于链路带宽的最大值丢弃的,而非DDoS攻击防御的丢弃),此时需要通过运营商的DDoS攻击流量清洗服务进行。如果攻击流量没有超过链路本身的带宽,本地清洗就可以起到防御效果。还可以在边界路由器上通过ACL把这类流量限制掉。在本地的DDoS攻击清洗设备上可以配置以下策略,来彻底清洗此类反射型DDoS攻击的流量:

    0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 UDP 0:65535 123:123 drop NTP Reflect

    0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 UDP 0:65535 1900:1900 drop SSDP Reflect

    0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 UDP 0:65535 19:19 drop CHARGEN Reflect

0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 UDP 0:0 0:0 drop Fragment

防护DNS反射攻击(DNS反射攻击的query字段是0x00ff),使用DNS关键字过滤防护(目前所遇到的DNS反射攻击,query字段的type,都是0x00ff)

应用型DDoS攻击防御

对应应用型的DDoS攻击,最典型的还要数CC攻击、以及HTTP慢速攻击了。这两种攻击的攻击特点和流量型DDoS攻击最大的区别是并不需要大流量即可达到攻击效果。有些极端情况下在遭受此类攻击的时候,流量特征并没有明显的变化,业务就已经瘫痪了。

对于此类攻击,DDoS攻击清洗设备的基础算法可以就作用没有那么明显了,需要在攻击过程中实时抓取攻击的特征,然后才好对症下药。

对于CC攻击来说,发生攻击时特征还是很明显的。一般情况客户在访问业务的时候不会集中在几个页面,而是比较分散的。当发生了CC攻击的时候,抓包后可以很明显的发现大量的访问都集中在某几个(5-10个)页面,那么我们可以针对这几个页面在DDoS攻击清洗设备上进行配置过滤。

对于HTTP慢速攻击来说,针对body慢速来说,一般的流量模型不会出现大量字节数非常小的报文。而且当发生此类攻击的时候,数据包的大小也是非常有规律的。通过分析确认这些特征后,在DDoS攻击清洗设备上配置对应的参数既可达到防御效果。

DDoS攻击应急演练

       为了在发生DDoS攻击的时候真正可以高效的开展应急工作,需要的是平时我们的不懈努力。当我们确认了DDoS攻击应急策略,也根据自身的特点制定了DDoS攻击的应急流程,并且针对各种DDoS攻击的具体攻击分析以及应对操作也都有了以后。就应该定期的按照以上内容进行DDoS攻击的应急演练,演练的形式不限于沙盘演练还是实操演练。通过演练的方式让大家熟悉我们DDoS攻击的应急体系,另外通过演练总结我们在DDoS攻击应急过程中的不足。

知己知彼,百战不殆

以下是一些针对制定DDoS攻击应急体系中需要或多或少考虑的问题,供大家参考。

  1. 所在的网络环境中,有多少条互联网出口?每一条带宽多少?
  2. 每一条互联网出口的运营商是否支持DDoS攻击清洗,我们是否购买,或可以紧急试用?当发生DDoS攻击需要启用运营商清洗时应急流程是否确定?
  3. 每一条互联网出口的运营商是否支持紧急带宽扩容,我们是否购买,或可以紧急试用?

当发生攻击需要启用运营商紧急带宽扩容时应急流程是否确定?

  1. 每一条互联网出口的线路是否都具备本地DDoS攻击清洗能力?
  2. 本地抗DDoS攻击设备服务商是否提供了DDoS攻击的应急预案?
  3. 所有需要我们防御的业务是否都在抗DDoS设备的监控范围内?
  4. 出现DDoS攻击的时候所有需要自动清洗的业务是否可以自动牵引并清洗?
  5. 是否有内部针对DDoS攻击应急的指导流程?
  6. 当发生DDoS攻击的时候如何第一时间感知?

发表评论