This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] Add "Securing Xen" adapted from Anthony Liguori's Wiki e

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] Add "Securing Xen" adapted from Anthony Liguori's Wiki entry.
From: Xen patchbot -unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 10 Nov 2005 19:20:08 +0000
Delivery-date: Thu, 10 Nov 2005 19:20:31 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User Robb Romans <FMJ@xxxxxxxxxx>
# Node ID f1c07363956b06078b33b245dc51811c9a8c5b05
# Parent  79e8991af6b43a85547dccf976cdb5bb161fe005
Add "Securing Xen" adapted from Anthony Liguori's Wiki entry.

diff -r 79e8991af6b4 -r f1c07363956b docs/src/user.tex
--- a/docs/src/user.tex Thu Nov 10 16:42:58 2005
+++ b/docs/src/user.tex Thu Nov 10 16:43:24 2005
@@ -86,6 +86,9 @@
 %% Chapter Domain Configuration moved to domain_configuration.tex
+%% Chapter Securing Xen
 %% Chapter Build, Boot and Debug Options moved to build.tex
diff -r 79e8991af6b4 -r f1c07363956b docs/src/user/securing_xen.tex
--- /dev/null   Thu Nov 10 16:42:58 2005
+++ b/docs/src/user/securing_xen.tex    Thu Nov 10 16:43:24 2005
@@ -0,0 +1,85 @@
+\chapter{Securing Xen}
+This chapter describes how to secure a Xen system. It describes a number
+of scenarios and provides a corresponding set of best practices. It
+begins with a section devoted to understanding the security implications
+of a Xen system.
+\section{Xen Security Considerations}
+When deploying a Xen system, one must be sure to secure the management
+domain (Domain-0) as much as possible. If the management domain is
+compromised, all other domains are also vulnerable. The following are a
+set of best practices for Domain-0:
+\item \textbf{Run the smallest number of necessary services.} The less
+  things that are present in a management partition, the better.
+  Remember, a service running as root in the management domain has full
+  access to all other domains on the system.
+\item \textbf{Use a firewall to restrict the traffic to the management
+    domain.} A firewall with default-reject rules will help prevent
+  attacks on the management domain.
+\item \textbf{Do not allow users to access Domain-0.} The Linux kernel
+  has been known to have local-user root exploits. If you allow normal
+  users to access Domain-0 (even as unprivileged users) you run the risk
+  of a kernel exploit making all of your domains vulnerable.
+\section{Security Scenarios}
+\subsection{The Isolated Management Network}
+In this scenario, each node has two network cards in the cluster. One
+network card is connected to the outside world and one network card is a
+physically isolated management network specifically for Xen instances to
+As long as all of the management partitions are trusted equally, this is
+the most secure scenario. No additional configuration is needed other
+than forcing Xend to bind to the management interface for relocation.
+\textbf{FIXME:} What is the option to allow for this?
+\subsection{A Subnet Behind a Firewall}
+In this scenario, each node has only one network card but the entire
+cluster sits behind a firewall. This firewall should do at least the
+\item Prevent IP spoofing from outside of the subnet.
+\item Prevent access to the relocation port of any of the nodes in the
+  cluster except from within the cluster.
+The following iptables rules can be used on each node to prevent
+migrations to that node from outside the subnet assuming the main
+firewall does not do this for you:
+# this command disables all access to the Xen relocation
+# port:
+iptables -A INPUT -p tcp --destination-port 8002 -j REJECT
+# this command enables Xen relocations only from the specific
+# subnet:
+iptables -I INPUT -p tcp -{}-source \
+    --destination-port 8002 -j ACCEPT
+\subsection{Nodes on an Untrusted Subnet}
+Migration on an untrusted subnet is not safe in current versions of Xen.
+It may be possible to perform migrations through a secure tunnel via an
+VPN or SSH. The only safe option in the absence of a secure tunnel is to
+disable migration completely. The easiest way to do this is with
+# this command disables all access to the Xen relocation port
+iptables -A INPUT -p tcp -{}-destination-port 8002 -j REJECT

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] Add "Securing Xen" adapted from Anthony Liguori's Wiki entry., Xen patchbot -unstable <=