论持久战——带你走进腾讯DDoS防护体系

【前言：宙斯盾防护系统】

通过先前的文章<<宙斯盾系统构建之路—系统介绍>>，<<宙斯盾—DDoS大眼检测系统简介>>，大家或许已经了解到，针对如网络中海啸般存在的DDoS攻击，腾讯有大眼这个攻击发现预警系统，那么细心的读者就会发问了：有检测，没有防护怎么行呢？是的，检侧是DDoS对抗的基础，但防护是DDoS对抗中更为重要的一环。本文就要带你走进腾讯的DDoS防护世界。

【第一章：那年我们一起搞过的运维】

在公司成立初期，业务还处于发展期，那时网络、机房还比较集中，机房也是租运营商的，机器数量也比较少，出了DDoS事件影响到业务正常服务了，咋办呢？在那样一个年代下，最有效的工具莫过于iptables了，作为一名负责任的工程师，小宙要负责去处理这个case，于是就有了下面的方案；

图1：DDoS防护体系V1.1版

iptables的局限性不必多说，而且风险性比较大，一不留神把正常用户拉黑了，业务一投诉，小宙又要被老大批了。

从此小宙就和iptables结上了缘分。初期他们还是很幸福的，后来又过了一年，公司要横向和纵向拓展业务了，机器、机房也多了起来，什么深圳XXX2楼、上海XXX3楼、天津XXX4楼，自建机房数量如雨后春笋般崛起，单靠iptables，估计也是不行了。咱们是否有一些成熟、可靠的方案可借鉴呢？

【第二章：DDoS防护，你也可以很专业】

这个时候，小宙和他们团队的兄弟们就思考了：公司自建机房越来越多了，安全中心需要覆盖保护的业务也越来越多了，我们是否需要对机房所有入流量做分光镜像，以及时发现DDoS攻击呢？是否可以在IDC的入口进行引流及防护呢？再申请购买一批专业的抗DDoS设备进行部署？大家一拍即合，采用netflow/或者旁路IDS方式进行监控，目标为发现DDOS事件，确认攻击类型及攻击规模后，转流量清洗设备进行流量清洗；

这样，一个包含了检测、防护的DDoS防护架构就完成了，这个架构出现后，小宙每日的DDoS应急流程似乎变得简单了；

图2：DDoS防护体系1.2版

有了检测的DDoS报警、专业的清洗设备，DDoS应急似乎变得简单了，但是此时貌似黑客们的手法也似乎在变化，大家看下面的图，这哥们估计是开了crontab吧，打打停停，还让人消停会不？此时，公司的业务也继续在扩展，各类DDoS事件频繁发生，尤其对游戏业务，防护不及时可能就会导致玩家大规模掉线。

图3：无法让人消停的DDoS

综上，新一轮问题又出现了，汇总有两个，一、该套通知机制防护延迟较大、流程走完攻击可能都已经停止了，影响无法估计；二、需要人力24小时进行值守，虽然初期小宙同学曾通宵处理了七次DDoS事件，因此在部门中赢的了”一夜七次郎”的美名，但是伤身伤神啊；有没有再进一步的优化方案呢？

【第三章：自动化来了，小宙终于可以做个好梦了】

小宙和他的战友们又思考了，为了将DDoS应急同事从繁忙人工应急中解放出来，我们做一套自动化逻辑？目前这套DDoS自动化防护系统其实就是一个包含了智能策略配置、引流命令下发的管理中心，此系统一出，再也不需要应急同学每天辛苦的值守在电脑边了，于是现有的架构就成熟多了；

图4：DDoS防护体系V1.3版(终版)

话说到这里，就形成了目前腾讯安全中心处理DDoS日常攻击的一整套架构，包含了自动化防护的配置、引流，又包含了自动化防护效果的自动检验，是不是突然感觉很轻松？好吧，从目前的情况看，DDoS的对抗博弈是无止境的，小宙又遇到麻烦了：

【第四章：大流量攻击，安全同事的梦魇？】

某天早上11点，小宙在公司正等着开中午饭，突然桌面右下角TIPS弹起，与此同时电话铃声响起，“喂，你好，深圳XXX机房出现了大流量DDOS攻击，目前攻击流量达到40个G，请处理下”，“40个G?XXX防护容量不够啊，和业务沟通下，通知运营商暂时将业务IP封停吧”，“。。。。。”

上述场景正是近年来出现较为普遍的大流量攻击场景，小宙也处理过很多次了。大家或许对Spamhaus的那次300G超大流量DDoS攻击心有余悸吧，在攻击流量超过网络链路承载能力的情况下，在普通IDC级别的防护就会失效。好在2011年开始，安全中心就联合了公司的兄弟部门、国内的几大运营商，在国内的重点城市枢纽，逐步建设城域网级别的大规模清洗中心。现在咱们这套系统在面对大流量攻击时也可以从容应对了。

上面说的都是腾讯安全中心在防护DDoS中的一些架构演变过程了，下面小宙也来和大家聊聊DDoS攻防博弈中的一些心得，希望能借此抛砖引玉：

【防护对抗的思路】

1、        去伪存真，识别真假源

这里包含了两层意思，第一层意思是在网络层，对不符合TCP/IP协议栈规范的、或者不符合业务通信协议规范的报文做丢弃处理，比如说带负载的纯SYN包；第二层意思，是通过反向探测技术，利用协议栈行为来进行合法源识别，一般来说，只有合法源才能通过我们的挑战认证，而非法源则无法通过；

2、简单即有效

公司有几款基于TCP协议的游戏业务，经常遭受DDoS攻击，攻击流量偏大时清洗设备的性能可能会成为瓶颈。小宙同学与业务咨询后，确认游戏不存在非TCP协议的通信行为后，直接在外网核心上配置了ACL（访问控制列表）。非TCP类的攻击，在经过核心交换机时就会被丢弃，极大的降低了非TCP类攻击的安全风险；

3、魔高一尺，道高一丈

      
在与某UDP业务的疯狂DDoSer的激烈斗争中，攻击者为了突破我们的安全防线，尝试了一箩筐的攻击工具，通过小宙团队同事们的努力，进行了N轮的安全策略迭代，最终威胁都被我们一一化解。攻防就是一个博弈的过程，你有矛，我有盾，你升级，我也跟着升，看谁速度快；

4、杀手锏，我的秘密你不懂

此时的对抗已经进入白热化阶段了，在这种场景下，攻击已经没有明显的特征，连人也无法分辨是否属于正常数据包，通用的防护逻辑基本已经失效。。此时，小宙不得不放出杀手锏----与业务部门合作，把每个正常的业务包都打上水印标签，这样，咱识别起来也不费力， 又让黑客们白忙一场了。

5、丢车保帅，有损服务

某天，业务同学电话过来，”小宙同学，业务客户端疑似雪崩，大量正常请求透传后端，导致后端进程假死。。。请帮忙协助处理下”。在这种场景下，攻击与非攻击已经没有明确的界限，因为所有的数据包均正常，符合业务标准，因此在这种情况下，只能采取有损服务的思想，如自动限速；

6、回归本质，一切服务于业务

      
公司有很多不同的业务，每一种业务都有它自己的属性，只有通过与业务间的不断磨合及测试，制定出贴近业务的安全防护策略，才是我们做安全防护的最终目的；

【后记】

DDoS攻防对抗，势必是一个艰苦卓绝的旅程，我们，仍在路上。