セキュリティ機構のオフロード時の性能分離新井 昇鎬 * 　光来 健一 ** 　千葉 滋 ** 東京工業大学　** 九州工業大学 / CREST 　

セキュリティ機構のオフロード•外部にサービスを提供している仮想マシンの外へ出す▫セキュリティが向上

仮想マシンが攻撃されてもセキュリティ機構まで影響が及びにくい セキュリティ機構のポリシやログなどのデータの改竄を防ぐ

•セキュリティ機構とは？▫侵入検知システム▫ファイヤーウォール▫アクセス制御

仮想マシン

セキュリティ機構

2

仮想マシンを利用したオフロードの例•Snort のオフロード▫ドメイン０で通信パケットを監視可

•Tripwire のオフロード ドメイン０でファイルシステムを検査可

Snort

Xen

オフロード元の仮想マシンTripwire

Xen

オフロード元の仮想マシンドメイン０ ドメイン０

パケット

ディスクイメージ

3

仮想マシン間の性能分離の問題• しかし、オフロードすると性能分離ができなくなる▫性能分離とは

各仮想マシンの性能を保障すること▫オフロードしたセキュリティ機構により、他の仮想マシンの使える資源が減少

セキュリティ機構

CPU 40%

20%Webサーバ

CPU 50%

4

VMM

性能分離の問題が生じる例•Snort の場合▫オフロード元 VM に大量のパケットが送受信されたとき

Snort にも負荷がかかる•Tripwire の場合▫ファイルシステムを検査するとき

Tripwire だけで大量の資源を消費

CPU を大量に消費

Snort

VMM

オフロード元の仮想マシン

5

提案 : OffloadCage•オフロードしたセキュリティ機構を考慮して性能分離を実現▫セキュリティ機構とオフロード元 VM をひとまとまりとしてスケジューリング

合計としてオフロード元 VM の制限を守る＋

VMM

6

システム構成•OC-Monitor▫セキュリティ機構が使用した資源を監視▫監視した資源の量を

OC-Scheduler に通知•OC-Scheduler▫オフロードを考慮して仮想マシンをスケジューリング

7

オフロード元の仮想マシン

セキュリティ機構

OC-Monitor

ドメイン０

VMMOC-Scheduler

OC-Monitor (1)•セキュリティ機構の CPU 使用率を計測▫VMM 全体に対しての使用率▫/proc /pid/stat を利用

•オフロード元 VM とセキュリティ機構を関連付ける▫オフロード元はドメイン ID で指定

•モニタするセキュリティ機構はプロセス ID で指定

8

セキュリティ機構

OC-Monitor

20

定期的に計測・通知

OC-Scheduler

ハイパーコール

OC-Monitor (2) •監視しているセキュリティ機構の CPU 使用率を制限可▫セキュリティ機構だけでオフロード元の制限を超えさせない

Tripwire などは動作すると検査するだけで大量の CPU を消費

▫停止、動作させたりして制限を守る 現段階では、 cpulimit を利用

9

セキュリティ機構

OC-Monitor

CPU 使用率を制限

OC-Scheduler•セキュリティ機構が使った資源をオフロード元の仮想マシンのものとしてスケジューリング▫セキュリティ機構が使用した分だけ、オフロード元の使用できる CPU 時間は減少

•クレジットスケジューラを改良▫Xen の仮想マシンスケジューラ▫debt パラメータを追加

OC- Monitor からのハイパーコールで debt を更新

10

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

•30ms ごとに仮想 CPU を切替

11

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

物理CPU

仮想CPU

仮想CPU

仮想CPU

underover

under

仮想マシン 仮想マシン仮想マシン

Series1

-100-50

050

100150200

クレジット

10ms 20ms 30ms

クレジットの計算方法• weight 、 cap のそれぞれからクレジットを計算▫weight … 総 weight 数と比較する値▫ cap … 最大 CPU 使用率を表す値▫結果の小さい方を配布

12

cap: 60weight:256

仮想マシンＡ

cap: 40weight: 256

仮想マシンＢ

weight cap

配布

256 : 256 60 : 40

OC-Scheduler によるクレジットの計算方法•オフロードしたセキュリティ機構の CPU 使用分をオフロード元 VM から減少•debt パラメータを利用▫セキュリティ機構の CPU 使用率

13

cap: 60weight:256debt: 0

仮想マシンＡ

cap: 40weight: 256debt : 20

仮想マシンＢ

セキュリティ機構weight cap

配布

実験•Snort と Tripwire をオフロード•オフロードした場合の仮想マシン間の性能の分離を確かめる•実験環境▫オフロードなし、オフロードあり、 OffloadCage の３つの場合で比較▫マシン

CPU ： Athlon™ 　 2.2GHz ( コア１ ) メモリ： 2 GB VMM : Xen3.3.0 　 (x86_64) OS ： Linux Kernel 2.6.18

14

Snort のオフロード•実験内容▫オフロード元はウェブサーバ▫外部のマシンから攻撃

httperf を使用▫オフロード元には cap を 40

最大 CPU 使用率 40%

15

web

40%

snort

web

snort

web

snort

httperf

httperf

httperf

実験 : Snort とオフロード元 VM の CPU 使用率の合計• オフロードすると制限を大幅に超えている• OffloadCage▫オフロードしてもオフロード元　 VM の制限を守れている

•オフロードなし場合はオフロード元 VM の CPU使用率0 3 6 9 12 15 18 21 24 27 30 33 36

0102030405060708090

オフロードなしCPU 使用

率 %

時間 ( 秒 )

16

実験 : 配布されるクレジット• OffloadCage

Snort の分、配布されるクレジットが減少• オフロードあり

オフロードしないときと同様のクレジットが配布• オフロードなし

設定された cap と weight で計算されたクレジットが配布 30

270510

750990

12301470

17101950

21902430

0

20

40

60

80

100

120

140

オフロードなしオフロード

時間 ( m 秒 )

credit

17

実験 : 性能比• Snort の CPU 使用率▫ OffloadCage

オフロードしない場合より高い CPU 使用率 ウェブサーバの分が減少

• ウェブサーバのスループット▫ OffloadCage

オフロードなしのときより、スループットが減少Snort がオフロード前と異なる資源の使い方をしている

スループット (req/s)0

500100015002000250030003500

0 3 6 9 12 15 18 21 24 27 30 33 360

102030405060

オフロードなしオフロードありOffloadCage

CPU

使用率

( % )

req/

s

時間 ( 秒 )

18

Tripwire のオフロード•実験内容▫オフロード元では無限ループするプログラムが動作

CPU を制限まで使用▫cap を 50 に設定▫Tripwire は 30% に制限

19

web

50%

snort

web

snort

web

snort

オフロードなし

オフロードあり

OffloadCage

実験 : Tripwire とオフロード元 VM の合計• Tripwire とオフロード元の CPU 使用率の合計▫OffloadCage

オフロード元の制限を守れている▫オフロードすると

Tripwire の分だけ制限を超えている0 12 24 36 48 60 72 84 96

0102030405060708090

100

オフロードなしオフロードありOffloadCage

時間 ( 秒 )

CPU 使用率 ( % )

20

関連研究•セキュリティ機構のオフロードの研究▫Livewire [ Garfinkel. ’03 ]▫Saccessor [ 滝澤ら . ‘08 ]

•SEDF-DC [ Gupta et al. ’06]▫仮想マシン間の性能分離

Xen のスプリットドライバのドメイン０内の処理による資源の使用を仮想マシンに適切にカウント• LRP [ Druschel et al. ’96 ]▫アプリケーション間の性能分離

カーネル内のネットワーク処理による資源の使用をアプリケーションに適切にカウント

21

まとめ•セキュリティ機構のオフロードを考慮して性能分離を実現するシステム OffloadCage を提案した▫OC-Monitor はセキュリティ機構の使用した資源を監視▫OC-Scheduler はセキュリティ機構とオフロード元の仮想マシンをひとまとまりとしてスケジューリング

•Snort と Tripwire をオフロードしてもオフロード元の制限を守れていることを確認した

22

今後の課題•オフロードしたセキュリティ機構とオフロード元の仮想マシンの資源分配を考慮▫オフロード元の状況を応じて、セキュリティ機構の CPU 資源を制限

•CPU 以外の資源も監視▫メモリ▫ディスク

23