Get Slide - Core Software Group

仮想マシンを用いた
IDSオフロードを考慮するための
資源管理機構
数理・計算科学専攻
指導教員: 千葉滋
09M37028
新井昇鎬
1
IDS(侵入検知システム) オフロードとは
• 監視対象 VM の外から監視
– IDS自体が攻撃されにくいためセキュリティが向上
• IDS のポリシやログなどのデータの改竄を防ぐ
• 攻撃者はシステム侵入後に IDS を狙う
– 発見されるのを防ぐ
通常
攻撃
IDS
IDSオフロード
IDS-VM
監視対象 VM
検知
IDS
VMM
2
Xen を用いた IDS オフロードの例
• Snort のオフロード
– 監視対象の仮想インターフェイスを監視
• ClamAVのオフロード
– 監視対象のディスクイメージをマウントして監視
• Livewire (Garfinkel, ’03)、SAccessor (滝沢ら, ‘08)
パケット
監視対象 VM
IDS-VM
Snort
監視
VMM
監視
IDS-VM
Clam
AV
監視対象 VM
Disk
image
VMM
3
VM 間の性能分離の問題
• オフロードすると性能分離が難しくなる
– 性能分離とは
• 各 VM への資源割り当てを保証すること
• 例: 上限 50 % が設定された VM はその分を利用可
– IDS による資源消費分は監視対象元 VM に含め
るべき
• IDS は監視対象 VM のために動作
– 合計すると監視対象 VM の資源割り当てを超え
CPU 40%
CPU 50%
る
CPU20%
IDS
4
VM 単位の資源管理が原因
• VM の外で動作している IDS を考慮すること
はできない
– VMM は VM 単位で性能分離を実現
• 例: Xen では VM に cap, weight を設定
• IDS と VM に個別に資源割り当てを行うだけ
では不十分
– IDS が利用しない分を VM が使用できない
VM(40%)
CPU20%
IDS
Xen
5
提案: Resource Cage
• RC 単位で資源管理
– VM という実行単位から資源管理を切り離す
– RC: VM、プロセス
• cap(上限), weight (割合) を設定
– 複数の RC をグルーピング可能
• IDS オフロードを考慮
VM1
Resource Cage
RC2(Group)
RC1
VM2
VM1
RC3
RC4
IDS
VM2
IDS
VMM
6
ClamAV オフロードを考慮する例
• ClamAV と VM2 合わせて最大 CPU 50 %
– VM2 は 50% まで使用可
• ClamAV が使用しない分
• cap の値が 0 (無指定) のとき
– ClamAV は最大 20 %まで
RC2(Group)
RC1(VM1)
VM1
VM2
cap: 50
weight: 256
cap:0
weight: 256
cap:20
w:128
Clam
AV
VMM
cap: 0
w:128
RC3(ClamAV) RC4(VM2)
7
実装: Resource Cage の構成 ( Xen に実装)
• RC-Monitor
– 仮想マシンモニタレベルで CPU 使用率を監視
• RC Credit Scheduler
– RC を元に VM をスケジューリング
制御
• RC-Limiter
– RC に応じてプロセスの
動作を制御
dom0
参照
参照
VM
監視対象 VM
RCLimiter
IDS
記録
IDS
dom0
監視
RC-Monitor
Xen
RC Credit Scheduler
8
RC-Monitor
• CR3 レジスタの切り替えを利用してCPU 使用
率を計測
P1
P2
カーネル
• 0(1)スケジューラ、CFS
VMM
• VMの切り替えが考慮されて
いない古いカーネルや完全仮想化
ユーザランド
– CR3 = プロセスのページディレクトリ
のアドレス
– ゲスト OS のカーネル、
スケジューラに依存しない
VM
OC-Monitor
監視
CR3
9
RC Credit Scheduler
• 所属している RC の cap, weight を元に VM を
スケジューリング
– Xen のクレジットスケジューラを改良
• VM の cap, weight を参照してスケジューリング
• 監視対象の仮想マシンの場合は同じグルー
RC2(Group)
プ内の RC も考慮
VM1
VM2
cap: 80
weight: 256
Clam
AV
VMM
RC3(ClamAV) RC4(VM2)
cap: 0
cap:40
w:128
w:128
10
VM
VM
VM
11
クレジットスケジューラ
over
仮想
CPU
under
仮想
CPU
• クレジット
– 物理 CPU を使用できる量
under
仮想
– 30 ms ごとに仮想 CPU に配布
CPU
– 10 ms ごとに減少 (物理CPU 上の)
– 正の値の仮想 CPU が優先
物理CPUを使用している
仮想CPUのcreditの変化
200
100
0
-100
クレジット
10ms
20ms
30ms
RC-CS によるクレジットの配分
• 同じグループ内の IDS の RC の weight、cap
を参照してクレジットを計算
– IDS の CPU 使用率に応じてクレジットが増減
• 例: cap による制御
VM2
VM1
IDS がほとんど動作していないとき
IDS
クレジット
IDS が最大20%まで利用した時
VM1
cap:40
クレジット
Resource cage
cap: 50
IDS
cap:
20
VM2
cap:
0 12
RC-Limiter
• RC のプロセスの CPU 使用率を制限
– 設定された cap を超えさせない
• グループに所属してる場合: 全体のcap を超えない
– プロセスの動作を制御
• SIGCONT, SIGSTOP シグナルを利用
例: 40%に制限
100ms
時間
IDS-VM
監視対象 VM
OCLimiter
IDS
SIGCONT SIGSTOP
13
実験: Snort のオフロード
• 実験内容
– 監視対象 VM はウェブサーバ
– 外部マシンから攻撃
• httperf を使用
– RC (group) = RC1 (snort) + RC2 (監視対象VM)
• RC: 最大CPU使用率 50%
• RC1: 最大CPU使用率20%
実験環境マシン
CPU： Intel Core i7 2.80GHz (コア１)
メモリ：8 GB
VMM : Xen4.1.0 (x86_64)
OS：Linux Kernel 2.6.32.39
Dom 0
httperf
監視対象
VM
web
snort
14
Snort と VM の CPU使用率の合計
CPU 使用率 ( % )
100
80
• オフロードすると制限を60
40
超える(上図)
20
• Resource Cage
時間 ( 秒 )
0
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45
▫ オフロードしても 50 % の制
100
限を守れている (下図)
90
▫ RC-Limiterにより、Snort は 80
70
60
20 %以下
IDS
VM
IDS + VM
50
40
30
20
10
0
15
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45
ウェブサーバのスループット
– Snortの分だけウェブ
サーバが使用できる
• 本システムの場合 (緑)
– オフロードしない場合と
ほぼ同じスループット
5000
4500
4000
3500
offloadなし
3000
2500
req/sec
• offloadなしの場合 (赤)
offloadあり
2000
offloadあり
(RC)
1500
1000
offloadなし
offloadあり
500
0
throughput
16
実験: ClamAV のオフロード
• 実験内容
– 監視対象 VM のディスクイメージをマウントするこ
とで VM の外からウイルスチェック
– 監視対象では無限ループが動作
• 途中から Clam AV が動作を始める
– RC = RC1(ClamAV) + RC2(監視対象VM)
• 合計で最大 CPU 使用率 60 ％
• ClamAV は最大 CPU使用率 30 ％
Dom 0
監視対象
VM
loop
ClavA
V
17
ClamAV と VM の CPU 使用率の合計
100
80
• オフロードすると制限を
超える(上図)
60
40
20
• Resource Cage
▫ オフロードしても 60 % の制
限を守れている (下図)
▫ RC-Limiterにより、ClamAV
は 30 %以下
0
0 3 6 9 121518212427303336394245
IDS
VM
IDS + VM
100
80
60
40
20
0
18
0 3 6 9 121518212427303336394245
19
• 無限ループを計測
– 途中で別のVM でも
無限ループを動作
– CR3 はVM 切り替えが考慮
• Snort の CPU 使用率
– O(1) は正確に課金できない
CR3
proc O(1)
100
90
80
70
60
50
40
30
20
10
0
CPU 使用率 ( % )
実験： CR3 と proc
100
時間 ( 秒 )
0
6
12 18 24 30 36 42
CR3
proc O(1)
80
実験環境マシン
CPU：Athlon™ 2.2GHz (コア１)
メモリ：2 GB
VMM : Xen3.3.0 (x86_64)
OS：Linux Kernel 2.6.18
60
40
20
0
0
6 12 18 24 30 36 42 48
関連研究
• SEDF-DC [ Gupta et al. ’06]
– 仮想マシン間の性能分離
• Xen のスプリットドライバのドメイン０内の処理による資源の
使用を使用した仮想マシンに適切にカウント
• Resource Container [ Banga et al. ‘99]
– プロセス単位ではなく適切な単位でOSの資源管理
• VMdesched Component [VMware]
– 完全仮想化で正確な時間管理
• VMDesched プロセス動作時に溜まっていた割り込みを処
理
20
Future Work
• シェアスケジューリングの実現
• オフロードしたプロセスを監視対象の仮想マ
シンの物理CPUと共有させる
– CGroup でプロセスと VCPUを固定
– その VCPU を監視対象の
仮想マシンの物理 CPU と共有
仮想
CPU1
物理 CPU
VM1
VM2
IDS
仮想
CPU2
仮想
CPU3
共有
21
まとめ
• 仮想マシンを用いた IDS をオフロードを考慮し
た資源管理機構を Xen 上に実装
– VM単位ではなく、Resource Cage 単位で資源管理
– Resource Cage に対して CPU 制約
– Snort と ClamAV をオフロードして実験
• ここまでの成果
– ’09 VM ミニワークショップ
– ’10 DSW
– ’10 OS 研究会
22
実験: ClamAV のオフロード時の
性能分離
CPU使用率
100
90
80
70
60
50
40
ClamAV
• グループ内のClamAV
と domU は 1 対 2 でス
ケジューリング
• 途中から domU 内で無
限ループ
domU
30
domU
20
10
0
時間
Clam
AV
Xen
23
実験: シェアスケジューリング(無限
ループ)
CPU使用率
100
• 無限ループと domU で
グルーピング
90
80
– 最大 60 %
70
60
loop
50
domU
40
group
• ループと domU で 1: 2
シェアスケジューリング
30
domU
20
10
0
時間
loop
loop
Xen
24
新しい手法
• オフロードしたプロセスに VCPU (仮想 CPU) を
持たせ、オフロード元の仮想マシンと共有
VM1
Resource Cage
VM2
RC2(Group)
RC1
IDS
仮想
CPU1
仮想
CPU2
物理 CPU
仮想
CPU3
共有
物理 CPU
RC3
RC4
VM1
IDS
VM2
仮想
CPU1
仮想
CPU2
仮想
CPU3
25

Download Report