0×01前言
系列回顾
DDOS攻击是每个需要对外提供服务的公司最大的威胁之一，尤其是新兴的互联网公司与电信运行商对此尤其看重，每个公司的网络安全组都必须具备一定的防御DDOS攻击的能力，不仅仅是会使用各个品牌的安全设备，更重要的是要有防御DDOS攻击的明确思路以及正确的方法，这样才能保证自己的公司不被黑客破坏、勒索。
任何需要通过网络提供服务的业务系统，不论是处于经济原因还是其他方面，都应该对DDoS攻击防护的投资进行考虑。大型企业、政府组织以及服务提供商都需要保护其基础业务系统（包括Web、DNS、Mail、交换机、路由器或是防火墙）免受DDoS攻击的侵害，保证其业务系统运行的连续性。虽然DDoS防护需要增加运营成本，但是从投资回报率上进行分析，可以发现这部分的投资是值得的。接下来我将详细讲解一下在企业层面和运营商层面防御主流DDOS攻击的思路。
0×02 企业层面的防御
在企业层面上防御DDOS攻击目的比较明确，就是保障自身的服务在攻击过程中不受明显的破坏，但由于 企业自身能力有限，有时候必须求助电信运营商帮助才能清洗较大流量。
SYN FLOOD的防御
Random Drop：随机丢包的方式，这种是最简单但是效果 也最不理想的方法，会对用户的体验造成很大影响，如果在垃圾流量比例较高时， 会使大量用户无法获得服务，这种方法不推荐只有在万不得已情况下（例如 服务器濒临死机）才能使用。
首报文丢弃：对所有首次发来的syn包丢弃，如果是真是由用户会刷新再次连接，第二次就可以成功通过，如果是软件随机生成的就不会再次 重试，但是如果对于那种一次发两个到多个报文的攻击就会失去效果，可以改进算法使用首秒丢弃，一秒对于用户来说不算长，但是对于攻击的软件来说一秒很久。
特征匹配：在攻击发生时统计攻击报文的特征，例如源IP、 ID、TTL、flag标志位、seq等字段， 然后丢弃与攻击报文有相同特征的报文，但是对于完全随机的攻击报文 则无法防御。
反向探测：企业服务器前的安全设备ADS或者WAF对每一个syn请求的地址发起反向探测，探测syn请求的源地址是否真实存在，如果不存在即可断开 半开连接。但是如果每个syn包 再配一个ack包会使反向探测难度增大，使得效果降低。
cookie验证：清洗设备收到syn报文时不向服务器端转发，而是由清洗设备直接给客户端回复syn ack报文，同时在回复syn ack报文的序列号中携带随机变化的cookie值，在收到客户端的回复报文中检查cookie值，如果检查通过则是合法客户端，允许访问服务器；而通常仿冒攻击的客户端没有完整的TCP状态机制，无法回复携带正确cookie的报文，因此无法通过清洗设备的cookie验证，最终无法对服务器形成攻击，可以有效用于syn flood的防护
TCP 代理：这种方法能完美的解决syn flood攻击，方法 就是在服务器前增加一个代理机制，访问服务器的TCP连接先与代理进行三次握手，握手成功后代理再与服务器进行三次握手，如果收到只有一个syn的半开连接，代理将不会与服务器进行连接，从而保护服务器 不受到syn flood的攻击，但是这种方法比较耗费TCP代理的资源，需要用专业的设备才行。 如下图：

SafeReset算法
所有的SYN包均主动回应，回应包特意构造错误的字段，真实存在的IP地址会发送reset包给防护设备，然后发起第2次连接，从而建立TCP连接。缺点是如果攻击者的源IP可以伪造成互联网上真实存在的IP，同样也会回复reset，进而通过验证。 原理如下：

ACK FLOOD防御
ack的防御于syn防御有很多的共通之处，再此我就不过多赘述。
特征匹配：同syn的特征匹配，计算攻击包的 指纹对符合的包直接丢弃 。
TCP代理：TCP代理既能完美防御syn攻击也能防御 ack攻击，但是ack攻击也会消耗TCP代理的大量资源。
带宽限制：限制ack数据包的传入带宽，使数量不足以瘫痪服务器。
cookie验证：同syn cookie验证。
CC攻击的防御
防御cc攻击的重点在于反欺骗，在海量的连接中需要分辨出攻击流量与正常流量 ，如何分辨出攻击流量与正常流量正是防 CC攻击