インターネットにおけるDDoS対策が難しい理由（その2）：DDoS攻撃クロニクル（3）（2/4 ページ）
DDoS攻撃の“歴史”を振り返ることを通じて、有効なDDoS攻撃対策について考える本連載。第3回では、「典型的な攻撃手法とWebサイト側で観測される状況」を解説し、Webサイト側で実施できる対策とその限界について考える。
DDoS攻撃発生時の負荷の増大とその影響
Webサイトに対してDDoS攻撃が行われると、システム全体の負荷が増大してゆくが、負荷が前ページで説明した目標値以下であればサイト運営は継続できる。また、攻撃規模が全体目標をわずかに上回る程度であれば、各構成要素容量の余裕分（バッファ）によって運営継続が期待できる。しかし、負荷がさらに上昇し、「最もバッファの小さい構成要素」（ボトルネック）が過負荷となった瞬間に、Webサイト全体の機能は停止する。
つまり、このボトルネックの処理可能容量がWebサイト全体のDDoS攻撃への耐性を決めることになる。しかし、設計段階で意図してボトルネックを導入するような場合を除けば、「システム内のどこがボトルネックとなるのか」、また「その容量はどの程度か」を事前に厳密に知ることは難しい。従って、基本的にWebサイトのDDoS耐性は、「サイト全体の目標値」に等しいと考えることになる。
全ての構成要素が攻撃対象となる
攻撃者の立場から見ると、Webサイトを“倒す”ためには、その設計容量を超える攻撃を仕掛ける必要がある。仮に攻撃者がボトルネックの所在とその容量を知っていれば、ピンポイントに攻撃を仕掛けて確実にサイトをダウンさせることができるわけだが、そのような情報を外部の攻撃者が知ることはほとんど不可能だといえる。従って、攻撃者はさまざまな方法でシステムの各部に打撃を与えようと試みる。図2に、典型的なDDoS攻撃手法とその攻撃の観点、事例やツールなどをまとめた。手法次第で、さまざまな構成要素を攻撃することができるということがお分かりいただけるはずだ。
「クローラー」や「スクレイパー」はWebサイト内の情報を自動的に収集するツール全般を指すものであり、必ずしもDDoS 攻撃を目的したものではない。しかし、頻繁にWeb上のアプリケーションを動作させればアプリケーションサーバやデータベースサーバが高負荷になることから、攻撃の意図を持って用いれば、DDoS攻撃の道具にもなる。
サーバ負荷の上昇を狙う攻撃の多くは、ある程度想像しやすいものだったが、「スローポスト」のように負荷上昇を伴わずに静かにリソースを枯渇させる攻撃は、Webシステム管理（サーバ負荷監視）の盲点を突くもので、気付くのが難しかったケースも少なくない。
リフレクション攻撃のように回線帯域を占有したりISPのルーターを過負荷にしたりするものは、単一のWebサイトをダウンさせるだけでなく、回線やルーターを共用する他のシステムを巻き添えにすることもある。
Webサイト運営者は、DDoS攻撃に対して、こうした全ての状況をカバーできる防御システムを構築しなければならないのである。
対策のためにDDoS攻撃を「定量化」する
DDoS攻撃の対象や手法を理解した上で、これに対抗するためには、具体的な攻撃の「威力」や「規模」を知らなければならない。そのためには、DDoS攻撃を「定量化」する必要がある。
これまで見てきた通り、DDoS攻撃はWebサイトのあらゆる構成要素、リソースを攻撃対象にする。従って、攻撃の対象や手法ごとに異なる定量化の単位を用いる必要がある。例えば、回線や通信処理容量を狙った攻撃であれば「bps」、ルーターを狙ったものなら「pps」、Webサーバを狙ったものであれば「Req/s」を用いるといった具合である。
このように、厳密に対策を講じようとするなら、構成要素ごとに適切なパラメータで“耐久力”を評価する必要があるが、それでは対策を考えるのが非常に複雑で面倒になってしまう。従って、何らかの簡略化が望まれる。詳しくは以降のページで述べるが、最近発生しているDDoS攻撃は通信回線を狙ったものが大半を占めており、また一般になじみがよいことからも、以下では基本的に単位として「bps」を用いることにする。
Copyright © ITmedia, Inc. All Rights Reserved.