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

Presentation on theme: "セキュリティ機構のオフロード時の 性能分離"— Presentation transcript:

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

2 セキュリティ機構のオフロード 外部にサービスを提供している仮想マシンの外へ 出す セキュリティ機構とは？ セキュリティが向上
仮想マシンが攻撃されてもセキュリティ機構まで影響が 及びにくい セキュリティ機構のポリシやログなどの データの改竄を防ぐ セキュリティ機構とは？ 侵入検知システム ファイヤーウォール アクセス制御 仮想マシン セキュリティを向上させる方法として、仮想マシンを利用したセキュリティ機構のオフロードがある。 セキュリティ機構のオフロードとは、サービスなどを提供している仮想マシンからセキュリティ機構を仮想マシンの外へだし、 外から仮想マシンを監視します。 このオフロードにより、攻撃者からセキュリティ機構が直接攻撃されにくくなります。 オフロードしない場合では、仮想マシンがクラックされたときに、攻撃者によりセキュリティ機構のポリシーやログなどのデータなどが改ざんされてしまいます。 関連研究 仮想マシンを利用したセキュリティ機構のオフロードを行っている研究はたくさんあります。 ここではLivewire と Saccessor について説明します。 Livewireは侵入検知システムを仮想マシンからオフロードしていて、監視対象の仮想マシンの内部情報をみることで、外部から監視します。 Saccessorはファイルのアクセス制御を仮想マシンからオフロードしていて、オフロード先の仮想マシンをファイルサーバとして動作させることで、オフロード元の仮想マシンのファイルのアクセス制御を行っています。 セキュリティ 機構

3 仮想マシンを利用したオフロードの例 Snort のオフロード Tripwire のオフロード ドメイン０で通信パ ケットを監視可
ドメイン０でファイル システムを検査可 オフロード元の 仮想マシン オフロード元の 仮想マシン ドメイン０ ドメイン０ Xen を利用した 侵入検知システム のオフロードを紹介します。 Xen では、一般的に使用される仮想マシン、ドメインＵとそれらの仮想マシンを管理する仮想マシン、ドメイン０の ２種類の仮想マシンがあります。 ここでは、一般的に使用される仮想マシンから Snort や Tripwire をドメイン０へオフロードします。 ドメイン０は一般的に使用される仮想マシンより攻撃されにくいのでセキュリティは向上します。 Snort とはネットワーク型の侵入検知システムで監視対象ホストの通信パケットを監視 シグネチャと呼ばれるルールと照らし合わせて、攻撃を検出する。 仮想マシンが送受信するパケットがドメイン０を経由することを利用してXen上でのSnortのオフロードを実現します。 一方、Tripwireとはホスト型の侵入検知システムで監視対象ホストのファイルシステムの状態を定期的にチェックすることでデータの改ざんなどを検知します。 オフロード元の仮想マシンのイメージファイル利用することで、オフロード元のファイルシステムをチェックすることができます。 Snort Tripwire ディスク イメージ Xen Xen パケット

4 仮想マシン間の性能分離の問題 しかし、オフロードすると性能分離ができなくなる 性能分離とは 各仮想マシンの性能を保障すること
オフロードしたセキュリティ機構により、他の仮想マシンの 使える資源が減少 CPU 40% CPU 50% Web サーバ しかし、さきほどのオフロードにより、仮想マシン間の性能分離に問題が生じます 性能分離されているとは、仮想マシン間の性能が互いに影響されず、保障されている環境のことを言います。 たとえば図のようにセキュリティ機構をオフロードして、オフロード元にウェブサーバが動作しているとき、パケット処理などでWEB サーバが CPU を制限をいっぱいに使うと、 セキュリティ機構が少し使うだけで、セキュリティ機構とオフロード元の仮想マシンのCPU 使用率の合計はオフロード元の制限の 40 % をオーバーします。 オーバーした分だけ、他の仮想マシンの資源にも影響が出てきます。 図では、60%いくと、他の仮想マシンが50%まで使えなくなる 20% セキュリティ 機構 VMM

5 性能分離の問題が生じる例 Snortの場合 Snort にも負荷がかかる Tripwireの場合 Tripwire だけで大量の資源 を消費
オフロード元 VM に大量のパケットが送受信されたと き Snort にも負荷がかかる Tripwireの場合 ファイルシステムを検査するとき Tripwire だけで大量の資源 を消費 CPUを大量に消費 オフロード元の 仮想マシン Snort Tripwire のオフロードした時の性能分離の問題を説明します。 少量のパケットでは問題ないが オフロード元に大量のパケット 1, オフロード元はパケット処理で自分自身だけで制限分の CPU を使用 2., Snort はパケットを監視するので同様に負荷 3, 制限　プラス　Snorの CPU 使用率 Tripwire が動いてないときは問題ない しかし、Tripwire がひとたび動作すると、オフロード元の仮想マシンの制限とは関係なしに必要な分だけ CPU を使用してしまう Snort VMM

6 提案: OffloadCage ＋ オフロードしたセキュリティ機構を考慮して性 能分離を実現
セキュリティ機構とオフロード元 VM をひと まとまりとしてスケジューリング 合計としてオフロード元 VM の制限を守る このようなオフロード時の性能分離の問題を解決する OffloadCage を提案 オフロードしたセキュリティ機構の使ったCPU 資源をオフロード元の仮想マシンにカウント 図のように オフロードしたセキュリティ機構とオフロード元の仮想マシンをひとまとまりと考え、この２つの CPU 使用率の合計がオフロード元に設定された制限を超えないようにスケジューリングします ＋ VMM

7 システム構成 OC-Monitor OC-Scheduler セキュリティ機構が使 用した資源を監視
オフロード元 の仮想マシン OC-Monitor セキュリティ機構が使 用した資源を監視 監視した資源の量を OC-Scheduler に通知 OC-Scheduler オフロードを考慮して仮 想マシンをスケジューリ ング ドメイン０ OC-Monitor セキュリティ 機構 VMM OC-Scheduler

8 OC-Monitor (1) セキュリティ機構のCPU使用率を計測 オフロード元 VM とセキュリティ 機構を関連付ける
定期的に 計測・通知 セキュリティ機構のCPU使用率を計測 VMM 全体に対しての使用率 /proc /pid/stat を利用 オフロード元 VM とセキュリティ 機構を関連付ける オフロード元はドメインIDで指定 モニタするセキュリティ機構はプロセス ID で指定 OC-Monitor 20 セキュリティ 機構 ハイパーコール OC-Scheduler

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

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

11 物理CPUを使用している仮想CPUのcreditの変化
仮想マシン 仮想マシン 仮想マシン クレジットスケジューラ over under 仮想 CPU 仮想 CPU クレジット 物理 CPU を使用できる量 30ms ごとに仮想 CPU に配布 10ms ごとに減少 クレジットが正の仮想 CPU が優先 30ms ごとに仮想 CPU を切替 under 仮想 CPU 物理 CPU 物理CPUを使用している仮想CPUのcreditの変化 30ms ごとに仮想cpuが クレジットの値が正のほうが優先される 折れ線 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 実験目的 オフロード

15 Snort のオフロード 実験内容 オフロード元はウェブサーバ 外部のマシンから攻撃 オフロード元には cap を40
40% httperf 実験内容 オフロード元はウェブサーバ 外部のマシンから攻撃 httperf を使用 オフロード元には cap を40 最大 CPU 使用率 40% web snort httperf web snort httperf web snort

16 実験: Snort とオフロード元 VM の CPU 使用率の合計
オフロードすると制限を大幅 に超えている OffloadCage オフロードしてもオフロー ド元　VM の制限を守れて いる オフロードなし場合はオフ ロード元 VM のCPU使用率 実験内容は。 緑の線が単にオフロードした場合です。 オフロードした snort の分だけ制限を超えていることがわかります。 このオフロードした状態でOffloadCageを動作させた場合がピンク線です。 オフロードしたセキュリティ機構とオフロード元の仮想マシンの合計が制限を守れていることが確認できます。 オフロードしない場合はSnort がオフロード元に含まれているので、青の線がオフロード元の仮想マシンの CPU 使用率を表しています。 時間 ( 秒 )

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

18 実験: 性能比 Snort の CPU 使用率 ウェブサーバのスループッ ト Snort がオフロード前と異なる 資源の使い方をしている
OffloadCage オフロードしない場合より 高い CPU 使用率 ウェブサーバの分が減少 ウェブサーバのスループッ ト オフロードなしのときより、 スループットが減少 Snort がオフロード前と異なる 資源の使い方をしている 時間 ( 秒 ) 右上の図はSnort の CPU 使用率です。 単純にオフロードした場合、Snort はオフロード先のドメイン０のCPU 資源を大量に消費していることが確認できます。 しかし、OffloadCage を使うと、オフロード元の仮想マシンにSnortの分だけ制限がかかるのでWebサーバのスループットが落ち、その結果Snort の監視するパケットの量も減るため、単純にオフロードした場合より CPU 使用率が落ちたと考えられます。 オフロードしない場合は ４０％の制限のうちこの青の線くらいSnortが使用していることを表しています。 右下の図はオフロード元の仮想マシンで動作するウェブサーバのスループットです。 単純にオフロードした場合はSnortがオフロード元からいなくなる分だけウェブサーバが使える CPU 資源が増えるためスループットが上がったことを表します。 OffloadCage を使うと、オフロードしたSnortのCPU使用率の分だけオフロード元に制限がかかるため、その中で動作するWebserverが使える資源も減る。その結果スループットが単純にオフロードした場合よりも落ちています。 また、OffloadCageを使うと、オフロードしない場合よりもスループットが落ちてしまいます。 これは４０％の制限をSnortとウェブサーバの分け合い割合がことなるためです。 オフロードしない場合はSnort10%,webはのこりの30% オフロードしてOffloadCageを用いた場合はsnort20%, web20% 今後、この割合も考慮にいれる必要があると思います。 req/s

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

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

21 関連研究 セキュリティ機構のオフロードの研究 SEDF-DC [ Gupta et al. ’06]
Livewire [ Garfinkel. ’03 ] Saccessor [ 滝澤ら. ‘08 ] SEDF-DC [ Gupta et al. ’06] 仮想マシン間の性能分離 Xen のスプリットドライバのドメイン０内の処理による資 源の使用を仮想マシンに適切にカウント LRP [ Druschel et al. ’96 ] アプリケーション間の性能分離 カーネル内のネットワーク処理による資源の使用をアプ リケーションに適切にカウント Xen の仮想マシンのドライバは一部がドメイン０内にあります。 そのためネットワーク処理などはドメイン０が一部負担します。 そのドメイン０内のドライバの処理による CPU 使用量を、その処理を行わせた仮想マシンに適切にカウントします。 ドメイン０とドメインＵの間の通信の回数から使用量を推定しています。 ネットワーク処理のハンドラーなどのカーネル内の処理による資源の消費を、通信を行っているアプリケーションに適切にカウント 共有していたIP キューをプロセスごとに用意 ハンドラーが行っていた処理の一部をアプリケーションが呼ぶまで遅らせる

22 まとめ セキュリティ機構のオフロードを考慮して性能分離 を実現するシステム OffloadCageを提案した
OC-Monitor はセキュリティ機構の使用した資源を監 視 OC-Scheduler はセキュリティ機構とオフロード元の仮 想マシンをひとまとまりとしてスケジューリング Snort と Tripwire をオフロードしてもオフロード元の 制限を守れていることを確認した セキュリティ機構をオフロードしても仮想マシン間の性能分離が実現する OffloadCage を提案しました。 セキュリティ機構をオフロードすると、攻撃者がセキュリティ機構を直接攻撃しにくくなりセキュリティが向上します。 しかし、このオフロードにより仮想マシン間の性能分離に問題が生じます。 OffloadCage では OC-Monitorによりオフロードしたセキュリティ機構が使用した資源を監視して、 OC-Schedulerによりオフロード元の仮想マシンにカウントします。 実験では Snort と Tripwire をオフロードして、仮想マシンの性能分離が確かめました。

23 今後の課題 オフロードしたセキュリティ機構とオフロード元の仮 想マシンの資源分配を考慮 CPU 以外の資源も監視
メモリ ディスク したいと考えています するべきであると思います。