Apache Security - Ivan Ristic [124]
In addition to facilitating disaster recovery, another reason to keep an application isolated is to guard servers from intrusions that take place through applications. Such isolation contains the intrusion and makes the life of the attacker more difficult due to the absence of the tools he would like to use to progress further. This kind of isolation is done through the chroot process (see Chapter 2).
Isolating Application Modules
Isolating application modules from each other helps reduce damage caused by a break-in. The idea is not to put all your eggs into one basket. First, you need to determine whether there is room for isolation. When separating the application into individual logical modules, you need to determine whether there are modules that are accessed by only one class of user. Each module should be separated from the rest of the application to have its own:
Domain name
IP address
System user account
Database access account
Accounts for access to other resources (e.g., LDAP)
This configuration will allow for maximal security and maximal configuration flexibility. If you cannot accommodate such separation initially, due to budget constraints, you should plan for it anyway and upgrade the system when the opportunity arises.
To argue the case for isolation, consider the situation where a company information system consists of the following modules:
A self-service application for end users (public access)
An extranet application for partners (restricted access)
An intranet application (more restricted access)
A central administration module (very restricted access)
Four groups of users are each using their own application module and, what is more important, the company has four different levels of risk. The public application is the one carrying the largest risk. If you isolate application modules, a potential intrusion through the public portion of the application will not spill into the rest of the company (servers, databases, LDAP servers, etc.).
Here is the full range of solutions for isolation, given in the order of decreasing desirability from a security standpoint:
Each application module resides on its own physical server. This is very good from a security point of view but can be costly because it requires many servers (where they would otherwise not be required for performance reasons) and is expensive to maintain. The general trend in the industry is to consolidate servers, not have more of them.
Each application module resides on a virtual server. This is an interesting solution, which I will cover in more detail shortly.
The application modules share the same machine, but each is given a separate web server. Coupled with putting each web server in its own jail (via chroot), it can make a very good solution. It can be tricky if only one IP address is available, but you can succeed by putting web servers on different ports with a central web server in front working as a reverse proxy.
Application modules share the server, the web server, everything. This is the worst-case scenario, and the least desirable one.
Utilizing Virtual Servers
As previously mentioned, having many physical servers for security purposes can be costly. In between a full separate physical server solution and a chroot sits a third option: virtual servers.
Virtual servers are a software-based solution to the problem. Only one physical server exists, but it hosts many virtual servers. Each virtual server behaves like a less-powerful standalone server. There are many commercial options for virtual servers and two open source approaches:
User Mode Linux (http://user-mode-linux.sourceforge.net)
Linux VServer (http://www.linux-vserver.org)
Both solutions offer similar functionality, yet they take different paths to get there. User Mode Linux is a full emulation of a system, and each virtual server has its own kernel running and its own process list, memory allocation, etc. Virtual servers on a Linux VServer