ia64/xen-unstable

changeset 7772:f1c07363956b

Add "Securing Xen" adapted from Anthony Liguori's Wiki entry.
author Robb Romans <FMJ@us.ibm.com>
date Thu Nov 10 11:43:24 2005 -0500 (2005-11-10)
parents 79e8991af6b4
children 476d02c1346c
files docs/src/user.tex docs/src/user/securing_xen.tex
line diff
     1.1 --- a/docs/src/user.tex	Thu Nov 10 11:42:58 2005 -0500
     1.2 +++ b/docs/src/user.tex	Thu Nov 10 11:43:24 2005 -0500
     1.3 @@ -87,6 +87,9 @@
     1.4  %% Chapter Domain Configuration moved to domain_configuration.tex
     1.5  \include{src/user/domain_configuration}
     1.6  
     1.7 +%% Chapter Securing Xen
     1.8 +\include{src/user/securing_xen}
     1.9 +
    1.10  %% Chapter Build, Boot and Debug Options moved to build.tex
    1.11  \include{src/user/build}
    1.12  
     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/docs/src/user/securing_xen.tex	Thu Nov 10 11:43:24 2005 -0500
     2.3 @@ -0,0 +1,85 @@
     2.4 +\chapter{Securing Xen}
     2.5 +
     2.6 +This chapter describes how to secure a Xen system. It describes a number
     2.7 +of scenarios and provides a corresponding set of best practices. It
     2.8 +begins with a section devoted to understanding the security implications
     2.9 +of a Xen system.
    2.10 +
    2.11 +
    2.12 +\section{Xen Security Considerations}
    2.13 +
    2.14 +When deploying a Xen system, one must be sure to secure the management
    2.15 +domain (Domain-0) as much as possible. If the management domain is
    2.16 +compromised, all other domains are also vulnerable. The following are a
    2.17 +set of best practices for Domain-0:
    2.18 +
    2.19 +\begin{enumerate}
    2.20 +\item \textbf{Run the smallest number of necessary services.} The less
    2.21 +  things that are present in a management partition, the better.
    2.22 +  Remember, a service running as root in the management domain has full
    2.23 +  access to all other domains on the system.
    2.24 +\item \textbf{Use a firewall to restrict the traffic to the management
    2.25 +    domain.} A firewall with default-reject rules will help prevent
    2.26 +  attacks on the management domain.
    2.27 +\item \textbf{Do not allow users to access Domain-0.} The Linux kernel
    2.28 +  has been known to have local-user root exploits. If you allow normal
    2.29 +  users to access Domain-0 (even as unprivileged users) you run the risk
    2.30 +  of a kernel exploit making all of your domains vulnerable.
    2.31 +\end{enumerate}
    2.32 +
    2.33 +\section{Security Scenarios}
    2.34 +
    2.35 +
    2.36 +\subsection{The Isolated Management Network}
    2.37 +
    2.38 +In this scenario, each node has two network cards in the cluster. One
    2.39 +network card is connected to the outside world and one network card is a
    2.40 +physically isolated management network specifically for Xen instances to
    2.41 +use.
    2.42 +
    2.43 +As long as all of the management partitions are trusted equally, this is
    2.44 +the most secure scenario. No additional configuration is needed other
    2.45 +than forcing Xend to bind to the management interface for relocation.
    2.46 +
    2.47 +\textbf{FIXME:} What is the option to allow for this?
    2.48 +
    2.49 +
    2.50 +\subsection{A Subnet Behind a Firewall}
    2.51 +
    2.52 +In this scenario, each node has only one network card but the entire
    2.53 +cluster sits behind a firewall. This firewall should do at least the
    2.54 +following:
    2.55 +
    2.56 +\begin{enumerate}
    2.57 +\item Prevent IP spoofing from outside of the subnet.
    2.58 +\item Prevent access to the relocation port of any of the nodes in the
    2.59 +  cluster except from within the cluster.
    2.60 +\end{enumerate}
    2.61 +
    2.62 +The following iptables rules can be used on each node to prevent
    2.63 +migrations to that node from outside the subnet assuming the main
    2.64 +firewall does not do this for you:
    2.65 +
    2.66 +\begin{verbatim}
    2.67 +# this command disables all access to the Xen relocation
    2.68 +# port:
    2.69 +iptables -A INPUT -p tcp --destination-port 8002 -j REJECT
    2.70 +
    2.71 +# this command enables Xen relocations only from the specific
    2.72 +# subnet:
    2.73 +iptables -I INPUT -p tcp -{}-source 192.168.1.1/8 \
    2.74 +    --destination-port 8002 -j ACCEPT
    2.75 +\end{verbatim}
    2.76 +
    2.77 +\subsection{Nodes on an Untrusted Subnet}
    2.78 +
    2.79 +Migration on an untrusted subnet is not safe in current versions of Xen.
    2.80 +It may be possible to perform migrations through a secure tunnel via an
    2.81 +VPN or SSH. The only safe option in the absence of a secure tunnel is to
    2.82 +disable migration completely. The easiest way to do this is with
    2.83 +iptables:
    2.84 +
    2.85 +\begin{verbatim}
    2.86 +# this command disables all access to the Xen relocation port
    2.87 +iptables -A INPUT -p tcp -{}-destination-port 8002 -j REJECT
    2.88 +\end{verbatim}