SonicOS 7 ネットワーク ファイアウォール
SSL 制御
SonicOS には、SSL 制御機能があります。SSL 制御は、SSL セッションのハンドシェイクを可視化するシステムで、SSL 接続の確立を制御するポリシーを構築できます。SSL (セキュア ソケット レイヤ) は、TCP ベースのネットワーク通信において中心的な規格であり、最も一般的な、よく知られているアプリケーションとして HTTPS (HTTP over SSL) があります。「HTTP over SSL 通信」にその通信手順を示します。SSL では、デジタル証明書に基づいてエンドポイントが識別され、暗号化されたダイジェスト ベースの機密性を有するネットワーク通信が行われます。
SSL を使用すると、HTTPS セッションの確立時にクライアントから要求された URL (Uniform Resource Locator、例えば https://www.mysonicwall.com など) を含むすべてのペイロードをはっきりわからないようにするという、セキュリティ上の効果が得られます。これは、HTTPS を使用すると、暗号化された SSL トンネルを使用して HTTP が転送されるからです。SSL セッションが確立される (上記の図を参照) まで実際の対象リソース (www.mysonicwall.com) がクライアントによって要求されることはありませんが、SSL セッションが確立した後に、ファイアウォールやその他の中間機器がセッション データを検査することはできません。このため、URL ベースのコンテンツ フィルタ システムでは、IP アドレス以外の方法で要求を検査して、許可するかどうかを決定することはできません。
ホスト ヘッダー ベースの仮想ホスティング (定義については「SSL 制御の重要な概念」を参照) は効率的で人気があるため、IP アドレス ベースのフィルタは暗号化されていない HTTP に対して効果がありませんが、ホスト ヘッダー ベースの HTTPS サイトは滅多にないため、IP フィルタは効果的に機能します。しかし、この信頼は HTTPS サーバ オペレータが誠実であることに基づいたもので、SSL が人をだます目的では使用されないということを前提にしています。
ほとんどの場合、SSL は適切に使用されており、オンライン ショッピングまたはオンライン バンキングや、個人情報または貴重な情報のやり取りが行われるセッションなど、セキュリティが重視される通信で使用されています。しかし、SSL のコストが低下し続け、簡単に使用できるため、セキュリティ目的ではなく、あいまい化や隠蔽を目的とした信用性の乏しい SSL アプリケーションも増加しています。
よく使用されているカモフラージュの方法では、ブラウジングの詳細を隠したり、コンテンツ フィルタを回避する目的で、SSL で暗号化されたウェブ ベースのプロキシ サーバが使用されています。よく知られたこの種類の HTTPS プロキシ サービスを IP アドレスに基づいて遮断することは簡単ですが、単純なウェブ検索によって容易に利用できる何千ものプライベートホスト プロキシ サーバを遮断することは実際のところ不可能です。問題は、このようなサービスの数が増え続けていることではなく、これらのサービスの本質が予測できない点です。これらのサービスは、動的にアドレス指定された DSL およびケーブル モデム接続を使用するホーム ネットワーク上でホスティングされていることが多く、該当する IP が常に変わります。未知のこのような SSL を遮断するには、すべての SSL トラフィックを遮断する必要がありますが実際には不可能です。
確立された SSL セッションを管理者が細かく調べて、ポリシー ベースで制御できるようにすることにより、SSL 制御機能にはこの問題に対処する方法が多数用意されています。現在の実装では SSL アプリケーション データの復号化は行いませんが、ゲートウェイに基づく識別と疑わしいSSLトラフィックの禁止が可能です。
Was This Article Helpful?
Help us to improve our support portal