Apache Security - Ivan Ristic [125]
Both solutions appear to be production ready. I have used User Mode Linux with good results. Many companies offer virtual-server hosting using one of these two solutions. The drawback is that both solutions require heavy kernel patching to make them work, and you will need to spend a lot of time to get them up and running. Note: User Mode Linux has been incorporated into the SUSE Enterprise Server family since Version 9.
On the plus side, consider the use of virtual servers in environments where there are limited hardware resources available, with many projects requiring loose permissions on the server. Giving each project a virtual server would solve the problem without jeopardizing the security of the system as a whole.
Host Security
Going backward from applications, host security is the first layer we encounter. Though we will continue to build additional defenses, the host must be secured as if no additional protection existed. (This is a recurring theme in this book.)
Restricting and Securing User Access
After the operating system installation, you will discover many shell accounts active in the /etc/passwd file. For example, each database engine comes with its own user account. Few of these accounts are needed. Review every active account and cancel the shell access of each account not needed for server operation. To do this, replace the shell specified for the user in /etc/password with /bin/false. Here is a replacement example:
ivanr:x:506:506::/home/users/ivanr:/bin/bash
with:
ivanr:x:506:506::/home/users/ivanr:/bin/false
Restrict whom you provide shell access. Users who are not security conscious represent a threat. Work to provide some other way for them to do their jobs without the shell access. Most users only need to have a way to transport files and are quite happy using FTP for that. (Unfortunately, FTP sends credentials in plaintext, making it easy to break in.)
Finally, secure the entry point for interactive access by disabling insecure plaintext protocols such as Telnet, leaving only secure shell (SSH) as a means for host access. Configure SSH to refuse direct root logins, by setting PermitRootLogin to no in the sshd_config file. Otherwise, in an environment where the root password is shared among many administrators, you may not be able to tell who was logged on at a specific time.
If possible, do not allow users to use a mixture of plaintext (insecure) and encrypted (secure) services. For example, in the case of the FTP protocol, deploy Secure FTP (SFTP) where possible. If you absolutely must use a plaintext protocol and some of the users have shells, consider opening two accounts for each such user: one account for use with secure services and the other for use with insecure services. Interactive logging should be forbidden for the latter; that way a compromise of the account is less likely to lead to an attacker gaining a shell on the system.
Deploying Minimal Services
Every open port on a host represents an entry point for an attacker. Closing as many ports as possible increases the security of a host. Operating systems often have many services enabled by default. Use the netstat tool on the command line to retrieve a complete listing of active TCP and UDP ports on the server:
# netstat -nlp
PID/
Proto Recv-Q Send-Q Local Address Foreign Address State Program name
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 963/mysqld
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 834/xinetd
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 834/xinetd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 13566/httpd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1060/proftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 834/xinetd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 979/sendmail
udp 0 0 0.0.0.0:514 0.0.0.0:* 650/syslogd
Now that you know which services are running, turn off the ones you do not need. (You will probably want port 22 open so you can continue to access the server.) Turning services off permanently