【特集】 ファイアウォールの機能の現状と将来 （前編）
〜ポイントは、使用目的に応じたファイアウォールの選択〜

丸山 龍一郎
ストーンソフト・ジャパン
ネットワークセキュリティーマネージャー
2001/11/21

ファイアウォール・アーキテクチャの改良

（1）パケットフィルタリング型の進化

　第1世代のパケットフィルタリング機能は、“スタティック・フィルタリング”である。この方式の欠点を説明するうえでまず社内からインターネット上のサーバへのFTPの動作について説明する。

　FTPはインターネット上のサーバのポート番号21に接続する（制御セッションの確立）。制御セッションを使用してPORTコマンドを送信しクライアント側の接続用ポートをサーバに通知する。サーバはPORTコマンドで通知されたポート番号に対してデータ用の通信を開始する。

　スタティック・フィルタリング方式の大きな欠点は、下線の部分の実現にある。PORTコマンドによりサーバに通知されるポート番号は、クライアント上の1024以上の任意の非特権ポートである。サーバ側からのデータセッションを許可するルールを定義することは、インターネット上の任意のホストの20番ポートからのアクセスを許可することを意味するのである。これは、FTPが使用する2つのセッションがファイアウォールで個別に管理されるところに問題がある（図4）。

データ転送用セッションのために すべての非特権ポートをオープンする

図4 スタティック・パケットフィルタリング

　これを改良した“ダイナミック・フィルタリング”というアーキテクチャでは、ファイアウォールが制御セッションを使用して送信されたPORTコマンドのパラメータを認識しており、サーバからのデータセッション用のポートのみをダイナミックにオープンするようになっている（図5）。

データ転送用セッションのフィルタリング・ルールは PORTコマンドで通知されたポートのみオープンする

図5 ダイナミック・パケットフィルタリング

　ダイナミック・フィルタリングを採用したフィルタリング技術の1つに“ステートフル・インスペクション技術”がある。これは、CheckPointの「Firewall-1」に実装されている技術である。

　ステートフル・インスペクション技術の特徴を以下に説明する。

1. OSIの3〜7層の情報に基づく制御
   スタティック・フィルタリングでは、3層のみの情報を基にアクセス制御していた。しかし、この方式では、企業が実現したいセキュリティポリシーの実装が不可能である。そのためには、アプリケーション・ゲートウェイが実現するようなアプリケーションプロトコルに特化したアクセス制御を実行する必要がある。ステートフル・インスペクションのパケット走査は、IPヘッダ情報（3層）とペイロード情報（4〜7層）を参照することによりセキュリティを強化している。また、パケットに対する検証は Inbound／Outbound／Eitherboundで実行することが可能であり、これらは管理者が選択して行う。
   
   
2. データセッションの開始前に送受信された情報やユーザー認証の結果に基づいた制御が可能
   FTPのPORTコマンドやRealAudioなどのアプリケーションは、複数のセッションで1つのアプリケーションを実現しているタイプのものである。これらのアプリケーションの最初のセッションは制御用のコネクションであり、それを使用してその後のデータ転送用のセッション情報を通知するものが多い。スタティック・フィルタリングでは許可するポート範囲を静的にオープンにしておく必要があったが（FTPの場合、1024以上の非特権ポートをすべて許可する）、ステートフル・インスペクションでは制御セッションを使用して通知されたポート番号をステートテーブル上にペンディングしておき、そのポートあてのセッションのみを許可することができる。
   
   
3. セッションの情報は、ステートテーブルに保持
   ステートフル・インスペクションでは、最初のパケット（SYNパケット）がファイアウォールに到着したときにルールベースによって走査される。許可されたパケットに関する情報（ステータス、コンテキスト）はステートテーブルに追加され、同一セッションのそれ以降のパケットについてはルールベースでの走査ではなくステートテーブルの内容で検証される。TCPのようにセッションという概念がないUDPやRPCベースのアプリケーションに対しては、ステートテーブルを使用して仮想的にセッションという概念を作り出してセキュリティを強化している。
   

　上記の下線部分に対しては、最初のパケット到達後のパケットはすべてステートテーブル情報を基に判断されるため、高負荷時のステートテーブル更新やスプーフィングなどを利用したハイレベルのクラッキングには問題となるケースがある。この部分のセキュリティをさらに強化したものに、“マルチレイヤ・インスペクション技術”がある。この技術では、ルールベースを走査する性能を向上しつつ、すべてのInbound／Outboundパケットに対してルールベースとステートテーブルに基づき検証を行うのである。この技術は、ストーンソフトのFirewall/VPNソリューションで採用されている。

　 “マルチレイヤ・インスペクション技術”は、さらに“プロトコル・エージェント機能”を利用してアプリケーションに特化した検証を実行することができる。例えば、FTPではRFC959/2640で許可されているコマンドか否かとか、アンチウイルスサーバへリダイレクトするといった制御を行う。

（2）アプリケーション・ゲートウェイ型の進化

　アプリケーション・ゲートウェイの最も大きな欠点はデータ転送時のスループットである。この問題を解決するために、セキュリティレベルを維持しつつスループットを向上させるアプローチがなされた。例えば、その技術の1つにNAIの「Gauntlet Firewall」が採用している“アダプティブ・プロキシ技術”がある。これは、アプリケーションの実装形態を十分理解してなされた改良である。前述したFTPもそうであるが、アプリケーションは最初にアクセス制御とユーザー認証を行い、それを確認後実際のデータの転送を行う。

　 従来のアプリケーション・ゲートウェイは、アプリケーションの処理時間の大半を占めるデータ転送までをアプリケーション層で実行していたところに改善すべき点があった。アダプティブ・プロキシでは、最初のアクセス制御および認証フェーズは従来どおりアプリケーション層で検証し、認証後のデータ転送に対してはIP情報を基にダイナミックにフィルタリング・ルールをメモリ上に作成する。通常パケットは下位のレイヤから処理されるため、ネットワーク層に作成されたフィルタリング・ルールによりデータ転送用のセッションが許可され、転送される（図6）。

プロキシ・プログラムは、認証後のデータ転送用セッションのフィルタリング・ルールを動的に作成する。転送終了後は、フィルタリング・ルールは削除される。

図6 アダプティブ・プロキシ

　しかし、このアプローチにも問題がないわけではない。すべてのアプリケーションにアダプティブ・プロキシ技術が組み込まれているわけではないからである。さらにこの技術を使用するとアプリケーションデータの中に存在するセキュリティの脅威（ウイルス）の検査が実行できないのである。従って、ユーザーはパフォーマンスを優先するか、セキュリティを優先するかの選択を迫られることになる。

　ほかのアプリケーション・ゲートウェイ型のファイアウォールベンダのアプローチも同様で、アプリケーション・ゲートウェイとステートフル・インスペクションを組み合わせたハイブリッド型を採用している。

筆者が考える選択基準

　前節でファイアウォールが採用しているアクセス制御のアーキテクチャを説明してきたが、実際の選択基準はどうすべきであろうか？ 以下に筆者が考える選択基準を示すことにする。

（1）企業向けに導入するファイアウォール

　 導入するファイアウォールの目的は、社内から社外へのアクセスを制御することにある。実装されるアクセスポリシーも企業のセキュリティポリシーに基づいて設定される。考えられる要件としては、以下のものがある。

1. 業務で必要とされるアプリケーション以外は使用しない
   実業務で必要となるアプリケーションの抽出を行うと、結果は少数のアプリケーションに限定される。例えば、Web(HTTP／HTTPS)、 FTPである。特別な場合を除いては、ストリーミング系のアプリケーションの利用を許可する必要はない。もし利用する場合はネットワークの帯域を消費することに留意が必要である。
   
   
2. アプリケーションごとに詳細レベルでのアクセス制御が必要
   アプリケーションの使用においてもクライアントに頼らず、ゲートウェイで統一的なセキュリティを実現したい。例えば、FTPのPUT（それ以外にも社外サーバ上のリソースに影響を与えるコマンド）を制限したい。
   
   
3. データに対するセキュリティレベルを向上したい
   社外からダウンロードしたリソースにウイルスなどが含まれていないかの検証、社内から社外に送信されるメールの中に社内機密を含むような内容が含まれていないかの検証ができる機能を有する、あるいはそれらを実現する別システムと連携できることが必要である。
   
   
4. ユーザーのアクティビティを詳細につかみたい
   社内のクライアントが実行しているアクティビティを詳細に監視する必要があるならば、アプリケーション・ゲートウェイが作成するログ情報を記録できなければならない。
   

（2）インターネットサービス向けに導入するファイアウォール

　ビジネスサービスで使用するファイアウォールの選択基準は、BtoBかBtoCかで2つに分けられる。BtoBの場合、利用されるアプリケーションは制限される。どちらかというとパフォーマンスよりはセキュリティが重視される。

　それに対して、BtoCの場合は不特定多数のユーザーからのリクエストに対して、決まったレスポンスタイムを実現しなければならない。どちらかというとパフォーマンス重視である。ビジネスとして提供するサービスによってはやり取りされるデータのセキュリティを重視する必要がある。求められる要件もビジネスの内容に依存してしまう。

目的に応じたファイアウォール・アーキテクチャの選択

　結論（理想論）としては、使用する目的に応じてファイアウォール・アーキテクチャの選択を変更する必要がある。しかし、それを妨げる大きな問題として、1つの管理組織の中に複数のファイアウォール・アーキテクチャを設置した際の運用コスト（管理者のトレーニング、ソフトウェアのメンテナンスなど）がある。運用面についても最近は環境が変化し、セキュリティ製品の運用をアウトソーシングできるようなサービスを提供している企業も多い。これらのサービスを利用することで適材適所の実現も可能と考えられる。

　次回は、インターネットビジネス環境を実現するうえで必要とされるファイアウォール機能（VPN機能、クラスタリング技術など）について説明する予定である。

Index 特集：ファイアウォール機能の現状と将来 （前編）

Page 1 “製品ありき”の導入でよいのか ファイアウォールの基本機能 ファイアウォールのアーキテクチャ Page 2 ファイアウォール・アーキテクチャの改良 筆者が考える選択基準 目的に応じたファイアウォール・アーキテクチャの選択 特集：ファイアウォール機能の現状と将来 （後編） 　 Page 1 今後必要とされるファイアウォールの機能とは ファイアウォールの高速化 ファイアウォールの可用性 　 Page 2 ファイアウォールとIDSによりセキュリティを高める 障害発生時の問題を解消するマルチホーミング ファイアウォールが持つべきロギング機能 最後に

関連記事 連載：ファイアウォール運用の基礎 特集：ファイアウォールのリモート・マネジメントの機能と運用 第7回 読者調査結果〜ファイアウォール／VPNの最新導入状況と、その課題とは？〜 5分で絶対に分かるファイアウォール

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）