DDoS攻撃の防御を意識したSSLの展開方法

DDoS攻撃は、防御がきわめて難しい攻撃の一つです。攻撃者が数千台ものマシンを乗っ取りターゲットに向けて攻撃する様は、魔法使いが雷雨を召喚し野営中の敵に差し向けるシーンを思い起こさせます。DDoS攻撃の中でも特に対応が難しいのが、SSLセッションを利用したDDoS攻撃です。

しかし適切なアプローチを行うことによって、SSLセッションを利用したDDoS攻撃に対する防御も可能になります。それでは適切なアプローチとは、どのようなものなのでしょうか。まず下の図を御覧ください。

この図は、ある著名サイトのネットワーク構成です。このサイトは激しいDDoS攻撃にさらされ、数週間にわたり閉鎖を余儀なくされました。

　ここで注目したいのが、SSLトラフィックがアプリケーション サーバで終端されている点です。つまりSSLトラフィックはアプリケーション サーバに達するまで、暗号化された状態で各種セキュリティ デバイスの中を通過していたのです。またこのサイトのSLA（サービスレベル契約）では「SSL接続はすべてタイムアウトするまで維持されなければならない」と規定されていました。

このサイトの何が問題だったのか

　このような構成のサイトは、SSLを使ったDDoS攻撃を行う攻撃者にとって、格好の標的だといえます。前述のDDoS攻撃もSSLセッションを利用したものであり、攻撃者はペイロード（リクエストデータの本体）を含まない“空のSSLセッション”を大量に送りつけたのです。これらのトラフィックはそのままアプリケーション サーバまで届き、タイムアウトするまでSSLセッションが維持されていました。この攻撃は、確立されたSSLセッション内で起きているということを除けば、古典的なSYNフラッド攻撃と同様の攻撃です。

　実はこのサイトのアプリケーション サーバは、膨大な負荷にも対応できるだけのチューニングが行われており、実際にダウンしたのはサーバではありませんでした。空のSSLセッションは数百万回にも達しましたが、最初に音を上げたのはこの接続を前段で受けていたロード バランサーだったのです（もちろんこれはF5製品ではありません）。このロード バランサーは、同時接続の上限に達するとともに激しい障害を起こし、トラフィック処理を停止、DDoS攻撃が終了するまでサービスを完全に回復することはできませんでした。

導き出される二つの教訓

　この事例には二つの重要な教訓が含まれています。

　まず第1の教訓は、SSLの終端場所よりも前の段階でDDoS対策を施しても、まったく意味がないということです。SSLで暗号化されたトラフィックのままでは、各種セキュリティ製品は本来の機能を果たせません。今回紹介したケースでも、ロード バランサーの前段にアンチDDoSデバイスが置かれていましたが、SSL接続フラッドを検出できずに、ロード バランサーのダウンを招いてしまいました。SSLの終端は、各種セキュリティ機能の最前段で行うべきなのです。

　第2の教訓は、アプリケーション サーバに至るまでのチェーンが長くなるほど、リスクも高まるということです。

F5はBIG-IPなどのADC（アプリケーション デリバリ コントローラ）によって、一体化されたセキュリティ ソリューションを提供しています。これについてお客様とお話する際に、反論としてしばしば登場するのが「全部の卵を一つの籠に入れるべきではない」という諺です。もちろん株式投資などのポートフォリオを組む場合には、このような戦略が有効かもしれません。一つの籠をひっくり返してしまっても、他の籠に影響がなければ、残りの資産は保護されるからです。

　しかしセキュリティの世界では、まったく話が異なってきます。セキュリティ機能を複数製品に分けて実装したとしても、リスク分散にはならないのです。ネットワーク全体のセキュリティは、ネットワークの構成要素のうち“最も弱いリンク”で決まります。攻撃者が狙うのも、この“最も弱いリンク”です。デバイスが増えれば、そのうちのいずれかが“最も弱いリンク”になるでしょう。すべてのデバイスを同じレベルの強さにすることは、決して簡単ではないからです。前述のサイトの場合では、ロード バランサーがこの“最も弱いリンク”になりました。

それでは正しいアプローチとは

　この二つの教訓を頭に入れておけば、正しいアプローチが自然と見えてきます。データセンターの最前線に一体化したセキュリティ ソリューションを設置し、そこでSSLを終端させるという方法です。これならアプリケーションへのペイロードを確認してから、バックエンドのサーバへの接続を確立できます。DDoS攻撃の影響を、データセンターの最前線で食い止められるのです。

　ここで必要になるのが、不要なコネクションを自動的に削除する“動的リーピング機能”を装備した、インテリジェントなADCです。このようなADCであれば、サーバとの接続を確立できなかった“空のSSLセッション”を動的に削除することで、ADC自身の負荷超過でサービスが停止するという事態も回避できます。

　“最も弱いリンク”を見つけ出し、全体のバランスを取る必要もありません。アプリケーション サーバに至るまでのリンクはADCしか存在しないからです。またFIPS レベル3に対応するとともに、ハードウェアによって保護された鍵サービスを展開するデバイスとしても、ADCは最適だといえます。このようなサービスは一般に高価なものであり、すべてのアプリケーション サーバに導入しようとすれば、膨大なコストがかかります。しかしADCであれば冗長構成にしたとしても、導入対象はわずか2台に集約できます。

SSLはデータ保護のための重要な技術ですが、正しく展開されなかった場合には、攻撃に手を貸す存在にもなりかねません。SSLセッションを利用したDDos攻撃を避けるためにも、適切なSSL展開を行うべきなのです。