freeVSD -  Security
===================

This document describes the following security implications which should be 
considered when using freeVSD.

- Security Considerations of Using Apache
- Running Non-SSL Versions of freeVSD Through Remote Access
- Security Considerations of Port Redirection

1. Security Considerations of Using Apache
==========================================

The default Apache installation, provided in the sample site specific
scripts, is defined to listen on port 8080 and 8443 for web traffic, and start
as the user `web'.

Originally the web server was started as user root (to listen on ports 80 and
443) and then made to drop its privileges and run as user `web'.  However,
two problems were found:

  A malicious admin user could create his own Apache module and edit 'httpd.conf'
  to start it.  The module initialisation runs as user root, so it is possible
  to create a setuid '/bin/sh' directory allowing the user complete access to all binaries  
  that control all virtual servers. Moreover, allowing the user to create a '/bin/sh' 
  directory can corrupt the server's hard disk.

  NOTE: The '/bin/sh' directory allows the user to run as root.

  If you change Apache's directives for CustomLog, ErrorLog or AccessLog
  to log to a pipe rather than a file, then the program that is on the other end of 
  the pipe runs as root. The 'admin' user could simply write a malicious 
  program that creates a setuid '/bin/sh' directory.

To solve the problem of listening on port 8080 and 8443, port forwarding is provided by 
the 'vsdredirect' function within the 'vsboot' program. This spawns a chrooted port-redirection process when a virtual server is booted. When a virtual server is stopped, this process and all others are killed.

On Linux 2.4 running iptables it is possible to set up similar port-forwarding 
using the following commands:

  $ iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
  $ iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443

NOTE:	If you wish to disable the port-forwarding process, you can recompile and reinstall 'vsboot' using the --disable-vsdredirect switch.


2. Running Non-OpenSSL Versions of freeVSD Through Remote Access
================================================================

If you are running a non-SSL version of freeVSD, it is strongly recommended that 
port 1725 be placed behind a firewall to protect access from external sites. You can set
up a firewall using iptables or ipchains that are available in the Linux kernal versions.  

On the Linux 2.4 kernal running iptables, it is possible to set up a firewall using
the following commands:

  $ iptables -A INPUT -p tcp -s 1.2.3.4 --dport 1725 -j ACCEPT
  $ iptables -A INPUT -p tcp -s 0/0 --dport 1725 -j REJECT

NOTE:	1.2.3.4 is the example IP address of one machine where all virtual server
administration is performed from.

If you are using the Linux 2.2 kernal running ipchains the following commands perform the same function:

  $ ipchains -A input -p tcp -s 1.2.3.4 --dport 1725 -j ACCEPT
  $ ipchains -A input -p tcp -s 0/0 --dport 1725 -j REJECT

3. Security Considerations of Port Redirection
==============================================

The port redirector implemented for FreeVSD does not log the correct IP address of the requesting client in the http access log. By default it logs only the IP address of the virtual server. This problem can be solved using ipchains.

To implement port redirection using ipchains, a rule needs to be set
up for each virtual server, so that both tcp and udp packets get
forwarded to a unique port number for each virtual server. For example
to implement ipchains for vsone execute:

> ipchains -A input  --dst 192.168.100.20 --dport 80 -p tcp -j REDIRECT 8081
> ipchains -A input  --dst 192.168.100.20 --dport 80 -p udp -j REDIRECT 8081

where 192.168.100.20 is the IP address of the virtual server and 8081 is
the unique port number allocated to that virtual server only. The HTTP
configuration file then needs to be modified so that both the Port and
Listen directives are changed so that they point to that port, for example:

Port 8081
Listen 8081

NOTE: The IP address has been removed from the Listen directive.

The following example shows implementing ipchains for virtual server 'vstwo'. In this instance the Port and Listen directives are substituted as well as the IP addresses of that virtual server. 

> ipchains -A input  --dst 192.168.100.21 --dport 80 -p tcp -j REDIRECT 8082
> ipchains -A input  --dst 192.168.100.21 --dport 80 -p udp -j REDIRECT 8082

The following entries then need to be set in httpd.conf 

Port 8082
Listen 8082




  















