8月の3日間：DDoS攻撃が私たちのネットワークで露呈したもの

← すべてのブログ記事 • ノウハウ • 9分で読める RSS 8月の3日間：DDoS攻撃が私たちのネットワークで露呈したもの Raphael Knecht 著 公開日：2026年9月21日 共有 2026年8月11日の夕方、当社の顧客の1社が、当社のインフラストラクチャに向けられた史上最大規模の攻撃の標的となりました。当社はその顧客のインターネット接続を提供しているため、その影響は当社にも直接及び、数時間後には攻撃者は当社のサービス自体にも矛先を向けました。このインシデントに関する技術的なポストモーテムはPDFで既に公開しています。この記事では、この3日間で実際に何が起こったのか、なぜこれほど大規模な攻撃の処理に時間がかかったのか、そしてそれ以降、当社のインフラストラクチャで何が変更されたのかを、より深く掘り下げて説明します。 当社の能力を超えた攻撃 規模を把握するために例えると、当社のネットワークと影響を受けた顧客全体で、すべてのリンクを合わせたピークトラフィック量は500〜600 Gbit/sと推定されます。当社のアップストリームプロバイダー2社は、そのうち260 Gbit/sを直接確認しました。これは、当社のネットワーク内部の防御がどれほど優れていても、当社のアップリンク自体の容量を数倍上回る量です。 インシデントの経過中、異なるサービスが異なる時間に影響を受けました。Deploio上のすべてのアプリケーション、当社のウェブサイト、Cockpit、そして当社のチケットシステムです。「異なる時間」という言葉がここで重要です。これは単一で連続した42時間の停止ではなく、その間に通常の運用を挟みながら、一連の波状攻撃でした。火曜日の夕方19時15分頃から木曜日の12時51分頃まで、これらの波は繰り返し発生し、その都度ターゲットと強度を変えてきました。 この間、一度も疑問視されなかったことがあります。それは、お客様のデータの安全性です。不正アクセスやシステムの侵害はありませんでした。これは侵入ではなく、オーバーロード攻撃でした。 外部テレメトリによる確認 NokiaのDeepfield脅威研究チームからの独立したテレメトリデータは、当社のイベント分析を裏付けています。彼らのセンサーは、攻撃者が使用したボットネットのコマンド＆コントロール（C2）サーバーにボットとして登録されているため、ターゲットに到達したトラフィックだけでなく、実際のアタックコマンドを記録することができます。そのデータによると、CECbotとKatanaの2つのボットネットファミリーが関与しており、当社が確認したシーケンスを裏付けています。攻撃はまず直接顧客を標的とし、Nine自身のインフラストラクチャには約3時間後に拡大しました。これは、当社がその顧客のインターネット接続を提供しているために攻撃されたと考えるのが自然であり、当社が本来の標的であったとは考えにくい状況です。 さらに、特筆すべき詳細も明らかになりました。当社の顧客は、当社ともう1社のプロバイダーの2つの異なるプロバイダーを通じてアドレスブロックをアナウンスしています。そのため、当社のネットワークだけを見てこの攻撃をフィルタリングまたは特定しようとした場合、全体像の半分しか見えません。Nokiaのデータは特定の攻撃者を特定していませんが、当社も同様です。 このような攻撃が実際にどのように機能するか 攻撃者はUDPアンプリフィケーションと呼ばれる手法を使用しました。簡単に言うと、インターネット上の開いているサービスに小さなリクエストを送信しますが、送信元アドレスとして自分自身のアドレスを使用するのではなく、被害者のアドレスを偽装します。元のリクエストよりもはるかに大きい応答は、攻撃者ではなくターゲットに直接到達します。攻撃者自身の帯域幅のごく一部が、世界中の数万のソースに分散された大規模な攻撃ボリュームに変わります。詳細なメカニズムについては、CISAが「UDP-Based Amplification Attacks」でこの手法を網羅的にカバーしています。 以下のすべてにおいて重要な点：一度自分のインターネットアップリンクがいっぱいになると、自分のネットワーク内部でのフィルタリングはもはや役に立ちません。フィルタリングしたいパケットは、正規のトラフィックと同じラインを使用しようとしているものと一緒に、フィルターに到達する前に回線を詰まらせてしまいます。その時点から、緩和策は、そもそもあなたにトラフィックを運んでくるプロバイダーのさらに外部で行う必要があります。 そのためのツールはブラックホーリングです。当社はアップストリームプロバイダーに対し、特定の宛先アドレスへのすべてのトラフィックの配信を停止し、代わりにドロップするように依頼します。これにより、攻撃とは無関係のネットワーク全体とすべての顧客が確実に保護されます。その代償として、影響を受けたアドレスは、その間、正規の訪問者を含むすべての人にとって意図的に到達不能になります。このインシデント中、多くの場合、アプリケーションがダウンしていた実際の理由はこれでした。何かが壊れていたからではなく、他のすべてを安定させるためにそのアドレスを犠牲にしたからです。 さらに困難だったのは、攻撃者が撤退しなかったことです。当社のウェブサイトを新しいIPアドレスに移動すると、その新しいアドレスは数分以内に再び攻撃を受けました。そして、それは単なる生のボリュームの問題ではありませんでした。リクエストの絶対数が、帯域幅に関係なく、個々のサービスを過負荷にするのに十分でした。これはブラックホーリングとは異なるツールを必要とし、正規のトラフィックと悪意のあるトラフィックを無差別にブロックするのではなく、区別できるものでした。 可用性への復帰方法 ここで、最終的にインシデントを終了させた対策が登場します。ブラックホーリングだけでは、リクエストボリュームだけで当社を標的とする攻撃者に対抗できないことが明らかになったため、インシデントの1日目に、露出しているアプリケーションを、DDoS保護機能を内蔵した欧州のCDNであるbunny.netの背後に移動させ始め、翌日までに移行を完了しました。当社の顧客も同時に追加の保護対策を評価し、展開しました。それ以来、攻撃トラフィックは保護プロバイダーで終端され、正規のリクエストは引き続き当社に到達します。 この3日間で具体的に役立ったこと：当社は独自のネットワークを運用しているため、攻撃が進行中であってもルーティング変更を直接行うことができ、サードパーティの基盤となるネットワークインフラストラクチャの変更を待つことなく、追加の保護対策を調整できました。これが、これほど大規模な攻撃が数日間にわたる完全な停止にならなかった理由の一部です。 発見された3つのギャップ このインシデント中に3つの具体的なギャップを発見しました。それらを隠蔽するのではなく、率直に共有したいと思います。 第一に、当社の自動攻撃検出は、当社の所有アドレスのみを対象としていました。当社が顧客の代わりにインターネット上でアナウンスするネットワークであっても、顧客に属するものは自動化の対象外でした。最初の波はまさにそのようなネットワークを直撃したため、それを封じ込めるのに約90分間の手動緩和が必要でした。このギャップは同夜に解消しました。 第二に、当社のブラックホールシグナルが、トラフィックが通過するすべてのパスで実際に有効になるかどうかを体系的に検証したことがありませんでした。このシグナルは、既に事前にブラックホーリングが設定されているピア、またはインターネットエクスチェンジのルートサーバーを経由して当社に到達するトラフィックにのみ適用されます。接続しているインターネットエクスチェンジでは、直接のピアとのそのような合意はないため、ブラックホーリングはルートサーバー経由で送信されるトラフィックにのみ適用され、直接交換されるトラフィックには適用されません。さらに、特定のプロバイダーに対してのみ特定のネットワークをブロックする機能がまだなかったため、攻撃が進行中の満負荷の中でその機能を作成する必要がありました。それは機能しましたが、緊急事態の最中にツールを作成することは、既に準備ができている場合よりも常に遅く、リスクが高くなります。 第三に、そしてこれは多くの顧客にとって最も不快な結果でした。当社のウェブサイトは、お客様のアプリケーションと同じDeploioプラットフォームで稼働しています。攻撃が当社のウェブサイトを標的としたとき、同じプラットフォーム上の無関係なアプリケーションも自動的に影響を受けました。さらに、Cockpitとチケットシステムも後に直接攻撃されたため、一部の顧客は、最も必要としているときに、アプリケーション、その管理機能、および当社に連絡する手段の一部を同時に一時的に失いました。 現在何が違うか これら3つのギャップは、すべて解消されたか、または積極的に取り組んでいます。当社がアナウンスするすべての顧客ネットワークは、現在自動的に...