【特集】 ファイアウォールの機能の現状と将来 （後編）
〜インターネットビジネス環境で必要なファイアウォール機能〜

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

今後必要とされるファイアウォールの機能とは

　前回「ファイアウォールの機能の現状と将来（前編）」では、“使用する目的に応じてファイアウォール・アーキテクチャの選択を変更する必要がある”ことをテーマとして、ファイアウォールが採用しているアーキテクチャについて説明した。後編ではファイアウォールに今後必要とされる機能について説明する。

　あるアナリストの調査によるとファイアウォールに必要とされる機能として以下の要件などが挙げられた。

　（1）ハイ・パフォーマンス
　（2）ハイ・アベイラビリティ（高可用性）
　（3）スケーラビリティ
　（4）冗長性

　実際、ファイアウォールを取り巻く環境は非常に変化してきている。例えば、高速ネットワークへのニーズである。エンタープライズクラスではまだ必要とされるケースは多くないが、iDCやxSPなどのサービスプロバイダ内のバックボーンネットワークに導入されるファイアウォールにはギガビットのスループットが要求される。

　また、インターネットを経由したBtoB／BtoCが本格的に運用されることにより、24時間365日の継続したサービスの提供が必要である。そのためには、サービスを提供しているアプリケーションサーバを保護するファイアウォールに対してもアベイラビリティが要求され、メンテナンスや機器障害時に対する冗長性も求められる。

　さらに、トラフィック量やユーザーの増加に迅速、円滑に対応できるスケーラビリティも必要である。今回は、これらの要求に対してどのようなアプローチがなされているかを以下の項目について説明する。

• ファイアウォールの高速化
• ファイアウォールの可用性
• 侵入検知機能（IDS）
• マルチホーミング
• ロギング

ファイアウォールの高速化

　最近のファイアウォールベンダが提供するニュースリリースを見ると、「○○Gbpsのスループットを達成！」といった記事を目にする。業界では、ギガビット対応という言葉がトレンドのようにとらえられているが、一般の企業ネットワークではまだまだニーズは多くないと思われる。

　ハイ・スル−プットを実現するファイアウォールのほとんどはハードウェアに組み込まれた、いわゆるアプライアンス型である。また、ハイ・スループットを実現するために採用されるファイアウォール・アーキテクチャはステートフル・インスペクション技術を採用している（アプリケーション・ゲートウェイ型では、高いレイヤでのデータ転送、システムリソースへの高負荷などの理由で実現は難しい）。

●ファイアウォールのスループットに影響を与える要因は何か？

　スループットに影響を与える要因は、以下のようなものが考えられる。

• ルールベースの走査処理
  パケット到達時にIPヘッダ情報とルールベースに定義された情報とのマッチング処理にかかるオーバーヘッド
• セッション状態情報の走査処理
  処理中セッションのパケット到達時にセッション状態テーブルから該当するセッション情報を検索する処理のオーバーヘッド
• オペレーティングシステムとファイアウォールソフトウェア間のオーバーヘッド
• 暗号化（VPN）
• パケットサイズ
  

　例えば、ファイアウォールに定義されるルールは表形式で定義される。複雑なセキュリティポリシーとなると、100〜200行以上にも及ぶ場合がある。パケットが到達すると、そのIPヘッダ情報とルールの比較処理が実行される。

　前編でも記述したが、パケット単位でルールとの比較処理を実行すると1パケット当たりの処理のオーバーヘッドが非常に大きくなり、スループットが実現できないため、ステートフル・インスペクション技術では最初のパケットのみルールベースを走査し、以降のパケットはセッション状態テーブルを参照するようにインプリメントされている。

　次に問題となるのは、セッション状態テーブルから対象となるパケットに関する情報を検索する処理性能である。

　アプライアンス型のファイアウォールの多くが高いスループットを実現している理由の1つは、上記に説明した処理を専用のASIC（Application Specific Integrated Circuit）を開発して行っているためである。例えば、ネットスクリーンでは、ルールベース走査部分をASICで実現している。ノキアは、ASICでは実現していないが、セッション状態テーブルからの検索処理を Firewall Flows技術を使用して高速に実行できるような特別なソフトウェアを開発している。

　ここでルールベースの走査処理に対するまったく別のアプローチを紹介する。

　ルールベースを階層的に定義することにより、メインのセキュリティポリシーをシンプルにする方法である。この機能は主にMSP（Managed Service Provider）や内部に複数の管理するネットワークセグメントを保有する企業向けの機能である。MSP環境では、プロバイダネットワークに複数のユーザー環境が存在する。それらのユーザー環境を1台のファイアウォールによって管理する場合、いままでの表形式のルール定義ではMSPのネットワーク全体のスループットに大きく影響する。

　さらにルール数が増大し、各ルール間の整合性や順序などの管理上でも問題が発生する。そのような環境に階層ポリシーを使用すれば、ユーザーの環境単位（ユーザーに割り当てたデスティネーション・アドレス単位）に1つルールを作成し、それをメインのルールベースに定義する。後はサブルールとしてユーザー環境のより詳細なルールを定義する。つまり、プログラミングでいうところのサブルーチンコールのイメージである。

HOST-B2あてのパケットに関して、ルールベースを検索すると4番目のルールで合致する。さらに複雑な環境において表形式のルールベースでは、目的のルールに合致するまでのルールベース走査処理時間が、ファイアウォールのパフォーマンスに影響する。

図1 従来のルールベースの走査処理

HOST-B2あてのパケットに関して、ルールベースを検索するとメインルールの2番目のルールで合致する。さらにNetwork-Bあての詳細な定義に関しては、サブルールベースR-Bを検索する。階層化することで目的のオブジェクトに対するルールを効率よく検索することができる。

図2 効率のよいルールベースの走査処理

　メインルールのルール数を少なくすることにより、ルールベース走査処理の高速化を実現したアプローチである。

　また余談であるが、ニュースリリースなどで公表されているパフォーマンスデータは、そのままうのみにしてはいけないということである。どのようなプラットフォームでどのようなテストをしたのかを確認する必要がある。

　確認すべきパラメータとしては、以下が考えられる。

• ハードウェア（CPU性能、CPU数、メモリ、NICなど）
  
  
• ファイアウォール（ルールベース数、ルール内容など）
  最もスループットが達成できるルールは、"Any-Any-Any-Accept"である。
  
  
• テスト内容（パケットサイズ、プロトコル、暗号化アルゴリズム（VPNの場合）など）
  一般的に64bytesサイズの小さなパケットを使用するよりは、1.5Kbytes程度のパケットを使用した方がよい結果を得られる。
  　
  

ファイアウォールの可用性

　いまではファイアウォールの冗長化は、エンドユーザーにおいても必要性が認識されている機能である。例えば、オンライン・ショッピングサイトでは時間によらず、全国からのアクセスが期待される。

　環境構築の際には、セキュリティ対策としてDMZ上にショッピング・サイトを配置する。コマースサイトが問題なく運用されていくためにはアプリケーションサーバとファイアウォールの両システムが24時間365日の継続したサービスを提供できることが条件となる。

　しかし、実際にはハードウェアやソフトウェアのメンテナンス作業や何らかの不具合によるシステム停止を余儀なくされる。システム停止時間をどのように考えるかは、そのサイトの運営内容によっても変わってくるが、共通していえるのは停止中、ユーザーはそのサイトのサービスを利用できないということである。当然停止中はビジネスの売上損失となってしまう。

　ビジネス機会の損失を防ぐためにファイアウォールに対する可用性を実現するソリューションには以下の3つの方法が存在する。

ファイアウォール自体が持つクラスタリング機能の利用

ソフトウェアベースのクラスタリングソリューションの利用

ハードウェアベースの負荷分散装置の利用

●処理中のセッションの扱い

　ファイアウォールの可用性を実現する場合、複数台のファイアウォールシステムを用意し、それらをエンドユーザーから見た場合に1つのクラスタシステム（万一のときのシステム稼働停止時間を最小限にする、また負荷を分散することでシステムダウンを回避させるシステム）として認識させることになる。

　そこでポイントとなるのが、現在処理中のセッションがノードを切り替えた際（フェイルオーバー時）に切断されることなく他ノードに引き継がれるか否かということである。これはコマースサイトでは非常に重要な点である。メンテナンス目的のフェイルオーバーによってユーザーの処理中のセッションが切断されたのでは、クラスタリング構成を取った意味合いが薄れてしまう。さらに、ユーザーからのクレームを受けることにもなる。

　セッションが維持されるためには何が必要か？ セッションが維持されるためには、各ノードが処理しているセッション情報を、クラスタシステムを構成するノード間で共有する必要がある。一般的に、ステートフルインスペクション技術を採用しているファイアウォールには、他ノードとの間でセッション状態情報（ステートテーブルという）を共有する機能が組み込まれている。

　これに対しアプリケーション・ゲートウェイのアーキテクチャに基づくファイアウォールでは、ユーザーセッションをファイアウォール上のプロキシが中継することにより通信しているため、すべてのセッション・コンテキストはそのプロキシプログラムで管理される。

　そのためクラスタ内のノード間でセッション情報を共有できず、フェイルオーバー時には処理中のセッションが切断され、ユーザー側で再接続作業が必要となる。

　しかし、ステートフル・インスペクションの状態情報の共有に問題がないわけではない。例えば、ネットワーク上を流れるトラフィックが急激に増大した場合や高速ネットワークに接続された場合などは、ノード間での状態情報を共有する処理に遅延時間が発生する。

　共有処理もある時間間隔で実行されるため、共有が完了する前にフェイルオーバーが実行されてしまうと当然そのセッションは切断されてしまう。

　また、トラフィックの増大でも同様な現象が考えられるため、セッション状態情報の共有を実行するネットワークセグメントには専用のセグメントを利用する必要がある。

　さらに、ファイアウォールの前後のネットワークに使用する回線の速度も考慮する必要がある。例えば、ギガビットのネットワークを使用する場合は、共有用のネットワークには100Mbpsを使用することである。

●クラスタシステムの構成タイプ

　現在のファイアウォールが持つハイ・アベイラビリティ機能は、ホットスタンバイ型が多い。ホットスタンバイ型は、一般に2台のノードで構成され、その中の1台が実際にトラフィックを処理するアクティブノードとなり、ほかの1台がスタンバイノードを構成する。そして、アクティブノードに障害が発生した場合は、スタンバイノードが処理を引き継ぐというシステムである。

　結局のところホットスタンバイ型ではクラスタシステムが複数台で構成されていても実際の性能は1台の性能しか利用できない。

　それに対して、すべてのクラスタノードがトラフィックを負荷分散しながら動作するロードバランシング型を採用しているものがある。例えばストーンソフトのFirewall／VPNなどがある。Firewall／VPNが採用したロードバランシング技術は、サードベンダファイアウォール製品のハイ・アベイラビリティソリューションとして知られているStoneBeatの技術を使用しており、求める可用性のレベルに応じてロードバランシング型とホットスタンバイ型を選択して構成することが可能である。

　ここで、ロードバランシングの方法について説明する。

負荷分散装置（LB）が、入力されたパケットのIPヘッダ情報とファイアウォールのステータスによりパケットの転送先を決定する。	入力されたパケットのIPヘッダ情報とハートビートネットワーク を経由してやり取りされるクラスタステータスに基づき、各ノードが分散アルゴリズムを使用して自律的にパケットを処理する／しないを決定する。
図3 ディスパッチャ型と自立型負荷分散方法

　例えばFirewall／VPNが採用しているロードバランシングは、「自律型負荷分散」である。つまり、各クラスタノードにはプライマリといった特別なノードは存在せず、個々のノードが入力パケットのIP情報とその時点でのクラスタシステムの負荷状態を基に自分自身でそのパケットを処理すべきか否か判断するのである。

　一方、アルテオンをはじめとするハードウェア負荷分散装置は、「ディスパッチャ型負荷分散」である。負荷分散装置は、ファイアウォールを挟み込むように両側のネットワークに配置される。パケットは、1度負荷分散装置が受け、その背後に存在するファイアウォールノードのステータスに応じてそのパケットを分配する。パケットの転送先を決定するアルゴリズムの特徴には、ラウンドロビン、重み付けラウンドロビン、最も接続処理数が少ないなどのことが挙げられる。

　ディスパッチャ型で注意すべき点は、負荷分散装置に不具合が発生するとシステム全体が動作不可能となるため、負荷分散装置自体を2重化する必要があるということである。

●クラスタシステムにおける障害検知

　クラスタシステムで重要な点は、構成するノードの異常を迅速に検知し、そのノードをトラフィック処理の対象から外すことである。そのためには、ノードをモニタする機能が装備されている必要がある。ここでは、ファイアウォールが稼働しているシステムのモニタ機能について自律型とディスパッチャ型の両者を比較してみる。

ファイアウォールノードの監視は、負荷分散装置（LB)が外部からPINGなどを使用して実行する。	ファイアウォールノードの監視は、システムに常駐するエージェントが内部からハードウェア／オペレーティングシステム／ファイアウォールに対して実行する。
図4 ディスパッチャ型と自律型のクラスタノードの監視方法

　ディスパッチャ型の負荷分散装置では、アプリケーションが稼働しているシステムを外側から監視する。例えば、PINGや特定のアプリケーションプロトコル（HTTPなど）要求を疑似的に発行してそのレスポンスをみてノードを監視する。

　それに対して、自律型では負荷分散機能が、ファイアウォールが稼働しているシステムに常駐しているため、そのシステムの状態を詳細にモニタすることが可能である。例えば、ファイアウォールの動作に必要なプロセスが稼働しているか否か、ログ収集のための空きディスク容量チェックやスワップ領域のチェックなどが組み込まれている。

　ファイアウォールの可用性を実現するためのソリューションも多岐にわたっている。ファイアウォールの選定と同様、その環境に求められる可用性がどのようなレベルなのかをよく理解し、最適なソリューションを導入することが重要である。

「ファイアウォールとIDSによりセキュリティを高める」へ

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

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

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

Security&Trust記事一覧

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