XenによるゲストOSの解析に 基づくパケットフィルタリング 安積 武志* 光来 健一** 千葉 滋* *東京工業大学 **九州工業大学
踏み台攻撃 sshで不正にログインされ、他のホストへ攻撃 検出したらその通信を 即座に制限する必要がある 特定ホストに対して大量のパケットを送信 サービスの妨害 不特定多数のホストにポートスキャン 更なる踏み台を求める 検出したらその通信を 即座に制限する必要がある 被害の拡大を防ぐため 大量の パケット 対象ホスト sshd 不 正 ロ グ イ ン
一般的なパケットフィルタリング 外部のファイアウォールによる通信制限 ポートやIPアドレス単位で通信を制限する 踏み台攻撃でない通信まで制限してしまう 制限が大雑把過ぎる メールサーバ ファイアウォール 25 不 正 ロ グ イ ン sshd 25 sendmail
きめ細かいパケットフィルタリング サーバ内部で通信制限 OS内部の情報も使って通信を制限する 通信制限を無効化される恐れがある 例:プロセスID、ユーザID ipfwやiptablesで利用可能 通信制限を無効化される恐れがある メールサーバ ファイアウォール 25 sshd 不 正 ロ グ イ ン 25 sendmail
提案:xFilter 仮想マシンモニタ(VMM)によるきめ細かい パケットフィルタリング 無効化することは難しい VMMはVMから隔離されているため ゲストOSの内部の情報を参照可能 メモリのバイト列を解析 VMからの通信はすべてVMM を通過する 物理マシン VM ゲストOS VMM xFilter パケット
システム構成 xFilterは2つの部分から構成される メモリ解析部 フィルタリング部 ゲストOSのメモリを解析して 通信の情報を取得 プロセスID、ユーザID フィルタリング部 パケットのヘッダを解析 ゲストOSの情報も使って フィルタリング VM ゲストOS 解析 パケット VMM xFilter フィルタ リング部 メモリ 解析部 依頼 破棄 送信
メモリ解析部 型情報を用いてゲストOSのメモリを解析 ページテーブルを 引いてアドレス変換 型情報はカーネルの デバッグ情報より取得 仮想アドレスから 物理アドレスへ 仮想メモリ 物理メモリ task_struct{ pid } task_struc{ pid }
通信情報の取得 Linux の場合の取得手順 プロセスID順につながっている GSレジスタ task_struct task_struct ・・・ files fdtab files_struct プロセスID ユーザID を取得 fdtable fd file private_data ポートやIPアドレスなどの情報 を取得 sk socket sock
deny ip(x, y) port(x, y) id フィルタリング部 ルールの例 deny ip(src, dst) port(src, dst) uid/pid フィルタリングのアルゴリズム パケットのヘッダ情報に マッチするルールがあるか なければ許可 マッチしたルールで uid/pid が指定されていれば、 通信一覧をメモリ解析部から取得 取得した一覧に一致するものがあれば破棄 ヘッダ情報 ip(x, y) port(x, y) ルール deny ip(x, y) port(x, y) id 通信一覧 : ip(x, y) port(x, y)
一括検査 キューにためておいてまとめて検査 パケット到着毎だとオーバーヘッドが大きい 検査を行う代わりにパケットをキューに入れる メモリ解析には時間がかかる その間は一貫性のためにゲストOSを停止 検査を行う代わりにパケットをキューに入れる 一定時間毎にキュー内のパケットをすべて検査 一回のメモリ解析で検査できる
キャッシュ機能 TCP通信に関しては検査結果をキャッシュする パケットのTCPヘッダを 解析してフラグを取得 同じコネクションならば検査結果は変わらない パケットのTCPヘッダを 解析してフラグを取得 SYN:コネクションの確立 →フィルタリング結果をキャッシュ FIN:コネクションの終了 →キャッシュからエントリを削除 VM OS プロセス SYN パケット FIN パケット VMM xFilter
Xenを用いた実装 VMMとして Xen、ゲストOSとして Linux を使用 ドメイン0にxFilterを実装 ドメインU: 一般のVM ドメイン0にxFilterを実装 ドメインUがパケット を送信するときは ドメイン0に依頼 domain0 domainU xFilter プロ セス メモリ 解析 driver netback netfront Xen VMM
実装(メモリ解析部) ドメイン0のユーザランドプロセスとして実装 ドメインUのメモリマップ 解析結果をシステムコールで通知 仮想アドレスから メモリフレーム番号を取得 ドメイン0のプロセスの アドレス空間にマップ 解析結果をシステムコールで通知 domain0 domainU xFilter プロ セス analyzer メモリ 解析 syscall filter driver netback netfront Xen VMM
実装(フィルタリング部) ドメイン0のカーネル内に実装 一定時間毎にanalyzer がメモリを解析 netback ドライバと 実デバイスの間 一定時間毎にanalyzer がメモリを解析 システムコールハンドラ でフィルタリング domain0 domainU xFilter プロ セス analyzer メモリ 解析 syscall filter driver netback netfront Xen VMM
実験 ドメインU上で Apache 2.0 を動作 クライアントマシンで httperf 0.9.0 を動作 3918byteのHTMLファイルに100リクエスト/sで送信 パケットの送信が許可されている状態で測定 実験環境 Athlon 64 Processor 3500+, 1Gbyte Xen 3.3.0 (x86_64) domain0:Linux 2.6.18.8, 512Mbyte domainU:Linux 2.6.18.8, 256Mbyte
メモリ解析のオーバーヘッド メモリ解析の詳細を調査 実験結果 一括検査の間隔:50ms 1回のメモリ解析にかかる時間:平均15.4ms プロセス数:74 マップしたページ数:148
性能実験 実験結果 処理時間とCPU使用率はトレードオフの関係 200msの場合性能が悪い 10ms以下では処理時間は短くならなかった タイムアウトするパケットがあったため 10ms以下では処理時間は短くならなかった メモリ解析がボトルネック
キャッシュ機能による性能改善 実験結果 キャッシュによってリクエスト処理時間を57.2ms削減できた 処理時間はコネクション確立にかかる時間+レスポンス 1コネクション1リクエストで実験 コネクション成立にかかる時間は改善されない まだキャッシュはないため レスポンスは大幅に向上 キャッシュにヒットするため
関連研究 Livewire [Gerfinkel et al. ’03] identd [RFC 1413] ステートフルインスペクション VMMでVMの侵入検知 VMのメモリを解析してプロセスの情報を取得 identd [RFC 1413] TCPを張ったユーザのIDを取得することができる 正しい情報を返す保証がない ステートフルインスペクション SYNパケットはルールベースで、それ以降はステートテーブルでチェック
まとめと今後の課題 xFilterを用いたVMMによるフィルタリングを提案 今後の課題 送信元のプロセスやユーザを指定してフィルタリング 踏み台攻撃に対して安全かつきめ細かい通信制限が可能 VMのメモリを解析してゲストOS内の情報を取得 カーネルの型情報を利用 今後の課題 メモリ解析部をVMM内に実装する VMのメモリを直接参照できる オーバーヘッドを削減