1

仮想マシンを用いたIDS オフロードを考慮するための

資源管理機構

数理・計算科学専攻指導教員 : 千葉滋

09M37028新井昇鎬

2

IDS( 侵入検知システム ) オフロードとは

• 監視対象 VM の外から監視– IDS 自体が攻撃されにくいためセキュリティが

向上• IDS のポリシやログなどのデータの改竄を防ぐ

• 攻撃者はシステム侵入後に IDS を狙う– 発見されるのを防ぐ

IDS

VMM

監視対象 VM

IDS攻撃

通常

IDS オフロードIDS-VM

検知

3

Xen を用いた IDS オフロードの例

• Snort のオフロード– 監視対象の仮想インターフェイスを監視

• ClamAV のオフロード– 監視対象のディスクイメージをマウントして

監視• Livewire (Garfinkel, ’03) 、 SAccessor ( 滝沢ら , ‘08)

ClamAV

VMM

監視Disk

image

監視対象 VMIDS-VM

Snort

VMM

監視対象 VMIDS-VM

監視

パケット

4

VM 間の性能分離の問題• オフロードすると性能分離が難しくなる– 性能分離とは• 各 VM への資源割り当てを保証すること• 例 : 上限 50 % が設定された VM はその分を利用

可– IDS による資源消費分は監視対象元 VM に含

めるべき• IDS は監視対象 VM のために動作

– 合計すると監視対象 VM の資源割り当てを超える

IDS

CPU 40%

CPU20%

CPU 50%

5

VM 単位の資源管理が原因• VM の外で動作している IDS を考慮する

ことはできない– VMM は VM 単位で性能分離を実現• 例 : Xen では VM に cap, weight を設定

• IDS と VM に個別に資源割り当てを行うだけでは不十分– IDS が利用しない分を VM が使用できない

Xen

IDS

VM(40%)

CPU20%

6

提案 : Resource Cage

• RC 単位で資源管理– VM という実行単位から資源管理を切り離す– RC: VM 、プロセス• cap( 上限 ), weight ( 割合 ) を設定

– 複数の RC をグルーピング可能• IDS オフロードを考慮

IDS

VMM

VM1 VM2

VM1 IDS VM2

RC2(Group)RC1RC3 RC4

Resource Cage

7

ClamAV オフロードを考慮する例

• ClamAV と VM2 合わせて最大 CPU 50 %– VM2 は 50% まで使用可• ClamAV が使用しない分 • cap の値が 0 ( 無指定 ) のとき

– ClamAV は最大 20 % まで

cap:0weight: 256

cap: 50weight: 256

cap:20w:128

cap: 0w:128

RC2(Group)

RC1(VM1)

RC3(ClamAV) RC4(VM2)

ClamAV

VM1 VM2

VMM

8

実装 : Resource Cage の構成 ( Xen に実装 )

• RC-Monitor– 仮想マシンモニタレベルで CPU 使用率を監

視• RC Credit Scheduler– RC を元に VM をスケジューリング

• RC-Limiter– RC に応じてプロセスの 　動作を制御

IDS

監視対象 VMdom0

RC Credit Scheduler

RC-Monitor

RC-Limiter

Xen

制御

監視

dom0

IDS VM

参照

記録

参照

9

RC-Monitor

• CR3 レジスタの切り替えを利用して CPU 使用率を計測– CR3 = プロセスのページディレクトリ　 のアドレス– ゲスト OS のカーネル、　スケジューラに依存しない• 0(1) スケジューラ、 CFS• VM の切り替えが考慮されて　いない古いカーネルや完全仮想化

P1 P2

ユー

ザラ

ンド

カー

ネル

VM

CR3

VMM OC-Monitor

監視

10

RC Credit Scheduler

• 所属している RC の cap, weight を元に VM をスケジューリング– Xen のクレジットスケジューラを改良• VM の cap, weight を参照してスケジューリング

• 監視対象の仮想マシンの場合は同じグループ内の RC も考慮

ClamAV

VM1 VM2

VMM

cap: 80weight: 256

cap:40w:128

cap: 0w:128

RC2(Group)

RC3(ClamAV) RC4(VM2)

クレジットスケジューラ• クレジット– 物理 CPU を使用できる量– 30 ms ごとに仮想 CPU に配布– 10 ms ごとに減少 ( 物理 CPU 上の )– 正の値の 仮想 CPU が優先

11

仮想CPU

仮想CPU

underover

under

VM VM VM

仮想CPU

Series1

-100-50

050

100150200

クレジット

10ms 20ms 30ms

物理 CPU を使用している仮想 CPU の credit の

変化

12

RC-CS によるクレジットの配分

• 同じグループ内の IDS の RC の weight 、cap を参照してクレジットを計算– IDS の CPU 使用率に応じてクレジットが増減

• 例 : cap による制御 VM2

IDS

VM1cap:40 cap: 50

IDScap:20

VM2cap:

0Resource cage

IDS がほとんど動作していないとき

VM1

IDS が最大 20% まで利用した時

クレジット

クレジット

13

RC-Limiter

• RC のプロセスの CPU 使用率を制限– 設定された cap を超えさせない• グループに所属してる場合 : 全体の cap を超えな

い – プロセスの動作を制御• SIGCONT, SIGSTOP シグナルを利用

時間

SIGSTOPSIGCONT

100ms

IDS

監視対象 VMIDS-VM

OC-Limiter

例 : 40% に制限

14

実験 : Snort のオフロード• 実験内容– 監視対象 VM はウェブサーバ– 外部マシンから攻撃• httperf を使用

– RC (group) = RC1 (snort) + RC2 ( 監視対象 VM)• RC: 最大 CPU 使用率 50%• RC1: 最大 CPU 使用率 20%

web

snort

httperf

監視対象 VMDom 0

実験環境マシンCPU ： Intel Core i7 　 2.80GHz ( コア１ )メモリ： 8 GB VMM : Xen4.1.0 　 (x86_64)OS ： Linux Kernel 2.6.32.39

15

Snort と VM の CPU 使用率の合計

0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 450

20

40

60

80

100

0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 450

20

40

60

80

100

IDS VM IDS + VM

•オフロードすると制限を超える ( 上図 )

•Resource Cage▫オフロードしても 50 %

の制限を守れている ( 下図 )

▫RC-Limiter により、 Snort は 20 % 以下

CPU

使用

率 (

% )

時間 ( 秒 )

16

ウェブサーバのスループット• offload なしの場合

( 赤 )– Snort の分だけウェブ

サーバが使用できる• 本システムの場合

( 緑 )– オフロードしない場合

とほぼ同じスループット

throughput0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

offload なしoffload ありoffload あり(RC)

offload なし offload あり

req/

sec

17

実験 : ClamAV のオフロード• 実験内容– 監視対象 VM のディスクイメージをマウント

することで VM の外からウイルスチェック– 監視対象では無限ループが動作• 途中から Clam AV が動作を始める

– RC = RC1(ClamAV) + RC2( 監視対象 VM)• 合計で最大 CPU 使用率 60 ％• ClamAV は最大 CPU 使用率 30 ％ loop

ClavAV

監視対象 VMDom 0

18

ClamAV と VM の CPU 使用率の合計

0 6 12 18 24 30 36 420

20406080

100

IDS VMIDS + VM

0 6 12 18 24 30 36 420

20

40

60

80

100

•オフロードすると制限を超える ( 上図 )

•Resource Cage▫オフロードしても 60 %

の制限を守れている ( 下図 )

▫RC-Limiter により、 ClamAV は 30 % 以下

実験： CR3 と proc

• 無限ループを計測– 途中で別の VM でも　無限ループを動作– CR3 は VM 切り替えが考慮

• Snort の CPU 使用率– O(1) は正確に課金できない

19

0 6 12 18 24 30 36 420

20

40

60

80

100CR3 proc O(1)

0 6 12 18 24 30 36 42 480

102030405060708090

100CR3 proc O(1)

実験環境マシンCPU ： Athlon™ 　 2.2GHz ( コア１ )メモリ： 2 GB VMM : Xen3.3.0 　 (x86_64)OS ： Linux Kernel 2.6.18

CPU

使用

率 (

% )

時間 ( 秒 )

20

関連研究• SEDF-DC [ Gupta et al. ’06]– 仮想マシン間の性能分離

• Xen のスプリットドライバのドメイン０内の処理による資源の使用を使用した仮想マシンに適切にカウント

• Resource Container [ Banga et al. ‘99]– プロセス単位ではなく適切な単位で OS の資源管理

• VMdesched Component [VMware]– 完全仮想化で正確な時間管理

• VMDesched プロセス 動作時に溜まっていた割り込みを処理

21

Future Work

• シェアスケジューリングの実現

• オフロードしたプロセスを監視対象の仮想マシンの物理 CPU と共有させる– CGroup で プロセスと VCPU を固定– その VCPU を監視対象の　仮想マシンの物理 CPU と共有

IDS

VM1 VM2

仮想CPU1

仮想CPU2

仮想CPU3

物理 CPU

共有

22

まとめ• 仮想マシンを用いた IDS をオフロードを考慮

した資源管理機構を Xen 上に実装– VM 単位ではなく、 Resource Cage 単位で資源管理– Resource Cage に対して CPU 制約– Snort と ClamAV をオフロードして実験

• ここまでの成果– ’09 VM ミニワークショップ– ’10 DSW– ’10 OS 研究会

23

実験 : ClamAV のオフロード時の性能分離

Series1

0102030405060708090

100

ClamAVdomU

• グループ内の ClamAV と domU は 1 対 2 でスケジューリング

• 途中から domU 内で無限ループ

Xen

ClamAV

domU

CPU 使用率

時間

24

実験 : シェアスケジューリング ( 無限ループ )

• 無限ループと domU でグルーピング– 最大 60 %

• ループ と domU で 1: 2 シェアスケジューリング

Xen

looploop

domU

CPU 使用率

時間

Series1

0102030405060708090

100

loopdomUgroup

25

新しい手法• オフロードしたプロセスに VCPU ( 仮想

CPU) を持たせ、オフロード元の仮想マシンと共有

IDS

VM1 VM2

VM1 IDS VM2

RC2(Group)RC1RC3 RC4

Resource Cage

仮想CPU1

仮想CPU2

仮想CPU3

物理 CPU 物理 CPU

仮想CPU1

仮想CPU3

仮想CPU2

共有