slides (PPT)

download slides (PPT)

of 28

  • date post

    26-May-2015
  • Category

    Documents

  • view

    844
  • download

    1

Embed Size (px)

Transcript of slides (PPT)

  • 1. Secure and High-performance Web Server Systemfor Shared Hosting Service D a isuke Ha r aand Yasuichi Nakayama The University of Electro-Communications, Tokyo, Japan

2. Outline

  • Introduction
  • Background
    • Problems of large-scale hosting service and web server
  • Proposal -H i -s a p
    • Design
    • Implementation
  • Evaluation
  • Conclusions

3. Introduction

  • Problemof existing web servers
    • Server embedded interpreters cannot be used safely in large-scale environments like a shared hosting service.
  • Proposal-H i -s a p
    • Web objects that are stored in a server are divided intopartitions* .
    • Server processes run under the privilege of different users in every partition.
  • Achievement
    • H i -s a psolves 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. Problemof existing web servers As website Bs website Cs website Server Internal users can steal & delete authentication content without authentication (cp, rm commands or malicious CGI scripts). browser authentication auth content auth content steal & delete ID & Pass It is required to grant read permission to another. (rw-r--r--) 7. Problemof 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 another .
    • (*) dedicated user is user account that runs server processes.
    • e.g. www, apache, www-data

8. Problemof 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 ofH i -s a p
  • Server processes run under the privilege of the site owner.

root root root browser GET /~userA/

  • 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.

Harache Server Process userA 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)

H i -s a p solves Haraches performance problem. 11. Goal

  • Realization of secure, high-performance, and scalable web server system,H i -s a p
    • 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. Overview ofrequest processing B workers GET / HTTP/1.1 Host: www.C.net terminating workerA www www B B hisapd asking to activate workerC root root workerAhas no requests HTTP UNIX Domain socket sending the response process the request reverse proxy activating workerC confirming if workerCis active dispatcher OK Browser Server heavy load A A A C C C C 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 DELL PowerConnect 2724 1000 BASE-T x 24 Switching Hub Network Broadcom BCM5704C1 Gbps NIC Fedora Core 4(kernel 2.6.14) OS 4 GB (swap 8 GB) Memory AMD Opteron 240EE 1.4 GHz x 2 CPU Server Intel PRO/1000XT PWLA8490XT 1 Gbps NIC Fedora Core 4(kernel 2.6.14) OS 256 MB (swap 512 MB) Memory Intel Pentium III Xeon500 MHz x 4 CPU Client 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 callsphpinfo().
      • 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.