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

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

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

　DMZ上に設置するアプリケーションサーバはファイアウォールと侵入検知システム（IDS）を併用することによってセキュリティを高めることが可能である。

　それでは、ネットワークの入り口であるファイアウォールはどのように攻撃から防御するのか？ ファイアウォールを守る方法として、1つはネットワーク型IDSをファイアウォールの前段に設置する方法がある。

　しかし、ネットワーク型IDSでよく議論される問題として、トラフィック増大や高速ネットワークの場合には検出能力が大幅に低下するという点がある。さらにファイアウォール防御のためには検出するだけでなくその事象に対するアクションまで完了しなければ意味がない。そのため、IDSとファイアウォールの連携ソリューションでは、対応しきれない場合が多い。

　また、もう1つの方法として、アプリケーションサーバが稼働しているシステム自体に導入して、そのシステムの入出力パケットを監視できるハイブリッド型IDSを使用することも考えられるが、ファイアウォールのインスペクションを実現する仮想ドライバとIDSの仮想ドライバとの間で不具合が生じる場合が多い。

　このような点から、ファイアウォール自体がIDS機能が実現されていることが望ましい。例えば、マイクロソフトのISAやネットスクリーンのNetScreenでは、ファイアウォール自身でDos攻撃を検知し、対応できる機能を持っている。例えば、“SYN Floods”、“ICMP Floods”、“Port Scan”などの攻撃に対応している。

障害発生時の問題を解消するマルチホーミング

　今年は“ブロードバンド”元年といってもいいほど、高速かつ格安のネットワークサービスが利用できる環境が整備された。それによりかねて企業ネットワークにおいて懸案とされてきた回線やISPの障害発生時にインターネットが、利用できなくなる問題などを解消する“マルチホームネットワーク”のための環境が整いつつある。

　しかし、マーケットのファイアウォールのほとんどは、マルチホーミングに対応した機能は持っていない。そのため、相手先を固定した経路情報によって実現したり、アプリケーションプロキシを利用したり、さらには、ラドウェアのLinkProofのようなハードウェアベースの回線負荷分散装置を組み合わせる必要があった。

　LinkProofの場合、社内からインターネットへの通常のアウトバウンド接続であれば複数の回線を負荷分散して利用することが可能であるが、将来必要性が考えられるインターネットVPNの負荷分散には対応できない。それは、VPNトンネルは、End-to-Endで確立される。End-Pointはファイアウォールであり、LinkProofはその性格上ファイアウォールの前段に設置されるため、トンネルのSA（Security Association）情報を参照することができないからである。

　また、ハードウェア装置であるため装置自体の2重化が必要である。

　最近、マルチホーミング環境に対応したファイアウォールが発表されている。「マルチリンク・テクノロジ」を採用して、マルチホーミング環境において通常のトラフィックに加え、VPNの負荷分散及びフェイルオーバーを実現したFirewall／VPNなどもある。

　では、マルチリンク・テクノロジがどのように複数回線を選択するかを説明する。

ファイアウォールが認識する3つの回線を使用して、ターゲットにTCP-SYNを送信する。SYN／SYN-ACKのRound-Trip-Time（RTT）を監視することにより、その時に最もパフォーマンスが良い回線を選択する。選択された回線情報はある期間キャッシュされる。

図5 アウトバウンド通信のためのロードバランシング

　図5では、ファイアウォールは3つの回線と接続していることを認識している。その際に各ISPから個々にグローバルアドレスをアサインされる。ローカルネットワーク上のクライアントからインターネット上のWebサーバに対してアクセス要求が発生した場合を考える。

　TCPプロトコルの場合、ファイアウォールは3つの回線に対してSYNパケットを送信する。このときクライアントから送信されたパケットの送信元IPアドレスは、個々のISPから割り当てられたグローバルアドレスに自動的にアドレス変換されて送出される。

　Webサーバはそのリプライとして、SYN-ACKパケットを送信する。ファイアウォールはWebサーバから返信される3つのSYN-ACKパケットのRTT（Round-Trip-Time）を監視し、最もレスポンスが良い回線を選択し、キャッシュ時間中は同じ相手先に対しては同じ回線を使用する。

　以下の図6では、「マルチリンク・テクノロジー」をインターネットVPNに応用した例である。この技術をインターネットVPNに応用したのが、マルチリンクVPNロードバランシングである。

	Site A-B間のVPNトンネルは、4本の論理トンネルから構成される。パケットは4本の論理トンネル間でロードバランシングされる。
図6 マルチホーミング環境におけるVPNの負荷分散

　図6の下図のように、Site-Aが2つの回線、Site-Bも2つの回線を使用する場合、Site A-B間で確立される論理トンネルは4本となる。Site-AからSite-Bへ通信が発生するとファイアウォールが最速のトンネルを選択してパケットを送出する。従って、回線速度に変化が生じるとパケットは別のトンネルを使用して送出されることになる。これはセキュリティの観点からも非常に強固な秘匿性を実現している。

　今後、xDSLを複数使用したマルチホーミング環境を利用したネットワークインフラストラクチャを構築するケースが多くなると思われる。現に、キャリアが提供するIP-VPNネットワークのアクセス回線としてxDSLを利用できる。その場合、品質およびサポート面で充実した専用線から回線速度の安定性やサポート面がやや劣るxDSLに乗り換えることになるため、回線に対する冗長性は必ず検討される項目である。

ファイアウォールが持つべきロギング機能

　ファイアウォールの重要な機能にロギングがあるが、蓄積されたログ情報を何％の管理者が参照しているのか？ おそらく半数以上が参照していないと思われる。参照しない（できない）理由としては、ログ情報が膨大であり、大量の情報から重要な事象を抽出することが困難である、といったところであろう。

　ログ情報の収集に関しては、どのファイアウォールも同様な実現方法を取っている。ファイアウォールエンジンと管理サーバ（あるいはSYSLOGが動作しているシステム）間でログ情報を送受信する。つまり、ネットワーク経由でログ情報を送受信することになる。

　この実現方法で注意すべき点は、リモートのファイアウォールエンジンを管理する場合、ログ情報の通信に消費されるネットワーク帯域と、仮にエンジンと管理サーバ間の通信ができない場合にエンジンがどのような動作をするのかである。ログ情報でネットワーク帯域の大部分が使用されていては本末転倒であるし、管理サーバをメンテナンスのために停止した際にエンジン側でロギングされ、エンジンのリソースが満杯になった際にファイアウォール自体が停止してしまうケースもあるからである。

　ロギングに関してファイアウォールが持つべき機能として、定義したルール単位にログ情報を作成するか否かの設定が行えることが最低限でも必要である。例えば、NetBIOSは通常拒否するプロトコルであるが、ネットワーク上にWindows系のシステムが存在する場合に際限なくログ情報が生成されるが、管理者にとってはまったく無意味な情報である。

　ログ情報自体は、テキストファイルあるいはデータベースに格納される。テキストファイルに格納された場合は、そのままで解析作業を行うことは困難であるため WebTrendsのようなファイアウォール専用のログ解析ルールを使用すると便利である。例えば、WebTrendsを使用すると以下のような集計レポートを作成してくれる。

ファイアウォールを通過したアドレス

プロトコル別 利用数／帯域占有率

アドレス別 利用数／帯域占有率／データ転送サイズ／コスト

イベントタイプ別 サマリ／詳細

　データベースに格納した場合のアドバンテージとしては、ログ情報の参照・検索処理を迅速に行うことができる。さらに、データベースから必要な情報のみをCSV形式で抽出し、表計算アプリケーションを利用して解析することも可能。また、定期的に必要な情報のみを外部ファイルとして抽出・アーカイブしておくことも可能である。

　しかし、一番重要なのはツールを使用して集計した結果を的確に理解して、ファイアウォールの動作環境にフィードバックする分析作業である。

最後に

　今回（前、後編）の記事では、ファイアウォールを導入する際に何に基づいて選択すればよいかに関して、前編では主にセキュリティを実現するアーキテクチャを中心として、後編ではファイアウォールに求められる付加機能をいくつか紹介して説明した。

　しかし、実際にはここで紹介した機能以外にも必要なものは存在する。例えば、QoS機能、マルチポリシー、リモート管理、VPNなどである。結論として、“何がしたいのか”といった目的を明確にしてファイアウォールを選択することに尽きると思う。これらに関しては、また後日語ることにする。最後に、この記事が読者の方に少しでもお役に立てれば幸いである。

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

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

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

Security&Trust記事一覧

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