セッション追跡型IDSの設計と実装

セッション追跡型IDSの設計と実装
The Design and Implementation of
Session Tracking IDS
mizutani@sing (B2) 親:true
背景
「侵入検知システム（IDS）は、コストがかかる非
効率的なセキュリティ対策である。2005年ま
でにIDSの導入は廃れるだろう」
「24時間7日間体制で監視の必要があるため、
情報システム担当部門の負担が大きい」
(“Information Security Hype Cycle“ Gartner [U.S.] )
背景
 IDS (Network Based Intrusion Detection
System)
 攻撃トラフィックのみでアラートを検知
 既存IDSのアラートの内訳
 攻撃が行われ，成功したアラート．
 攻撃が行われ，失敗したアラート．
 誤検知 (Positive False)
 成功，失敗の判定は行わない
問題点
 全てのアラートの成功・失敗を調査
 リスクの大小に関わらず調査
IDSの運用には多大なコストが必要
 インシデントレスポンスの遅れ
 インシデントの見逃し
解決手法
 セッションの追跡
 Attackerの攻撃Traffic
 Targetの応答Traffic
 攻撃の発見＆攻撃成功・失敗判別
 Ex)
 Backdoor “root.exe”
 Nimda Warmが設置
 HTTPで ”GET /root.exe” とすることで第三者
が侵入可能
アラート検知（既存のIDS）
GET /root.exe
GET /root.exe
Target-A
Attacker
Alert
Alert
Normal IDS
Target-B
アラート検知（セッション追跡IDS）
GET /root.exe
200 OK
GET /root.exe
Target-A
Attacker
Exploded
!
404 Not Found
Failur
e
Session Tracking IDS
Target-B
得られる結果
 攻撃の成功を検知
 管理者に即座に通知
 成功・失敗確認の手間を省く
IDSの運用コストを削減
設計（想定される環境）
IDS
Segment α
Mirroring
Segment β
BackBone
Router
Segment γ
設計 (IDS Works)
Packet
Capture
Search Flow
Not Found
Detected
Add Flow
Search Unit Signature
Search Signature
Not Found
Detected
Add Unit Signature
設計（セッション管理機能）
 内部ネットワークのノードをキーにして検索
Ex) 198.120.100.1 -> 203.178.143.109
Internal Network Segment Internal Network Nodes
203.178.139.192/26
203.178.143.0
External Network Nodes
203.196.192.168
203.178.143.1
192.120.100.1
203.178.143.0/25
203.178.143.109
203.178.143.127
203.178.143.128/25
203.178.143.128
211.10.16.64
Session Information
- Unit Signature
- Timestamp
設計 (セッション追跡)
Normal Signature
Unit Signature
Packet Detected
Pattern1
動的に生成
Packet Pattern2
Session
Detected
Packet
Pattern2
Pattern3
Packet Pattern3
 Normal SignatureからPattern1にマッチするものを検索
 Pattern1を検知後，Pattern2から動的にSignatureを生
成(Unit Signature)
 以後，当該セッションではUnit Signatureを検索
設計（シグネチャ）
tcp IN (title:“Root.exe attempt”; dport=80; flags=AP; payload=“root.exe”;)
=[out:7]>
(flow=OUT; sport=80; flags=AP; payload!="404";);
 基本設定
 $Protocol = {tcp, udp, icmp, ip}
 $Direction = {IN, OUT}
設計（シグネチャ）
tcp IN (title:“Root.exe attempt”; dport=80; flags=AP; payload=“root.exe”;)
=[out:7]>
(flow=OUT; sport=80; flags=AP; payload!="404";);
 Packet Pattern






複数設定可能
title : アラートの名称
dport / sport : Distenation Port / Source Port
flags : TCP Flags
payload : TCP Payload or UDP Payload
flow : pattern2以降の方向
設計（シグネチャ）
tcp IN (title:“Root.exe attempt”; dport=80; flags=AP; payload=“root.exe”;)
=[out:7]>
(flow=OUT; sport=80; flags=AP; payload!="404";);
 Keeping Condition
当該セッション中でー
 out
: 外部ネットワーク宛のパケットをN個発見
 in
: 内部ネットワーク宛のパケットをN個発見
 time : N秒経過（タイムアウト）
実装
 OS
 RedHat Linux 9.0 (kernel 2.4.20-8)
 Debian GNU/Linux 2.3 testing (kernel 2.2.21)
 C言語
 libpcap
 http://www.sfc.wide.ad.jp/~mizutani/term20
03s/witch-0.0.2.tar.gz
デモ
 root.exeを利用した侵入の例
今後の課題１
 さらに高速化
 シグネチャの検索方法
 データ構造 / flow statusの持ち方
 アラート機能の充実
 リモートマネージャーへの出力
 DBへのログ出力
 メールでの通知
今後の課題２
 シグネチャの設定項目の追加
 Payload offset
 IP Protocol,
 IP Datagram size... etc.
 シグネチャ数の充実
 Snortのルール等参考に
 RG-NETでの実運用
 秋学期始まるまで目安に

Download Report