mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-23 16:13:18 +01:00
4033e6051b
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3521 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
243 lines
9.7 KiB
XML
243 lines
9.7 KiB
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>2006-02-02</pubdate>
|
|
|
|
<copyright>
|
|
<year>2006</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>
|
|
|
|
<section>
|
|
<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>
|
|
<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 me to safely
|
|
run Internet-accessible servers in my local zone by creating a firewall in
|
|
(the Extended) Dom0 to isolate the server(s) from the other local systems
|
|
(including Dom0).</para>
|
|
|
|
<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>
|
|
<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>
|
|
<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 is
|
|
the name given to the virtual system running in Dom0); 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>
|
|
<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>
|
|
<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+<footnote>
|
|
<para>There is a bug in Shorewall versions prior to 3.0.4 that treats all bridge ports as if they had routeback specified. I recommend that you run a Shorewall verison > 3.0.3 if you run Xen.</para>
|
|
</footnote>
|
|
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>
|
|
<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>
|
|
<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 my 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> |