Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

第1回 松本勉強会 2012 05 11 - 公開版

4,896 views

Published on

自分のこれまでの研究成果とmod_process_securityについての復習。

第1回 松本勉強会 2012 05 11 - 公開版

  1. 1. Webサービスの高度化に耐えうる 基盤設計に関する研究(前半) 第1回 松本勉強会 5月11日 京都大学 情報学研究科 松本 亮介 @matsumotory
  2. 2. 今日の発表1. これまでの研究成果 – 2011年12月(FSとして発表) – 2012年03月(京大として発表)2. 3月の発表内容を説明 – mod_process_security 適宜、質問・指摘・アドバイス下さい!
  3. 3. 1. これまでの研究成果
  4. 4. 研究の背景• Webサービスを介したシステムが普及 – ホスティングサービス(レンタルサーバ) • 低価格化 • 高機能 – Webサービスの高度化(Twitter、Facebook等) • Webアプリケーションで情報の共有 • HTTPを介したプログラムの実行(Web API) – インシデントも増加 • Webサーバの高負荷 • アプリケーションの脆弱性からWebサーバの権限奪取 Webサービスの高度化に耐えうる基盤が必要
  5. 5. 研究概要• Webサーバと関連するOSのアーキテクチャを研究 – セキュリティ • Webアプリケーションの脆弱性の被害を最小限にする – Webサーバ上の任意アクセス制御 – 大規模(高集積) • 物理サーバにどれだけユーザ領域を積み込めるか 今日の発表 – プロセス数やfork()に注目 – パフォーマンス • アクセス集中時もパフォーマンス劣化を少なくする – ソケットI/OやファイルI/Oに注目(C10k問題) – 運用性 • 大規模Webサーバを効率良く運用する手法 – リソース割当のチューニング • Webサーバに簡単に機能追加する手法 次回の発表 – mod_luaやmod_mruby
  6. 6. Goodにしたい
  7. 7. これまでの研究成果(去年の12月) 大規模共有型Webバーチャルホスティング基盤の設計[1] 1. 高集積 2. セキュア Webサーバ群 他の顧客領域やシステ 1サーバで2,000仮想ホスト ム領域を覗き見できない (単一のサーバプロセス方式) アクセス制御手法クライアント 顧客領域 の追加 ロードバランサ ストレージ 3. 高い運用性 Ⅰ. 高負荷時 Ⅱ. リソース不足時 Ⅲ. 新規契約時 細やかな高負荷原 サーバ追加で 顧客領域追加で 因の調査と柔軟な 即時リソース増強 サービス即時反映 リソース制限手法 効率良く負荷分散[1] 松本亮介, 川原将司, 松岡輝夫, 汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善, インターネットと運用技術シンポジウム2011論文集, 2011,31-38 (2011-11-24). ※1 特許出願中. 7
  8. 8. これまでの研究成果(今年の3月) • セキュリティとパフォーマンス向上 – 12月のシステムはパフォーマンスを重視していない – 高速かつ安全にWebサービスのプログラムを処理する設計 • 前提は高集積 • スレッド単位で権限分離を行うアーキテクチャを提案※1 ─ Webサーバ上の動的コンテンツを高速に処理可能 ─ スレッドを利用することで性能劣化を少なくかつセキュアに動作 ─ これまではプロセス単位で権限を分離 ─ 複数あるアクセス制御手法を統一的に扱うアーキテクチャ 川原さんに謝辞しています※1• IEEE/IPSJ International Symposium on Applications and the Internet SAINT2012 で発表予定• IA/IOT/SITE/ISMS合同研究会で発表済み 8
  9. 9. 2. 3月の発表内容
  10. 10. Webサーバ上の動的コンテンツの扱いCGI実行方式は性能が低い – 高速に動作するDSO実行方式を使いたい – DSO実行方式とは? CGI実行方式 DSO実行方式 ボトルネックServer Process Server Process CGI Process Program Program インタプリタを組み込んでおくマルチテナント環境でもDSO実行方式を使って高速に処理したい
  11. 11. 動的コンテンツに関する問題従来のアクセス制御手法は不完全 – 従来のDSO実行方式のためのアクセス制御の問題 • プロセスの中で疑似的に権限を分離するアーキテクチャ • 不完全な仕様(性能劣化が大きい・セキュリティが弱い等) – CGI実行方式のためのアクセス制御の特徴 • プロセス単位で権限を分離するアーキテクチャ • アクセス制御とは関係なくCGI実行方式そのものの性能が低い – 実行方式毎にアクセス制御が存在していて煩雑 • 設定も複雑で開発者の敷居が高いマルチテナント環境で動的コンテンツを扱うには・・・ – CGI実行方式を使わざるを得ない – DSOを使うためには個別にデーモンやOSを起動して分離 ⇒ オーバースペックでリソース効率が悪い
  12. 12. 親サーバプロセス CGI実行方式 (owner : root) suEXECアーキテクチャ 子サーバプロセス (owner : apache) fork() execve() suexec-programボトルネック CGI用 プロセス (owner : root) setuid(), setgid() execve() CGI用 プロセス (owner : user1) index.php terminate process(owner: user1)
  13. 13. 親サーバプロセス DSO実行方式 (owner : root) mod_ruid2アーキテクチャ Set cap(Linux capability) 子サーバプロセス (owner : apache) ボトルネック Set capability setuid(), setgid() Unset cap × 子サーバプロセス execve() (owner : user1) Set capability index.php setuid(), setgid() terminate process (owner: user1) × Index.php経由で 権限変更が可能
  14. 14. 提案するアクセス制御アーキテクチャ - mod_process_security -• スレッドを利用してボトルネックを低減 – 制御用スレッド単位で権限分離するアーキテクチャ • 動的コンテンツのリクエスト時にスレッド生成 • プロセスの生成・破棄は不要 • スレッドの生成・破棄により処理効率が上昇 – 実行方式で区別しない統一的アーキテクチャ • CGIやDSOに個別のソフトウェアを組み込む必要無し – Apacheモジュールで簡単に組み込み・設定可能 • 開発者が扱いやすい仕様
  15. 15. 親サーバプロセス CGI実行方式 (owner : root) mod_process_security 子サーバプロセス (owner : apache) Create thread, set cap 制御用スレッド (owner : apache) setuid・setgid, unset cap CGIの仕様 制御用スレッド (owner : user1) execve() CGI用プロセス (owner : user1) index.php terminate process destroy thread(owner: user1)
  16. 16. 親サーバプロセス FCGI実行方式 (owner : root) mod_process_security 子サーバプロセス (owner : apache) Create thread, set cap 制御用スレッド (owner : apache) setuid・setgid, unset cap FCGIの仕様 制御用スレッド (owner : user1) execve() FCGI用プロセス (owner : user1) index.php destroy thread(owner: user1) 再利用
  17. 17. 親サーバプロセス DSO実行方式 (owner : root) mod_process_security 子サーバプロセス (owner : apache) Create thread, set cap 制御用スレッド (owner : apache) DSOの仕様 setuid・setgid, unset cap phpを直接実行 制御用スレッド (owner : user1) index.php (owner: user1) destroy thread
  18. 18. 実験• 1秒間に処理可能なレスポンス数を計測(response/sec) • クライアントからWebサーバに対して1秒間に複数リクエストを生成 • リクエスト数を変動させて、スループットが低下するか評価 • アクセス制御の適応有無でスループットに差がでるか評価 • phpinfo()を表示するプログラム(54KB)ベンチマークソフト(httperf 0.9.0) クライアントCPU Intel Core2Duo E8400 3.00GHzMemory 4GBNIC Realtek RTL8111/8168B 1GbpsOS CentOS 5.6 Webサーバ CPU Intel Xeon X5355 2.66GHz Memory 8GB NIC Broadcom BCM5708 1Gbps OS CentOS 5.6 Middle Ware Apache 2.2
  19. 19. 導入方法$ sudo cp mod_process_security.so /etc/httpd/modules/.$ cat /etc/httpd/conf.d/ps.confLoadModule process_security_module modules/mod_process_security.soPSExtensions .php .cgi .py .pl .rb# 静的コンテンツも動的コンテンツも適応したい場合は以下# PSExAll On$ sudo /etc/init.d/httpd restart
  20. 20. スループット比較 3000 DSO(mod_process_security)は DSO(アクセス制御無し)と比較 2500 してスループット劣化は微小 DSO実行方式Responses/sec 2000 CGIのアクセス制御のス 1500 ループット劣化は微小 1000 CGI実行方式 DSO(mod_ruid2)は全てのRequestに対し 500 (次スライドで拡大) て、5前後のResponse/secでありスルー プット劣化が大きい 0 Requests/sec DSO(mod_process_security) DSO(アクセス制御無し) DSO(mod_ruid2) CGI(アクセス制御無し) CGI(suEXEC) CGI(mod_process_security)
  21. 21. CGIに関するスループット比較 200 180Responses/sec 160 140 アクセス制御無し、 mod_process_secuiry、 120 suEXECの順に性能が高い。 100 100 200 300 400 500 600 700 800 900 1000 Requests/sec CGI(アクセス制御無し) CGI(suexec) CGI(mod_process_security)
  22. 22. 考察• mod_process_security採用によるスループット劣化は少ない – アクセス制御を組み込まない場合と比較 • CGI実行方式の場合はsuEXECよりもスループット劣化が少ない • DSO実行方式の場合はmod_ruid2よりもスループット劣化が少ない アクセス制御無しと 実行方式 アクセス制御手法 比較したスループット 低下率(平均) suEXEC 2.13% CGI mod_process_security 1.48% mod_ruid2やmod_suid2 99.9% DSO mod_process_security 0.19%
  23. 23. ご清聴ありがとうございました

×