ポストモーテム: AMS-01、11分、2020年10月14日

概要

2020年10月14日の02:41から02:52(UTC)の間、AMS-01のすべてのインスタンスが到達不能になりました。単一の顧客アドレスを狙った大量トラフィック攻撃は340 Gbit/sに達し、サイトのアップリンクを飽和させました。私たちは、上流にターゲットアドレスへのすべてのトラフィックを破棄するよう依頼することでこれを解決し、サイトは復旧しましたが、その顧客はさらに50分間オフラインのままでした。データの損失はなく、インスタンスへの被害もありませんでした。当時、サイトにはスクラビング能力がなく、それは事故ではなく購入判断によるものでした。

タイムライン

すべての時刻はUTC、2020年10月14日。

根本原因

直接の原因は吸収できない攻撃でした。実際の原因は、この規模の攻撃が日常的であり、200ギガビットのアップリンクとフィルタリングが一切ない都市でホスティングを販売し、上流の破棄契約を計画として扱ったことです。

それは不運ではありません。2019年にハードウェアに資金を使うことを選択した決定であり、それは間違っていました。

2つの二次的な障害が状況を悪化させました。フローコレクションは、実際のイベント中に有用な詳細を提供しないレートでサンプリングされていたため、最初の4分間はインターフェースカウンタを読むのに費やされました。また、破棄は手動であり、人間が起きていて、認証され、自信を持っている必要がありました。これは午前3時には3つの要件が多すぎます。

これが顧客に与えたコスト

率直に言うと：私たちは彼らのサービスを停止することで自分の問題を解決しました。破棄ルートは、他の全員が影響を受けないようにするために1人の顧客が到達不能になるという決定です。それは手持ちのツールでは正しい判断でしたが、それでもそれは私たちではなく彼らの停止であり、彼らは私たちからそのような約束をする製品を購入していませんでした。

彼らは留まりました。私たちは10月の料金を請求しませんでした。

私たちが変更したこと

1. エッジでの常時スクラビングを3週間以内に購入し、1.2 Tbit/sの容量から開始。フィルタリングはパス内に常時配置されるため、検出遅延はなく、02:47に誰かが押すボタンもありません。これは現在、すべてのサイトで標準であり、最大のサイトでは最大12 Tbit/sです。
2. AMS-01のアップリンクを引き上げ、まず200 Gbit/sの追加容量に、その後現在の400 Gbit/sに。
3. サンプリングされていないフローテレメトリをすべてのサイトエッジに追加し、運用目的で7日間保持。これは当社のポートのトラフィックメタデータであり、インスタンストラフィックやコンテンツではありません。
4. 破棄ルートを自動化し、文書化されたしきい値、公開されたポリシー、影響を受ける顧客へのメールを39分ではなく60秒以内に送信。
5. 攻撃を[ステータスページ](/ja/status)で公開し、誰かが気づいたかどうかに関係なく、サイズと期間を含めて。

変更しなかったこととその理由

フィルタリングの課金は開始しませんでした。 ベースのスクラビングはすべてのサイトのすべてのプランに含まれており、購入した日からそうです。攻撃は被害者が求めたサービスではありません。カスタムルールによるレイヤー7フィルタリングはアドオンとして存在します。それは当社側の人間が必要であり、大量フラッドとは異なるものです。

破棄ルートは削除しませんでした。 12テラビット/秒は数字であり、無限大ではありません。今後、そのような単純なツールが必要になることはないと装うのは不誠実です。変更したのは、それが唯一のステップではなく、文書化された最後の手段になったことです。

顧客あたりのトラフィック上限は設定しませんでした。 すべての顧客をアップリンクの安全な割合にレート制限することは、これを防ぎ、同時に正当なスパイクも抑制します。フィルタリングはエッジで、攻撃に対して行うべきであり、顧客に対してではありません。

顧客を別の製品に移行しませんでした。 彼らは自分たちが購入したものを、自分たちに適したプランで実行しており、誰かがボットネットを彼らに向けたのは彼らのせいではありません。