仮想マシンモニタによる
きめ細かい
パケットフィルタリング
安積 武志* 光来 健一** 千葉 滋*
*東京工業大学
**九州工業大学
踏み台攻撃
sshで不正にログインされ、他のホストへ攻撃
特定ホストに対して大量のパケットを送信
サービスの妨害
不特定多数のホストにポートスキャン
更なる踏み台を求める
大量の
パケット
検出したらその通信を
即座に制限する必要がある
被害の拡大を防ぐため
対象ホスト
スパム
ソフト
一般的な対処法
外部のファイアウォールによる通信制限
ポートやIPアドレス単位で通信を制限する
踏み台攻撃でない通信まで制限してしまう
制限が大雑把過ぎる
ファイアウォール
メールサーバ
port:25
スパム
ソフト
port:25
sendmail
従来のきめ細かい対処法
サーバ内部で通信制限
OS内部の情報も使って通信を制限する
例：送信元のプロセス名、所有者
ipfwやiptablesで利用可能
通信制限を無効化される恐れがある
メールサーバ
ファイアウォール
port:25
port:25
スパム
ソフト
sendmail
xFliter
仮想マシンモニタ（VMM）におけるきめ細かい
フィルタリング
仮想マシン（VM）でサーバを
立ててVMMでフィルタリング
すべてのパケットを検査できる
VMから隔離されているので安全
ゲストOSの内部のプロセス情報
を利用
VMのメモリを解析して取得
物理マシン
VM
ゲストOS
VMM
xFilter
xFilterの構成
フィルタモジュール
xFilter本体からパケット
情報を受け取る
メモリ解析して必要な情
報を取得
VM
プロセス
ゲストOS
パケット
プロセス名、ユーザIDなど
解析
VMM
フィルタリングルールに基
づいて判断を本体に返す
xFilter
破棄
送信
フィルタ
モジュール
フィルタリングの流れ
VM
xFilterにルールを追加
ルールに基づき特定のプロ
セス、ユーザからの通信のみ
遮断できる
ヘッダ情報からプロセスを特定
スパム
ソフト sendmail
ゲストOS
パケット
プロセス情報を取得
解析
VMM
xFilter
指定するプロセス名、ユーザIDは
通信一覧表示機能から
破棄
送信
フィルタ
モジュール
開発時のシステム構成
ユーザランドでモジュール
を動作
ゲストOSのメモリを参照
するためにVMMの機能
VM
プロセス
解析
フィルタ
モジュール
ゲストOS
メモリマップ
フィルタリング性能は低下
パケット
syscall
VMM
クラッシュしても立ち上げ
なおすだけで良い
VMM内だとシステム全体が
クラッシュする危険性
xFilter
破棄
送信
Xenを用いた実装
VMMとして Xen、ゲストOSとして Linux を使用
ドメインUからのパケットはドメイン０を通過
netfrontからnetbackへ
netbackから実ドライバへ
netbackと実ドライバの間
にxFilterを実装
domain0
process
driver netback
xFilter
domainU
フィルタモジュールとは
ハイパーコールでやり取り
hypercall
module
netfront
メモリ
解析
Xen VMM
メモリ解析
型情報を用いてゲストOSのメモリを解析
型情報はカーネルのデバッグ情報より取得
init_task
プロセスID順に
リンクされている
task_struct
files_struct
fdtab
file
private_data
task_struct ・・・ task_struct
files
ルールに一致
プロセス名
すればsock
fdtable
ユーザID
までたどる
fd
を取得
socket
sk
sock
ポートやIP
アドレスなど
の情報
を取得
一貫性
メモリ解析の前にゲストOSをpause
カーネルがtask_structを操作していないことを確認
task_structのリストの spinlock をチェック
ロックが取られていなければメモリ解析を行う
メモリ解析の後にゲストOSをunpause
アドレス変換
VMMからゲストOSにアクセスするためには
アドレス変換が必要
ドメインU上のアドレスは仮想アドレスを使用
VMM上ではマシンメモリアドレスを使用
仮想メモリ
マシンメモリ
VM
ページ
テーブル
task_struct{
pid
}
task_struc{
pid
}
VMM 仮想アドレス
変換
xFilter
テーブル
マシン
アドレス
解析結果のキャッシュ
TCP通信に関しては検査結果をキャッシュする
同一コネクションの通信は結果が変わらない
パケットのTCPヘッダを解析してフラグを取得
SYN:コネクションの確立
→フィルタリング結果をキャッシュ
FIN:コネクションの終了
→キャッシュからエントリを削除
パケット
受信
xFilter
miss フィルタ
キャッシュ
モジュール
hit
ユーザランドの実装
メモリマップ
ページテーブルを引いて
マシンメモリを取得
ドメイン0のプロセスの
アドレス空間にマップ
Xenの機能を用いる
domain0
domainU
メモリ
解析
module
syscall
xFilter
driver netback
システムコールで本体に
解析結果を通知
process
Xen VMM
netfront
一括検査
キューにためておいてまとめて検査
パケット到着毎だとオーバーヘッドが大きい
メモリ解析には時間がかかる
その間は一貫性のためにゲストOSを停止
検査を行う代わりにパケットをキューに入れる
一定時間毎にキュー内の パケット
受信
パケットをすべて検査
xFilter
一回のメモリ解析で検査できる
キュー
フィルタ
モジュール
実験
xFilterのオーバーヘッドを測定
ドメインU上で Apache 2.0 を動作
クライアントマシンで httperf 0.9.0 を動作
3918byteのHTMLファイルにリクエストを送信
パケットの送信が許可されている状態で測定
実験環境
Intel Core i7 860
Xen 3.4.2 (x86_64)
domain0:Linux 2.6.18.8, 7Gbyte
domainU:Linux 2.6.18.8, 1Gbyte
ルールに一致するプロセスがない状態での性能を測定
リクエストのレートを100、200、300、400、500のそれぞれ
について測定した
リクエスト処理時間はコネクションを張り始めてから終了するま
での時間
0.45
実験結果
レート500まで処理時間に
影響はなかった
メモリ解析にかかる時間は
平均19μsだった
リクエスト処理時間(ms)
0.4
0.35
0.3
0.25
xFilterあり
xFilterなし
0.2
0.15
0.1
0.05
0
100
200
300
リクエストレート
400
500
検査するソケット数と性能
ルールに指定したプロセスがオープンしているソケット
数を変えてオーバーヘッドを測定
ソケット数0、10、20、30、40、50で測定
0.7
実験結果
ルールにマッチするソケット数
が増えると、オーバーヘッドが
大きくなる
メモリ解析にかかる時間も
同様に増加
50ソケットで平均35μs
0.6
リクエスト処理時間(ms)
0.5
0.4
xFilterあり
xFilterなし
0.3
0.2
0.1
0
10
20
30
ソケット数
40
50
キャッシュを有効にした場合
検査結果をキャッシュした場合の性能を測定
リクエストレートは100req/s
ルールにマッチするソケットを50
0.7
実験結果
オーバーヘッドを削減できた
一旦コネクションを張れば結果
がキャッシュされるため
レスポンス性能が向上
→キャッシュは充分に効果がある
0.6
リクエスト処理時間（ms）
0.5
0.4
レスポンス
コネクション
0.3
0.2
0.1
0
xFilterなし
キャッシュon
キャッシュoff
開発時の性能
ドメイン0でフィルタモジュールを動作させた場合の
性能を測定
ルールに一致するプロセスがない状態の性能
35
実験結果
毎秒100リクエストでもかなり
大きなオーバーヘッド
レートが上がるとさらに増加
開発時であれば問題ない
実用には使えない
30
リクエスト処理時間(ms)
25
20
xFilterあり
xFilterなし
15
10
5
0
100
200
リクエストレート
300
関連研究
Livewire [Gerfinkel et al. ’03]
identd [RFC 1413]
VMMでVMの侵入検知
VMのメモリを解析してプロセスの情報を取得
TCPを張ったユーザのIDを取得することができる
正しい情報を返す保証がない
ステートフルインスペクション
SYNパケットはルールベースで、それ以降はステート
テーブルでチェック
まとめと今後の課題
xFilterを用いたVMMによるフィルタリングを提案
送信元のプロセスやユーザを指定してフィルタリング
踏み台攻撃に対して安全かつきめ細かい通信制限が可能
VMのメモリを解析してゲストOS内の情報を取得
カーネルの型情報を利用
今後の課題
ルールの実装を完成させる
受信パケットについても実装を行う
現在は送信パケットのみの実装
© Copyright 2024 ExpyDoc
