セキュリティ・ベンダーである米Internet Security Systems(ISS)は米国時間3月14日,侵入検知システム (IDS) を混乱させ無効化するというツール「Stick」を警告するアドバイザリ(「"Stick"- A Potential Denial of Service Against IDS Systems」 )を公開した。しかしながら,“ネットワークの見張り番”ともいうべきIDSが,そんなツール一つで簡単に混乱させられてしまうのだろうか---。この疑問に答えるべく,今回のコラムではStickについて解説したい。

狙われる“ネットワークの見張り番”

 Stickの話をする前に,まずIDSについて簡単に説明しておこう。IDS には,大きく分けて「ホストベースIDS(HIDS)」と「ネットワークベースIDS(NIDS)」の2方式がある。

 HIDSは文字通りホスト(マシン)ごとにインストールされ,以下のプログラムが出力するログ・ファイルを監視する。

  • オペレーティング・システムやアプリケーション
  • オペレーティング・システムで実行している監視プログラム(BSM,TCBなど)
  • IDS が持っている監視用のプログラム

 そして,これらのログ・ファイル中に特定のイベントによって発生する異常な形跡を発見したら,電子メールを送信したりポケベルを鳴らしたりしてサイト管理者に通知する。

 HIDSがホスト単位で監視するのに対し,NIDSは保護すべきネットワーク上の通信を監視する。そして通信内容を解析し,攻撃などの特定の通信で発生する異常なパターンを発見したらユーザーに通知する。

 攻撃者にとっては IDSほど厄介(やっかい)ものはない。特にNIDSは手強い。ポート・スキャンなどを行えばほとんどの場合検知され,攻撃元のIPアドレスも判明してしまう。そのため,サイト管理者は境界ルーターなどでその IP アドレスからの通信をすべて遮断するような対策をとることが可能である。また,攻撃対象のポート番号も分かるので,どのサービスを狙った攻撃なのかも明らかにできる。

 セキュリティ・レベルの維持には頼りになるNIDS。このNIDSを混乱させるのがStickなのである。

“本当の攻撃”を隠蔽する

 NIDSで監視されているネットワークへの攻撃を成功させるために,まず考えつくのが,「NIDSに検知されないように攻撃する」ことである。実際にそうした試みは今までに数多く行われている(「A look at whisker's anti-IDS tactics」)。しかしStickは,これとはまったく逆の手法で攻撃する。NIDSが検知するような異常なパターンをわざと大量に送信するのだ。

 Stick開発者のWeb ページで説明されている内容によれば,有名なフリーのNIDSプログラム「Snort」の「ルールセット」を使用して,NIDSに検知されるようなパターンを生成するという。ルールセットには,攻撃などの特定の通信で発生する異常なパターンが複数定義されており,そのルールセットと通信内容を比較してSnortは攻撃を検知する。

 Stickは,Snortのルールセットに定義された「検出されるための情報」を大量に送信して,NIDSに偽の警告通知を多数発生させる。この状況下で,攻撃者が本当の攻撃をしても,警告通知を受け取るサイト管理者は,どの通知が本当の攻撃によって発生した通知なのか分からない(Stick 開発者はこれを「information overload」と呼んでいる)。Stickを使えば“見張り番”であるNIDSを単なる“オオカミ少年”にできるのだ。

 ただしここで問題がある。いくら検出されるための攻撃といっても,NIDSを使えばその攻撃元を突き止められてしまう。そこでStickは「IP Spoofing」という攻撃手法を用いている。IP Spoofingとは,別のIP アドレスを持ったホストになりすまして通信する攻撃手法である。Stickは,IP Spoofingを組み合わせることで攻撃元を分からなくする。

サービス妨害ツールにもなる

 上述のように,Stickは攻撃を隠蔽するために設計されたツールである。加えて,NIDSをサービス不能状態に陥れることも可能である。Stickによる攻撃で,NIDSは大量の攻撃検出処理を強いられることになる。この処理の負荷により,NIDSが稼働するマシンのCPU 使用率は100%になり,NIDSが停止する可能性がある。

 Stickの開発者がIDS関連のメーリング・リスト「FOCUS-IDS」に投稿した内容によれば,Snort を実行させているLinuxベースのホストに Stick を使用したところ,CPU 使用率が 100%になり,パケットを処理しきれなくなったという。また,米ISSのRealSecureについては停止させることができたという(http://www.securityfocus.com/archive/96/167232)。このように,サービス妨害ツールとしても成り立ってしまうStick は,攻撃を隠蔽するというその目的以上のことが可能なのだ。

“おとり”に惑わされずホストを守れ

 Stickのような「おとりを利用したかく乱」への対策は非常に難しい。たとえファイアウオールに保護されたネットワーク・セグメントにNIDS を設置しているとしても,同じセグメントに外部からアクセス可能なサーバーが置いてあれば,そのサーバーに対してStickを使用され,結局はかく乱されてしまう可能性が高い。

 「ステートフル・インスペクション」*1のような高度な技術を用いたファイアウオールであっても,残念ながらかく乱の発生を最小限に抑制することしかできない。National Infrastructure Protection Center(NIPC)が公開している「Intrusion Detection Systems Exploit」という報告はこのことを物語っている。

 とはいえ,「おとりを利用したかく乱」を過度に恐れる必要はない。セキュリティの観点からは,保護対象のホストに侵入させないことが最も重要なことだからである。たとえ,おとりの攻撃によって NIDS がかく乱されてしまっても,対象ホストを侵入から守ることができればよいのである。

 そのためには NIDS 一つに頼り過ぎないことが重要だ。例えば,前述の HIDS を保護対象のホストで稼働させていれば,NIDSがかく乱されようとも侵入をいち早く検知できる。そして,保護対象のホストに十分な対策を施してさえいれば,検知することができなくても侵入を防ぐことは可能である。つまり,セキュリティを高めるためのアプリケーションを適切な設定で複数利用し,ホストそのものを「要塞化」するという統合的なネットワーク・セキュリティを施すのである。そうすれば,Stickによるかく乱戦法も無力化できるのだ。

 今回登場したStickのように,既存の製品や技術のウラをかく攻撃手法やツールが今後も現れる可能性はある。いくら「統合的なネットワーク・セキュリティを施せば大丈夫」といっても安心はできない。こうした情報やソフトウエアのぜい弱性に関する情報に,サイト管理者は絶えず目を光らせる必要がある。

◇ ◇ ◇ ◇ ◇ ◇

*1: 一般的なパケット・フィルタリング型ファイアウオールでは, OSI 参照モデルで言うところのアプリケーション層の情報までは認識することができない。しかし,ステートフル・インスペクション技術を使用すれば,パケット・フィルタリング型でもファイアウォールを通過する通信のすべての階層の状態をチェックすることができる。つまり,保護したいと考えている複数のネットワーク・サービスに対して,別々のプロキシを必要とせずにアプリケーション層の情報まで認識することができる。より詳細な情報に関しては以下の URL を参照されたい。

[Stateful Inspection Technology]
[Application Gateways and Stateful Inspection]


新井悠 (ARAI Yuu)
株式会社ラック コンピュータセキュリティ研究所
y.arai@lac.co.jp


 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。