「クラウドベースのDDoS攻撃対策」徹底解説：DDoS攻撃クロニクル（4）（2/3 ページ）
DDoS攻撃の“歴史”を振り返ることを通じて、有効なDDoS攻撃対策について考える本連載。第4回では、クラウドベースのDDoS攻撃対策の仕組みとその効果について解説する。
CDNへのDDoS対策の実装
第3回で説明した通り、大規模なDDoS攻撃の規模を仮に数百Gbps程度とした場合、CDNが持つサーバの容量とインターネットへの接続帯域は、これを大幅に上回っていなければならない。これについては、大規模分散配置されたCDNでは“35Tbps”という配信実績もあることから、最大規模のDDoS攻撃を受け止める体力は十分に備えているといえる。
従って、このCDNのサーバ容量を有効利用し、前述したa）〜c）の3機能を実装すれば、有効なDDoS対策を構築することができそうである。以下で、3機能それぞれの実装において、CDNの能力をどのように生かすことができるかを見ていこう。
DDoSの検知能力
まず、「a）混雑し始めたWebサイトを特定する」機能だが、CDNは契約顧客のWebサイトへのアクセスを常に受け止めており、平常時のトラフィックレベルを把握している。従って、あるWebサイトがDDoS攻撃の対象となったときに起こるアクセス急増を検出することは、比較的容易に実現できる。
発信元近くでアクセスを受け止める能力
では、「b）そのWebサイトに向けた通信要求を、発信元近くで認識する」機能についてはどうか。CDNは、その本来の目的である「Webの混雑回避」のために、世界中の多くの地域にCDNサーバを分散配置している（大規模なCDNでは数千箇所にサーバを分散配置している例もある）。
これらのサーバを効率的に使う方法は、アクセスしてくるクライアントをなるべく近傍のサーバに誘導することだろう。実際に、図2のようにクライアントのアクセスをCDNサーバに誘導するときには、クライアントとの物理的な距離が考慮されている。
この能力を生かし、攻撃トラフィックも同様に攻撃拠点の近くのCDNサーバで受け止めることにより、トラフィックの1点集中を防止することができる。
攻撃パケットの判定、遮断能力
最後は、「c）攻撃パケットと正規パケットを区分し、攻撃パケットのみを遮断する」機能だが、CDNでは既に、第2回で述べた2つの方法、つまり「個々のパケットの詳細分析を行い、攻撃かどうかを判定する」方法と、「攻撃に参加している疑いの強いクライアントを識別する」方法が、さまざまな技術を用いて実現されている。
以下で、第3回で紹介した代表的なDDoS攻撃の手法ごとに、CDNがどのような方法でパケットの識別、遮断を行うのかを解説しよう。
＜リフレクション攻撃＞
CDNは一般に、Webアクセス用のTCPベースのHTTP/S電文しか受け付けないため、リフレクション攻撃に用いられるUDPベースの攻撃パケットを遮断することは容易である。
ただし、リフレクション攻撃の規模がそれなりに大きくなると、局所的にCDNサーバでのUDP遮断処理負荷の増加や、CDNサーバの前段の接続回線、あるいはISPのルーターが過負荷となり、CDNサーバとの通信ができなくなるケースもある。このような場合には、稼働中の代替CDNサーバに正規ユーザーを誘導し、Webサイト閲覧を継続させる。このような代替サーバの割当は、機器故障やビル停電、地域的な自然災害に対する備えとして、CDNの通常のオペレーションに組み込まれている。
＜Flooding＞
UDPベースのFlooding攻撃については、リフレクション攻撃と同様に、正規アクセスではないことを識別、遮断することができる。
一方、Floodingで頻繁に用いられるTCPベースの「SYNフラッド攻撃（TCP SYN Flood）」に対しては、一般に「SYN cookies」を用いて対処する。SYN cookiesは、SYNを送ってきたクライアントに対して、サーバから特殊なパラメータを持ったSYN ACKを送り、クライアントがそれを正しく処理し、正しいACKを返してきた場合のみサーバ側の通信関係のリソースを割り当てるというものである。この機能をCDNサーバに実装することで、SYN送信元のIPを偽装した攻撃を防ぐことができる。
なお、リフレクションと同様に、CDNサーバの容量やISPのルーターもしくは回線容量を超えるような攻撃に対しては、代替CDNサーバを割り当てることでWebサイトの運用を継続させる。また、BotNetを利用した攻撃など、クライアントのIPアドレスが偽装されていない攻撃により、局所的にCDNサーバへの攻撃が成立してしまった場合にも、代替CDNサーバで対処する。
＜スローポストなど＞
スローポストは、不完全なメッセージをゆっくりと送り、サーバ側の通信リソース（セッション管理のためのメモリ領域など）を長時間保留状態にすることで、サーバのリソース枯渇を狙うものである。これに対してCDNでは、不完全なメッセージを完全に復元するまでオリジンに送ることはないため、オリジンの通信リソースが危機に陥ることはない。また、CDNサーバ側のリソース消費については、「異常に遅い通信」を監視し、適宜セッションをリセットすることで対処する。
＜HTTP GET Flood＞
見かけ上正規のWebリクエストメッセージを送りつけてくるHTTP GET Floodは、攻撃なのかどうかを単一のメッセージから判定することが難しい。この攻撃に対してCDNでは、下記のような仕組みで対処を図る。
まず、GETの対象がキャッシュ可能なコンテンツであれば、キャッシュからコンテンツを返すことでオリジンを守る。前述の通り、分散配置されたCDNの容量はDDoS攻撃の規模よりもはるかに大きいため、全てのGETリクエストに対してキャッシュからコンテンツを返送することは十分に可能である。これは見方によっては、全てのアクセスを正規リクエストと見なして処理しているともいえる。
キャッシュできない、あるいはそもそも存在しない架空のコンテンツに対するリクエストを大量に送りつけてくる攻撃の場合はどうか。この場合、CDNから見て攻撃であることが判定できなければ、リクエストがオリジンまで到達してしまう可能性がある。
これに対しては、架空のコンテンツへのリクエストであれば、メッセージがオリジンへ到達する度にエラーが返送されるため、エラーが何度か繰り返された場合に、対象クライアントのIPアドレスを疑わしいものとして間引き処理を行うことで対処できる。このような間引き処理を「Rate Limiting」と呼ぶ。
また、実在するがキャッシュできないコンテンツへの攻撃の場合も、特定のIPアドレスから特定Webサイトへのアクセス数が急増したときに、やはりRate Limitingを行うことで対応が可能である。ただし、クライアントのIPアドレスを基にRate Limitingを行うと、第2回で述べたように、NATの背後にいる正規ユーザーの通信までも規制してしまう可能性がある。これに対しては「アクセス元が人間であるのか攻撃ツールであるのか」を切り分け、ツールの場合のみ遮断するといった方法により回避する。この手法については後述する。
Copyright © ITmedia, Inc. All Rights Reserved.