1 / 21

Hi-sap: Secure and Scalable Web Server System for Shared Hosting Services

Hi-sap: Secure and Scalable Web Server System for Shared Hosting Services. Daisuke Hara , Ryohei Fukuda, Kazuki Hyoudou, Ryota Ozaki, and Yasuichi Nakayama The University of Electro-Communications, Tokyo, Japan. Outline. Introduction Background Increase in end users’ Web contents

minerva-stephens
Télécharger la présentation

Hi-sap: Secure and Scalable Web Server System for Shared Hosting Services

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. Hi-sap: Secure and ScalableWeb Server Systemfor Shared Hosting Services Daisuke Hara, Ryohei Fukuda, Kazuki Hyoudou, Ryota Ozaki, and Yasuichi Nakayama The University of Electro-Communications, Tokyo, Japan BROADNETS 2010@Athens, Greece

  2. Outline • Introduction • Background • Increase in end users’ Web contents • Problems of sharing a Web server • Existing approaches about runtime privilege • Proposal - Hi-sap: Secure and ScalableWeb Server System for Shared Hosting Services • Design • Implementation • Evaluation • Conclusions

  3. Introduction • Problem of sharing a Web server • Malicious users that share the server can potentially steal, delete, or tamper with other user’s files. • Proposal: a Web server system that solves the problem and that achieves high site-number scalability with little performance degradation • Contributions: • We have clarified security problems and requirements of shared hosting services. • We have clarified that existing approaches and their limitations. • We have designed a secure and scalable Web server system for shared hosting services, and implemented it on a Linux OS with SELinux.

  4. Background • More people are creating their own content and publishing it on the Web as the Internet grows in popularity. • End users create weblogs, wikis, CMSs. • Shared hosting services are widely used. • Many customers share a server. • 100s - 1000s sites/server • low price & flexible • custom CGI, etc.

  5. Hosting service • Shared hosting service vs. Dedicated hosting service Web server program Web site … … machine • Suitable for end users • Target of our study

  6. Problem of sharing a Web server • Processes of a Web server program (e.g. Apache) • A parent process run under the privilege of a root user. • binding port 80 • Many server (child) processes run under the privilege of a dedicated user (e.g. apache, www-data, www). • processing requests • Read, write, execution permission on these content files must be granted to an other. • UNIX permission model: owner/group/other

  7. (1) receive HTTP request Problem of sharing a Web server (cont.) • Malicious users that share the server can illegally steal, delete, or tamper with other user’s files. • (i-1) command attack, (i-2) HTTP attack • (0) File permission • rw-/---/r-- (static contents (e.g., HTML and image files)) • rw-/---/rw- (e.g., log files, wiki’s data files) • rwx/---/r-x (CGI scripts) Web server Web client www A www (i-1) www Malicioususer B (3) send response (i-2) www C (2) process request ・・・ ・・・ ・・・ www: runtime privilege HTTP Server process User account User’s file Command-line tools

  8. Existing approaches about runtime privilege • Existing approaches solve a portion of the security problem, but they either lack performance,site-number scalability, or generality.

  9. Design • The privilege of server processes is changed in advance to reuse them. => It can avoid performance degradation. • A “dispatcher” distributes requests to “workers” that are server processes and run under the privilege of an individual user. Dispatcher forward A B C workers A,B,C – privilege of server processes (an individual user) reusable

  10. Partition • Hi-sap protects customer files by isolating them in separate security domains, called “partition”. • A unit of protection by using a secure OS facility Site X (Partition A) Site Y Content Y1 (Partition B) Content Y2 (Partition C) Domain A Domain B Domain C Server process worker (C) worker (A) worker (B) Customer file mod_python mod_perl mod_ruby File access (b) (a) File permission rw-/---/-— Type enforcement of a secure OS Type A Type B Type C A,B,C – privilege/owner (an individual user) A B C • An attacker cannot access files in other partition, • even if the files are on the same site.

  11. Content access scheduler • A Web-server-level scheduler that enhances the scalability of the number of partitions in a server. • It controls the creation and termination of workers.

  12. Implementation • We implemented Hi-sap on a Linux OS with SELinux. • The dispatcher was implemented as an Apache module, mod_hisap, on an Apache HTTP server (ver. 2.0.55). • One thousand Apache HTTP servers (ver. 2.0.55) were used as workers. • Each worker waited for requests at a unique port. • The content access scheduler and other management facilities of the workers were implemented as a daemon, hisapd.

  13. (1) receive request GET / HTTP/1.1 Host: www.C.net worker A worker C C A C A C Overview of request processing (3) ask to activate worker C (2) determine if worker C is active (i) select worker A, who has no requests Web client heavy load hisapd dispatcher root www www (8) send response root (4) activate worker C (ii) terminate worker A (7) forward response (5) forward request … worker B reverseproxy B (6) process request B Hi-sap workers UNIX domain socket HTTP A,B,C,www,root: privilege Server process

  14. Evaluation • Experimental environment Gigabit Ethernet Gigabit Ethernet

  15. Basic performance evaluation - throughput - • The throughput with Hi-sap was, on average, 2.0% lower than with Apache and was a maximum of 6.9% lower. • The overhead of Hi-sap is very low. • Web application: tDiary 2.0.2 (written in Ruby) • Benchmark: httperf 0.8 • One-to-one is similar to Hi-sap (mod_hisap and hisapd were not installed).

  16. Basic performance evaluation - latency - • The latencies of Apache, one-to-one, and Hi-sap were small. • The latency of suEXEC was very large, so suEXEC is not suitable.

  17. Site-number scalability evaluation • Hi-sap’s scalability is high. • The reduction in throughput with Hi-sap as the number of partitions increased was lower than with one-to-one. • With one-to-one, the OS crashed due to a memory shortage when the number of partitions reached about 600. • Web application: PHP script (It calls phpinfo(), which displays the system information of the PHP language processor.) • Benchmark: Apache Benchmark

  18. Site-number scalability evaluation- memory utilization - • The swap utilization of one-to-one increased dramatically as the number of partitions increased. • This is the reason for the OS crash. • Hi-sap does not use swap space as much because of content access scheduler.

  19. Conclusions • Proposal: • A Web server system that solves the problem and that achieves high site-number scalability with little performance degradation • Contributions: • We have clarified security problems and requirements of shared hosting services. • We have clarified existing approaches and their limitations. • We have designed a secure and scalable Web server system for shared hosting services, and implemented it on a Linux OS with SELinux. Our evaluation results demonstrate Hi-sap qualitatively and quantitatively satisfies the requirements.

  20. Future work • Optimizing the content access scheduler algorithm to avoid swapping and to enable more than 1000 sites to be housed • Applying the concept of Hi-sap to other server programs that provide service to many users • e.g., mail servers and network file systems

  21. Thank you. Any questions/comments?

More Related