本文会涉及到DDoS攻击应急过程中的整体策略、应急流程以及针对一些典型攻击的具体分析和应对措施，旨在分析如何在遭受DDoS攻击的时候更高效的组织应急工作。所以并不会深入到每一种特定DDoS攻击的的具体攻击方法或是应对措施的具体配置。
0×00、引言
近年来DDoS攻击事件可谓是层出不穷，从各安全厂商的DDoS分析报告中也不难看出，DDoS攻击的规模及趋势正在成倍的增长。由于攻击的成本不断降低，技术门槛要求越来越低，攻击工具的肆意传播，互联网上随处可见成群的肉鸡，使得想发动一起DDoS攻击变成了一件轻而易举的事情。各企业对于DDoS攻击防御的投入也是慢慢的水涨船高。高投入当然需要高回报，抗DDoS工作做得好不好，往往就体现在了发生DDoS攻击时候的应急能力。
希望通过本文可以使读者了解并且能站到一个高度全面的看待DDoS攻击应急的工作。当我们真的遭受到的DDoS攻击的时候，能游刃有余的应对，而不是手忙脚乱。
0×01、总览
一般日常运维中对于应急的定义通常都会分为两类：一类是设备本身故障的应急，另一类就是对于业务的应急。
在这里，我们也把设备的故障列了出来。虽然这一块不是本文重点要讲的东西，但是如果当我们在遭受DDoS攻击的时候，抗D设备出了问题，也会使得我们空有一身力气无处使。所以在整体的应急框架里，这也是非常重要的一部分。
0×02、DDoS攻击应急策略
DDoS攻击应急策略总结为8个字就是“立体防御，层层过滤”，具体见下图。
大家都知道，DDoS攻击最最最大的特点就是流量大，但是也有很多不需要太大流量但是同样可以达到攻击效果的方式。所以就有了上图中的防御层次。
当受到DDoS攻击的流量还没有超过链路带宽的80%的时候，我们本地的抗DDoS攻击设备完全可以实现DDoS攻击的清洗。能自己搞定绝不麻烦别人。
当受到DDoS攻击的流量超过了链路带宽的100%的时候，这个时候就需要启动运营商的DDoS攻击清洗了。哎呀呀，你说刚好这条受攻击的链路运营商不提供DDoS攻击清洗服务怎么办？没关系，这个时候还可启用Plan B，通知运营商临时给我们扩容一下带宽就好了。只要攻击流量没把带宽占满，本地清洗就可行。
当受到DDoS攻击的流量运营商清洗起来效果不是那么好的情况下，可以紧急启用云清洗服务来进行最后的对决。
因为大多数真正的DDoS攻击都是“混合”攻击（掺杂着各种不同的攻击类型），比如说：以大流量反射做背景，期间混入一些CC和连接耗尽，以及慢速攻击。那么这个时候很有可能需要运营商清洗（针对流量型的攻击）先把80%以上的流量清洗掉，把链路带宽清出来，这个时候剩下的20%里面很有可能还有80%是攻击流量（类似慢速攻击、CC攻击等），那么就需要本地进一步的清洗了。
0x03、DDoS攻击应急流程
下图是一个比较适合大多数客户的对于DDoS攻击应急的整体流程图，其中有一些细节需要指出；1、如果我们没有专门24小时现场值守的安全运维工程师的话，一般情况下是通过网管中心来发现DDoS告警，那么就需要和网管监控中心的监控同事有相应的合作处理机制。2、如果我们的清洗设备并没有配置自动牵引，那么在发生攻击的时候需要手动开启。在应急状态下，这个动作由谁来做，怎么做，需要什么授权等等，这一块也是需要事前进行沟通并纳入到应急流程当中（尤其是如果在凌晨2点发生了DDoS攻击，就不会显得手忙脚乱）。3、关于通知运营商这一块依然是需要前期就沟通确认好对应的处理机制，使得应急状态下可以顺利进行。最起码需要保证运营商的接口人的联系方式，以及双方都确认的授权方式（比如有些客户的运营商清洗的流程是需要发送盖公章的书函的传真）。4、对于厂商的专家支持建议前期做好相关的技术交流与沟通，至少要确认在什么情况下启动此项机制，并且提前就一些基础信息的收集提供做好确认（毕竟二线支持到现场的相应是需要交通时间的，进入到应急流程以后业务恢复时间是我们不得不考虑的因素）
由于上图是一个通用的指导流程，所以会在很多细节方面没有太多的针对性（针对性太强了就没有办法通用了，这是一个很矛盾的点），所以该流程仅做参考使用，在使用过程中，还需要针对自己的事业环境因素来做相应的裁剪和优化。
0x04、DDoS攻击应急指导
4.1 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攻击防御总方针，接下来就可以对号入座的针对每一个梳理出来的攻击场景部署防御手段了。
- 流量型（直接）—流量未超过链路带宽—本地清洗
- 流量型（直接）—流量超过链路带宽—通知运营商清洗||临时扩容||云清洗—本地清洗
针对SYN、ACK、UDP、ICMP等类型的flood攻击：
一般情况下：本地清洗设备的防御算法都可以轻松应对。比如说首包丢弃、IP溯源等。
特殊情况下：可以再次基础上增加一些限速，至少就可以保证在遭受攻击的时候保持业务基本的可用性。
如果通过排查发现发生攻击源IP具有地域特征，可以根据地域进行限制（大量来自国外的攻击尤其适用）。
- 流量型（反射）—流量未超过链路带宽—本地清洗
- 流量型（反射）—流量超过链路带宽—通知运营商清洗||临时扩容||云清洗—本地清洗
针对NTP、DNS、SSDP等类型的反射攻击：
一般情况下：本地清洗设备的防御算法都可以有效的进行缓解。比如说对UDP碎片包的丢弃，以及限速等。
特殊情况下：由于反射攻击的特征大多呈现为固定源端口+固定目的IP地址的流量占了整个链路带宽的90%+
我们可以针对这些特征配置更加彻底的丢弃规则
- CC—本地清洗—本地清洗效果不佳后—-云清洗
针对CC攻击，如果清洗效果非常不明显，情况又很紧急的情况下可以采用临时使用静态页面替换。
- HTTP慢速—本地清洗—本地清洗效果不佳后—云清洗
对于HTTP body慢速攻击，在攻击过程中分析出攻击工具的特征后，针对特征在本地防御设备进行配置。
- URL（反射）—本地清洗+云清洗
对于URL反射攻击，在攻击过程中找出反射源，在本地防御设备进行高级配置
- 各种DOS效果漏洞利用：监控入侵检测或防御设备的告警信息、做好系统漏洞修复
对于此类攻击，其实严格意义来说并不能算DDoS攻击，只能算是能达到DOS效果的攻击，仅做补充场景
4.2 DDoS攻击应急指导
4.2.1流量型（直接）DDoS攻击
首先我们针对流量型（直接）DDoS攻击的判断以及清洗来做说明，此类型攻击比较有代表性的攻击有SYN-FLOOD、ACK-FLOOD、ICM-FLOOD、UDP-FLOOD攻击等。首先在发生DDoS攻击的时候在DDoS攻击检测设备上面就会有对应的告警，通常我们可以在检测设备上获取第一手的信息，不论是自动清洗还是手动清洗，当发生了DDoS攻击的时候想要对攻击进行防御，就需要把流量牵引到DDoS攻击的清洗设备上（串联部署除外）。不论是何种方式，当流量已经被牵引到清洗设备上以后，我们就可以通过抓包来进一步分析当前DDoS攻击的特征。
一般情况下，当我们抓到的数据包某类型的数据包的流量占到了整个包数的80%以上我们就确认攻击了。
- SYN-FLOOD
- TCP-SYN包的数量占到整个抓包文件的80%左右
2、服务器连接数查看
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攻击流量清洗设备的一般算法的防御效果就很好。关于设备的具体配置在这里就不做详细描述了。
4.2.2流量型（反射）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）
4.2.3应用型DDoS攻击
对应应用型的DDoS攻击，最典型的还要数CC攻击、以及HTTP慢速攻击了。这两种攻击的攻击特点和流量型DDoS攻击最大的区别是并不需要大流量即可达到攻击效果。有些极端情况下在遭受此类攻击的时候，流量特征并没有明显的变化，业务就已经瘫痪了。
对于此类攻击，DDoS攻击清洗设备的基础算法可以就作用没有那么明显了，需要在攻击过程中实时抓取攻击的特征，然后才好对症下药。
对于CC攻击来说，发生攻击时特征还是很明显的。一般情况客户在访问业务的时候不会集中在几个页面，而是比较分散的。当发生了CC攻击的时候，抓包后可以很明显的发现大量的访问都集中在某几个（5-10个）页面，那么我们可以针对这几个页面在DDoS攻击清洗设备上进行配置过滤。
对于HTTP慢速攻击来说，针对body慢速来说，一般的流量模型不会出现大量字节数非常小的报文。而且当发生此类攻击的时候，数据包的大小也是非常有规律的。通过分析确认这些特征后，在DDoS攻击清洗设备上配置对应的参数既可达到防御效果。
0x05、DDoS攻击应急演练
为了在发生DDoS攻击的时候真正可以高效的开展应急工作，需要的是平时我们的不懈努力。当我们确认了DDoS攻击应急策略，也根据自身的特点制定了DDoS攻击的应急流程，并且针对各种DDoS攻击的具体攻击分析以及应对操作也都有了以后。就应该定期的按照以上内容进行DDoS攻击的应急演练，演练的形式不限于沙盘演练还是实操演练。通过演练的方式让大家熟悉我们DDoS攻击的应急体系，另外通过演练总结我们在DDoS攻击应急过程中的不足。
0x06、知己知彼，百战不殆
以下是一些针对制定DDoS攻击应急体系中需要或多或少考虑的问题，供大家参考。
- 所在的网络环境中，有多少条互联网出口？每一条带宽多少？
- 每一条互联网出口的运营商是否支持DDoS攻击清洗，我们是否购买，或可以紧急试用？当发生DDoS攻击需要启用运营商清洗时应急流程是否确定？
- 每一条互联网出口的运营商是否支持紧急带宽扩容，我们是否购买，或可以紧急试用？
当发生DDoS攻击需要启用运营商紧急带宽扩容时应急流程是否确定？
- 每一条互联网出口的线路是否都具备本地DDoS攻击清洗能力？
- 本地抗DDoS攻击设备服务商是否提供了DDoS攻击的应急预案？
- 所有需要我们防御的业务是否都在抗DDoS设备的监控范围内？
- 出现DDoS攻击的时候所有需要自动清洗的业务是否可以自动牵引并清洗？
- 是否有内部针对DDoS攻击应急的指导流程？
- 当发生DDoS攻击的时候如何第一时间感知？