揭秘DDos防护 - 腾讯云大禹系统

Posted 2021-04-28 高可用架构

揭秘DDos防护 - 腾讯云大禹系统

郭伟（david），西电毕业，先后就职于华为、腾讯，安全架构师。主要负责大禹系统架构工作。大禹是腾讯云自主研发部署的一套分布式DDoS系统，因2015年先后帮助艺龙、土巴兔、锤子手机进行了DDoS防护，而在行业内知名。目前也是携程、饿了么、优酷等互联网企业的安全保障。

大家好，很高兴今天有机会和大家交流。:)

以下先用PPT的形式给大家大概介绍一下大禹系统。后面在QA环节具体回答大家关心的问题。

感谢大家，已上是大禹系统的基本介绍。 : )

下面进入QA环节。

一、DDoS简介

Q1：DDoS攻击如何防范？有哪些通用解决方案，各个方案优缺点，以及如何正确的选择？

有分布式防护和集中式防护两种。

分布式防护：

优点：
超大防护带宽。
可快速扩容。
单点受影响是对于业务的影响是部分受损。

缺点：目前仅仅支持HTTP和TCP类型业务。

集中式防护：

优点：支持全协议类型。

缺点：防护带宽小。

Q2：目前的DDoS攻击方式组成占比是什么样的？

从我这里的检测情况来看，今年NTP反射和SSDP的攻击是比较主流的攻击。目前TCP和UDP的攻击占比，粗略的说基本是4：6的样子。

Q3：攻击的流量有什么特性能检测到吗？

有，比如说大量发送TCP SYN包，但无第三次握手回应；或者TCP SYN和ACK比例不对等。这些都是可以作为攻击的鉴别特征。还用到了一些机器学习、数据挖掘等技术。

Q4：一般攻击的持续时间大概多长？平均每个IP的攻击流量大概在什么范围？一般攻击的IP总个数大概范围是多少？攻击倾向非常多的肉鸡还是数量较小但是高输出带宽的机器？

攻击时间一般会10~30分钟。每个IP攻击的流量在一般小于50G。一般受攻击的总IP数在1到数十个不等。攻击者倾向于使用高输出的机器，攻击源中肉鸡占比不高。

二、大禹系统简介

Q5：大禹系统是软件平台还是硬件平台？ 这套系统是什么语言开发的？

软硬件都有。大禹的所有系统都是跑在Linux系统。系统使用C++开发。

Q6：大禹具体使用了哪些硬件设备？

比如说节点上的流量防护设备，这些是我们针对DDoS这种场景定制化的专用硬件设备。

Q7：这个系统搭建，从最初到现在，大概用了多长时间？ 系统实现最大的难点在哪里？

从1.0开始建设大禹系统到现在用了1年半的时间。 我简单说下在搭建大禹架构的时候遇到的几个问题：

1. 针对网站的场景优化防护策略。

2. 大并发场景下处理能力的优化。

3. Client到大禹和大禹到源站基本都是外网链路，网络复杂环境下的监控和调度等。

4. 平台自身的安全问题等。

Q8：大禹系统支持哪些协议类型？

HTTP协议全部支持；HTTPS协议配置证书后可以支持；其他私有协议，定制化开发后可支持。支持长连接服务。

Q9: 大禹能做 DNS 防护吗？

大禹主要针对网站类业务。如果DNS类型的攻击来攻击网站，大禹会直接丢弃这类报文。

Q10: 接入大禹收费吗？

测试免费。使用时收费，根据攻击流量大小可议价。

Q11: 大禹系统可以自定义阈值的吗？还是系统自动检测？

是自动检测。不会通过自定义阈值的形式来限制检测阀值。

三、大禹系统硬件防护能力

Q12: 40G是大禹单机抗攻击的能力上限吗？

不是，我们有部分高防节点，可抵挡100G以上攻击。

Q13: 如果单个节点攻击流量大于40G怎么办？

由于是分布式，即使单个节点被打趴，还有其他节点可到达服务器，因此不影响访问。

Q14: 是不是说攻击大于4T+ 就会出问题？

目前还有遇到过T级的攻击，如果攻击流量开始超过T级的时候，大禹会加入更多的防护节点以横向扩容防护能力。

Q15: 大禹是否更重视硬件成本投入？在智能化判断攻击源与清洗方面有成熟方案吗？

防护DDoS本身就是一种拼资源的事情。攻击流量超过机房带宽时，清洗的意义就不大了。另外，攻击源是可以伪造的。

Q16: 能否介绍下15年最大的攻击？

这次攻击最大流量达到290G左右，发生在7月21日，我们有10多个节点同时被攻击了20G+的流量。

Q17: 可否讲讲这次锤子的事情，例如攻击的带宽，持续，开始结束，攻击来源，分布，等等，怎么防御，比较想了解。

锤子本身就部分接入了大禹。被攻击的时候，增加接入了一些域名。当时攻击锤子的流量30G多，接入大禹后立刻恢复业务。接入大禹时，攻击流量同步跟到了大禹这边。攻击类型比较多，其中主要的攻击类型是NTP反射。

四、算法设计

Q18：NTP反射类型的攻击如何防御，原理是怎样的？

我们没有NTP服务。所以一般是限流居多，黑白名单配合。

Q19：攻击源是否来自同一个IP？封IP是否可行？

这样做不合适。首先攻击源可能是伪造的。另外DDoS攻击的源IP一般是数以万计，其中有一些IP既有攻击也有正常业务。直接封堵不合适。

Q20: 是否有单机请求过多检测？

有，但是主要是基于自动机识别以判断是否人肉请求的情况。单机请求过多，仅仅是会进入灰色检测策略，但不会直接判断为异常。

Q21: 业务侧的服务 是部署在某个具体机房的吧？不过这个IP不对外， DNS上配置的是 大禹系统的IP。如果知道用户服务的具体IP， 大禹系统能防御么？

如果只有一套IP，如果IP泄漏后，攻击者是可以绕过大禹直接攻击服务器。建议准备两套IP，一套对外，一套不对外但接入大禹。当对外的IP被攻击后，可以快速切换到大禹上来。

Q22: 那如果原ip流量打满IDC其实依然是无法通过切IP解决的，这种情况下还有别的办法吗？ 是不是只能求上级运营商链路丢弃原IP的所有包？

没错，这种情况需要在IDC上联的ISP交换机上进行流量压制，也就是拉黑洞。必须要保证IDC正常业务是可以访问的。

Q23: 通过域名发送到后端大禹是简单的根据域名解析到地区去划分吗？还是通过其他方式？

解析是腾讯GSLB来做。是通过域名解析到地区，但是解析IP的时候会考虑到当地具体线路用户的访问速度和节点负载等信息。

Q24: 只能等缓存失效后，GSLB才能导到下一个接入点么？

GSLB可以强制刷新LDNS的缓存，按照我现网的对抗经验看，TTL设置为2分钟是OK的。

Q25: 大禹是用什么技术来处理高并发请求的？

这部分技术应该是比较透明了，相信大家接触了比较多。简单描述一些大禹做过的实践：OSPF分流、服务降级、过载保护、修改内核部分数据流向等。

Q26: 有蜜罐系统吗？如何设计？

有一些蜜罐逻辑，但没有蜜罐系统。比如返回一些报文诱惑攻击者，以为攻击成功等。

Q27: 大禹系统核心技术有哪些？是否有黑名单判定？

黑名单只是处罚的一种手段，其他的方式如恶意协议丢包、限流等都是我这边对抗常用的手段。

Q28: 是通过Redis实现黑白名单的吗？

大禹现在的黑白名单并不是很大，主要自身防护策略使用，目前还是通过本机内存直接读取。如果后续大禹给客户开放这个功能时，我们会考虑使用Redis或者ckv之类的工具。

Q29: 用到流量整形技术了吗？

是备选，但一般不用。

Q30:如果我们想发生攻击时才cname过去，有什么办法解决用户侧的dns缓存时间？

DNS服务器之间可以刷新缓存。这个是标准的DNS协议

Q31: 使用某云时，两个网段传输几十TB数据，被当成ddos攻击，如何能避免误判?

这种情况，不能通过流量徒增来进行判断。而且像这种情况，长TCP一直进行业务传输，正常特征还是比较明显的。建议使用白名单。

五、大禹和其他产品、技术的区别

Q32: 大禹跟绿盟的黑洞有什么不同？

严格来说，大禹和黑洞不算是一类产品。大禹的防护是同时能解决流量清洗和超大流量攻击时调度以减小业务受损的场景。大禹的防护总带宽是4T。黑洞只能清洗流量，但是还需要配置机房的带宽规模得知防护能力。

Q33: 大禹系统跟云盾系统有什么区别？

云盾是机房防火墙，大禹是针对网站的DDoS防护体系。

Q34: 大禹是不是类似宙斯盾系统？

不是。 宙斯盾系统类似黑洞，是一种防火墙，只有配合机房的带宽才能体现其防护能力。大禹系统是DDoS分布式防护体系。

Q35: 大禹就是CDN节点上具备了清洗能力，我能这样理解不？或者更多区别？

这是分离两个业务，但是大禹使用的是独立的腾讯节点，我们现在在推进大禹系统和CDN的融合，相信不久的将来CDN具备大禹的防护能力。