仮想マシンモニタによる きめ細かい パケットフィルタリング 安積 武志*　光来 健一**　千葉 滋* *東京工業大学 **九州工業大学

踏み台攻撃 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本体からパケット情報を受け取る メモリ解析して必要な情報を取得 プロセス名、ユーザIDなど フィルタリングルールに基づいて判断を本体に返す VM プロセス ゲストOS パケット 解析 VMM xFilter　　　　　　　　 フィルタ モジュール 破棄 送信

フィルタリングの流れ xFilterにルールを追加 ルールに基づき特定のプロ セス、ユーザからの通信のみ 遮断できる ヘッダ情報からプロセスを特定 プロセス情報を取得 指定するプロセス名、ユーザIDは 通信一覧表示機能から VM スパム ソフト sendmail ゲストOS パケット 解析 VMM xFilter　　　　　　　　 フィルタ モジュール 破棄 送信

開発時のシステム構成 ユーザランドでモジュール を動作 ゲストOSのメモリを参照 するためにVMMの機能 クラッシュしても立ち上げ メモリマップ フィルタリング性能は低下 クラッシュしても立ち上げ 　 なおすだけで良い VMM内だとシステム全体が 　 クラッシュする危険性 VM プロセス 解析 フィルタ モジュール ゲストOS パケット syscall VMM xFilter 破棄 送信

Xenを用いた実装 VMMとして Xen、ゲストOSとして Linux を使用 ドメインUからのパケットはドメイン０を通過 netfrontからnetbackへ netbackから実ドライバへ netbackと実ドライバの間 にxFilterを実装 フィルタモジュールとは ハイパーコールでやり取り domain0 domainU process driver netback netfront xFilter メモリ 解析 hypercall 　　　　Xen VMM module

メモリ解析 型情報を用いてゲストOSのメモリを解析 型情報はカーネルのデバッグ情報より取得 init_task task_struct ・・・ プロセスID順にリンクされている files ルールに一致 すればsock までたどる fdtab files_struct プロセス名 ユーザID を取得 fdtable fd file private_data ポートやIPアドレスなどの情報 を取得 sk socket sock

一貫性 メモリ解析の前にゲストOSをpause メモリ解析の後にゲストOSをunpause カーネルがtask_structを操作していないことを確認 task_structのリストの spinlock をチェック ロックが取られていなければメモリ解析を行う メモリ解析の後にゲストOSをunpause

アドレス変換 VMMからゲストOSにアクセスするためには アドレス変換が必要 ドメインU上のアドレスは仮想アドレスを使用 仮想メモリ マシンメモリ VM ページ テーブル task_struct{ pid } task_struc{ pid } VMM 仮想アドレス 変換 テーブル xFilter マシン アドレス

解析結果のキャッシュ TCP通信に関しては検査結果をキャッシュする 同一コネクションの通信は結果が変わらない SYN:コネクションの確立 →フィルタリング結果をキャッシュ FIN:コネクションの終了 →キャッシュからエントリを削除 パケット 受信 xFilter miss フィルタ モジュール キャッシュ hit

ユーザランドの実装 メモリマップ システムコールで本体に 解析結果を通知 ページテーブルを引いて マシンメモリを取得 ドメイン0のプロセスの アドレス空間にマップ Xenの機能を用いる システムコールで本体に 解析結果を通知 domain0 domainU メモリ 解析 process module syscall xFilter driver netback netfront Xen VMM

一括検査 キューにためておいてまとめて検査 パケット到着毎だとオーバーヘッドが大きい 検査を行う代わりにパケットをキューに入れる メモリ解析には時間がかかる その間は一貫性のためにゲスト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のそれぞれ について測定した リクエスト処理時間はコネクションを張り始めてから終了するまでの時間 実験結果 レート500まで処理時間に 影響はなかった メモリ解析にかかる時間は 平均19μsだった

検査するソケット数と性能 ルールに指定したプロセスがオープンしているソケット数を変えてオーバーヘッドを測定 実験結果 ソケット数0、10、20、30、40、50で測定 実験結果 ルールにマッチするソケット数 が増えると、オーバーヘッドが 大きくなる メモリ解析にかかる時間も 同様に増加 50ソケットで平均35μs

キャッシュを有効にした場合 検査結果をキャッシュした場合の性能を測定 実験結果 リクエストレートは100req/s ルールにマッチするソケットを50 実験結果 オーバーヘッドを削減できた 一旦コネクションを張れば結果 がキャッシュされるため レスポンス性能が向上 →キャッシュは充分に効果がある

開発時の性能 ドメイン0でフィルタモジュールを動作させた場合の 性能を測定 ルールに一致するプロセスがない状態の性能 実験結果 毎秒100リクエストでもかなり 大きなオーバーヘッド レートが上がるとさらに増加 開発時であれば問題ない 実用には使えない

関連研究 Livewire [Gerfinkel et al. ’03] identd [RFC 1413] ステートフルインスペクション VMMでVMの侵入検知 VMのメモリを解析してプロセスの情報を取得 identd [RFC 1413] TCPを張ったユーザのIDを取得することができる 正しい情報を返す保証がない ステートフルインスペクション SYNパケットはルールベースで、それ以降はステートテーブルでチェック

まとめと今後の課題 xFilterを用いたVMMによるフィルタリングを提案 今後の課題 送信元のプロセスやユーザを指定してフィルタリング 踏み台攻撃に対して安全かつきめ細かい通信制限が可能 VMのメモリを解析してゲストOS内の情報を取得 カーネルの型情報を利用 今後の課題 ルールの実装を完成させる 受信パケットについても実装を行う 現在は送信パケットのみの実装