9 月 15 日（周二）下午开始，华北区的云引擎服务受到 DDoS 攻击，导致部分应用无法访问（已经绑定独立 IP 或加速域名的应用因其入口独立则不受影响）。晚间 10 点半之后，攻击者转而攻击一部分存储 API 的共享域名，导致部分应用的 API 访问也出现问题。

对本轮攻击，这里就一些细节和疑问跟大家详细汇报如下：

攻击的时间线如何，流量有多大？

• 针对云引擎外网 IP 的攻击最早发生在 15 日下午 2 点半左右，因为我们的外网 IP 数量较多，且都附带一定程度的抗 D 能力，所以对终端访问影响不大。

• 截至下午 4 点 40 左右，云引擎服务的外网入口被轮番攻击相继不可用，我们补充新 IP 也于事无补，所以开始接入机房服务商的高防服务；

• 下午 5 点 20 分，因为攻击流量增长太快（超过 90Gbps），达到机房服务商的高防瓶颈，我们开始寻找外部服务商。

• 下午 6 点，开始接入外部服务商，并将高防带宽提升到 300Gbps，这一操作在下午 7 点左右基本完成。

• 晚间 11 点左右，存储服务的部分外网入口受到攻击，我们立即进行了切换。

• 所有攻击一直持续到 16 日凌晨 3 点才暂时告一段落，期间流量高峰超过 300Gbps。

攻击现在停止了吗？

从统计数据来看，今天（9 月 16 日）攻击还在发生，上午 11 点我们看到攻击流量的峰值达到了 400Gbps，截止到本报告写完的时候，攻击还在持续。

攻击的目标是单个应用，还是 LeanCloud 平台自身？

对于云引擎域名的攻击，影响到了绝大部分共享入口；而对存储服务的攻击，则只影响了小部分的入口。从我们的调查来看，存储服务被攻击的 IP 主要对应少量的共享 API 域名，而云引擎服务的共享域名区分度相比 API 来说要小一点，所以云引擎受影响的入口比例要大于存储服务。从这里推断，攻击目标是单个应用而不是平台自身的可能性更大一点。

其实区分攻击目标是平台还是应用并没有太大意义，因为溯源本身是一件非常困难的事，这也导致互联网上这种网络攻击从未断绝。根据我们内部的记录来看，从 2016 年至今，我们每年都会遭受 3-4 次攻击，平均下来基本上每个季度都会来一次。互联网是一个充满理想和创意的地方，同时也有很多灰色地带，活跃着一些不可说的商业模式，这是我们在这个环境中必须面对的现实。

对此次攻击，LeanCloud 做了哪些紧急防范措施？

• 针对云引擎服务的攻击发生之后，我们就开始接入高防服务，以保证对外服务不受影响，同时也建议并协助开发者启用「加速域名」来提高可用性。从今天上午的统计结果来看，昨天已经有数百个应用切换到了「加速域名」上。

• 在切换到外部高防的过程中，因为高防入口会检查域名备案的合法性，所以走 http 协议的云引擎域名会因为备案未在高防服务商那里完成接入而被拒绝。我们紧急联系供应商讨论解决方案，后来争取到一个容量受限的白名单配额，将部分云引擎的访问域名加入其中，剩下的大部分域名则只能通过切换到 https 协议或者转为加速域名来提供对外服务。

• 15 日夜间 11 点，收到存储服务的部分入口被攻击的报警之后，我们立即启动了高防切换的操作，使用较短的时间完成了访问路线的调整。但是同样因为高防服务对 http 协议处理的问题，我们也及时对部分域名进行了人工调整，并且帮助开发者配置独立 IP。从统计结果来看，目前已经有数十个应用为存储服务配置好了独立 IP。

• 夜间有用户反馈云引擎内部通过自定义域名访问其他云引擎或存储 API 存在一定概率失败的现象，我们判断可能是高防服务清洗策略导致的访问受限，所以紧急联系供应商的工程师进行排查处理，最终在调整了部分清洗参数之后，这个问题得到一定程度的缓解。同时，我们也准备好了另一套修改内部 DNS 路由的方案，在 16 日上午为部分用户进行了配置，最大程度优化了云引擎实例间的内部访问线路。

在攻击发生之后，我们收到了很多用户焦急的电话以及工单，虽然一直全力以赴地解决这些问题，但可能还有不少提升空间，我们会继续努力。

后续还有哪些措施来防范这种攻击的发生？

LeanCloud 一直在网络攻击的「陪伴」下发展壮大，在这种「魔高一尺道高一丈」的较量中，我们也在不断寻找更好的对策确保服务的稳定可靠：

• 2016 年，为了降低访问入口唯一的风险，我们按照服务对外部访问入口进行了拆分，在部分服务受到攻击的时候，可以避免其他服务受到牵连。
• 在上一步的基础上，我们在同一个服务内部，对应用进行了分群处理，以便于进一步缩小攻击范围，避免大面积的应用受到影响。所以大家会看到不同应用访问我们服务时，SDK 内部使用的域名是不一样的。
• 2019 年 6 月，受 leancloud.cn 和 lncld.net 域名被注册商禁用问题的影响，我们推出了为数据存储、文件、云引擎服务绑定自定义域名的功能，希望应用通过自己的域名来访问我们的服务，这既符合监管层的要求，也可以保证应用间的相互隔离和降低被攻击的风险。
• 2019 年 11 月，因为云引擎服务的外网 IP 饱受攻击，我们增加了为云引擎域名配置独立 IP 的功能。不同于以往的 CNAME 域名绑定，独立 IP 的方式使用了完全不同的流量入口，可以更好保证服务稳定。这一改动同样适用于存储服务的自定义域名。
• 2020 年 8 月，我们为云引擎推出了「加速域名」，一方面可以加快终端用户的网络访问速度，另一方面也可以显著增强抗攻击的能力。

现在，我们建议开发者都尽快为自己的云引擎实例配置加速域名，为存储服务配置独立 IP 并绑定独立域名。

加速域名/独立 IP 等方案，收费方案是什么样子的？

• 对于云引擎加速域名，目前还在免费推广阶段，将来会根据实际的流量进行收费，价格与文件服务的流量计费方案基本相当，大家可以放心使用。

• 对于独立 IP，在分配的当月是不收费的，从第二个月开始我们会按照「100 元/月/IP」进行扣费，并且这个独立 IP 可以供同一账户下的多个应用共享使用（但 API 与云引擎之间不能共用），所以总体上来看是非常便宜的。

• 绑定自定义域名时我们还可以随带提供 SSL 证书并支持自动定期更新，这一功能是免费的。

独立 IP 能默认提供抗攻击的能力吗？

独立 IP 只能保证不受别人牵连，如果就是自己被攻击的话，它并不能提供抗攻击的能力；不过独立 IP 同时也提供了选择上的灵活性，开发者可以自主接入第三方的防 D 服务。

如果独立 IP 就是攻击目标，此时如何抗攻击，成本如何承担，这是很多开发者有顾虑的地方，也是大家宁愿被影响也不愿独立出来的现实考量点。对于这个问题，我们内部有一些讨论，争取尽快推出一个比较平衡的方案，请大家对此保持关注。

如果还有其他疑问，欢迎通过邮件或者工单联系我们。感谢您对 LeanCloud 的支持与信任，希望我们能成为您发展中的长期伙伴。

Loading comments ...