IDSの現状と課題(2)


●IDSの構成

カリフォルニア大学デービス校の研究グループが共通侵入検知フレームワーク(CIDF:Common Intrusion Detection Framework)というものを提案中。この中で説明されているIDSの一般的な構成は以下の4つ。

・イベント生成部

 →監視対象となるホストやネットワークからイベント情報(データ)を入手するセンサ機能を実現。
 →センサの情報はOSやアプリケーションによって生成されるログやネットワークモニタリング・デバイスからの入力情報などから得る。
 →イベント取得の形態によりネットワークベースとホストベースに分類される。


・イベント分析部

 →イベント生成部において取得した情報やデータベース中の情報を分析し、侵害状況を特定する。
 →その際に使用する方法として異常検出(anomaly detection)と不正検出(misuse detection)がある。

 異常検出:正常時に作成されたプロファイルと比較して、その差があまりにも大きいときに異常として検出する。
 不正検出:ウィルスソフトのように、事前に登録されたシグネチャと比較して不正を検出する。



・イベントデータベース

 →イベント情報やその分析結果を格納する。
 →このデータベースをもとに記録を視覚化してシステムの状況を把握することができる。


・レスポンスユニット

 →イベント分析部によるセキュリティ侵害の検出を受け、管理者への通知・防御機構の自動制御などの対応処理を行う。
 →レスポンスユニット機能として下の2つがある。

 通知機能:侵害検出を何らかの方法で管理者等に知らせる。
 自動対応機能:セキュリティ侵害を受けた後、発信元を追求するための処理を可能な範囲で自動的に行う機能。



●現状と課題

 ・検出精度
 フォールスネガティブ(FN):実際に侵入が行われているにもかかわらず警報を発しないこと。
 →不意急襲に行われる不正行為に対応できないのが問題。
 フォールスポジティブ(FP):侵入が行われていないにもかかわらず警報を発してしまうこと。
 →警報に対するユーザの信頼を低下させ、システムの信用喪失へとつながる

▲FNとFPの中間を探し出すのが大変でなかなか難しい。


 ・ネットワークプロトコル処理
 挿入と回避攻撃(Insertion and Evation Attack)
 →パケットの細分化や順序の入れ替えなどプロトコル特有の機能を使用することにより、監視を回避することができる場合がある。
 →OSそれぞれにおけるTCP/IPスタック実装の微妙な違いを利用して、あるOS上のIDSでは検知されるが違うOS上では検知されないといったパケットの混入がある。

▲プロトコル寄りの問題であり、解決するには多くの労力と時間がかかる


 ・スケーラビリティ
 →特にネットワーク型IDSはネットワーク上の通信を監視するため、ネットワークの大きさや通信量によってその性能が問題となってくる。
 →IDS自体に対するDoS攻撃も考えられるため、IDSの負荷に関しては慎重に考えるべき問題である。

▲単にIDS自体の性能を上げれば済む問題であるのか?


 ・検知アルゴリズム
 →IDSはもともと異常検出の手法から研究が始まっているが、現在ではシグネチャと比較する不正検出の手法がさかんになっている。
 免疫アプローチ:生物における免疫が「自己」と「他者」を区別するメカニズムを利用してシステムに応用する手法。
 →しかし実際本質的に「免疫」という言葉であらわすことができるモデルは未だ確立されていない。

▲これらを利用して最適なアルゴリズムを考えることはできないか?


 ・検出対象の定義
 →IDSの利用目的に応じてどんな種類の異常を検出したいのかは異なってくる。
 →結局これを設定するのはシステムの管理者が行うことになる。
 →データベースの調節が大変な作業になる。

▲システム側で自動的に必要なデータだけを集める仕組み(学習型IDSみたいなもの?)を作成できないか?



●IDS(Snort)を試験的に作成してみる

◎今回利用したIDS:〜Snort〜

・とにかくSnortを動かしてみる!
・実行結果(Snortを動かしているコンピュータを対象に他のコンピュータからnmapポートスキャンを実行した結果)
   04/24-16:33:36.124644 203.216.243.227:80 -> 192.168.0.3:1158
   TCP TTL:51 TOS:0x0 ID:58084 IpLen:20 DgmLen:52 DF
   ***A***F Seq: 0x9AFB032B  Ack: 0x45E7816F  Win: 0xFFFF  TcpLen: 32
   TCP Options (3) => NOP NOP TS: 889918527 234308
   =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   04/24-16:33:36.125376 192.168.0.3:1158 -> 203.216.243.227:80
   TCP TTL:64 TOS:0x0 ID:60732 IpLen:20 DgmLen:52 DF
   ***A***F Seq: 0x45E7816F  Ack: 0x9AFB032C  Win: 0x1B58  TcpLen: 32
   TCP Options (3) => NOP NOP TS: 234310 889918527
   =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   04/24-16:33:36.137985 203.216.243.227:80 -> 192.168.0.3:1158
   TCP TTL:51 TOS:0x0 ID:58099 IpLen:20 DgmLen:52 DF
   ***A**** Seq: 0x9AFB032C  Ack: 0x45E78170  Win: 0xFFFF  TcpLen: 32
   TCP Options (3) => NOP NOP TS: 889918529 234310
   =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   04/24-16:33:36.957952 192.168.0.3:1125 -> 203.216.243.227:80
   TCP TTL:64 TOS:0x0 ID:42084 IpLen:20 DgmLen:52 DF
   ***A***F Seq: 0x45E02EBB  Ack: 0x2652BE7C  Win: 0x43E0  TcpLen: 32
   TCP Options (3) => NOP NOP TS: 234394 889917577
   =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   04/24-16:33:36.971848 203.216.243.227:80 -> 192.168.0.3:1125
   TCP TTL:187 TOS:0x0 ID:22953 IpLen:20 DgmLen:40 DF
   *****R** Seq: 0x2652BE7C  Ack: 0xFA9CD92D  Win: 0x0  TcpLen: 20
   =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   04/24-16:33:37.980465 192.168.0.3:1142 -> 203.216.247.248:80
   TCP TTL:64 TOS:0x0 ID:6811 IpLen:20 DgmLen:52 DF
   ***A***F Seq: 0x46628CE8  Ack: 0x2A06E027  Win: 0x21F0  TcpLen: 32
   TCP Options (3) => NOP NOP TS: 234496 889921672
   =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
                  :
                  :
                  :

◎問題点

*ログの見方が今の時点ではさっぱりわからない。
*今回は自分自身を監視の対象にしたため、今後はネットワーク下にある様々なコンピュータを監視の対象としたい。



●参考資料

・武田圭史:侵入検知システムに関する研究の現状,「情報処理」Vol.42, No.12, pp.1169-1174, 社団法人情報処理学会(2001年12月)

・@IT:Snortでつくる不正侵入検知システム  http://www.atmarkit.co.jp/fsecurity/rensai/snort01/snort01.html