DDoS:(Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。达到阻止目标业务运转和系统瘫痪的目的。

流量型(直接)SYN\ACK\ICMP\UDP\Connection FLOOD等告警

流量型(反射)NTP\DNS\SSDP\ICMP FLOOD等告警

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

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

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

各种DoS效果漏洞利用入侵检测防御设备可能出现告警

摸清楚环境与资源 为DDoS应急预案提供支撑

所在的网络环境中，有多少条互联网出口？每一条带宽多少？

每一条互联网出口的运营商是否支持DDoS攻击清洗，我们是否购买，或可以紧急试用？当发生攻击需要启用运营商清洗时，应急流程是否确定？

每一条互联网出口的运营商是否支持紧急带宽扩容，我们是否购买，或可以紧急试用？当发生攻击需要启用运营商紧急带宽扩容时，应急流程是否确定？

每一条互联网出口的线路，是否都具备本地DDoS攻击清洗能力？

本地抗DDoS攻击设备服务商，是否提供了DDoS攻击的应急预案？

所有需要我们防御的业务，是否都在抗DDoS设备的监控范围内？

出现DDoS攻击的时候，所有需要自动清洗的业务，是否可以自动牵引并清洗？

是否有内部针对DDoS攻击应急的指导流程？

当发生DDoS攻击的时候如何第一时间感知？

安保应急中的DDoS攻击应急预案

根据以上信息，接下来就可以对号入座的针对每一个梳理出来的攻击场景部署防御手段了

流量型(直接)—流量未超过链路带宽—本地清洗

流量型(直接)—流量超过链路带宽—通知运营商清洗||临时扩容||云清洗—本地清洗

针对SYN、ACK、UDP、ICMP等类型的flood攻击：

一般情况下：本地清洗设备的防御算法都可以轻松应对。比如说首包丢弃、IP溯源等。

特殊情况下：可以再次基础上增加一些限速，至少就可以保证在遭受攻击的时候保持业务基本的可用性。

如果通过排查发现发生攻击源IP具有地域特征，可以根据地域进行限制(大量来自国外的攻击尤其适用)。

流量型(反射)—流量未超过链路带宽—本地清洗

流量型(反射)—流量超过链路带宽—通知运营商清洗||临时扩容||云清洗—本地清洗

针对NTP、DNS、SSDP等类型的反射攻击：

一般情况下：本地清洗设备的防御算法都可以有效的进行缓解。比如说对UDP碎片包的丢弃，以及限速等。

特殊情况下：由于反射攻击的特征大多呈现为固定源端口+固定目的IP地址的流量占了整个链路带宽的90%+

我们可以针对这些特征配置更加彻底的丢弃规则

CC—本地清洗—本地清洗效果不佳后—-云清洗

针对CC攻击，如果清洗效果非常不明显，情况又很紧急的情况下可以采用临时使用静态页面替换。

HTTP慢速—本地清洗—本地清洗效果不佳后—云清洗

对于HTTP body慢速攻击，在攻击过程中分析出攻击工具的特征后，针对特征在本地防御设备进行配置。

URL(反射)—本地清洗+云清洗

对于URL反射攻击，在攻击过程中找出反射源，在本地防御设备进行高级配置

各种DoS效果漏洞利用：监控入侵检测或防御设备的告警信息、做好系统漏洞修复

对于此类攻击，其实严格意义来说并不能算攻击，只能算是能达到DoS效果的攻击，仅做补充场景。

了解引流技术原理后，简要阐述各种方式在DDoS应急上的优劣：

本地DDoS防护设备：

本地化防护设备，增强了用户监控DDoS监控能力的同时做到了业务安全可控，且设备具备高度可定制化的策略和服务，更加适合通过分析攻击报文，定制策略应对多样化的、针对性的DDoS攻击类型；但当流量型攻击的攻击流量超出互联网链路带宽时，需要借助运营商清洗服务或者云清洗服务来完成攻击流量的清洗。

运营商清洗服务：

运营商采购安全厂家的DDoS防护设备并部署在城域网，通过路由方式引流，和Cname引流方式相比其生效时间更快，运营商通过提清洗服务方式帮助企业用户解决带宽消耗性的拒绝服务攻击；但是运营商清洗服务多是基于Flow方式检测DDoS攻击，且策略的颗粒度较粗，因此针对低流量特征的DDoS攻击类型检测效果往往不够理想，此外部分攻击类型受限于防护算法往往会有透传的攻击报文，此时对于企业用户还需要借助本地DDoS防护设备，实现二级清洗。

云清洗服务：

云清洗服务使用场景较窄，当使用云清洗服务做DDoS应急时，为了解决攻击者直接向站点真实IP地址发起攻击而绕过了云清洗中心的问题，通常情况下还需要企业用户配合做业务地址更换、Cname引流等操作配置，尤其是业务地址更换导致的实际变更过程可能会出现不能落地的情况。另一方面对于HTTPS Flood防御，当前云清洗服务需要用户上传HTTPS业务私钥证书，可操作性不强。此外业务流量导入到云平台，对业务数据安全性也提出了挑战。

对比了三种方式的不同和适用场景，我们会发现单一解决方案不能完成所有DDoS攻击清洗，推荐企业用户在实际情况下可以组合本地DDoS防护设备+运营商清洗服务或者本地DDoS防护设备+云清洗服务，实现分层清洗的效果。针对金融行业，更推荐的组合方案是本地DDoS防护设备+运营商清洗服务。对于选择云清洗服务的用户，如果只是在DDoS攻击发生时才选择将流量导入到云清洗平台，需要做好备用业务地址的更换预配置(新业务地址不可泄露，否则一旦被攻击者获悉将会失去其意义)。

3.DDOS防护实践总结

借鉴DDoS攻防工程师总结的经验，企业客户在DDoS防护体系建设上通常需要开展的工作有：应用系统开发过程中持续消除性能瓶颈，提升性能

通过各类优化技术，提升应用系统的并发、新建以及数据库查询等能力，减少应用型DDOS攻击类型的潜在危害；定期扫描和加固自身业务设备

定期扫描现有的网络主节点及主机，清查可能存在的安全漏洞和不规范的安全配置，对新出现的漏洞及时进行清理，对于需要加强安全配置的参数进行加固；确保资源冗余，提升耐打能力

建立多节点负载均衡，配备多线路高带宽，配备强大的运算能力，借此“吸收”DDoS攻击；服务最小化，关停不必要的服务和端口

关停不必要的服务和端口，实现服务最小化，例如WWW服务器只开放80而将其它所有端口关闭或在防火墙上做阻止策略。可大大减少被与服务不相关的攻击所影响的概率；选择专业的产品和服务

三分产品技术，七分设计服务，除了防护产品本身的功能、性能、稳定性，易用性等方面，还需要考虑防护产品厂家的技术实力，服务和支持能力，应急经验等；多层监控、纵深防御

从骨干网络、IDC入口网络的BPS、PPS、协议分布，负载均衡层的新建连接数、并发连接数、BPS、PPS到主机层的CPU状态、TCP新建连接数状态、TCP并发连接数状态，到业务层的业务处理量、业务连通性等多个点部署监控系统。即使一个监控点失效，其他监控点也能够及时给出报警信息。多个点信息结合，准确判断被攻击目标和攻击手法；完备的防御组织

囊括到足够全面的人员，至少包含监控部门、运维部门、网络部门、安全部门、客服部门、业务部门等，所有人员都需要2-3个备份明确并执行应急流程

提前演练，应急流程启动后，除了人工处理，还应该包含一定的自动处理、半自动处理能力。例如自动化的攻击分析，确定攻击类型，自动化、半自动化的防御策略，在安全人员到位之前，最先发现攻击的部门可以做一些缓解措施。

总结

针对DDoS防御，主要的工作是幕后积累，在没有充分的资源准备，没有足够的应急演练，没有丰富的处理经验，DDoS攻击将会造成灾难性的后果。