Step 1: Think about the web server's design, and what a successful attacker could do.
The web server httpd(8) runs in a chroot(2) and is structured with privilege separation. In the event of a successful web server compromise, the attacker should have only unprivileged functions and be limited to the chroot() filesystem, which is /var/www by default.
You must determine what the impact of such a breach could be. Examine both the immediate access to data within the chroot(), and the use of the web server as a new attack vector.
Data access: Do you have anything of value stored within /var/www, or whatever chroot() you provision? Are there any databases, user data, or applications (such as PHP) that you want to protect? Are they protected from the www user?
Attack Vector: What internal network or socket access restrictions should be considered? What should the web server not normally be able to connect with? How will you block these attacks in advance, before a breach occurs?
Step 2: Consider the operational features of virtual machines.
You may want to separate the functions of your web applications. For example, you may want a web server to provide presentation services, an application server to provide the application's logic, and a database server to provide and store the data. By isolating the three functions, you may be able to provide performance scaling by adding and removing web and application servers as transaction demands vary. Or provide additional network layers to isolate your database servers from all external accesses except by your application servers.
But please, don't consider virtual machines a "security" feature. Consider them operational isolation.
|