セキュリティ機構のオフロード時の 性能 分離

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

2. セキュリティ機構のオフロード • 外部にサービスを提供している仮想マシンの外へ出す • セキュリティが向上 • 仮想マシンが攻撃されてもセキュリティ機構まで影響が及びにくい • セキュリティ機構のポリシやログなどの データの改竄を防ぐ • セキュリティ機構とは？ • 侵入検知システム • ファイヤーウォール • アクセス制御 仮想マシン セキュリティ 機構

3. 仮想マシンを利用したオフロードの例 • Snort のオフロード • ドメイン０で通信パケットを監視可 • Tripwire のオフロード • ドメイン０でファイルシステムを検査可 オフロード元の 仮想マシン オフロード元の 仮想マシン ドメイン０ ドメイン０ Snort Tripwire ディスク イメージ Xen Xen パケット

4. 仮想マシン間の性能分離の問題 • しかし、オフロードすると性能分離ができなくなる • 性能分離とは • 各仮想マシンの性能を保障すること • オフロードしたセキュリティ機構により、他の仮想マシンの使える資源が減少 CPU 40% CPU 50% Web サーバ 20% セキュリティ 機構 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で指定 • モニタするセキュリティ機構はプロセス ID で指定 OC-Monitor 20 セキュリティ 機構 ハイパーコール OC-Scheduler

9. OC-Monitor (2) • 監視しているセキュリティ機構の CPU 使用率を制限可 • セキュリティ機構だけでオフロード元の制限を超えさせない • Tripwire などは動作すると検査するだけで大量の CPU を消費 • 停止、動作させたりして制限を守る • 現段階では、cpulimitを利用 OC-Monitor CPU 使用率を 制限 セキュリティ 機構

10. OC-Scheduler • セキュリティ機構が使った資源をオフロード元の仮想マシンのものとしてスケジューリング • セキュリティ機構が使用した分だけ、オフロード元の使用できる CPU 時間は減少 • クレジットスケジューラを改良 • Xenの仮想マシンスケジューラ • debt パラメータを追加 • OC- Monitor からのハイパーコールで debt を更新

11. 仮想マシン 仮想マシン 仮想マシン クレジットスケジューラ over under 仮想 CPU 仮想 CPU • クレジット • 物理 CPU を使用できる量 • 30ms ごとに仮想 CPU に配布 • 10ms ごとに減少 • クレジットが正の仮想 CPUが優先 • 30ms ごとに仮想 CPU を切替 under 仮想 CPU 物理 CPU 物理CPUを使用している仮想CPUのcreditの変化 10ms 20ms 30ms

12. クレジットの計算方法 • weight、capのそれぞれからクレジットを計算 • weight …総 weight 数と比較する値 • cap … 最大 CPU 使用率を表す値 • 結果の小さい方を配布 仮想マシンＡ 仮想マシンＢ cap: 60 weight:256 cap: 40 weight: 256 weight cap 配布 256 : 256 60 : 40

13. OC-Scheduler によるクレジットの計算方法 • オフロードしたセキュリティ機構のCPU 使用分をオフロード元 VM から減少 • debt パラメータを利用 • セキュリティ機構の CPU 使用率 仮想マシンＡ 仮想マシンＢ セキュリティ 機構 cap: 60 weight:256 debt: 0 cap: 40 weight: 256 debt : 20 weight cap 配布

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 • 実験内容 • オフロード元はウェブサーバ • 外部のマシンから攻撃 • httperfを使用 • オフロード元には cap を40 • 最大 CPU 使用率 40% web snort httperf web snort httperf web snort

16. 実験:Snort とオフロード元 VM の CPU 使用率の合計 • オフロードすると制限を大幅に超えている • OffloadCage • オフロードしてもオフロード元　VM の制限を守れている • オフロードなし場合はオフロード元 VM のCPU使用率 時間 ( 秒 )

17. 実験: 配布されるクレジット credit • OffloadCage • Snort の分、配布されるクレジットが減少 • オフロードあり • オフロードしないときと同様のクレジットが配布 • オフロードなし • 設定されたcap と weight で計算されたクレジットが配布 時間 ( m秒 )

18. 実験: 性能比 CPU 使用率 ( % ) • Snort の CPU 使用率 • OffloadCage • オフロードしない場合より 高い CPU 使用率 • ウェブサーバの分が減少 • ウェブサーバのスループット • OffloadCage • オフロードなしのときより、スループットが減少 Snort がオフロード前と異なる資源の使い方をしている 時間 ( 秒 ) req/s

19. 50% Tripwire のオフロード web snort オフロードなし • 実験内容 • オフロード元では無限ループするプログラムが動作 • CPU を制限まで使用 • cap を 50 に設定 • Tripwire は 30% に制限 web snort オフロードあり web snort OffloadCage

20. 実験 : Tripwire とオフロード元 VM の合計 • Tripwire とオフロード元の CPU 使用率の合計 • OffloadCage • オフロード元の制限を守れている • オフロードするとTripwire の分だけ制限を超えている CPU 使用率 ( % ) 時間 ( 秒 )

21. 関連研究 • セキュリティ機構のオフロードの研究 • Livewire [ Garfinkel. ’03 ] • Saccessor [ 滝澤ら. ‘08 ] • SEDF-DC [ Guptaet al. ’06] • 仮想マシン間の性能分離 • Xenのスプリットドライバのドメイン０内の処理による資源の使用を仮想マシンに適切にカウント • LRP [ Druschel et al. ’96 ] • アプリケーション間の性能分離 • カーネル内のネットワーク処理による資源の使用をアプリケーションに適切にカウント

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

23. 今後の課題 • オフロードしたセキュリティ機構とオフロード元の仮想マシンの資源分配を考慮 • オフロード元の状況を応じて、セキュリティ機構のCPU資源を制限 • CPU 以外の資源も監視 • メモリ • ディスク