百度回应质疑：防御1Tbps DDoS攻击流量是如何做到的？

浮尘

1Tbps流量——83个春运期间12306官网最高峰值带宽流量；足够让一座城市断网好几次……

当大流量攻击来袭，网站该如何应对？在9.18日百度云安全用一场DDoS攻防实战演练，形象、直观地告诉了我们答案。

不少来自安全圈、IT界的怀疑声音：这么大的流量，是从哪来的？目前全球最高的抗D记录也不过400多G，百度这次声称的流量是真实的吗，攻击的手段是足够“专业”的吗？……

类似的疑问还有很多。

我们就通过技术解析来阐释，百度云安全是如何做到1Tbps压制能力的？

问题一：现场演练中1Tbps攻击流量是怎么来的？

本次演练以流量攻击为主，同时混合了数十万QPS的CC攻击。整个演练过程中模拟了多种专业手段，包括流量攻击与应用层攻击，从强度上也模拟攻击流量不断攀升、波动、区域流量变动、巨大流量突袭等各种形式。让这些攻击特征混在一起，并且在短短的几分钟内呈现出来，的确不是件容易的事情。为此，百度和合作伙伴们一起，确实下了很大功夫。

为了确保攻击流量“货真价实”， 首先必须要验证合作伙伴乐视云提供的不同服务器的实际发包能力，调试控制不同时间段的发包幅度，并且汇总整体发包数量级，验证流量到达目标的比例等。为此，我们分机房、分比例在指定设备上做测试，分析10%、20%、30%等不同发送流量条件下的攻击流量形态。

起初我们想偷懒，攻防演练计划以UDP Flood流量型攻击为主（我们听说过的攻击流量最大的几次攻击都是UDP Flood类型的，例如NTP反射），混合10%的SYN Flood流量型攻击。这样做的好处是防御起来相对简单。但是，通过多次调试，我们发现乐视云网络有安全策略，禁止大量发送UDP。在不方便调整乐视网络安全策略的情况下，我们“被迫”采用全SYN Flood流量型攻击，同时混合50万QPS的CC攻击。这对整个攻防演练的防御增加了不少压力。

在正式演练的前一周里，云加速和乐视云的工程师一起熬过了很多不眠之夜，不断调试国内及海外各个机房及服务器集群的发包比例、发包强度，了解每一个机房发出的流量，与能到达演练目标的数量级的关系。最后，我们集结了国内及海外总计127个机房的586台服务器（其中144台是万兆网卡、其余的为双千兆或4千兆网卡），成功地发出了1.4T以上的攻击流量，攻击流量分别覆盖了电信、联通和海外多条线路。

云加速与乐视云的技术团队，反复尝试了数百次各种攻击手段和流量组合，并制定了精确的攻击演习方案，经过反复修改后形成了自动化的控制脚本。最终，现场演习期间的流量攻击全部通过部署在乐视云全球各个机房服务器上面的自动化控制脚本来精确的完成。小伙伴们纷纷表示，想要干『黑产』做攻击也不是那么容易的。

问题二：百度是如何构建1Tbps防御能力的ADN的？

在整个攻防演练过程中，最大的技术亮点是单IP 1Tbps的ADN（抗DDoS流量压制网络）。百度云加速是如何做到的？

事实上，针对国内网络环境的特殊情况，安全业界针对DDoS这一行业难题，也曾经有过多种尝试。最早，业界的抗DDoS解决方案是采用硬件设备来清洗流量，业内通常称为ADS（Anti DDoS System）。安全宝最早在中国提出ADC（抗DDoS中心）概念，即用户无需自己购买庞大的带宽储备和昂贵的ADS设备，而是直接租用ADC的防御能力。

众所周知，由于运营商的限制，Anycast技术目前在国内基本没有大规模商用的可能。百度云加速分布式的超级节点对于CDN效果有很大帮助，但虽然这些节点汇总在一起有巨大的带宽，从DDoS攻击清洗的角度看却没有实质意义。这是因为，只有最大节点所拥有的可用带宽才是其防御能力，因此若想清洗1Tb级别的攻击流量，除了建设巨大带宽储备的ADC节点外，也必须在大网层面有相应的手段去支撑。

同时，即使有如此强大的资源和手段，还必须要保证针对复杂混合型攻击特征的准确识别以及清洗效果，这是确保攻击清洗过程中用户实际访问体验的关键因素。

为了解决这一系列技术难题，百度云加速本次发布会上发布了ADN（Anti DDoS Network），即不但加强自身ADC建设，更重视与合作伙伴共同构建全球合作的防御体系，继续领导DDoS防御领域的发展方向。

随着攻击流量的国际化，防御也必须网络化和全球化。必须引入更多的合作伙伴来共同打造一个完整的防御系统，而不是所有事情自己解决。于是，云加速在防御体系中邀请了电信云堤和CloudFlare，并且与他们一起逐渐勾勒出了整体技术架构，也就是今天我们看到的，具备防御1Tbps DDoS攻击能力的ADN技术方案。

目前国内有三大流量途径：电信、联通和海外。网站用户通常为了让各条线路的访问速度达到最快，会对自己的网站做分线路的解析。攻击者发起攻击时也同样不会是从单点发起攻击，其发起攻击的“肉鸡”服务器也是遍布全球。如果“肉鸡”依据域名解析实施攻击，则会被三条线路分担流量。在这种情况下，我们通过电信节点来分担电信过来的攻击流量和请求；通过CloudFlare遍布全球的Anycast节点，来分担海外的攻击流量和请求。目前业内能够实现全球防御部署能力的只有百度云加速。

然而，只要攻击没有停止，防御就没有结束。

攻击者的最终目标是让服务器宕机，当他发现攻击没有持续有效时，会进一步分析线路关系，最终定位到一个关键节点上，实施关键节点逐个击破的策略。如果定位到海外，那就让CloudFlare的Anycast节点去消化这些攻击流量；如果是定位到国内，在我们没有Anycast的情况下，需要百度去建立一个远远大于普通CDN节点的“阿尔法”级别的超级抗攻击节点。然而目前城域网能够支撑的出口流量只有几百G，还不足以满足Tbps级别的压制能力。在引入了电信云堤后，这个问题也有了明确的解决思路：通过云堤提供的近源压制策略，在运营商层面使用路由黑洞技术，在各个跨网的关键点上消灭到指定目标的非电信流量。这样一来，我们就可以只建立一个“阿尔法”级ADC即可。事实上，百度也的确在上海电信建成了一个这样带宽高达数百G的“阿尔法”级ADC。

以上这些策略，让我们具备了足以支撑整个抗攻击系统具有1Tbps的清洗能力。

也许有同学会产生疑问：有攻击的时候全扔海外去啊？虽然这样的方式看起来貌似比较简单，但事实上却会大大影响国内用户访问该网站的速度和质量。同时，如果攻击流量也跟随DNS解析到海外，很有可能会造成国际出口带宽的堵塞。通过高质量的抗攻击服务为用户提供更好的安全防护服务，也就成了一句空话。

基于上述考虑，百度云加速抗攻击系统采用“替身式”防御：

网络层的攻击流量全部会在抗攻击节点上清洗掉，不让攻击流量透到源站；ADN采用两层交换机IP Hash分发机制，建立多个集群去分担流量，实现了流量的负载均衡，极大的保障了服务的高可用性及灵活的扩展性。同时，每个集群内部还有备用机组，采用IP漂移技术，针对有故障的设备，备用机会实时切换接管服务，在保障IP Hash一致性的前提下实现了高可靠性。在攻击流量检测和清洗方面，百度云加速抗攻击系统采用流量指纹模型，实现秒级告警和毫秒级清洗能力。在清洗的方式上，区别于传统的SYN-Proxy模式，百度云加速抗攻击系统建立了IP跟踪定位模型，结合IP白名单、IP线路属性等特征进行甄别，因此在防御DDoS攻击过程中，不影响正常用户的正常访问。

在应用层防御方面，百度云加速的“阿尔法”级ADC实现了高效的源站保护模型，分层清洗CC流量，保障源站服务的持续可用。在这个过程中，所有的CC攻击IP都会被一一定位成功。源站带宽是第一保护对象，确保源站可以正常服务；第二保护对象是节点自身，在攻击流量清洗过程中，会对部分CC攻击IP实施网络层的拦截，降低CC攻击占用带宽。

百度ADN产品架构



问题三：与真实攻击有区别吗？

当然有！最大的区别是真实攻击我们不知道什么时候会发生，必须有一个机制监测流量并快速做出响应，而攻防演练是知道攻击将要发生的。心里上的差别对于像云加速这样天天帮用户防御攻击的团队影响不大，但不经常遇到这种情况的用户可能就会惊慌。

另一个区别是真实攻击通常会直接打到某一个级别的流量，如果无法成功就直接跳到下一个级别，没有中间过程。而演练由于不确定防御能力的实际效果，也为了让观众看清楚流量的增长，拉长了中间过程。

写在最后

虽然现场演练的持续时间只有几分钟，但是现场震撼的效果背后，是百度云加速与合作伙伴的工程师辛苦的付出，在百度云加速一直对抗攻击技术孜孜不倦的追求和持续积累的基础上，又花了几个月的时间进行了技术提升和合作协调，并且在演练前的几天进行了密集的训练和讨论，这才保证了这场攻防演练的成功。

飘零

一开始觉得百度挺好用的，不过现在的百度太商业化了，有时候答非所问

菜鸟小羽

若冰

还是不错的哦，顶了

a136

ruguoruo

支持中国红客联盟(ihonker.org)

ayang

学习学习技术，加油！

borall

支持，看起来不错呢！

ruguoruo

感谢楼主的分享~

H.U.C-麦麦