shorewall_code/docs/Xen.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
  <!--$Id$-->

  <articleinfo>
    <title>Xen and Shorewall</title>

    <authorgroup>
      <author>
        <firstname>Tom</firstname>

        <surname>Eastep</surname>
      </author>
    </authorgroup>

    <pubdate><?dbtimestamp format="Y/m/d"?></pubdate>

    <copyright>
      <year>2006</year>

      <year>2007</year>

      <holder>Thomas M. Eastep</holder>
    </copyright>

    <legalnotice>
      <para>Permission is granted to copy, distribute and/or modify this
      document under the terms of the GNU Free Documentation License, Version
      1.2 or any later version published by the Free Software Foundation; with
      no Invariant Sections, with no Front-Cover, and with no Back-Cover
      Texts. A copy of the license is included in the section entitled
      <quote><ulink url="GnuCopyright.htm">GNU Free Documentation
      License</ulink></quote>.</para>
    </legalnotice>
  </articleinfo>

  <caution>
    <para>This article applies to <emphasis role="bold">Shorewall
    3.0.6</emphasis> and later. If you are running a version of Shorewall
    earlier than Shorewall 3.0.6, you will need to upgrade to that
    version.</para>
  </caution>

  <caution>
    <para>The technique described in this article will not work if you are
    running kernel 2.6.20 or later.</para>
  </caution>

  <section id="Environment">
    <title>Xen Network Environment</title>

    <para><ulink
    url="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/">Xen</ulink> is a
    <firstterm>paravirtualization</firstterm> tool that allows you to run
    multiple virtual machines on one physical machine. It is available on a
    wide number of platforms and is included in recent
    <trademark>SUSE</trademark> distributions.</para>

    <para>Xen refers to the virtual machines as
    <firstterm>Domains</firstterm>. Domains are numbered with the first domain
    being domain 0, the second domain 1, and so on. Domain 0
    (<firstterm>Dom0</firstterm>) is special because that is the domain
    created when to machine is booted. Additional domains (called
    <firstterm>DomU</firstterm>'s) are created using the <command>xm
    create</command> command from within Domain 0. Additional domains can also
    be created automatically at boot time by using the
    <command>xendomains</command> service.</para>

    <para>Xen virtualizes a network interface named <filename
    class="devicefile">eth0</filename><footnote>
        <para>This assumes the default Xen configuration created by
        <command>xend </command>and assumes that the host system has a single
        ethernet interface named <filename
        class="devicefile">eth0</filename>.</para>
      </footnote>in each domain. In Dom0, Xen also creates a bridge (<filename
    class="devicefile">xenbr0</filename>) and a number of virtual interfaces
    as shown in the following diagram.</para>

    <graphic align="center" fileref="images/Xen1.png" />

    <para>I use the term <firstterm>Extended Dom0</firstterm> to distinguish
    the bridge and virtual interfaces from Dom0 itself. That distinction is
    important when we try to apply Shorewall in this environment.</para>

    <para>The bridge has a number of ports:</para>

    <itemizedlist>
      <listitem>
        <para>peth0 — This is the port that connects to the physical network
        interface in your system.</para>
      </listitem>

      <listitem>
        <para>vif0.0 — This is the bridge port that is used by traffic to/from
        Domain 0.</para>
      </listitem>

      <listitem>
        <para>vifX.0 — This is the bridge port that is used by traffic to/from
        Domain X.</para>
      </listitem>
    </itemizedlist>
  </section>

  <section id="Dom0">
    <title>Configuring Shorewall in Dom0</title>

    <para>As I state in the answer to <ulink url="FAQ.htm#faq2">Shorewall FAQ
    2</ulink>, I object to running servers in a local zone because if the
    server becomes compromised then there is no protection between that
    compromised server and the other local systems. Xen allows you to safely
    run Internet-accessible servers in your local zone by creating a firewall
    in (the Extended) Dom0 to isolate the server(s) from the other local
    systems (including Dom0).</para>

    <caution>
      <para>The Shorewall configuration shown in this article does not work
      with kernel 2.6.20 and later. For new Xen installations, I strongly
      recommend against a bridged Xen Domain 0 unless you <ulink
      url="XenMyWay.html">run Shorewall in a DomU</ulink>.</para>
    </caution>

    <caution>
      <para>I find a bridged Xen Domain 0 to be an arcane environment in which
      to try to use Netfilter (and hence Shorewall). As the number of
      interfaces and bridges increase, complexity increases geometrically. I
      recommend following this guide only if you really need to place a public
      server in your local network. Otherwise, <ulink
      url="XenMyWay.html">running Shorewall in a DomU</ulink> is much more
      straight-forward as is <ulink url="XenMyWay-Routed.html">running
      Shorewall in a routed Dom0</ulink>.</para>
    </caution>

    <warning>
      <para>I know of no case where a user has successfully used NAT
      (including Masquerade) in a bridged Xen Dom0. So if you want to create a
      masquerading firewall/gateway using Xen, you need to do so in a DomU
      (see <ulink url="XenMyWay.html">how I did it</ulink>) or you must
      configure <ulink url="XenMyWay-Routed.html">Xen to use routing</ulink>
      or NAT rather than the default bridging.</para>
    </warning>

    <para>Here is an example. In this example, we will assume that the system
    is behind a second firewall that restricts incoming traffic so that we
    only have to worry about protecting the local LAN from the systems running
    in the DomU's.</para>

    <section id="shorewall.conf">
      <title>/etc/shorewall/shorewall.conf</title>

      <para>Because Xen uses normal Linux bridging, you must enable bridge
      support in shorewall.conf</para>

      <blockquote>
        <programlisting>BRIDGING=Yes</programlisting>
      </blockquote>
    </section>

    <section id="zonesfile">
      <title>/etc/shorewall/zones</title>

      <para>One thing strange about configuring Shorewall in this environment
      is that Dom0 is defined as two different zones. It is defined as the
      firewall zone and it is also defined as "all systems connected to
      <filename class="devicefile">xenbr0:vif0.0</filename>. In this case, I
      call this second zone <emphasis role="bold">ursa</emphasis> (which was
      the name given to the virtual system running in Dom0 when I ran this
      configuration); that zone corresponds to Dom0 as seen from the outside
      in the diagram above (see more <link
      linkend="zones">below</link>).</para>

      <blockquote>
        <programlisting>#                                       OPTIONS                 OPTIONS
fw      firewall                        #Domain 0
ursa    ipv4                            #Domain 0 on the bridge
dmz     ipv4                            #Server(s) running in Domains other than 0
net     ipv4                            #The local LAN and beyond
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
      </blockquote>
    </section>

    <section id="interfaces">
      <title>/etc/shorewall/interfaces</title>

      <para>We must deal with two network interfaces. We must deal with the
      (virtualized) eth0 and we must also deal with the bridge (xenbr0)
      created by Xen.</para>

      <blockquote>
        <programlisting>#ZONE   INTERFACE       BROADCAST       OPTIONS
-       xenbr0          -               dhcp
net     eth0            detect          dhcp
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
      </blockquote>
    </section>

    <section id="hosts">
      <title>/etc/shorewall/hosts</title>

      <para>Here we define the zones <emphasis role="bold">ursa</emphasis> and
      <emphasis role="bold">dmz</emphasis> and we extend the definition of the
      zone <emphasis role="bold">net</emphasis>.<blockquote>
          <programlisting>#ZONE   HOST(S)                                 OPTIONS
ursa    xenbr0:vif0.0
dmz     xenbr0:vif+                             routeback
net     xenbr0:peth0
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE</programlisting>
        </blockquote></para>

      <para>Note that the <emphasis role="bold">net</emphasis> zone has two
      different interfaces. From the point of view of Dom0 (which is where
      Shorewall runs), the <emphasis role="bold">net</emphasis> zone comprises
      everything except Dom0. From the point of view of the Extended Domain 0,
      the <emphasis role="bold">net</emphasis> zone is everything connected
      (directly or indirectly) to the <filename
      class="devicefile">peth0</filename> port on the bridge.</para>
    </section>

    <section id="policy">
      <title>/etc/shorewall/policy</title>

      <para>The policies shown here effectively isolate Domains 1...N.</para>

      <blockquote>
        <programlisting>#SOURCE         DEST            POLICY          LOG             LIMIT:BURST
#                                               LEVEL
all             fw              ACCEPT
fw              all             ACCEPT
ursa            all             ACCEPT
net             ursa            ACCEPT
net             net             NONE
all             all             REJECT          info
#LAST LINE -- DO NOT REMOVE
</programlisting>
      </blockquote>
    </section>

    <section id="rules">
      <title>/etc/shorewall/rules</title>

      <para>These rules determine the traffic allowed into and out of the
      <emphasis role="bold">dmz</emphasis> zone.</para>

      <blockquote>
        <programlisting>#
# "Net' to DMZ
#
ACCEPT          net                dmz                     udp     domain
ACCEPT          net                dmz                     tcp     www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128
Trcrt/ACCEPT    net                dmz
#
# DMZ to 'Net'
#
ACCEPT          dmz                net:!192.168.0.0/22     udp     domain,ntp
ACCEPT          dmz                net:!192.168.0.0/22     tcp     echo,ftp,ssh,smtp,whois,domain,www,81,https,rsync,cvspserver,2702,2703,8080
ACCEPT          dmz                net:$POPSERVERS         tcp     pop3
Ping/ACCEPT     dmz                net

Ping/ACCEPT     dmz                ursa</programlisting>
      </blockquote>

      <para>Here, 192.168.0.0/22 comprises the local network.</para>

      <para id="zones">From the point of view of Shorewall, the zone diagram
      is as shown in the following diagram.</para>

      <graphic align="center" fileref="images/Xen2.png" />

      <para>Note that the <emphasis role="bold">ursa</emphasis> zone subsumes
      the <emphasis role="bold">fw</emphasis> zone because the <emphasis
      role="bold">ursa</emphasis> zone is defined to be all systems that
      interface to xenbr0's vif0.0 port — it is the rules governing traffic
      to/from the <emphasis role="bold">ursa</emphasis> zone that protect the
      firewall in this configuration.</para>

      <para>More elaborate configurations are possible as described in my
      <ulink url="XenMyWay.html">Xen and the Art of Consolidation</ulink>
      article.</para>
    </section>
  </section>
</article>