論 文

Session Based IDS の設計と実装

水谷 正慶

^†

白畑 真

^††

南 政樹

^†

村井 純

^†,††

The Design and Implementation of Session Based IDS

Masayoshi MIZUTANI

^†

, Shin SHIRAHATA

^††

, Masaki MINAMI

^†

, and Jun MURAI

^†,††

あらまし

ネットワークのトラフィックから，悪意のある通信を発見する手法の一つにNetwork Based Intrusion Detection

System(IDS)が挙げられる．しかし，既存のIDSは，攻撃が失敗したリスクの低いアラートと攻撃が成功した

リスクの高いアラートを同様に扱うため，アラート毎にリスク評価を行わなければ正しく検知できたことにはな らない．このことは、IDSの検知対象が増加するのに比例して、アラート毎のリスク評価のコストも増大するこ とを意味する．つまり、検知対象が増加し続けた場合、IDSによる効果的なネットワークインシデントへの対応 が困難になってしまう．

本稿では攻撃が行われた後の通信を継続的に監視することで，その応答から攻撃の成否を判断できる事に着目し た．このような継続的な通信をセッションと定義し，即時的かつ自動的にリスク評価を可能とするSession Based IDSを設計，実装した．また，これを実運用ネットワークにおいてその有効性の評価を行った．本研究により IDSの運用コストを低下させ，ネットワークインシデントの効果的な対応が可能となった．

キーワード インターネットセキュリティIDS過剰検知 リスク評価

1.

は じ め に

ネットワークのトラフィックにおける，悪意のある通 信を発見する手法の一つに

Network Based Intrusion Detection System(IDS)

が挙げられる．これは管理者 が管理するネットワーク内の特定箇所でトラフィック を監視し，攻撃を検知するシステムである．攻撃の可 能性が高いトラフィックが発見された際に，それを記 録し管理者に通知する事でインシデントの対応を促す．

IDS

は統計情報などから異常を検知するアノーマリ型 と，攻撃時の通信のパターンが記述されたシグネチャ を用いたシグネチャ型の

IDS

の二種類に分類できる が，本稿ではシグネチャ型の

IDS

をとりあげる．

IDS

は様々な攻撃をアラートとして検知するが，同 様の攻撃を意味するアラートであっても攻撃の結果が 成功か失敗かによって，脅威となるか否かが異なる．

実際に検知されるアラートは以下に挙げる脅威とはな らない攻撃が大部分を占めている．

†慶應義塾大学 環境情報学部

Keio University, Faculty of Environmental Information

††慶應義塾大学 政策・メディア研究科

Keio University, Graduate School of Media and Governance

a )

既に脆弱性についての対策を施してあるホスト への攻撃

b )

使用しているソフトウェアとは，異なるソフト ウェアの脆弱性を利用した攻撃

c )

適切に設定されているソフトウェアに対する 攻撃

一方で，不正侵入が成功した，またはウィルスに感 染した，などの脅威となるアラートも同様に扱われる．

このように，アラート毎に管理ネットワークに対する 脅威の度合が異なる．この度合を「リスク」とし，ア ラート毎に脅威となる可能性があるか調査することを

「リスク評価」と呼ぶ．

アラートは，攻撃の種類や数の増加に伴い，その数 が増加している．そのため，大量のアラートからリス クの高い攻撃を抽出するためにはなんらかの手法を用 いて全てのアラートに対してリスク評価をしなければ ならない．しかし，既存の手法では即時性，確実性，

規模性などにおいて十分ではない．そのため，運用コ ストが高くなり，効果的な運用が難しくなるという問 題点がある．

本稿では

IDS

が検知したアラートを即時的かつ確 実性の高い手法によりリスク評価することで問題の解

決を目指す．アプローチとしてネットワークを通じて なされる攻撃は，その結果により応答が変化する事に 着目する．そして，通信の内容を継続的に監視するこ とにより，攻撃の成否を判断する機構を提案する．こ れは，あらかじめ特定の攻撃に対し，攻撃が成功した 場合，あるいは失敗した場合にそれぞれどのような応 答があるかを設定することで，即時的，自動的に，精 度の高いリスク評価を可能とするものである．本稿で は，これを

Session Based IDS

として設計，実装し，

その評価を行った．

2.

既存のリスク評価手法

IDS

が検知したアラートのリスク評価において，既 存の手法・関連研究をとりあげ，その問題点について 述べる．

2. 1

内部からの攻撃の検知

攻撃者，ウィルスは不正侵入したホストを経由し，外 部のホストに対して攻撃する可能性が高い．そのため 内部から外部への攻撃を検知するシグネチャを用意し，

不正侵入の成功を検知する手法がある．

IDS

は脆弱性 やバックドアを利用した不正侵入，各ホストに対する 調査活動，ウィルスの感染活動などを検知することが できる．しかし，この手法では感染した直後，他ホス トへの感染活動を開始するウィルスやワーム

[2] [3] [4]

には有効だが，それ以外の攻撃についてはその限りで はないため迅速かつ正確な評価が困難である．

2. 2

継続的な通信の記録

IDS

の実装によっては攻撃そのものの検知だけでは なく，その後のトラフィックも継続的に記録し続ける ことができる．この機能は

Snort [1]

や

NFR [7]

にお いて実装されており，これをリスク評価の手がかりと して利用できる．しかし，検知されたアラートに対し て，その全てを検査しなければならず，管理するネッ トワークの規模の拡大，

IDS

が検知したアラート数の 増加によって運用コストが高くなってしまう．また，

知識の無い管理者は，通信の意味を理解できないため，

攻撃を検知した後のトラフィックから正確なリスク評 価をするのが難しい．さらに，豊富な知識があったと しても，人為的なミスにより誤判断，あるいは見逃し が起こる可能性がある．

2. 3 Target Based IDS

Target Based IDS(TB-IDS)

は管理対象のネット ワークに接続されている全ホストを調査し，ホストに ついての情報を得る．例えば，接続されているホスト

が使用している

OS

やアプリケーション，さらにその バージョン情報の取得により，各ホストが抱えている 脆弱性を判断することが可能となる．この脆弱性情報 と，

IDS

が検知したアラートの情報を組み合わせる ことで攻撃の成否を推定し，リスクが高いと考えられ るアラートを抽出することができる．例えば，特定の

OS

が持つ脆弱性を利用した攻撃であれば，それ以外 の

OS

を使用しているホストに対する攻撃は失敗した とみなせる．

この手法の欠点は，情報が得られるホストや，判別 ができるソフトウェアの種類が限られる点である．動 的にホストが接続されるネットワーク，特に不特定多 数のホストが接続される場合は，個別にホストで使用 しているソフトウェアの把握は困難であり，調査ツー ルなどを用いても判別できないソフトウェアは少なく ない．また，脆弱性があるとされるバージョンのアプ リケーションでも，修正パッチを適用して脆弱性を補 完している可能性がある．そのため，完全に状況を把 握することは困難であり，リスク評価が適切に行われ ない可能性がある．

また，多くの管理者はシステムを利用せずにネット ワーク内のホスト情報を把握し，リスクの高いものを 抽出するが，管理ホストの数に比例して作業量も増加 するため非常にコストの高い手法であると言える．さ らに，接続されているホストが動的に変化する場合や，

管理対象外のホストがネットワークに接続する場合で は，全ホストの情報を把握するのは困難である．

3.

解決すべき問題

3. 1 IDS

運用のコスト増加

第

2.

節であげた各手法では，

IDS

が検知したアラー トのリスク評価を適切かつ迅速に行うことは困難で ある．さらに，攻撃の種類の増加や，管理ネットワー クに接続されるホスト数の増加によって検知されるア ラートも増加する．

管理者はインシデントに対応するため，成功した攻 撃の情報をいち早く知る必要がある．攻撃が成功して から，管理者がそれを発見し対応するまでの時間が長 いほど，内部ホストへのさらなる不正侵入やリソース の不正利用，さらに内部ホストを経由した外部への攻 撃が起こりやすくなる．しかし

IDS

の運用コストが高 くなると，このようなリスクの高いアラートの発見が 遅れたり，あるいは見逃してしまう可能性がある．見 逃しや発見の遅れを防ぐために現在は監視を複数人で

行うなどの施策がとられているが，このような運用方 法ではコストパフォーマンスが悪い．

本稿では

IDS

が効果的に運用できない事を問題と し，適切なリスク評価手法を実現することでこの問題 を解決する．

3. 2

運用コスト増加の実例

Snort [1]

により，既存の

IDS

による監視が管理コ ストを増大させることを示す．対象となるネットワー クは約

500

台のホストが接続可能な

IPv4

ネットワー クである．このネットワークに対して

Snort

で監視を 行った．図

1

は

2004

年

4

月

1

日から

5

月

30

日までで，

Snort

が攻撃として検知したアラート件数の推移およ

び，観測されたトラフィック量の推移を示すグラフで ある．また，使用した

Snort

のルールを表

1

に示す．

観測した結果，一日あたりの平均アラート数は

97976

件，平均トラフィック量は

3.334Mbps

となった．

0 1 2 3 4 5 6

04/03 04/10 04/17 04/24 05/01 05/08 05/15 05/22 05/29 0

50000 100000 150000 200000

Mbps Number per day

date

Alert Number Total Traffic

図1 Snortのアラート数推移/トラフィック量推移 Fig. 1 Trends of Alert by Snort and Traffic

表1 監視に用いたSnortのルール一覧 Table 1 Snort Rule File List for Observation attack-responses.rules backdoor.rules dns.rules bad-traffic.rules ddos.rules dos.rules exploit.rules finger.rules ftp.rules local.rules misc.rules info.rules netbios.rules pass.rules rpc.rules scan.rules shellcode.rules smtp.rules rservices.rules sql.rules tftp.rules telnet.rules virus.rules vision18.rules web-coldfusion.rules web-cgi.rules x11.rules web-frontpage.rules web-iis.rules web-misc.rules

大部分が低リスクのアラートであることを示すため に同様の環境から得られたアラートの一部を用いて，

TB-IDS

の手法を用いたリスク評価を行った．結果を

表

2

に示す．この評価は，その攻撃が対象としている

OS

と，実際に攻撃をうけたホストの

OS

を比較し，一 致したものを高リスクとして分類している．

OS

情報 は

DHCP

の

DHCP DISCOVER

メッセージから取 得し

[14]

，

IDS

のアラートおよび独自に作成した攻撃

表2 ホスト情報に基づいたリスク評価 Table 2 Risk Evaluation by Host Information

アラートの種類 全検知数 高リスクと 高リスクの 評価した数 割合 Concept-Nimda - root.exe

probe

2734 118 4.32%

Concept-Nimda 17264 781 4.52%

CodeRed Defacement 632 30 4.75%

MISC MS Terminal server request

45 45 100.00%

WEB-IIS view source via translate header

2597 94 3.62%

IIS vti inf access at- tempt

27 2 7.40%

IDS475/web-iis web-webdav- propfind

1024 0 0.00%

WEB-IIS webdav file lock attempt

40 0 0.00%

possible CodeRed II Worm 1 0 0.00%

ida ISAPI Overflow 99 13 13.13%

WEB-IIS cmd.exe access 255 6 2.35%

rpc tcp traffic contains bin sh 18 0 0.00%

X11 xopen 13 0 0.00%

MISC MS Terminal server request (RDP)

6 6 100.00%

Total 24755 1095 4.42%

の種類と目標とする

OS

のマップを使用した．

その結果，この評価からリスクが高いと判断される アラートは全体の

4.42%

であり，他の大部分のアラー トは低リスクであるという事実が明らかとなった．さ らに，この評価で高リスクと判断されたものでも，そ の多くは既にパッチによる脆弱性の修正，

Personal

Firewall

の導入，適切なソフトウェアの設定などの対

策が施されており，実際に高リスクなアラートはこの 中のさらにごく一部，あるいはこの中には存在してい ないと考えられる．そのため実際にリスクの高い攻撃 は極めて少なく，それを全体から見つけ出すのは困難 である．

4.

関 連 研 究

4. 1 Stateful Signature

通常のシグネチャ型

IDS

ではトラフィック中に含ま れる特定のキーワードの発見によって攻撃を検知す る．しかし，攻撃ではないトラフィックにも同じキー ワードが偶然含まれる可能性があり，

False Positive

をおこす原因となる．これを解決するために，

Stateful Signature [15]

では単一のトラフィックだけではなく，

TCP

の同一セッションなどから複数のパケット，ある いはキーワードを検知対象にできる．これにより攻撃

に関連する一連の動作を識別することが可能となり，

False Positive

の削減につながる．

しかしこの技術は，実際の攻撃を検知したアラート に対してリスク評価をするものではなく，攻撃数の増 加によりコスト削減が難しくなる。

4. 2 NetSTAT

NetSTAT [12]

はネットワークで観測されたイベン トやホスト上で発生したイベントなどの，複数の事実 から侵入を発見する研究である．ホストの状態やネッ トワークトラフィックの情報，トポロジ情報などを組 み合わせたルールを用いる事で，管理ネットワーク内 で起きたイベントを正確に検知する事ができる．また，

各アプリケーションにおける状態遷移も検知に利用で きるため，汎用性が高く設計されている．

ただし，ネットワーク側は通信の開始から終了まで の状態遷移，ホスト側は各イベントでの状態を記録す る必要がある．そのため広帯域なネットワークでは，

監視ホストに高い性能と多くの記憶領域が要求され る．また，トポロジの変更に伴い，その都度適用され るルールを変更しなければならない．多数のホストが 動的に接続するネットワークでは，ルール管理ホスト に高い負荷がかかると予想される．さらに，各ホスト にシステムを導入しなければならないため，不特定多 数のホストが接続する場合，システムが機能しない可 能性が高い．このため高帯域，または多数のホストが 動的に接続するネットワークにおいては運用が困難で あると考えられる．

これに対し，本研究はネットワークトラフィック上 のイベントに焦点をあてており，さらにリスク評価に 必要となるトラフィックのみを扱い，監視のための負 荷を軽減している．さらに

IDS

が監視しているネット ワークを利用しているホストであれば，システム導入 の必要は無く，またトポロジの変更も影響しない．ゆ えに，様々なネットワークにおいて運用が可能である と考える．

5.

解 決 手 法

5. 1

要 件 定 義

IDS

が検知したアラートのリスク評価における要件 を以下に挙げる．

a )

即 時 性

リスク評価に時間と手間がかかってしまうことで，

インシデントへの対処が遅れる，あるいは行われなく なるなどの弊害が起こる．そのため処理時間および管

理者の手間の，両方の側面から即時性が要求される．

b )

確 実 性

評価された結果が正しくないことで，リスクの高い アラートの見逃しにつながってしまう．そのため，リ スクの低いアラートを判別する精度の高さが必要と なる．

c )

規 模 性

評価の手法によっては管理ホスト数の増加により，

評価に手間と時間がかかる可能性が高い．多くのホス トで構成されているネットワークにおける運用では重 要な要件となる．

d )

多 様 性

多様性とはリスク評価をできる攻撃の多さをあらわ す．いかに適切な評価が行えるとしても一部の攻撃に しか対応できなければ有効性が著しく低下してしまう．

5. 2

セッション

本稿では，通信を行っている二つの

IP

アドレスに おいて

TCP

の

HTTP

による

Web

リソースの取得，

UDP

による

DNS

問い合わせ，

ICMP

のエコーリク エストなど，特定のサービスのための一連の通信を

「セッション」と定義する．

ステートフル型の通信である

TCP

は１つの

TCP

セッションを本稿で定義する１セッションとし，ステー トレスである

UDP

は同一の送信元ポート番号，送信 先ポート番号の組合せを１セッションとする．

ICMP

はエコー要求やエコー応答などの関連性のある通信を 一つにまとめ，１セッションとする．その他の

IP

通 信では，プロトコルの種類毎に１セッションとする．

5. 3

本研究におけるアプローチ

本研究では第

3.

節の問題点を解決するため，継続的 な通信であるセッションに着目する．

ネットワークからの多くの攻撃には，その攻撃に対 する応答のトラフィックが存在する．例として不正侵 入を試みた後にその成功を示す応答が返される，ある いは攻撃対象のホストに対して調査をした後に，その 結果が返されるなどが挙げられる．多くの場合，これ らの応答には攻撃の成否を判断する手がかりが含まれ る．この情報をもとに

IDS

が自動的に攻撃の成否を 判断し，その情報をアラートに付与する．管理者がア ラートを見る際，攻撃の成否の情報によって同種類の アラートにおいてもリスクの順位付が可能となる．攻 撃が成功し，リスクが高いと判断されたアラートにつ いてのみ緊急に対応することで，

IDS

による監視運用 コストの大幅な減少が期待される．

本機構は

IDS

の検知システム内において即時的にア ラートのリスクを評価する．別のアプローチとして，

関連する全ての通信の記録を２次記憶領域に保存し，

後から応答を自動的に解析することで，アラートをリ スク評価することもできる．しかし，高帯域，あるい は多数のホストが接続しているネットワークにおいて，

通信の記録は大量の記憶領域が必要となり，記憶領域 が圧迫され記録に失敗する可能性がある．そのため，

IDS

の検知システム内で評価を行い，結果のみを記録 することで，記憶領域の圧迫を防ぐ．

このような動作機構を持つ

IDS

を

Session Based IDS (

以下，

SB-IDS)

と命名する．

192.168.0.1

HTTP (TCP Session : port 8732 <-> 80 )

DNS (UDP : port 3211<->53) 10.0.1.5

Session 図2 セッションのモデル Fig. 2 Model of Session

5. 4

追跡型監視の提案

SB-IDS

では主に，攻撃の通信が行われたホストか

らの応答を監視し，その応答によって攻撃の成功，あ るいは失敗を判断する．そのために，以下に挙げる二 つのシグネチャを用意し，攻撃とその応答を監視する．

（

1

） 攻撃が行われたことを示すパケットのシグネ チャ

（

2

） 攻撃が成功，あるいは失敗したことを示す反 応のパケットのシグネチャ

最初に全てのパケットを

(1)

と比較する．攻撃が行わ れた可能性を示すパケットを検知した場合，そのセッ ションの応答に該当するパケットを

(2)

と比較し，合 致すれば攻撃が成功した可能性があると判断し，記 録，通知を行う．その際，経過時間や該当する攻撃が 必要とするセッション内でのパケット数に応じて，そ のセッションに対する反応検知シグネチャの保持条件 を定義することで，新たな誤検知を軽減する．

5. 5

シ ナ リ オ

本節では，

SB-IDS

が有効に動作する例としてバ ックドアを用いた不正侵入を挙げる．バックドアは

CodeRedII [5]

ワームが設置するものとする．

CodeRedII

ワームは

Microsoft

社の

IIS(Internet Information Server)

の脆弱性を利用し，感染する．

CodeRedII

ワームは感染した後，感染コンピュータの

ハードディスクの複数箇所に

“root.exe”

というバック

ドア用のファイルをコピーする．さらに，

IIS

の設定 を変更することで，遠隔から任意のコマンドを実行可 能とする．

Attacker

GET /scripts/root.exe?/c+dir

404 Not Found...

Target

Failed Case Exploided Case

Attacker

GET /scripts/root.exe?/c+dir

200 ok ...

Target

図3 バックドアを利用した攻撃の成功例と失敗例 Fig. 3 Failure Case and Exploited Case of Attack

with Backdoor

ここで、任意のコマンドの実行例を図

3

に示す．バッ クドアが設置されているホストに対しては，

“GET /scripts/root.exe?/c+dir”

というリクエストを送信 することで，ディレクトリが参照できる．図

3

の左 部分は感染していないホストの例である．ホストに 対する不正アクセスは

HTTP

のファイル取得不能エ ラー

[9]

である

“404”

などが応答として返され，攻撃 は失敗する．一方で，右側は感染したホストに対する 不正アクセスである．このケースではアクセスが成功 するため，ファイル取得成功コード

“200”

と，実行結 果であるディレクトリのファイル名一覧が返される．

Conversation Based IDS

Attacker

GET /scripts/root.exe?/c+dir

200 ok ...

Target

Session Based IDS

Alert: Exploited

Conversation Based IDS Conventional

IDS Alert

図4 システム動作例 Fig. 4 A Case of Detection Attack

図

4

ではバックドアへのアクセスに対する、従来の

IDS

と

SB-IDS

の検知手法を比較している．図のよう に、従来の

IDS

では攻撃者が送信するトラフィックの みを監視していたため、

“GET /scripts/root.exe”

と いうリクエストは全て同様のアラートとして検知する．

SB-IDS

では，送信されたリクエストを「攻撃があっ

たことを示すパケット」として検出し，続けてその攻 撃に対するホストの応答を監視する．ファイル取得成 功コードの

“200”

が返された場合、

root.exe

へのアク

セスが成功したと判断できる．以上の動作により，成 功した攻撃と，失敗した攻撃を判別することが可能と なる．

6.

設 計

SB-IDS

を実現するために必要となる全体，及び各

部の設計について述べる．

6. 1

シグネチャ

SB-IDS

は攻撃およびその反応のパターンを記述し

たシグネチャと監視しているトラフィックのパターン を比較し，一致することでアラートをあげるシグネ チャ型

IDS

とする．シグネチャは攻撃が開始されたこ とを示すパケットを記述するための部分と，攻撃の成 功，もしくは失敗としての反応を示すパケットを記述 するため部分の，２種類を用意する必要がある．それ ぞれの部分をシグネチャの「ブロック」とし，前者を

「トリガーブロック」，後者を「トラッキングブロック」

とする．

トラッキングブロックの監視においては，パターン に合致するパケットが半永久的に出現しない場合が予 想される．１次記憶領域の圧迫を防ぐため，ある基準 を設けそれを満たさなくなると攻撃失敗と判断する．

この基準を「保持条件」とする．保持条件は，当該セッ ションで観測されたパケットの数，およびブロックが 検知されてから経過した時間で決定する．

また，トラッキングブロックで監視すべき対象は攻 撃対象ホストからの反応だけに限らない．通常はリク エストをトリガーブロックとし，レスポンスをトラッ キングとすることで，シグネチャを設定できる．しか し，場合によってはリクエスト，レスポンス，リクエ ストのように連続したトラフィックが観測されて，初 めて侵入とみなせる攻撃も考えられる．そのため，ト ラッキングブロックが攻撃者から攻撃目標に対するリ クエストであるか，攻撃を受けたホストからのレスポ ンスのパケットであるかというシグネチャの方向を示 す項目が必要となる．

6. 2

検 索 機 能

既存のシグネチャ型

IDS

は予め登録されたシグネ チャと一致するパケットを攻撃として検知する．それ に対して，

SB-IDS

はトリガーブロックのシグネチャ を検出した後，さらに当該セッションからトラッキン グブロックを検出する．そのためトリガーブロックに より検出した情報を当該セッションと関連づけ，保持 し続ける．そして，後から当該セッションのトラフィッ

クを発見した場合，トラッキングブロックの比較する 機能が必要となる．トラッキングブロックは連続して 設定可能とするため，一致するトラフィックを検知し た場合はさらなるトラッキングブロックが設定されて いないかを確認する．トラッキングブロックが連続し て設定されている場合は，次のトラッキングブロック を登録する．最後のトラッキングブロックを検知し，

攻撃の成功，あるいは失敗を判断する．

6. 3

イベント種別

SB-IDS

は攻撃の成否の情報を，アラートに付与し，

記録できる．また，必要に応じて通信を監視し

SB-IDS

において攻撃の分析を行うデータも同様に記録する．

本稿ではこれらの記録すべき事象の総称を「イベント」

とする．主にアラートとしてあげるイベントの種別は 以下の３種類である．

a ) ALERT EXPLOITED

トラッキングブロックと比較し，攻撃成功と判断し たイベント．

b ) ALERT FAILED

トラッキングブロックと合致するパケットが出現せ ず，保持条件が無効になり，攻撃失敗と判断したイベ ント．

c ) ALERT SINGLE

ある攻撃についての情報が少なく，攻撃をうけたホ ストが返す反応が不明なため，トリガーブロックのみ で構成されたシグネチャが使用される場合がある．そ のようなシグネチャが検知された場合のイベント．

7.

実 装

第

6.

節の設計に従い，

SB-IDS

を実装した．

OS

は

Debian GNU/Linux 3.0 testing

を使用し，

C

言語を 用いた．監視すべきトラフィックの取得には，多数の

OS

をサポートする

libpcap [6]

ライブラリを使用した．

また，以下で詳細な実装について述べる．

7. 1

機 能 分 類

SB-IDS

の機能を図

5

に示す．

a )

パケット取得

指定したインターフェースを通してネットワーク上 のトラフィックを監視し，検査すべきパケットを取得 する．検査するパケットを限定する場合はこの部分で 処理する．

b )

パケット解析，セッション検索

取得したパケットをプロトコル毎の形式へ変換し，

該当するセッションの検索，追加，時間切れを管理す

Trigger Block Detection Engine

Log

Capture and Filter

Tracking Block Detection Engine add

Tracking Session

ALERT_EXPLOITED / ALERT_FAILURE ALERT_SINGLE

Network Traffic Parse Traffic &

Search Session

図5 動作概要図 Fig. 5 System Diagram

る．セッションの検索については第

7. 4

節において詳 細を述べる．

c )

トリガーブロック検索

攻撃が開始されたことを示すシグネチャであるトリ ガーブロックの検索を行う．発見後，トラッキングブ ロックが存在するシグネチャの場合はセッションをト ラッキングブロック検索に追加する．存在しなければ ログとして記録する．

d )

トラッキングブロック検索

攻撃が成功，あるいは失敗したことを示すシグネ チャであるトラッキングブロックとパケットを比較し，

合致するものを検索する．発見後は結果をログとして 記録する．また，結果が出る前の通信も解析用に記録 する．

e )

ロ グ 出 力

各処理において発生したイベントの記録，あるいは 管理者へアラートの通知をする．記録はテキストある いはデータベースに保存する．

7. 2

シグネチャ書式

シグネチャの書式を以下に示し，記述すべき項目に ついて述べる．

1| action "message" protocol sport->dport { 2| direction: ([item=data;]* );

3| direction: keepcond([item=data;]*);

| ...

n| };

図6 シグネチャの記述書式 Fig. 6 Signature Format

図

6

の１行目ではシグネチャ全体についての設定項 目を記述する．２行目をトリガーブロックとし，３行 目以降をトラッキングブロックとする．

まず，シグネチャ全体の設定項目について述べる．

a ) action

シグネチャの属性を指定する．攻撃として，シグネ チャのパターンと一致するトラフィックを発見した際 にアラートとして検知する

“alert”

，特定のトラフィッ クをアラートとして検知しないようにする

“pass”

を 指定する．

b ) message

シグネチャの内容を説明するメッセージを指定する．

c ) protocol

レイヤー

4

のプロトコルを指定する．

d ) sport / dport

最初に検知すべきパケットのポート番号を指定する．

指定が無い場合は

“any”

とする．

この後にパケットのパターンを表すブロックを記述 する．２行目がトリガーブロックとなり，３行目以降 がトラッキングブロックとなる．それぞれの括弧内の 記述が一種類のパケットに相当する．それぞれのブ ロックの前にはその方向を示す

“direction”

と，保持 条件となる

“keepcond”

を指定する．

それぞれ，指定できる項目を表

3

，表

4

に示す．

表3 ブロックの方向 指定項目 Table 3 Block Direction Configuration Items シンボル 説明

fac “factor”．攻撃者から攻撃対象のホストへ送

られる，攻撃パケット．

res “result”．行われた攻撃に対する反応・結果

として，攻撃対象のホストから攻撃者に送信 されるパケット．

表4 保持条件 設定項目

Table 4 Keeping Condition Configuration Items シンボル 説明

f p 攻撃者から攻撃対象へのパケットの数 fp p 攻撃者から攻撃対象へのペイロード部を含む

パケットの数

r p 攻撃対象から攻撃者へのパケットの数 rp p 攻撃対象から攻撃者へのペイロード部を含む

パケットの数

p 方向を問わず観測されたパケット数 p p 方向を問わず，ペイロード部を含むパケット

数

timeout 前のブロックが検知されてから経過した時間

さらに，パケットのパターンを記述するブロックで

指定できる項目を表

5

に示す．これらを一つ，あるい は複数指定することで様々なパケットのパターンを表 現できる．

表5 ブロック 設定項目 Table 5 Block Configuration Items シンボル 説明

saddr IPソースアドレス(個別アドレス/アドレ

ス空間)

daddr IPデスティネーションアドレス(個別アドレ

ス/アドレス空間) ip proto レイヤー4のプロトコル

ip len IPパケット長

ip ttl 生存時間(Time To Live)

sport TCP,もしくはUDPのソースポート番号

dport TCP,もしくはUDPのデスティネーション

ポート番号

tcp seq TCPシーケンス番号

tcp ack TCP応答番号

tcp win TCPウィンドウサイズ

tcp flags TCPフラグ icmp type ICMP種別 icmp code ICMPコード icmp seq ICMPシーケンス番号 icmp id ICMP識別番号 payload len ペイロード長

payload ペイロード内容

7. 2. 1

シグネチャ記述の例

alert "root.exe probe" tcp any->80{

fac:(tcp_flags=AP;

payload="root.exe?/c+dir"; );

res:rp_p<1 !(tcp_flags=AP;

payload="404"|"403";);

};

図7 root.exeバックドアを用いた攻撃 Fig. 7 A Signature of Attack by “root.exe”

ここでは

root.exe

バックドアへの侵入を検知するた めのシグネチャを例として図

7

に示す．

上 記 の 例 で は ト リ ガ ー ブ ロック に よって

“root.exe?/c+dir”

を含む

TCP

の

http(

ポート

80

番

)

へのアクセスを検知する．その後，ペイロード部を含む 攻撃対象からの反応に，

HTTP

のファイル取得不能エ ラーコードの

404(File Not Found), 403(Permission

Denied)

のいずれかを含む場合は攻撃の失敗とみなす．

逆に

404, 403

が含まれなかった場合は攻撃が成功し

たと判断し，アラートとして検知する．

7. 3

トリガーブロック検索

トリガーブロックは，常に同様のデータ群とパケッ トを比較し検索するため，ハッシュテーブルを使用す る．ハッシュ検索に利用するキーを

TCP,UDP

では ポート番号，

ICMP

では

ICMP

コード，それ以外の

IP

通信ではプロトコル番号とする．ハッシュの衝突が 発生した場合は，リストとして保存していく．

7. 4

セッション，トラッキングブロック管理 セッション，トラッキングブロック管理の実装につ いて，図

8

に概要を示す．

Hash Table of Flow IP Header

192.168.67.144->192.168.0.2

Flow Linked List

192.168.43.213 <>10.0.133.155 Flow Linked List

192.168.67.144 <>192.168.0.2 TCP

src port: 3345 dst port: 80

Session Linked List (TCP) port 4564 <-> 22 Session Linked List

(TCP) port 3345 <-> 80 Tracking Block

"Nimda-root.exe probe"

Tracking Block

"Slammer worm attempt"

Session Linked List (UDP) port 9141 <-> 1434

図8 セッション，トラッキングブロック検索動作概要 Fig. 8 A Description About Control of Flow, Session

and Tracking Block

セッション，トラッキングブロック検索のために，通 信を行っている二つのホストをあらわす「フロー」を 定義する．各セッション，トラッキングブロックは一つ のフローに属するため，フローを検索した後，セッショ ン，トラッキングブロックを検索するよう実装した．

フローの検索は，取得したパケットの

IP

アドレス のハッシュによって行われる．ハッシュテーブルのス ケールは監視するネットワークの規模と設定値によっ て異なる．ハッシュの競合に対処するため，そのハッ シュ値に一致するフローをグループとして管理する．

グループはリンクドリストによって保存され，検索す る場合はこれを順番に検証していく．

発見された当該フローには，それぞれセッションの リスト，トラッキングブロックのリストが関連付され ている．双方ともリストを順番に検査し，該当するも のを検索する．セッションは発見されなかった場合，

新しいものを追加する．

トラッキングブロックの検索では，当該セッション のトラッキングブロックであるかを検査し，必要に応 じて検索をスキップする．

該当するトラッキングブロックが発見された場合は，

イベントを記録し登録を削除する．

8.

評 価

幾つかのシグネチャを作成し，第

3. 2

節と同様の環 境において実験を行った．その結果をもとに，

SB-IDS

の評価を行う．評価は，実際にリスクを分類し運用コ ストの削減を実現できているか，分類した結果が正し いか，についての定量評価と，他の手法と比較した定 性評価を行った．

8. 1

リスク評価

実際に取得したログから，応答の監視によってリス ク評価が可能となることを検証する．

評価は実運用ネットワークを

2004/01/12 03:30:00

から

2004/01/16 20:20:00

まで監視することで行った．

図

9

，図

10

に評価に用いたシグネチャを示し，その結 果を表

6

，表

7

にそれぞれ示す．

alert "CodeRed II Worm" TCP any->80{

fac:(payload = "\\root.exe";);

res:rp_p<1 !(payload = "404"|"403";);

};

図9 CodeRed IIワームのシグネチャ Fig. 9 A Signature for CodeRed II Worm

表6 CodeRed IIワームの検出結果 Table 6 Results of CodeRed II Worm

種別 メッセージ 件数 割合

検知数 LOG TRIGER 571件

失敗判定数 ALERT FALIED 544件 95.271%

成功判定数 ALERT EXPLOITED 27件 4.729%

表7 Windows netbios name検索の検知結果 Table 7 Results of Windows Netbios Name Search-

ing

種別 メッセージ 件数 割合

検知数 LOG TRIGER 59764件

失敗判定数 ALERT FALIED 56838件 95.104%

成功判定数 ALERT EXPLOITED 2926件 4.896%

以上の通り，攻撃されたホストの応答を監視するこ とで危険性の高いアラートを識別することを可能とし

alert "netbios_netbios-name-query"

UDP any -> 137 {

fac:(payload="CKAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA|00 00|";);

res:r_p<1 (payload="CKAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA|00 00|";);

};

図10 Windows netbios name検索のシグネチャ Fig. 10 A Signature for Windows Netbios Name

Searching

た．表

6

，表

7

では共に

95%

以上の失敗したと考えら れる低リスクの攻撃と，

5%

以下の攻撃が成功した可 能性のある攻撃に分類している．

また，トリガーブロックで検知した内容が

False Pos-

itive

である可能性を考慮した場合も，成功判定された

アラートに対してのみ，検知内容が

False Positive

で あるかの調査を行えば良い．ゆえに，結果として運用 コストは削減されていると言える．

8. 2

検 出 精 度

第

8. 1

節で使用した

CodeRedII

ワームのデータを もとに，検出精度を評価する．まず，失敗と判定され た攻撃についての内訳を表

8

に示す．

表8 失敗判別された攻撃の内容 Table 8 The Breakdown of failed attack

応答 件数

404 Not Found 339 403 Forbidden 7

Timeout 198

404

と

403

のエラーメッセージによる失敗判定は，

シグネチャの通りの挙動であるため，

SB-IDS

が正常 に稼働していることを示している．

Timeout

はトラッ キングブロックの時間切れ処理がなされたものである．

トラッキングブロックの保持条件はペイロードを含む パケットが来るまで監視するものと設定されていた．

そのため

TCP

セッションが異常終了，あるいは能動 的な終了をする際にペイロードを含まない，

RST

や

FIN

によって

TCP

セッションの中断が行われており，

パケット数のカウントが行われなかった．

これは観測したネットワークが研究用ネットワーク であったために，アドレスでアクセスを制限している，

あるいは

HTTP

ではないプロトコルを使用していた，

などの理由が考えられるが，

SB-IDS

の動作としては 正しいと言える．

次に表

9

で攻撃が成功したものの内訳を示す．

表9 成功判別された攻撃の内容

Table 9 The Breakdown of Attack Indicated Success

応答 件数

400 BadRequest 8

200 Ok 5

301 Moved Permanently 12 411 Length Required 2

HTTP

のエラーコードである

400

，

411

については 明らかに攻撃失敗であることが分かる．

301

は同一の ホストに対する攻撃で，あらゆるリクエストに対して

301

を返すという設定になっているホストであるため，

特にリスクは無いと判断できる．リスクとして考えら れるのはコード

200

を応答しているホストだが，この ホストでは全てのリクエストに対してコード

200

を返 すという，

RFC

に準拠していない

Web

サーバが稼働 していることを確認した．本来

IDS

は，ネットワーク 毎の特異な状況を管理者が考慮し，それに応じた設定 をしたうえで運用するため，このような例外は許容範 囲であると考えられる．ゆえに本ネットワークで運用 する際は，このようなホストを無視する事で，さらに リスクの低いアラートを取り除くことができる．

成功判定がでたアラートには，全てに危険性が無 かったため，これらは誤検知であると言える．表

9

の 結果をもとに，

400

，

301

，

411

も失敗判定できるよう シグネチャを変更することで，さらに誤検知を減らす ことができる．

8. 3

定 性 評 価

SB-IDS

を他のリスク評価手法と比較し，

SB-IDS

の定性評価を行う．第

5. 1

節で挙げている要件の４つ を評価項目に組み込む．

（

1

） 即時性

（

2

） 確実性

（

3

） 規模性

（

4

） 多様性

(1)

は速やかにアラートのリスクを評価できるか，

(2)

はアラートの評価をした結果が正しいと言えるかどう か，

(3)

は多数の内部ホストで構成されるネットワー クにおいても運用のための手間が変わらないか，

(4)

は様々な攻撃に対応できるか，の以上４つを定性評価 項目とする．

また，比較する対策手法は第

2.

節で挙げている内 部からの攻撃検知による判断，継続的な通信の記録，

TB-IDS [8]

を挙げる．

以下で評価について述べ，表

10

においてその一覧

をまとめる．

8. 3. 1

即 時 性

内部からの攻撃検知，

TB-IDS

，

SB-IDS

はそれぞ れ，

IDS

の検知エンジンやアラートの解析エンジン が自動的にリスク評価を行う．これにより，各ソフト ウェアが即座にリスク評価の情報を記録に残す，ある いは管理者への通知が可能となり，早急なインシデン ト対応ができる．しかし，攻撃検知後に継続して通信 を記録しても，リスク評価は管理者が一つずつアラー トを検査しなければならず，多くの手間がかかってし まう．

8. 3. 2

確 実 性

TB-IDS

はネットワークの全ホストについての完全

な情報を取得することで，確実なリスク評価ができる．

また，内部からの攻撃検知と

SB-IDS

はシグネチャに 定められた通信のパターンを確実に検知する．そのた め，適切なシグネチャが設定されていればリスク評価 の確実性は高いと言える．しかし，攻撃検知後に継続 して通信を記録しても，管理者が多くの通信プロトコ ルについて熟練した知識を持っていなければリスク評 価は困難となる．また，人間が記録を検査することで リスク評価を行っているため，誤判断を起こす可能性 が有り，他の手法に比べ劣っていると言える．

8. 3. 3

規 模 性

TB-IDS

はリスク評価を行うために，全ての内部ホ

ストについてホスト情報を把握する必要がある．ゆえ に，ネットワークの規模拡大に伴いホスト情報の把握 が困難になり，リスク評価の弊害となる．攻撃検知後 の継続的な通信の記録も，管理者が自らリスク評価を しなければならず，ホスト数の増加はアラートの増加 につながり，大幅に手間が増えてしまう．内部からの 攻撃検知と

SB-IDS

はホスト数が増えても，常に同様 のリスク評価の処理を行うため規模性について問題は ない．

8. 3. 4

多 様 性

内部からの攻撃検知は第

2. 1

節で述べたようにごく 一部の攻撃にのみ対して有効なリスク評価手法であり，

不正侵入や調査活動の評価ができない．

TB-IDS

はバッファオーバーフローによる不正侵入

などについてはリスク評価が可能だが，

OS

やアプリ ケーションに依存しない，攻撃者による調査活動等に は対応できない．また，

SB-IDS

は第

9. 2

節で触れる が，一部の応答が期待できない攻撃については未対応 となっている．攻撃検知後の継続的な通信の記録は，

表10 定 性 評 価 Table 10 Qualitative evaluation

内部からの攻撃検知 継続的な通信の記録 TB-IDS SB-IDS

即時性 ○ × ○ ○

確実性 ○ △ ○ ○

規模性 ○ × △ ○

多様性 × △ △ △

どのような攻撃に対しても記録が可能である．しかし

SB-IDS

と同様に，攻撃後に通信が発生しない攻撃も

存在するためこれについてはリスク評価のための手が かりを得ることができない．

9.

今後の課題と展望

9. 1

保持情報量の増加

フロー，セッション，トラッキングブロックは，検 知を行うためにそれぞれの状態を記憶しておかなけれ ばならない．そのため，

SB-IDS

は従来の

IDS

と比較 すると保持すべき情報量が増加する．また，情報量の 増加は処理への負担も大きくする可能性がある．これ により，ある条件下では

IDS

が正常に動作しなくな り，脅威となる攻撃が検知できなくなる可能性がある．

例として，特定の偽装したパケットを大量に送信され る

[17]

，あるいは急速に感染を広めるワームの突発的 な発生などが挙げられる．

これは

SB-IDS

の構造によるものであり，アルゴリ

ズムによる根本的な解決は困難であるが，今後のハー ドウェアにおける記憶保持，及び処理機能の改善によ りある程度解決可能であると考えられる．

9. 2

応答の通信が期待できない攻撃への対策

SB-IDS

を用いても応答の通信が期待できない可能

性のある攻撃の成否を判断するのは困難である．具体 例として

DoS

攻撃や，ステートレスな

UDP

を利用し たウィルスの感染活動

[2]

が挙げられる．ステートレ スな

UDP

を利用したウィルスの感染活動は，

ICMP Port Unreachable Error

のパケットが返答により，失 敗を判定できるが，

Personal Firewall

が有効なホス トでは

ICMP

を返さないため，成否を判別すること ができない．

また，応答が無い場合に成功したと判断される攻撃 については，

Firewall

などで遮断されることで

False

Positive

が多数発生してしまうことが予想される．一

部のホストに対する攻撃で失敗の判定を得られたとし ても，特に堅牢に構築されたネットワークほど

False

Positive

が多発し別個にリスク評価をするコスト発生

の可能性が高い．

この問題についてはセッションの追跡とは別に，内 部ホストの挙動を継続的に監視する，あるいは他の評 価手法との併用などによって解決できると考える．

9. 3

プロトコルアノーマリ検知への応用

SB-IDS

はシグネチャの記述方法により，プロトコル

アノーマリ

[16]

な通信の検知が可能となる．セッショ ンを追跡しての監視が可能であるため，プロトコル違 反のパケットに対して，プロトコル違反の応答がなさ れた場合，リスクが高いと判断できる．これによって，

高リスクの通信を抽出し，シグネチャとして登録され ていない攻撃の検出が容易になる．具体例としては，

HTTP

のリクエストは通常

ASCII

コードのみの通信 とされているが，この中にアセンブラコードが含まれ る場合，攻撃の可能性があるため当該セッションを監 視し続ける．その応答に通常のエラーコードが含まれ ていれば正常な動作であると考えられる．しかし，エ ラーコードが含まれない，あるいは

ASCII

以外の文 字コードが含まれるなどの応答を確認することで正常 な動作では無いと判断し，高リスクであることが評価 できる．ゆえに，

SB-IDS

は未知の攻撃にたいしても リスク評価ができる可能性が高いため，幅広い応用が 期待できる．

10.

ま と め

本稿では，ネットワークの監視技術である

IDS

が検 知したアラートについてリスク評価ができないことを 指摘し，これが

IDS

の運用コストを増大させている という問題点を挙げた．この問題を解決するために，

攻撃のあったセッションを追跡し，攻撃の検知だけで はなく，その攻撃に対する応答も同時に監視すること で，成功・失敗の判別をする

Session Based IDS

を提 案し，実装，実験した．その結果，

IDS

の運用コスト の削減を実現できた．

謝辞 本論文を執筆するにあたり，御助力頂いた小 柴晋氏，金井瑛氏に感謝します．

文 献 [1] Snort，Martin Roesch，

“SNORT-LIGHTWEIGHT INTRUSION DETEC- TION FOR NETWORKS”，USENIX LISA 99 Con- ference，1999. http://www.snort.org

[2] CERT Advisory CA-2003-04 :MS-SQL Server worm http://www.cert.org/advisories/CA-2003-04.html, Jan.

2003

[3] CERT Advisory CA-2003-20 W32/Blaster worm http://www.cert.org/advisories/CA-2003-20.html, Aug.

2003

[4] CERT Advisory CA-2001-26 Nimda worm

http://www.cert.org/advisories/CA-2001-26.html, Sep.

2001

[5] CERT Incident Note IN-2001-09 “Code Red II: An- other worm Exploiting Buffer Overflow In IIS Index- ing Service DLL”

http://www.cert.org/incident notes/IN-2001-09.html, Aug. 2001

[6] TCPDUMP/LIBPCAPhttp://www.tcpdump.org/

[7] Network Flight Recorderhttp://www.nfr.com [8] “Target Based IDS”, Joel Snyder

http://infosecuritymag.techtarget.com/ss/0,295796, sid6 iss306 art540,00.html, Jan. 2004

[9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Mas- inter, P. Leach, T. Berners-Lee

“Hypertext Transfer Protocol – HTTP/1.1”, Re- quest for Comments 2616 ftp://ftp.isi.edu/in- notes/rfc2616.txt, Jun. 1999

[10] Mark Cooper, Stephen Northcutt , Matt Fearnow , Karen Frederick,

“Intrusion Signatures and Analysis”, Person Educa- tion, Jan. 2001

[11] Stephen Northcutt, Donald McLachlan, Judy Novak,

“Network Intrusion Detection: An Analyst´s Hand- book (2nd Edition)”, Paperback, Sep. 2000 [12] “NetSTAT: A Network-based Intrusion Detection

Approach”, Giovanni Vigna,Richard A. Kemmerer, ACSAC 1998

[13] “State Transition Analysis: A Rule-Based Intrusion Detection System”, Koral Ilgun, Software Engineer- ing, IEEE Trans. on Software Engineering, March 1995

[14] “DHCPを用いた受動的フィンガープリンティング手法の

提案と実装”,白畑 真，土本 康生，村井 純, “第111回 マルチメディア通信と分散処理研究会”, Feb. 2003 [15] “Stateful Signature Detection”,

http://www.juniper.net/products/intrusion/

detection.html#Stateful Sign Det, Juniper Networks Inc.

[16] Erwan Lemonnier, “Protocol Anomaly Detection in Network-based IDSs”, Defcom 28th June 2001 [17] Sniph. Snot.http://www.sec33.com/sniph/, 2001.

（平成xx年xx月xx日受付）

水谷 正慶

現在，慶應義塾大学環境情報学部在籍中．

白畑 真

学士(環境情報学)．2004年 慶應義塾大 学環境情報学部卒業．現在，慶應義塾大学 政策・メディア研究科修士課程在学中

南 政樹

修士(政策・メディア) 1996年 慶應義塾 大学環境情報学部卒業．1998年 政策・メ ディア研究科修了．現在，慶應義塾大学 環 境情報学部 専任講師

村井 純

博士(工学)．1979年 慶應義塾大学工学 部数理工学科卒業．1981年 同大学院理工 学研究科修士課程数理工学専攻修了．1987 年1月 博士(工学)．現在，同大学環境情 報学部教授．

disregarding the fact that operational costs of NIDS is high. Conventional NIDS dose not determine success and failure of detected attack. In this paper, in order to solve this problem, Session Based NIDS which cuts down the operational costs of NIDS is proposed, designed and implemented. Session Based NIDS is able to determine success and failure by monitoring the response against the detected attack. We have evaluated this new NIDS in the real network and show that the reduction of operation cost is achieved.

Key words “Internet-Security”, “Network-based IDS”, “Over Detection”, “Risk-Evaluation”