ディレイドバインディング
いままで説明してきた防御方法がパケット単位でアタックを検出する方法だったのに対して、ディレイドバインディング方式ではDoS防御製品により一度通信セッションを終端してサーバのリソースをアタックから防御する(TCPプロキシ方式またはIPプロキシ方式と呼ぶ場合もある)。
前編での説明の繰り返しになるが、TCP通信におけるセッション確立までの手順は図5のとおりとなる。
このセッション確立時におけるSYN、SYN-ACK、ACKのやりとりをサーバに代わってDoS防御製品が行うことにより、さまざまなSYNアタックからサーバのリソースを保護することが可能になる。
クライアント側のTCP通信とサーバ側のTCP通信の間にDoS防御製品が入ることで、通信の処理に若干の遅れが生じるため、ディレイド(遅延)バインディング(結合)と呼ばれている。この仕組みを応用してサーバやリソースを守ることが可能になるのだが、キーとなる技術が、どのようにして「正常なTCP通信」であるかを判断するか、という点だ。ここにベンダはさまざまな特徴を持った実装を試みている。
例えばプロトコルがRFCの定義どおりに送受信されているか判定する「プロトコルアノーマリ」、トラフィックの統計データを基に異常を判定する「トラフィックアノーマリ」などが代表的だ。このような「アノーマリ」(不正または異常)技術と組み合わせることにより、未知のアタックにもある程度対応可能であり、脆弱性が発見されてから間髪入れずにアタックが発生するような「ゼロデイアタック」にも対応できる可能性がある。
またディレイドバインディングと組み合わせる技術の中でも、特にSYNアタックからの防御にフォーカスした技術が「SYNクッキー」であり、次項にて詳しく解説する。
これらのディレイドバインディング方式の場合、完全なセッションベースの検査となるため、DoS防御製品上のメモリ容量によって処理可能な同時接続数が限られてしまう欠点がある。対象となるネットワークの規模に応じて慎重なサイジングが必要だ。
SYNクッキー
ディレイドバインディングの対象となるTCP通信では、SYNやACKなどのフラグのほかにもさまざまな情報がパケットの中の「TCPヘッダ」と呼ばれる部分に格納されている。TCPヘッダのフォーマットを以下の図7に示す。
このTCPヘッダの中に含まれるシーケンス番号は、通常のセッション確立時にはランダムな32ビットの値が生成される。確認応答番号は、通信相手のシーケンス番号にそのパケットのバイト数を足すことにより、次に送信すべきデータを相手に伝えるために使う。
SYNクッキーの場合、本来ランダムに生成されるべきシーケンス番号に、該当するセッションに関する情報を埋め込むことでセッションの正当性を確認する。SYNクッキーとはそのシーケンス番号に埋め込まれるデータそのものを指し、各製品により実装方法はさまざまだが、おおむねTCPヘッダの内容をハッシュした値を使う。SYNクッキー使用時の通信例を図8に示す。
SYNクッキーの場合、クライアントからSYNを受けた段階ではTCPソケットをオープンしない。その後のACKの中に含まれる確認応答番号を計算し、正しいセッションであることを確認してからセッションの情報をメモリに展開する(製品によってはその後のアプリケーションデータが来てからメモリ展開するものもある)ため、ディレイドバインディングやTCPプロキシアーキテクチャの欠点である、アタック処理時のメモリ容量による同時接続数の制限が緩和される。
SYNアタックの中でも、特にSYN、SYN-ACK、ACKまで完了していながらアプリケーションレベルのデータを一向に送信してこないような「コネクション完了型」のアタックに対しては、このSYNクッキーによる防御方法が有効だ。SYNクッキーを使用する場合の注意事項としては、メモリを消費しない代わりにDoS防御製品のCPU処理能力を使ってSYNクッキーの計算を行うため、該当するネットワークのトランザクション量や想定されるアタック量に応じた性能の製品を使用することが肝心だ。
Copyright © ITmedia, Inc. All Rights Reserved.