创业耗费百万，为何DDoS如此要命Part 1

0×00多年运维，不敌攻击从05年开始做运维到现在也有13年了，干过论坛，电商，游戏，金融，直播这些业务的运维，活很杂，什么WebServer，Database，Netfilter，Docker，Xen，KVM，OpenVZ，Ceph，iSCSI，DNS，负载均衡等等。

就和上面的图片一样，服务器资源被耗尽，用户无法和服务器建立连接，攻击者目的达到。那如何防御SYNFlood攻击呢(其实是缓解，提高一下系统的处理能力，但是只限于小攻击)？

如上图，这类攻击虽然不会导致服务器系统中出现大量的SYN_RECV，但是会出现服务器向伪造源IP发送大量的RST报文。举个例子：如果你的服务器接入带宽有1Gbps，并假设服务器OS的PPS处理能力达到1.4Mpps，并且OS设计非常牛逼，没有导致大量的中断和锁的开销为前提。那么你遭受500Mbps的ACKFlood攻击时，你的服务器也会出现上行带宽用到500Mbps左右。

对于网站业务来说，是用不到UDP协议的，所以防御这种攻击只需要拥有足够大的接入带宽(只要接入带宽比DDoS攻击更大)，你只需要一条ACL策略丢弃UDP协议便可以防御这种攻击。

这种攻击最大的威胁便是，通过随机构造并查询被攻击域名的二级域名，绕过递归DNS服务器的解析记录缓存，各地区地市的递归DNS服务器向权威DNS服务器发起大量的DNS查询请求，如果被攻击域名所在的权威DNS服务器性能和带宽无法支撑查询所需要的带宽，那么就会直接瘫痪，并影响这个权威DNS服务器上的其他域名。所以防御这种DNSQuery攻击，不但难度极大，而且成本极高，并且还不一定是100%防御。

攻击发起看似非常简单，实则暗藏玄机！HTTP(s)Flood攻击早在08年的时候，防御还是较为简单的，因为浏览器单一(大部分都是IE浏览器)，通常硬件防火墙会采用JS-Redirect算法来做CC防御，效果非常显著，但是99%的DDoS硬件防火墙是不支持HTTPS场景防御的。

防御方式：方案1：主要是扩展后端业务服务器规模来死扛这种攻击，成本极高，但是能解决。部署数据库集群，支持横向扩展，应对超大的CC攻击带来的数据库查询压力。部署WEB服务器集群，支持横向扩展，对应超大CC攻击带来的CPU和内存以及内核连接数瓶颈压力。业务熔断机制和算法，需要自行研发业务熔断保护算法，在遭受超大攻击的时候能够对业务进行熔断和降级保护，防止所有业务全线崩溃。

这种攻击可以在短时间内发起多次DDoS攻击，并且快速停止，快速打击，这对于很多云安全防御服务商来说就是噩梦。为啥那么说呢？我们先来梳理一下云安全服务商和IDC服务商的DDoS硬件防火墙的部署模式。模式A:串联模式(In-line)串联模式部署的DDoS防御系统对于攻击流量检测和防御可以非常及时，通常可以在1秒左右检测到DDoS攻击并启用防御，最快的可以做到毫秒级别。

旁路部署模式需要由DDoS清洗设备和DDoS检测设备组成，通常90%的云安全服务商和IDC机房是采用旁路部署模式，这种部署需要DDoS检测设备检测到DDoS攻击后才可以将被攻击IP地址的路由牵引到DDoS清洗设备上。