セッション追跡型IDSを応用したIPSの設計と実装

Download Report

Transcript セッション追跡型IDSを応用したIPSの設計と実装

セッション追跡によるプロトコル
アノーマリの検知と対処
SING mizutani(B3)
Parent true
Road to Bachelor’s Paper
2004年秋
「ホストベース型防御機構の
設計と実装」(予定)
2004年春「Session Based IDSの
設計と実装」電子情報通信学会
和文論文誌 (投稿中)
2003年秋
「The Design and Implementation
of Session Based IDS」 USENIX
※ failed
2002年秋
「ホスト情報をもとにした
攻撃情報のリスク評価」
Bachelor’s Paper
卒業論文
「不正侵入に対する総合的な
セキュリティ環境の実現(仮)」
(あくまで予定)
2004年春
「セッション追跡によるプロトコル
アノーマリの検知と対処」
2003年春
「セッション追跡型IDSの設計と実装」
2003年1月 「IDSのログ視覚化システムの開発」
情報処理学会 DMSシンポジウム
2002年春 IDSログ視覚化システム「pigeye」の開発
問題点

Intrusion Prevention System (IPS)



遮断できない攻撃



攻撃と判断した通信を遮断
定型的、かつ確実な攻撃(ex:ワーム)を防御
未知の攻撃
非定型の攻撃(自作ツール等)
正常な通信を阻害する恐れ

Preventionが困難
アプローチ

厳密なプロトコルアノーマリは困難


ベンダの独自仕様、ユーザの設定ミス、アプリ
ケーションのバグ
悪意のある通信と判断できる要素


攻撃の可能性がある通信を検知、通信の追跡
内部ホストの応答
正常な応答の場合、攻撃の失敗、あるいは独自仕様、
設定ミス、バグなど
 異常な応答の場合、攻撃をうけた可能性

解決方法

プロトコルアノーマリから攻撃か否かを判断



正常とされている通信の方式を登録
反応を含めた通信を監視
攻撃の可能性がある通信



継続的に監視する事で判断
攻撃が成功したと考えられるホストへの内外とも
に拒否
被害の拡大を防止
具体例
正常な通信
成功コード(200) や
エラーコード(400等)
を含む応答
とても長いHTTP
GET Request
(入力ミス等)
HTTPのレスポンスコー
ドを含まない応答
とても長いHTTP GET
Request
(Exploit Codeを含む)
異常が発生
した通信
プロトコルアノーマリ防御に関する設計

Inlineモード



シグネチャによる検知



トラフィックの転送、遮断の設定
マルチプラットホーム
プロトコルの要求と応答をルールとして定義
数字、アルファベット、バイナリコードを指定するよう拡張
Out of scope


unknownなプロトコル(自作/非公開プロトコル)
暗号化されたトラフィック
防御機構の概要
異常のあった
通信を遮断
Layer-3
Layer-2
Interface-2
Interface-1
本実装
システム概要
Search Tracking
Signature
Search Signature
Search Trigger
Signature
Interface-1
Packet Capture
Interface-2
Reject
Address List
Forward
/ Drop
実装

C言語による実装


テスト環境



libpcap, libnet
Debian GNU/Linux testing 3.0
FreeBSD 5.2.1-Release
Session-Based IDSを拡張

http://www.sfc.wide.ad.jp/~mizutani/blitz
シグネチャ例
シグネチャの名前
TCP port 80へのアクセス
alert “Web Too-Long Request Attempt” tcp any->80 {
fac:(payload=0:3,”GET” & “HTTP/1.1”; payload_len=100: ;);
res:rp_p<1(payload!=0:12,”HTTP/1.1 \d\d\d”;);
} [drop: ever, all, 2;];
永続的に
パケットをdropさ
せるオプション
攻撃元、および
攻撃対象を遮断
2つ目のシグネ
チャ(3行目)を検
知したら適用
GETとHTTP/1.1を
含み、100byte以上
のパケットを最初に
検知
応答にHTTP/1.1と結果コ
ード(3桁の数字)が含まれ
なければ攻撃と判断
実験環境
Host-1 :
Lavie M LM500J
CPU: Pentium III 500MHz
Memory: 192MB
IF: 100Base-TX
OS: Debian GNU/Linux
testing 3.0
Host-2 :
ThinkPad X24
CPU: Pentium III 1.13GHz
Memory: 640MB
IF: 100Base-TX (On Board)
OS: Debian GNU/Linux
testing 3.0
This System :
Dell PowerEdge 1750
CPU: Xeon™ 2.4GHz
Memory: 512MB
IF: 100Base-TX
OS: Debian GNU/Linux testing 3.0
評価 (動作検証)

使用するシグネチャ




Port 80(HTTP)へのアクセス
100byte以上のGETリクエストを検知
応答にHTTPの結果コードがふくまれていなければ遮断
テストサーバプログラム


あらゆるリクエストに対してHTTPによるHTMLファイルを
返すサーバ
ただし、リクエストにバイナリコードが含まれると結果コー
ドを含まないデータが返される
評価 (動作検証)
リクエストの内容
リクエストの長さ
期待される動作
結果
テキストのみ
100byte未満
何もしない
何もしない
テキストのみ
100byte以上
発見だけする
発見だけする
バイナリ含む
100byte未満
何もしない
何もしない
バイナリ含む
100byte以上
発見、遮断する
発見、遮断する
評価 (速度測定)




Host-1,2 間で10MBのファイルをHTTPで転送(100回試行)
シグネチャ数 2055個
シングルユーザモード
インラインモード、kernelブリッジ、直接接続
平均速度
本システム
50.3026 Mbps
Linux kernel bridge
74.3930 Mbps
直接接続
74.4322 Mbps
今後の課題

転送・処理速度



UserLandで転送処理
パフォーマンスで劣る
改善策


kernelの機能(libipq on Linuxなど)を用いる
kernel中への実装
まとめ




既存の防御手法における問題点を指摘
セッション追跡による解決手法を提案
プロトコルアノーマリ機能追加のための設計
これを用いた防御機構を実装

DPSワークショップに論文提出予定

7月30日 論文提出