En

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

作者:熊喵君公布时间:2014-10-16阅读次数:55439评论:6

分享

前言:宙斯盾防护系统

通过先前的文章<<宙斯盾系统构建之路—系统介绍>><<宙斯盾—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
攻防对抗,势必是一个艰苦卓绝的旅程,我们,仍在路上。


评论留言

提交评论 您输入的漏洞名称有误,请重新输入