1 / 28

Secure and High-performance Web Server System for Shared Hosting Service

Secure and High-performance Web Server System for Shared Hosting Service. D a isuke Ha r a and Yasuichi Nakayama The University of Electro-Communications, Tokyo, Japan. Outline. Introduction Background Problems of large-scale hosting service and web server Proposal - H i -s a p Design

ilya
Download Presentation

Secure and High-performance Web Server System for Shared Hosting Service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Secure and High-performance Web Server System for Shared Hosting Service Daisuke Hara and Yasuichi Nakayama The University of Electro-Communications, Tokyo, Japan ICPADS 2006@Minneapolis

  2. Outline • Introduction • Background • Problems of large-scale hosting service and web server • Proposal - Hi-sap • Design • Implementation • Evaluation • Conclusions

  3. Introduction • Problem of existing web servers • Server embedded interpreters cannot be used safely in large-scale environments like a shared hosting service. • Proposal - Hi-sap • Web objects that are stored in a server are divided into partitions*. • Server processes run under the privilege of different users in every partition. • Achievement • Hi-sap solves the problem. • It achieves high performance & scalability. (*) “partition” is a unit of division of web objects. (e.g. site, content, QUERY_STRING)

  4. Background • More people are creating their own websites as the Internet grows in popularity. • weblog, wiki, CMS • Shared hosting services are widely used. • Many customers share a server. • 100s - 1000s sites/server • low price & flexible • custom CGI, etc.

  5. Server embedded interpreters • e.g. PHP, mod_ruby, mod_perl • Because they have server processes including interpreters of language processors, • they can improve performance in processing dynamic content like weblogs and wikis.

  6. Problem of existing web servers It is required to grant read permission to an other. (rw-r--r--) A’s website B’s website ID & Pass authentication auth content auth content C’s website browser steal & delete Server Internal users can steal & delete authentication content without authentication (cp, rm commands or malicious CGI scripts).

  7. Problem of existing web servers (cont.) • Existing solution: POSIX ACL & suEXEC • CGI scripts run under the privilege of the site owner by using suEXEC. • Permissions of public access files are granted only to the dedicated user* by using POSIX ACL. • It is not required to grant read permission to an other. (*) “dedicated user” is user account that runs server processes. e.g. www, apache, www-data

  8. Problem of existing web servers (cont.) • Even if POSIX ACL & suEXEC is used, the problem occurrs when server embedded interpreters are used. • Dynamic content that use server embedded interpreters (e.g. PHP, mod_ruby, mod_perl) also run under the privilege of a dedicated user. • Malicious PHP scripts can steal & delete authentication content.

  9. Harache ([13][14]) • Predecessor of Hi-sap • Server processes run under the privilege of the site owner. Harache root root ② GET /~userA/ ① root userA ③ ④ browser • A browser sends request to the user A's website. • The privilege of the server process is changed to user A. • The server process processes the request. • It returns a response to the browser. Server Process

  10. Harache (cont.) • Server embedded interpreters can be used safely. • File permissions to a dedicated user are not necessary. • It is required to grant permissions only to the site owner. • But, it cannot fully use the increased speed of server embedded interpreters. • Server processes terminate after each session. (= CGI) Hi-sapsolves Harache’s performance problem.

  11. Goal • Realization of secure, high-performance, and scalable web server system, Hi-sap • Secure: Scripts of a partition cannot access other partitions. • High performance: Dynamic content can be processed at high speed by fully using the increased speed of server embedded interpreters. • Scalable: A number of partitions can be housed in a server.

  12. Design • Security • Server processes run under the privilege of different users in every partition. (= Harache) • The system brings access control into operation with a secure OS. • Performance • The system pools server processes that run under the privilege of the different users. (!= Harache) • Scalability • The system controls the creation and termination of server processes. Content Access Scheduler

  13. Content Access Scheduler • Web-server level scheduler • [aim] It enhances the scalability of the number of partitions in a server. • [method] It controls the creation and termination of server processes. By using the suitable scheduler for the purpose, it achieves high-scalability.

  14. Implementation • OS: Linux OS with SELinux • dispatcher • reverse proxy server • Apache 2.0.55 + mod_hisap • workers • Each worker runs under the privilege of a different user and processes requests for a specific dedicated partition. • Apache 2.0.55 x 1000 • Any web server software can be used. • hisapd • Content Access Scheduler

  15. UNIX Domain socket GET / HTTP/1.1 Host: www.C.net A C C A C A C Overview of request processing HTTP asking to activate worker C confirming if worker C is active Browser worker A has no requests hisapd dispatcher www root sending the response heavy load www root OK reverse proxy terminating worker A activating worker C … B B process the request B Server workers

  16. Scheduling algorithm • We developed Content Access Scheduler to avoid thrashing. • Thrashing decreases the performance of web servers dramatically. • Algorithm of worker activation • hisapd dynamically activates workers after requests from the dispatcher. • Algorithm of worker termination • When thrashing seems to occur, hisapd terminates workers that have not been requested recently.

  17. Scheduling algorithm (cont.) • Conditions for which hisapd judges that thrashing seems to occur • A swap-in occurs. • A swap-out occurs. • Memory use is 99% or more. • Conditions for which hisapd chooses workers to terminate • The worker is active. • The worker is not recorded in the most recent 10,000 requests.

  18. Evaluation • Experimental environments Gigabit Ethernet Gigabit Ethernet

  19. Evaluation (conf.) • Basic performance evaluation • We evaluated the basic performance in processing dynamic content. • Scalability evaluation • We evaluated the scalability of the number of partitions in a server in processing dynamic content. • Target content • We sent requests to a PHP script that calls phpinfo(). • The script displays the system information of the PHP language processor. (40 KB per request)

  20. Basic performance evaluation • Aim • to determine useful performance of our system • Systems for comparison • Apache • One-to-one • It uses networks with a reverse proxy, and has a dispatcher and many workers that are dedicated to process requests for each partition. • Although it is similar to our system, mod_hisap and hisapd are not installed. • Apache with suEXEC • Benchmark • httperf benchmark ver. 0.8

  21. Basic performance evaluation (cont.) • The system loses an avg. of 28.0% of the throughput relative to Apache. • The overhead of the system is because of a reverse proxy. • However, the system has high throughput relative to suEXEC. • The system loses an avg. of 1.0% of the throughput relative to One-to-one. • The overhead of mod_hisap & hisapd is very low.

  22. Scalability evaluation • Aim • to determine the effectivenessof Content Access Scheduler • Comparison system • One-to-one • mod_hisap and hisapd (Content Access Scheduler) are not installed. • Benchmark • Apache benchmark ver. 2.0.41-dev

  23. Scalability evaluation (cont.) • Our system’s scalability is high. • The throughput decrement due to an increase in the number of partitions was low. • For One-to-one, the OS crashed due to a memory shortage when the number of partitions was 600.

  24. Scalability evaluation (cont.) • The swap use of One-to-one dramatically increases due to an increase in the number of partitions. • This is the reasonof the OS crash. • Our system does not useswap space as much because of Content Access Scheduler.

  25. Comparison of approaches

  26. Conclusions • Proposal: Hi-sap • Secure and high-performance web server system • Implementation: • On a Linux OS with SELinux. • Achievement: • High performance • High scalability

  27. Future Work • Creating various Content Access Schedulers • for wiki • for weblog • for CMS, etc. • Evaluating these schedulers

  28. Thank you. Any questions/comments?

More Related