「セキュリティ」と一口に言っても、セキュリティベンダーに加え、さまざまなベンダーが、DoS攻撃からマルウェアによる攻撃まで、さまざまなサイバー攻撃への対策を提供しています。この連載では、ネットワークベンダーから見たセキュリティの現状を、解説していきます。第2回は、DDoS攻撃への防御を意識したSSLのデプロイ方法について説明します。

とあるWebサイトの残念なネットワーク構成

DDoS攻撃は、防御がきわめて難しい攻撃の1つです。攻撃者が数千台ものマシンを乗っ取ってターゲットを攻撃する様は、魔法使いが雷雲を呼び寄せ、敵上空に雨風を浴びせかけるシーンといっても過言ではないでしょう。そのようなDDoS攻撃の中でも、特に対応が難しいのが「SSLセッションを利用したDDoS攻撃」です。

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

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

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

このような構成のサイトは、SSLを使ったDDoS攻撃を行う攻撃者にとって、格好の標的だと言えます。

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

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

導き出される2つの教訓

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

まず第1の教訓は、「SSLの終端場所より前の段階でDDoS対策を施してもまったく意味がない」ということです。

SSLで暗号化されたトラフィックのままでは、セキュリティ製品が本来の機能を果たすことができません。今回紹介したケースでも、ロードバランサーの前段にDDoS対策製品が置かれていましたが、SSLのセッションフラッド(攻撃)を検出できずに、ロードバランサーのダウンを招いてしまいました。SSLの終端は、各種セキュリティ機能の最前段で行うべきなのです。

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

ADC(アプリケーション・デリバリー・コントローラ)によって一体化されたセキュリティ・ソリューションについてお客さまと話す際に、反論としてしばしば登場するのが「卵は1つのカゴに盛るな」ということわざです。もちろん株式投資などのポートフォリオを組む場合は、このような戦略が有効かもしれません。1つのカゴをひっくり返してしまっても、ほかのカゴに影響がなければ、残りの資産は保護されるからです。

しかし、セキュリティの世界では、まったく話が異なってきます。

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

正しいアプローチは何か?

この2つの教訓を頭に入れておけば、正しいアプローチが自然と見えてきます。

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

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

これであれば、「最も弱いリンク」を見つけ出し、全体のバランスを取る必要もありません。アプリケーション・サーバに至るまでのリンクが、ADCしか存在しないからです。またFIPS レベル3に対応するとともに、ハードウェアによって保護された鍵サービスを展開するデバイスとしても、ADCは最適だと言えます。

このようなサービスは一般に高価なものであり、すべてのアプリケーション・サーバに導入しようとすれば膨大なコストがかかりますが、ADCであれば冗長構成にしたとしても、導入対象を2台に集約できます。

SSLはデータ保護するための重要な技術ですが、正しく展開されなかった場合は攻撃に手を貸す存在にもなりかねません。SSLセッションを利用したDDoS攻撃を避けるためにも、適切なSSLのデプロイメントを意識することが重要です。

著者プロフィール

伊藤 悠紀夫(いとう ゆきお)
F5ネットワークスジャパン
セールスエンジニアリング本部
プリセールスコンサルタント

UNIXサーバー、ストレージ、シン・クライアントといったインフラエンジニアを経て、F5ネットワークスジャパンへ2012年に入社。
現在はセキュリティ・クラウドをキーワードにイベント講演やハンズオンラボを行い、F5ソリューションの啓蒙活動に奮闘中。
最近はOpenStackやIoTといったキーワードを中心に連携ソリューションを模索している。