ネットワーク侵入検知システム用アラートフィルタの性能評価

加藤 高男1, 塙　雅典2，田中 雅貴3，杉山 仁4, 中村 一彦2

1山梨大学 大学院 医学工学総合教育部 工学領域 修士課程 電気電子システム工学専攻
2山梨大学 大学院 医学工学総合研究部 工学学域 情報システム工学系
3株式会社カルク MSPグループ 監視センタ
4 山梨大学 総合情報処理センタ

 

１．  はじめに

　近年インターネットは, IP電話や携帯電話によるWebページ閲覧などでも利用され, 様々なサービスが展開されている. 一方でアカウントを持たないユーザが,　ネットワーク経由でサービスを提供しているコンピュータに不正にアクセスする行為(以下「不正侵入」, または単に「攻撃」と記す)が重大な問題となっている. 不正侵入の多くは, サービスを実行するオペレーティングシステム(以下「OS」)やアプリケーションプログラムの脆弱な部分(以下「セキュリティホール」)を探り当て, 攻撃プログラムを実行することで侵入を果たす. 一般にセキュリティホール対策は, ベンダが用意する修正プログラムをインストールすることで行われるが, セキュリティ対策への認識が乏しいユーザは的確な対策を行っていないホストをネットワークに接続し, そのホストを通じて不正侵入を許してしまっているのが現状である. また, セキュリティ対策は多大な労費を伴う反面収益を生ないため, 多くの企業では情報システムの運用管理者が兼務している報告[1]もある. このため, 不正侵入に対する安全かつ簡易な対処方法が求められている.

 著者らは昨年の山梨大学総合情報処理センタ研究報告において, ネットワーク侵入検知システム(以下「NIDS」)であるSnort[2]が発するアラート警告から, 真に危険なアラートのみを抽出するRealAlertシステム[3]について報告した. そこでは, RealAlertシステムの試験運用結果として2006年2月19日から3月12日までの結果を示し, 発生した様々なアラートから無用なアラートをフィルタリングできたことを確認した. しかし実験期間中に発生したアラートは一つも危険に結びつくものがなかったため, 最も注目する「真に危険なアラート(不正侵入)情報」だけが抽出できるか否かを確認出来なかった. また監視対象クライアントの修正プログラムの導入検査では, 修正プログラムの導入手順によっては正確に判別できないものが存在していた. そこで今回, 修正プログラムの導入状況の検査法を改善し, 疑似攻撃コードの実行によって真に危険なアラートに対するRealAlertシステムの動作確認を行ったので報告する.

 

２．  RealAlertシステムの概要[3]

　RealAlertシステムはWindows系OSをターゲットとし, 監視ネットワークに存在するクライアントコンピュータに対する膨大な不正侵入の試みの中から, 真に危険な攻撃だけを抽出してネットワーク管理者に知らせるアラートフィルタリングシステムである. この機能を実現するために, 各クライアントコンピュータにインストールされている修正プログラムの導入状況を事前に検査しておき, 監視ネットワーク上を流れるパケットを監視しているSnortが攻撃を検知した際に発するアラートと, 攻撃先となるクライアントコンピュータの修正プログラムの導入状況を結びつけ, 実際に影響を受ける「真に危険な攻撃」のみをネットワーク管理者に通知する(図1).

図1: RealAlertシステムによるSnortアラートの危険性判別方法

 

　事前に行われる修正プログラム導入状況の検査では, 既知のセキュリティホールに対する修正プログラムの有無により, 修正プログラムがインストール済みである「適用済」, インストールしていない「非適用」に分けて判別している. そして, これらの検査結果はRealAlertのデータベースに登録され, 当該ホストに対して攻撃が行われた場合, RealAlertシステムはSnortが発するアラートと検査結果をつき合わせて攻撃の危険性判別を行う. 即ち, 修正プログラムが導入済のクライアントへの攻撃に対しては, 単に攻撃があった事実を記録するに留め, 未導入のクライアントへの攻撃に対しては, ネットワーク管理者に対し監視用Webページへの表示とメール送信によって通知する. また上記2つの判別以外で, Snortが検知した攻撃がWindows系の脆弱性を突くものであっても, 修正プログラムの導入状況が判別できなかったクライアントへの攻撃を「警告」と称し, 監視用Webページに別途表示し, 管理者の判断に委ねている.

 

３．  修正プログラムの導入状況の検査法改善

 昨年までRealAlertシステムは, 監視クライアントの各セキュリティホールに対する修正プログラムの有無を, 修正プログラムがインストールされることにより登録されるレジストリキーで判別を行っていた. またこのとき検査するレジストリキーの情報は, 図2のようにマイクロソフト社のWebページ[4]に記載されているレジストリキーを基にしていた. しかしこの方法では, 適用する修正プログラムをインストールする順序によって正確に判別できないものが存在していた.

図2: レジストリキーの記載例

図3: セキュリティホールに対する修正プログラムの適用状態

 

図3はあるセキュリティホールに対し, 修正プログラムA, 後の更新で修正プログラムAに置き換わる修正プログラムB, もしくは両修正プログラムをインストールした場合を示している. この3通りともセキュリティホールに対する攻撃を防ぐことができる. しかし, クライアントコンピュータにはインストールした修正プログラムに対応するレジストリキーしか登録されないため, 修正プログラムBのみを適用した場合は, 修正プログラムAに対するレジストリキーが登録されない. 従来のRealAlertシステムでは, セキュリティホールに直接対応する修正プログラムしか検査していなかったため, 修正プログラムBしか導入されていない場合には導入状況検出が正しく行えなかった. 例として表1にマイクロソフト社のWebページで記されたMS04-011の場合を述べる.

表1: MS04-011に対する修正プログラムで対処できるセキュリティホール

MS04-011に対する修正プログラムには, 表1に示すようにマイクロソフト社製品のセキュリティホールに一意につけられたIDであるセキュリティ情報番号(以下「Bulletin ID」)への修正プログラムが含まれている. このためアップデートをする際, MS04-011に対する修正プログラムのみがインストールされ, それ以前に適用された修正プログラムはインストールされず, レジストリキーも登録されない.

一方, マイクロソフト社はセキュリティ対策状態の検査ツールであるMicrosoft Baseline Security Analyzer[5](以下「MBSA」) を提供している. MBSAは図4に示す手順に従い, 修正プログラムの実体となるファイルの存在及びバージョンの比較によって修正プログラムの有無の判別を行う.

図4 : MBSAの検査方法例

 

このとき修正プログラムは上記で説明した様に, 後の更新で置き換わる修正プログラムBが提供される場合がある. この場合, 修正プログラムAで導入された更新ファイルに対し, 新たな修正を加えファイルバージョンが更新された同ファイルが導入される. このため図4のように更新ファイルのバージョンを比較することで, 過去クライアントコンピュータに導入された修正プログラムの有無も検査することができる. MBSAではBulletin　ID毎に適用されたファイル及びバージョン情報等がリストアップされたファイルを別途用意している. そこで, 従来のWebページからの情報取得に代わり, MBSAが検査において利用するリストファイルを採用した. この検査リストの情報をサーバのデータベースに登録しておき, 図5の手順で修正プログラムの有無の検査を行うようにした.

図5: 修正プログラムの導入状況検査の手順

修正プログラムの導入状況の検査では初めに, 監視対象クライアントコンピュータのOSやアプリケーションのバージョン情報等をレジストリキーから得る. その情報をサーバに通知し, サーバ側で検査に必要なファイル情報「検査項目リスト」を組み立てる. このとき検査に必要な情報とは, 図6に示すようなマイクロソフト社が提供するソフトウェアに対するBulletin IDと, そのセキュリティホールを修正するファイルの名前及びパス, そしてファイルのバージョン情報である. クライアント側は検査項目リストをサーバからダウンロードし, 更新ファイルの有無やバージョンを比較し, 適切な修正プログラムの有無を判断する.　この検査結果は, サーバに送られデータベースに登録される.

図6: ある脆弱性の検査ファイル情報例

 

RealAlertシステムは, 上述の手順によって得られた監視対象クライアントコンピュータに対する修正プログラムの導入状況の情報とSnortが発するアラートをつき合わることで攻撃の危険性判別を行う. この危険性判別で「警告」と判定された場合は, 上述の修正プログラム導入状況検査処理の対象外アプリケーションに対するセキュリティホールへの攻撃と考えられる. これらに対しては, 別途レジストリキーを手動で追加することで対応可能となっている.

 

４．  実験環境

現在RealAlertシステムを運用している実験環境を図7に示す.

図7: RealAlertシステムを運用している実験環境

実験環境は, 山梨大学総合情報処理センタからクラスCサブネットを借用し構築した. また昨年では, 監視ライアントをVMwareによる仮想環境の下で, 1台の監視クライアントコンピュータ上に仮想的にクライアントコンピュータを4機に見せかけて実験していたが, 実際にコンピュータを4機用意した. OSは昨年と同様Windows 2000, Windows XPとし, それぞれOSをインストールしたままの状態と, Windows Updateをかけ適用される修正プログラムを全てインストールした状態のもの, 計４機を使用した. また監視クライアントコンピュータが実際に攻撃を受けた際, 外部ネットワークのコンピュータを2次的に攻撃できないようにFirewallを2重に設置し安全性を高めている. 各Firewallの設定は, 外部ネットワークからのパケットは全て許可するものの, 監視クライアントからのパケットはICMPを除き全て遮断するように設定している. そして内側のFirewallにSnort(133.23.xx.2)を運用し, 同ネットワーク上にコンピュータ(133.23.xx.4)を設置し, このサーバでRealAlertシステムを運用している.

 

５．  RealAlertシステムのアラート判別の性能評価

 Snortを含めたRealAlertシステム全体を運用実験した結果を表2に示す. 表2は2006年の10月から11月の2ヶ月間に発生したSnortアラートと, RealAlertシステムによって危険と判定されたアラートの総数を示している. クライアントAを除きSnortは千を超えるアラートが発生しているのに対し, RealAlertシステムのアラートは全て0件であった. つまり実際に危険な攻撃は発生しなかったといえる. この期間に発生したアラートを詳細に確認すると, 主としてLinuxサーバを対象とした攻撃が多く, Windowsの脆弱性を狙った攻撃は少なかった. また, Microsoft SQL Serverの脆弱性を狙う攻撃も少数発生していたが, 現在Microsoft SQL Serverのアプリケーションに対する脆弱性を検査していないため「警告」と判別されていた. この結果は昨年の報告と同様に, 実際に危険と結びつくアラートは1件も発生しなかった. これは, 総合情報処理センタの指示で設置したファイアウォールのために外部から試験用サブネットへのTCP接続が確立できず, UDP経由の攻撃に限定されていることガ理由である. このため本環境における通常運用試験を通じては, RealAlertシステムによるSnortアラートの危険性判別の可否を確認できなかった.

表2: 2006年10~11月の2ヶ月間のSnortとRealAlertのアラート総数

 

　次に試験用サブネット内から擬似攻撃を実施して, RealAlertシステムによる危険性判別の評価を行った. ここではBeyond Security[6]のSecuriteam[7]によって報告されている疑似攻撃コードのの中から, ネットワーク経由で攻撃を行うコードを使用した. 今回の擬似攻撃によって影響を受ける脆弱性を表3に示す. これら全6種類の擬似攻撃を実行し, 意図的にSnortアラートを発生させた.

表3: 擬似攻撃により影響を受けるセキュリティホール

 

これらの攻撃に対する監視対象クライアントコンピュータの修正プログラムの導入状況検査結果を表4に示す. 表4は擬似攻撃によって影響を受けるセキュリティホールに対し, 修正プログラムが適用済みを「有」, 非適用を「無」, MBSAがセキュリティホールとしてサポート対象外のもの「対象外」と示している. 表4からクライアントBは全ての修正プログラムが有ると判別され, クライアントDは上記3つのセキュリティホールに対し修正プログラムが有ると判別された. またクライアントCは下記3つのセキュリティホールに対し修正プログラムが無いと判別された.

 

表4: 各監視クライアントコンピュータの修正プログラムの適用状況

 

表5: 擬似攻撃によって発生したアラートの危険性判別結果

続いて擬似攻撃によって発生したアラートの危険性判別した結果を表5に示す. 表4と比較すると, クライアントC, Dへの攻撃は, 修正プログラムがインストールされているものは全て「安全」と判定できていることが確認できる. 逆にクライアントCへの攻撃は, 修正プログラムがインストールされていないものは全て「危険」と正確に判別できていることが確認できた.

今回実行できた擬似攻撃は上記6種類のみであったので, それ以外のアラート判別結果を評価するために擬似アラートの危険性判別を行った. 擬似アラートとは, Snortのアラート警告のどのような攻撃があったかを表す「Signature ID」を意図的に付加し, 作製したアラートである. この擬似アラートによってSnortでの処理を省き, かつ任意のアラートをRealAlertシステムで評価することが出来る. そのためRealAlertシステムのアラート判別結果を不定期に実行される攻撃を待つことなく得ることが出来る. 今回評価した擬似アラートはSignature IDとBulletin IDが結びつくアラートを使用した. 但しある1つのBulletin IDに対し, 複数のSignature IDが登録されているものが多数存在したため, 1つのBulletin IDに結びつく1つのSignature IDを意図的に選択し, 対応付けた. 表6に擬似アラートをRealAlertシステムによって評価した結果を示す.

 

表6: 擬似アラートを評価した結果

 

表6は左から各年毎のBulletin ID, 評価した擬似アラートの年代ごとの総数, そして各監視対象クライアントにおいて, クライアントA, Cは「危険」, クライアントB, Dは「安全」と判別できたアラートの総数, 「警告」と判別されたアラートの総数の順に示している. 表6から判別できたアラート数に対し, 「警告」と判定されたアラート数が非常に多いことが確認できる. 先の擬似攻撃によるアラート判別結果では, 修正プログラムの有無が判別できているセキュリティホールに対しては正確に判別できていることが確認できたが, 表6から危険性の判別が出来ているBulletin IDはごく一部であると捉えることができる. これが現在RealAlertシステムの最大の課題であると考えている. またMS03の擬似アラート数に対し, 「警告」を含め判別できたアラートの総数が異なる結果が得られた. この原因は, アラートの危険性を判別する時のSignature IDからBulletin IDを結びつける際に, 複数のBulletin　IDが候補に挙がってしまうためであった. 通常はSignature ID対Bulletin IDは1対1に結びついている. しかし, この対応が成り立たないため, 結果として他の脆弱性に対する修正プログラムの有無でアラートを判別してしまっていた. 今後はこの正確に判別できないアラートをなくすと共に, 警告アラートの数を減らしていく必要がある.

 

６．  まとめ

 Snortが発するアラートに対し, その危険性を自動で判別するRealAlertシステムにおいて, 監視クライアントコンピュータに対する修正プログラムの導入状況の検査法改善について説明した. また擬似アラート及び擬似攻撃によるRealAlertシステムのアラート判別処理の動作確認を行った. 擬似攻撃の実行では, 修正プログラムの有無でアラートの危険性判別を正確に出来ていることが確認できた. しかし, 擬似アラートの実験結果ではアラートの危険性判別を正確に行えていないアラートの存在と, セキュリティパッチの有無を判別できていない多数の警告アラートが確認された. 今後は, 正確な修正プログラムの有無の検査による警告アラートの削減, 実環境での実験, オープンソース化を目指していきたい.

 

謝辞

 RealAlertシステムの試験運用環境の構築にご配慮頂いた山梨大学総合情報処理センタ長に深く感謝いたします.

 

参考文献

[1] 総務省, 情報セキュリティに関する実態調査,

http://www.soumu.go.jp/s-news/2004/pdf/040705_2_bt.pdf

[2] Snort - the de facto standard for intrusion detection/prevention,
http://www.snort.org/

[3] RealAlert, 真に危険な不正侵入情報のみを抽出するアラートフィルタリングシステムの開発,

　　　http://sojo.yamanashi.ac.jp/ipc/bul/final05/hanawa/index.html

[4] Microsoft Security Bulletin Search,
http://www.microsoft.com/technet/security/current.aspx

[5] Microsoft Baseline Security Analyzer (MBSA),
http://www.microsoft.com/technet/security/tools/mbsahome.mspx

[6] Beyond Security,

    http://www.beyondsecurity.com

[7] SecuriTeam,

    http://www.securiteam.com