摘要
2020年10月14日，UTC时间02:41至02:52，AMS-01的每个实例均无法访问。针对单个客户地址的流量型攻击峰值达到340 Gbit/s，使该站点的上行链路饱和。我们通过请求上游丢弃至目标地址的所有流量解决了问题，这恢复了站点，但该单个客户又离线了五十分钟。没有数据丢失，也没有实例受损。该站点当时没有清洗能力，这是一个采购决策而非意外。
时间线
所有时间均为UTC，2020年10月14日。
| 时间 | 事件 |
|---|---|
| 02:41:04 | 指向单个客户地址的流量在不到二十秒内从约200 Mbit/s升至90 Gbit/s。 |
| 02:41:30 | 两个站点上行链路均已饱和。站点所有前缀丢包彻底，而不仅限于目标。 |
| 02:42 | 自动化告警因外部三个探测器的可达性而触发。 |
| 02:44 | 值班工程师上线。攻击在端口图表上可见，其他任何地方都不见，因为我们的流量采集采样率跟不上。 |
| 02:46 | 测量峰值达到340 Gbit/s。组成为反射UDP，主要来自数万个源的DNS和NTP。 |
| 02:47 | 决定请求上游丢弃所有发往目标地址的流量。这是当时我们唯一可用的工具。 |
| 02:49 | 丢弃规则在第一个上游传播。 |
| 02:51 | 第二个上游应用该规则。上行链路利用率降至容量以下。 |
| 02:52:10 | 站点完全可达。客户可见的总中断时长为十一分钟六秒。 |
| 03:20 | 已联系受影响的客户并提供新地址。 |
| 03:42 | 客户迁移至新地址；其服务恢复正常。 |
根本原因
直接原因是我们无法吸收的攻击。实际原因是我们在此类攻击频繁的城市销售主机，仅有200 Gbit上行链路且毫无过滤，还将上游丢弃协议当作计划。
这不是运气不好。这是2019年决定将资金用于硬件的决策，而且决定是错误的。
两个次要问题使情况更糟。我们的流量采集采样率导致在真实事件中无有效细节，因此前四分钟花费在阅读接口计数器上。而且丢弃操作是手动的，需要有人清醒、已认证且有信心，这在凌晨三点是三个过多要求。
这对客户造成的影响
直白地说：我们通过关掉客户服务解决了自己的问题。丢弃路由是决定让单个客户不可达，以便其他人可达。在我们拥有的工具下这是正确的举措，但这仍然是客户的而非我们自身的中断，他们也没有购买任何承诺避免此事的产品。
他们留了下来。我们没有收取他们十月份的费用。
我们做出的改变
- 边缘始终在线清洗，在三周内购买，起于1.2 Tbit/s容量。过滤永久置于路径中，因此没有检测延迟，也无需任何人在02:47按下按钮。这现在是所有站点的标准，最大站点可达12 Tbit/s。
- AMS-01上行链路提升，首先增加200 Gbit/s容量，后来提升至该站点今天运营的400 Gbit/s。
- 每个站点边缘均部署未采样的流量遥测，为运维目的保留七天。这是我们自己端口的流量元数据；不是实例流量，也不是任何内容。
- 丢弃路由变成自动化，具备明确的阈值、公布的政策，并在六十秒内向受影响客户发送邮件，而非三十九分钟。
- 攻击在[状态页](/zh/status)上公布，包含规模和持续时长，无论是否有人注意到。
我们未改变的内容及原因
我们没有对过滤额外收费。 基础清洗包含在每个站点所有计划中，且自从我们购买之日起一直如此。攻击不是受害者要求的服务。具有自定义规则的7层过滤作为附加服务存在，因为它需要我们这边的人来维护，这与流量型洪水是不同的。
我们没有移除丢弃路由。 每秒十二太比特是一个数字，而非无穷大，假装我们不会再次需要这个粗暴工具是不诚实的。改变的是，它现在记录为最后手段，而非唯一步骤。
我们没有强加每客户流量上限。 将每个客户限速至上行链路的安全比例虽能防止此事，但同样也会限制所有合法流量高峰。过滤应针对攻击位于边缘，而非针对客户。
我们没有将客户迁移至不同产品。 他们正按其支付的方案运行着他们购买的东西，且这不是他们的错——有人向您发了僵尸网络攻击。