Wikimedia Foundation（ウィキメディア財団）

Wikimediaは大規模DDoS攻撃の発生後、Cloudflare Magic Transitによってオンラインに復帰

ウィキメディア財団は、WikipediaとWikimedia Commons、Wikiquote、Wiktionaryといった幅広い無料の知識共有プロジェクトを運営しているNPOです。財団は無料の知識に取り組んでおり、財団のビジョンはすべての知識を集め、すべての人が無料で共有できる世界の構築です。

ボランティアによるグローバルコミュニティがこうしたプロジェクトを運営する一方で、財団のスタッフはプロジェクトの技術的なバックボーンを維持し、無料の知識源をサポートするためのポリシーと保護を代弁し、多言語、他文化、異なる大陸の知識を集約する取り組みを行うボランティアを支えています。

課題：世界中でWikimediaのサイトをオフラインにした大規模なDDoS 攻撃を阻止

「Wikimediaは無料の知識のエコシステムに不可欠なインフラストラクチャになりたいと考えています」とウィキメディア財団のCTO を務めるGrant Ingersoll氏は説明します。「我々は、すべての人がWikimediaのコンテンツにアクセスできて、知識を生かし、生活の中に取り入れ、人生を豊かにしていけるよう努め、さらに、より良いインターネットの構築を手伝いたいと考えています。」

この目標を達成するために、Wikimediaのサイトは信頼性が高くでセキュア、そして高速である必要があるのです。サイトリライアビリティディレクターのFaidon Liambotis氏は「コンテンツの作成と編集をするボランティアは、サイトがアクセスできなかったり、使いにくかったり、またはボットに書き換えられたりしたら、仕事ができなくなります。Webサイトがすべて順調に機能しているという安心感を持って、スタッフに夜ぐっすりと寝てもらいたいと願っています。」と話します。

セキュリティの面では、Wikimediaはここ数年、大規模なDDoS攻撃を受けてきませんでした。しかし、その歴史も2019年9月7日に終わりを告げます。大規模な攻撃によってサイトがアクセス不能になってしまったのです。ヨーロッパから始まり、アフリカ、中東、そして米国やアジアなど世界各地に広まりました。「攻撃のピーク時は、数百ギガバイト/秒でした」とChris Danis氏（サイトリライアビリティエンジニア）は振り返ります。

サイトが停止した最初の数時間以内に、Wikimediaのチームは攻撃を阻止し、サイトを復旧させることができませんでした。「GeoDNSベースの負荷分散の再マッピングを含めたいくつかの軽減策を行い、トラフィックがピアリングリンク経由で入る時、トラフィックエンジニアリング対策も試してみました。」とDanis氏は言います。

解決方法：WikimediaはMagic Transitを使ってすぐにオンラインに復帰

CloudflareはWikimediaに連絡をして、ネットワークインフラストラクチャを保護するソリューションのMagic Transitを使うことを提案しました。Liambotis氏は、金曜日の夕方だったにも関わらず、攻撃時にすぐにCloudflareから連絡が入ったと回想します。「Cloudflareのチームは、何が起きているのかを理解した上で連絡をくれました。」

「Cloudflareのセキュリティオペレーションセンターと脅威インテリジェンスチームは、我々が何か質問する前に、すでに攻撃シグネチャ（ポート65535からのTCP ACK）を把握していたと思います」と付け加えます。「Cloudflareは、我々の測定能力を上回る攻撃の測定値を示しました。Magic Transitが稼働すると、Cloudflareは（さまざまなポイントと単位で）攻撃を測定し、最大300Gbpsの帯域幅、105MPPSのTCP ACKトラフィック、340MPPSのUDPフラッドと測定値を出しました。」

Liambotis氏は、Magic Transitを使用し、ルーティングポリシーに必要な変更を加えることで攻撃を停止させることができたと報告しています。「しかし、これは簡略化した報告です。攻撃は断続的で、パターンを変えていました。Magic Transitは、攻撃が場所を変えても問題を解決してくれたのです。」

結果と利点：Magic TransitはWikimediaのDDoS防衛戦略に不可欠な要素

WikimediaはDDoS攻撃を軽減するためにMagic Transitの利用を続けています。Liamboits氏は、必要に応じてツールをオン/オフに切り替えることができる点を評価しています。「IPスペースのアナウンスをオフにできるため、何か問題が生じた場合の選択肢が増えます。」

Magic Transitは稼働中であっても、WikimediaプロジェクトとWikimediaのユーザーの間のエンドツーエンドの既存の暗号化を妨害しません。性能に加えて、Magic Transitがチームにとって正しい選択となった理由です。「我々のセキュリティとプライバシーに関するニーズに対するCloudflareの対応を高く評価しています。我々の組織は、プライバシーに非常に神経を使っているからです。」

Wikimediaは、Magic Transitが（他のクラウド「スクラビング」ベンダーがするように）トラフィックを一か所のスクラビングセンターへと迂回させる代わりに、ネットワークエッジでフィルターできることを評価しています。他社はより一元化されたアーキテクチャを使っています。」とLiambotis氏は話します。「エッジではなく、遠隔にある何か所かのスクラビングセンターでフィルタリングします。そのため、容量と機能の点で、我々の要件を満たしていませんでした。スクラビングセンターの1つで問題が発生し、そこに我々のトラフィックが迂回されている場合、レイテンシーの問題が起こります。」

「一元化されたスクラビングセンターを有効にするために必要なルーティング変更は、ユーザー側のレイテンシーとTTM(緩和開始までの時間）の両方に影響します。」とDanis氏は付け加えます。「Magic Transitのように、エッジでグローバルにフィルタリングすると、正当なトラフィックのレイテンシーを短縮できます。」

「インフラストラクチャへのリスクとして、DDoSを非常に懸念しています。そして、我々のDDoS軽減戦略の根幹となっているのが、Cloudflare Magic Transitです。」

Wikimediaのチームは、問題発生時のCloudflareの対応に満足していると言います。「Magic Transitをデプロイしてから、Cloudflareのチームと何回かやりとりする必要がありました。その時、Cloudflareのネットワーク内のルーティングループに関連する厄介な問題もありました。Cloudflareの対応の速さ、技術力に感銘を受けました」とDanis氏は締めくくりました。

「Cloudflareは、信頼性の高いインフラストラクチャと対応が速く非常に有能なチームを持っています。万全の態勢で、大規模な攻撃も阻止してくれます」と、Ingersoll氏。