スクラビングセンターで正規パケットと判定されたものは、対象のデータセンターに戻さなければならない。そのためには、ネットワーク上に特別なルートを構築する必要がある。前述の通り、対象データセンターのIPアドレス帯に関するルーティング情報は、スクラビングセンターに向かうようBGP広告を行ってしまっているため、通常のIPルーティングではパケットを届けることができない。そのため、スクラビングセンターと対象データセンター間で特別なネットワークを構成する必要がある。これについては、比較的小規模な用途の場合はGRE(Generic Routing Encapsulation)トンネルを設定する。大規模なデータセンター向けには、専用回線を設けている例もある。
スクラビングセンター型のサービスでは、データセンターを「常時攻撃から保護するか」「攻撃発生時のみ保護するか」という選択も可能である。常時保護の場合は、あらかじめBGP広告を行っておき、平時からデータセンター向けトラフィックを全てスクラビングセンターに回す構成をとる。そのメリットは、攻撃発生を即座に検知し、対処が可能な点にある。ただし、トラフィックを常にスクラビングセンターに回すことになることから、正規のアクセスユーザーの所在地や、データセンターの設置場所によっては、通信遅延の影響を考慮しなければならない。
一方、攻撃発生時のみ保護するケースでは、平時はデータセンターで直接パケットを受け取り、攻撃を検知したときにのみ、BGP広告を行い攻撃をスクラビングセンターに引き込む。こちらのケースでは平時には遅延を気にする必要はないが、いざ攻撃を受けたときに、各ISPがBGP広告内容に従って攻撃パケットをスクラビングセンターに送り始めるまでに、若干のタイムラグを要する。
図4は、2014年の夏にアカマイテクノロジーズが経験したアジア地区で最大級のDDoS攻撃への対処の記録である。このケースでは、あるゲームサイトが攻撃目標であったと思われるが、直接攻撃を受けたのはWebサイト周辺のネットワークだった。
具体的には、該当のサブネット全体にわたりUDPフラッド、TCP SYNフラッドが仕掛けられたもので、ピーク時の最大ボリュームは321Gbpsにも及んだ。そのうち3分の2に当たる攻撃(グラフ中の緑色)は、事前に把握していた典型的な攻撃元IPからのものであったため、比較的簡単に遮断することができた。
残りの3分の1(グラフ中の青色)はTCP SYNであり、試みにSYN-ACKを返送したところ、シーケンスが進まないことから、偽装されたIPアドレスが利用されている、つまり正規ユーザーによるアクセスではないことが判明した。これらのいずれの攻撃もスクラビングセンター上で遮断することで、正規ユーザーのアクセスを保護することができた。
前回説明したCDN型のDDoS攻撃対策は、Webサイトへの正面攻撃に対しては強固な防御を実現する。そして今回解説したスクラビングセンター型DDoS攻撃対策は、CDNをバイパスする側面攻撃に対して効果がある。つまり、この2つを組み合わせることで、さまざまなタイプのDDoS攻撃に対応できる強固な防御システムを構成することができる。事実、過去さまざまな攻撃にさらされてきた中央省庁や大手金融機関などでは、このような組み合わせ構成をとっている組織がある。
以上、本稿ではスクラビングセンター型DDoS攻撃対策の基本的な仕組みを解説した。近年では、各種セキュリティ機器のベンダーなども、この分野に参入し、独自のスクラビングセンターの運用を始めている。企業によって実装方法に多少の差異はあるものの、技術的な観点で大きな違いはない。そのため、「多岐にわたる攻撃手法に対して安定的な対処が可能か」「熟練した技術者が組織化されているか」といった点が差別化の要因となってくるだろう。
さて、次回はいよいよ本連載の最終回である。DDoS攻撃と防御に関する基本的な事項については今回までで大方言及できたため、最終回となる次回は、第1回の原稿を執筆してから今日までに起きた出来事や、「IoT」「FinTech」といった先端分野に関連する取り組みを紹介し、この“クロニクル“の締めくくりとしたい。
Copyright © ITmedia, Inc. All Rights Reserved.