Transcript Get Slide

セキュリティ機構のオフロード時の
性能分離
新井 昇鎬* 光来 健一** 千葉 滋*
*東京工業大学
**九州工業大学 / CREST
2
セキュリティ機構のオフロード
• 外部にサービスを提供している仮想マシンの外へ
出す
▫ セキュリティが向上
 仮想マシンが攻撃されてもセキュリティ機構まで影響が
及びにくい
 セキュリティ機構のポリシやログなどの
仮想マシン
データの改竄を防ぐ
• セキュリティ機構とは？
▫ 侵入検知システム
▫ ファイヤーウォール
▫ アクセス制御
セキュリティ
機構
3
仮想マシンを利用したオフロードの例
• Snort のオフロード
▫ ドメイン０で通信パ
ケットを監視可
ドメイン０
オフロード元の
仮想マシン
Snort
• Tripwire のオフロード
 ドメイン０でファイル
システムを検査可
ドメイン０
オフロード元の
仮想マシン
Tripwire
ディスク
イメージ
パケット
Xen
Xen
4
仮想マシン間の性能分離の問題
• しかし、オフロードすると性能分離ができなくなる
▫ 性能分離とは
 各仮想マシンの性能を保障すること
▫ オフロードしたセキュリティ機構により、他の仮想マシンの
CPU 40%
CPU 50%
使える資源が減少
20%
Web
サーバ
セキュリティ
機構
VMM
5
性能分離の問題が生じる例
• Snortの場合
▫ オフロード元 VM に大量のパケットが送受信されたと
き
 Snort にも負荷がかかる
• Tripwireの場合
▫ ファイルシステムを検査するとき
 Tripwire だけで大量の資源
を消費
CPUを大量
に消費
オフロード元の
仮想マシン
Snort
VMM
6
提案: OffloadCage
• オフロードしたセキュリティ機構を考慮して性
能分離を実現
▫ セキュリティ機構とオフロード元 VM をひと
まとまりとしてスケジューリング
 合計としてオフロード元 VM の制限を守る
＋
VMM
7
システム構成
• OC-Monitor
▫ セキュリティ機構が使
用した資源を監視
▫ 監視した資源の量を
OC-Scheduler に通知
• OC-Scheduler
▫ オフロードを考慮して仮
想マシンをスケジューリ
ング
ドメイン０
オフロード元
の仮想マシン
OC-Monitor
セキュリティ
機構
OC-Scheduler
VMM
8
OC-Monitor (1)
定期的に
計測・通知
• セキュリティ機構のCPU使用率を計測
▫ VMM 全体に対しての使用率
▫ /proc /pid/stat を利用
• オフロード元 VM とセキュリティ
機構を関連付ける
▫ オフロード元はドメインIDで指定
OC-Monitor
20
セキュリティ
機構
• モニタするセキュリティ機構はプロセス ID で指定
ハイパーコール
OC-Scheduler
9
OC-Monitor (2)
• 監視しているセキュリティ機構の CPU 使用率を制
限可
▫ セキュリティ機構だけでオフロード元の制限を超えさ
せない
 Tripwire などは動作すると検査するだけで大量の CPU
を消費
▫ 停止、動作させたりして制限を守る
 現段階では、cpulimitを利用
CPU 使用率を
制限
OC-Monitor
セキュリティ
機構
10
OC-Scheduler
• セキュリティ機構が使った資源をオフロード元の仮
想マシンのものとしてスケジューリング
▫ セキュリティ機構が使用した分だけ、オフロード元の
使用できる CPU 時間は減少
• クレジットスケジューラを改良
▫ Xenの仮想マシンスケジューラ
▫ debt パラメータを追加
 OC- Monitor からのハイパーコールで debt を更新
仮想マシン
クレジットスケジューラ
• クレジット
▫
▫
▫
▫
仮想マシン 仮想マシン
11
over
under
仮想
仮想
CPU
CPU
under
仮想
CPU
物理 CPU を使用できる量
30ms ごとに仮想 CPU に配布
物理
CPU
10ms ごとに減少
クレジットが正の仮想 CPU が優先
• 30ms ごとに仮想 CPU を切替
物理CPUを使用している
仮想CPUのcreditの変化
200
100
0
-100
クレジット
10ms
20ms
30ms
12
クレジットの計算方法
• weight、capのそれぞれからクレジットを計算
▫ weight …総 weight 数と比較する値
▫ cap … 最大 CPU 使用率を表す値
▫ 結果の小さい方を配布
weight
cap: 60
weight:256
cap
配布
256 : 256
60 : 40
仮想マシンＡ
仮想マシンＢ
cap: 40
weight: 256
13
OC-Scheduler によるクレジットの計算方法
• オフロードしたセキュリティ機構のCPU 使用分をオフ
ロード元 VM から減少
仮想マシンＡ 仮想マシンＢ
• debt パラメータを利用
▫ セキュリティ機構の CPU 使用率
weight
セキュリティ
機構
cap: 60
weight:256
debt: 0
cap
配布
cap: 40
weight: 256
debt : 20
14
実験
• Snort と Tripwire をオフロード
• オフロードした場合の仮想マシン間の性能の分離を
確かめる
• 実験環境
▫ オフロードなし、オフロードあり、OffloadCage の３つの
場合で比較
▫ マシン




CPU：Athlon™ 2.2GHz (コア１)
メモリ：2 GB
VMM : Xen3.3.0 (x86_64)
OS：Linux Kernel 2.6.18
15
Snort のオフロード
• 実験内容
40%
httperf
web
▫ オフロード元はウェブサーバ
▫ 外部のマシンから攻撃
 httperf を使用
▫ オフロード元には cap を40
snort
httperf
 最大 CPU 使用率 40%
web
snort
httperf
web
snort
実験: Snort とオフロード元 VM の CPU 使
用率の合計
• オフロードすると制限を大幅
に超えている
• OffloadCage
▫ オフロードしてもオフロー
ド元 VM の制限を守れて
いる
• オフロードなし場合はオフ
ロード元 VM のCPU使用率
CPU 使用率%
16
オフロードなし
オフロードあり
OffloadCage
90
80
70
60
50
40
30
20
10
0
0
9
18
27
時間 ( 秒 )
36
17
実験: 配布されるクレジット
• OffloadCage
 Snort の分、配布される
クレジットが減少
• オフロードあり
 オフロードしないときと同
様のクレジットが配布
• オフロードなし
 設定されたcap と weight
で計算されたクレジット
が配布
credit
140
オフロードなし
オフロード
OffloadCage
120
100
80
60
40
20
0
30
480 930 1380 1830 2280
時間 ( m秒 )
18
オフロードなし
オフロードあり
OffloadCage
CPU 使用率 ( % )
実験: 性能比
60
50
40
30
20
10
0
• Snort の CPU 使用率
▫ OffloadCage
 オフロードしない場合より
高い CPU 使用率
 ウェブサーバの分が減少
▫ OffloadCage
 オフロードなしのときより、
スループットが減少
Snort がオフロード前と異なる
資源の使い方をしている
9
18
27
時間 ( 秒 )
3500
3000
2500
2000
1500
1000
500
0
req/s
• ウェブサーバのスループッ
ト
0
スループット(req/s)
36
19
50%
Tripwire のオフロード
• 実験内容
web
snort
オフロードなし
▫ オフロード元では無限ループするプログラムが動作
 CPU を制限まで使用
▫ cap を 50 に設定
▫ Tripwire は 30% に制限
web
オフロードあり
snort
web
OffloadCage
snort
20
実験 : Tripwire とオフロード元 VM の合計
• Tripwire とオフロード元の
CPU 使用率の合計
▫ OffloadCage
 オフロード元の制限を
守れている
▫ オフロードするとTripwire
の分だけ制限を超えてい
る
オフロードなし
オフロードあり
OffloadCage
CPU 使用率 ( % )
100
90
80
70
60
50
40
30
20
10
0
0
15
30
45 60 75
時間 ( 秒 )
90
21
関連研究
• セキュリティ機構のオフロードの研究
▫ Livewire [ Garfinkel. ’03 ]
▫ Saccessor [ 滝澤ら. ‘08 ]
• SEDF-DC [ Gupta et al. ’06]
▫ 仮想マシン間の性能分離
 Xen のスプリットドライバのドメイン０内の処理による資
源の使用を仮想マシンに適切にカウント
• LRP [ Druschel et al. ’96 ]
▫ アプリケーション間の性能分離
 カーネル内のネットワーク処理による資源の使用をアプ
リケーションに適切にカウント
22
まとめ
• セキュリティ機構のオフロードを考慮して性能分離
を実現するシステム OffloadCageを提案した
▫ OC-Monitor はセキュリティ機構の使用した資源を監
視
▫ OC-Scheduler はセキュリティ機構とオフロード元の仮
想マシンをひとまとまりとしてスケジューリング
• Snort と Tripwire をオフロードしてもオフロード元の
制限を守れていることを確認した
23
今後の課題
• オフロードしたセキュリティ機構とオフロード元の仮
想マシンの資源分配を考慮
▫ オフロード元の状況を応じて、セキュリティ機構のCPU
資源を制限
• CPU 以外の資源も監視
▫ メモリ
▫ ディスク