インターネットにおけるDDoS対策が難しい理由：DDoS攻撃クロニクル（2）（2/3 ページ）

» 2016年03月14日 05時00分公開

インターネットの構造

　インターネットは、米国国防総省配下の研究機関「DARPA（Defence Advanced Research Project Agency）」を中心に研究・開発が進められた。その目的の一つは「全体が停止することがない通信ネットワークの実現」であった。この目的を達成するための手段として、インターネットの設計時には、徹底的な「分散管理」が追求された。しばしば「インターネットは核攻撃を受けても存続できるように開発された」といわれるが、その真偽はさておき、インターネットは、ネットワークの一部の故障が全体に波及することがないように設計されたのである。

　ネットワーク内の分散管理の単位は「AS（Autonomous System）」と呼ばれ、複数のASが緩く結合したものがインターネットである。大まかに言えば、読者の方々が家庭などで契約しているインターネット接続事業者（ISP）のネットワークがASであり、多数のISP（AS）が相互接続されることによって、インターネットが出来上がっていると考えてもらえばよい。そこで、必ずしも正確ではないのだが、ASという聞き慣れない言葉の代わりに、以下ではISPという語を用いることにする。

　さて、インターネットにおいては、たとえ1社のISP内で重大な故障が発生しても、（他のISP内の通信を含む）外部の通信には影響を与えない。この「緩い結合」がインターネットでは重要なのである。ISPは自分のネットワーク内の管理は厳重に行うが、他のISP内部の事情は知らなくてよいのだ。実際、こうした基本方針のもと、ISP間では最低限の情報交換のみが行われている。（参考：『インターネットのカタチ―もろさが織り成す粘り強い世界』、あきみち／空閑洋平共著、オーム社）

インターネットDDoS対策実現上の課題

　このようなインターネットの構造の中で、あるWebサイトに対するDDoS攻撃が発生したケースを想定しよう。インターネットにおけるDDoS攻撃を効果的に防止するには、上述のa）～c）の対策が必要だった。実際のDDoS攻撃に対して、これらがどのように機能するのか、その様子を見てみよう。

　なお、ここでは攻撃対象のWebサイトが所属するISPを「ISP #1」とし、DDoS攻撃を仕掛けてくる攻撃者は、分散した複数のISPに所属しているので、それらを「ISP #1」〜「ISP #N」とする。

　まずa）およびb）だが、ISP #1およびWebサイトのシステム管理者は、接続要求の急増により何か異常事態が発生したことに気付くだろう（なお、そもそも異常事態に気が付くのが難しい状況もあるのだが、これについては次回以降詳しく述べる）。また、ISP #1自身のネットワーク内で発生する接続要求であれば、その発信元を識別することも、電話ネットワークと同じように実現できそうだ。

　ところが、ここでインターネット特有の問題が発生する。インターネットでは、他の多くのISPにおいても、同じようにWebサイトの混雑を認識し、接続要求の発信元を識別してもらわなければならないのだ。しかしながら、ISP #2〜ISP #Nが、ISP #1のWebサイトの混雑を発見することは難しい。

　なぜなら、各ISPがそれを行うためには、いつ攻撃の標的となるか分からない世界中の全Webサイトへの接続要求数を常時計測する必要があるからだ。そのようなことは、設備容量的にほぼ不可能である。また、仮に計測できたとしても、各ISPから該当のWebサイトに向かう接続要求数は、当該Webサイトに向けられる全ての接続要求数に比べれば小さな数値となってしまうため、各ISPでは、それが攻撃による増加なのか日々の変動なのかを区別できないケースが多い。

　従って、各ISPでDDoS攻撃を検出することは諦め、「ISP #1からISP #2〜ISP #N宛てに、該当Webが混雑し始めたことを通知し、情報を集約して対策を実施する」ことが唯一の効果的解決策となる。しかしここに、前述の「分散管理」と「緩い結合」の壁が立ちはだかる。現在のISP間で交換する情報には、この目的を達成するような情報は含まれておらず、またそのような取り決めもないのだ。

　では、仮にb）が実現できたとして、実際に攻撃を止めるc）の対策はどうであろうか？結論から言えば、これも実現するのはかなり難しい。攻撃パケットと、正規ユーザーからの正当なパケットとの区別が簡単には付かないからだ。こうした攻撃パケットと正当なパケットの分別については、現在、大きく以下の二つのアプローチが試みられているのだが、それぞれに困難な課題があるのが実情だ。

　1つ目の方法は、パケットの内容を詳細分析し、攻撃パケットを見分けようとするものだ。しかし、攻撃者は見かけ上正当なパケットを作成することができてしまう。完全に正当でなくても、ISPに“十分正当”と思わせるようなパケットを作ることは難しくない。ISPはパケットに含まれる全ての情報を見ているわけではなく、ルーティングと呼ばれるパケットの接続先を指し示す情報と、わずかな付随情報をチェックしているだけなのである。パケット全体を分析して攻撃であるかを判定するための技術、設備を導入しているISPはほとんどいないといってよい。

　2つ目の方法としては、攻撃を仕掛けてくるユーザーを特定し、規制するというものがある。しかしこの方法にも“副作用”があり、安易に使用することはできない。というのも、異なるISP間での通信では「NAT（Network Address Translation）」による代表IPアドレスを、攻撃者と正規ユーザーが共用してしまうからだ。インターネットに接続されたコンピュータには「IPアドレス」と呼ばれる識別子が割り当てられるが、IPアドレスには、同一ISP内（あるいはもっと小さなネットワークの単位）で一意に付与される「ローカルIPアドレス」と、外部のISPからみても一意に付与されている「グローバルIPアドレス」がある。

　ローカルIPアドレスを持つコンピュータが自ISP外へ通信する場合、その発信元IPアドレスは、NATがもつグローバルIPアドレス（代表IPアドレス）に変換される。つまり、ISP #2内のコンピュータがISP #1のWebサイトに接続すると、それが正規ユーザーであっても攻撃者であっても、Webサイトから見ると同一のIPアドレス（NATによる代表IPアドレス）から発信されたパケットに見えてしまうのだ。従って、攻撃に対処しようとして代表IPアドレス発の該当Webサイト向けパケットを遮断すると、同時に正規ユーザーのアクセスを止めてしまう危険を伴うのである（図3）。