誤検知率評価

7.2.1 評価環境

False Positive^{の発生率を評価には}4種類の実運用ネットワークの通信データを用いた．意

図的にボットの通信を発生させている第7.1.3節の通信データとは異なり，通信データに含ま れるボット通信の件数を正確に把握するのは困難である．そのため，実運用ネットワークの 通信データはFalse Positiveの発生率調査のみに利用し，検知数は評価の対象としない．

表7.7は各通信データの概要を示しており，図7.2は各通信データの収集環境を示している．

D₁は筆者が定常的に運用している研究ネットワークの通信である．ファイヤウォールによっ て外部からの接続が遮断されているセグメントと，実験用に通信を制限していないセグメン トが存在している．D₂は4日間開催されたカンファレンスのネットワークである．特にファ イヤウォールなどによる通信制限はない．D₃はバックボーンネットワークであり，複数組織 が接続しているネットワークである．各組織の運用ポリシは様々であり，観測点は各組織内 ルータの上位となっている．D₄はD₁と同様のネットワークから取得した通信データだがD₁ とは取得時期が異なる．また各ネットワークにおいてWebサーバ，メールサーバ，DNS^サー バなどのサービスホストは各セグメント内部に設置されている．

インターネット 内部セグメント2 (/24程度) ミラーリング＆

通信データ収集

ルータ F/W

内部セグメント1 (/24程度)

インターネット 内部セグメント

(/22程度) ミラーリング＆

通信データ収集

ルータ

インターネット

複数内部セグメント (/15程度) ミラーリング＆

通信データ収集

ルータ

D

,D

D

D

図7.2: False Positive評価用通信データ取得環境概要

D_1,4の収集環境は研究用ネットワークであり，約250^{台が実験用ホスト，約}250^台が個人 利用のホストとなっている．個人利用のホストが接続するネットワークでは一般的利用形態 であるWeb閲覧，Eメール送受信，メッセンジャーサービスが多用されている．一方，実験 用ホストでは新しいプロトコルや独自のWebクライアント実装，自律的なWeb^{情報収集ツー} ルなどが動作している．そのため，一般的な企業・家庭ネットワークと比較して多様性があ るため，False Positiveが発生しやすい環境となっており，False Positive発生率の調査に適し ている．

検知には第7.1節の調査同様，本手法によるR1,2,3,4およびSnortを利用した．ただし，検知 結果が実際のボットの活動を検知したのかFalse Positiveなのかを判断するために，Snortで 利用したルールは第7.1.3節で検知されたもののみを利用した．また，収集および検査時期が 異なったため，R1,2,3とR4は異なるデータセットを用いて懸賞を実施した．

表7.8^にFalse Positive発生率調査の結果を示す．表は各データセットに対し，本手法がボッ

トの活動を検知したルールとSnortが検知したルールの各検知数を示している．ただし，パ ケットを検知対象とするSnortと複数のセッションを検知対象とする本手法とでは検知数の数 え方が異なるため，括弧内に一意な攻撃元IPアドレスの数を示している．本手法が検知した R₃は，ボットによる調査活動および攻略済みホストに対するWindows実行形式ファイルの送 信を検知するルールである．D1で発生した2,450^件とD3で発生した942^{件を調査したとこ} ろ，D1では17^個，D3では7^{個の外部の}IPアドレスから筆者らが運用するハニーポットに

表7.8: False Positive^評価結果

手法 ルール D₁ D₂ D₃ D₄

本手法 R1 0 0 0 -

R2 0 0 0 -

R₃ 17 (2450) 0 7 (942) -

R4 - - - 0

Snort BACKDOOR DoomJuice/mydoom.a 3 (7) 0 1 (1) -

backdoor upload/execute attempt

ボットの活動が確認されたIP^{アドレス数} 20 0 8 0

※ 全ての通信データにおいて検知数が0だったSnortのルール，および明示的にボットの活動を示しておらず誤 検知の可能性が高いルールは表から除外している

※ 数値が通信データ中でボットとして検知されたIPアドレス数，括弧内の数字が各種法での検知を示す

対して攻撃している通信であった．これはハニーポットのログからも同時間帯に攻撃があり，

Windowsの実行形式ファイルがハニーポットホストに送信されていたことを確認している．

よって，これらの検知結果はFalse Positiveではなくボットの活動であると判断できる．一方，

Snort^{が検知している}“BACKDOOR DoomJuice/mydoom.a backdoor upload/execute attempt”^は 既にボットに感染しているホストに対してWindows実行形式のファイルを送信する際のプロ トコルを検知している．D1で発生している7^件とD3で発生している1^{件も本手法の検知と同} 様にハニーポットへの攻撃であることを確認した．これらの結果から，両手法は共に第7.1.3 節でボットを検知したルールではFalse Positiveが発生していないことが明らかになった．ま た，同様にD4においてR4を検証した結果，False Positiveが発生しなかったことを確認した．

本手法とSnortの検知結果の内容を比較したところ，Snortと本手法が別のイベントを検知

していることが明らかになった．Snortで検知していたのは外部から内部への攻撃で，調査活 動をせずに1ホストに対する攻撃を検知していた．筆者らが運用しているハニーポットは検 体収集を目的としたNepenthesであり，攻撃受信後はボットの活動を一部のみ模倣する．そ のため，本手法では感染したホストとして検知しなかった．一方，本手法で検知したイベン トに対して追調査を実施したところ，第7.1.3^{節とは異なる}Snortのシグネチャによってボッ トの活動を検知した．

7.3 性能評価

本論文では実装の性能評価を変数に関連する処理に着目して実施した．ネットワークセキュ リティ監視の実装では，パケット処理の効率化に関する研究は多くあるため，これらを参考 にすればパターンマッチ検索の高速化や記憶容量の節約などが実現できる．本手法は従来の

0 50000 100000 150000 200000 250000 300000 350000 400000

0 20 40 60 80 100 120 140 160 180

Packet per Second

Nrv + Nvc Va=0.622

図7.3: MAWIトラフィックデータを用いた処理性能の測定

ネットワークセキュリティ監視手法に変数という概念を導入し実装しているため，変数の書 き込み，読み込み，検査などを実行する際に，どのように処理負荷が変化するかについて言 及し，実運用において本実装が利用できることを示す．

トラフィックを利用し，本実装の性能評価を実施した．評価にはMAWI Working Group Traffic Archive[26]で公開されている，観測点F^の2010^年5^月11日の通信データを用いた．本デー タは899.26秒間監視されたデータであり，2923.94MB，41,356,011のパケットが記録されて いる．出現したIPv4^{アドレスは}508,869^個，IPv6^{アドレスは}1,130個である．解析に用いた 環境はCPUがIntel(R) Core(TM) i7 CPU [email protected]，メモリが8GBである．通信データ はソリッドステートドライブ上に保存し，ディスクI/Oによる読み込み速度の低下を防いで いる．OS^はLinux 2.6^{，コンパイラには}g++ 4.4.1^{を用いた．}

評価では意図的に負荷をかけるルールを作成し，どのように性能が変化するかを測定した．

ルールは50種類用意し，それぞれ変数の保持数が一定で，読み込み回数と書き込み回数を変 化させている．書込み回数や読み込み回数，変数の保持数はルールの記述方法やトラフィック の性質によって大きく変化する．同一のルールを用いた場合でも書き込みが発生する条件に 一致するネットワークトラフィックが到着する確率によって，書き込み回数が変化し，保持し ている変数が変化し，条件として読み込まれる変数が変化する．そのため，本システムの定 常的な性能を示すのは極めて困難であるが，本評価では書き込み回数の変化が処理性能にど のような影響を与えるかを示すことを目的として，測定を実施している．

評価結果の指標とするために，第7.1節で用いたR_1,2,3を使って，実運用ネットワークのト ラフィックを観測した際に，発生する変数の平均保持数と読み込み，書き込みの平均発生回数 を測定した．MAWIから提供されている通信データはプライバシ配慮のため，パケットの取得 サイズが96バイトに制限されており，パケットのペイロード部分も変換されている．よって，

評価用ルールが正常に動作しないと見られるため，別途観測用のデータを用意した．観測は 第7.2節におけるD₁と同じ観測点で2010年5月12日に実施した．その結果，パケットが到 着した際に解析対象となるホストやセッションが保持していた変数の平均保持数は0.0331(^小 数点第4^{位以下切り捨て})であった．また，平均読み込み数と書き込み数は1.6631(^小数点第 4位以下切り捨て)となった．今後，新しいマルウェアの通信モデルに対応していくためには，

より多くのルールが必要になる．しかし，第7.1^節ではSnort^が3,387^{件のルールを用いてい} たのに対し，本手法は3件のルールしか適用していなかった．このことから，ルールが急速 に増えていくことは予想しにくいが，平均書き込み，読み込み数が約100倍の160回を目安 として考えることができる．

図7.3^{に測定結果を示す．}X^軸が1パケットあたりに発生した変数の書き込みおよび読み込 み数の平均，Y^軸が1秒間に処理したパケット数となっている．評価データでは変数の保持 数は平均して0.622になった（小数点第4位以下切り捨て）第6.3.3での分析通り，書き込み，

読み込み回数の増加は線形的に処理負荷を増加させていることがわかる．そして，図中では 変数の書き込みおよび読み込みの回数が160^{回を超えても，}50,000pps^{以上の性能を示してい} る．変数の保持数も平均して0.622であり，基準とした測定結果の約20倍となっている．

MAWIで提供されている通信データを参考にすると，平均パケットデータ長が約700バイト なので50,000pps^はおよそ280Mbpsに相当すると推定される．インターネット白書2007[76]

では1Gbps以上の回線を持つ企業は全体の9.7%^{であり，その他の}100Mbps^{以下の回線をも}

つ企業において監視する場合には，十分な性能を発揮していると言える．また，1Gbpsの回 線を持ちその帯域をすべて使い切っている企業でも約5台に分割して処理すれば十分に処理 できると言える．以上のことから，本システムは実運用ネットワークにおいても，利用可能 な性能をもつと言える．