extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-25 15:48:56 +01:00
Code Issues Packages Projects Releases Wiki Activity

Remove bridged Dom0 article

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6848 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2007-07-11 19:33:45 +00:00
parent 4f71b5a648
commit 7d0f2b7ed0
4 changed files with 76 additions and 312 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/Documentation_Index.xml
View File

@ -238,8 +238,8 @@
<entry><ulink url="PortKnocking.html">Port Knocking and Other Uses
of the 'Recent Match'</ulink></entry>
<entry><ulink url="Xen.html">Xen - Shorewall in Bridged Xen
Dom0</ulink></entry>
<entry><ulink url="XenMyWay-Routed.html">Xen - Shorewall in Routed
Xen Dom0</ulink></entry>
</row>
<row>
@ -247,8 +247,7 @@
<entry><ulink url="PPTP.htm">PPTP</ulink></entry>
<entry><ulink url="XenMyWay-Routed.html">Xen - Shorewall in Routed
Xen Dom0</ulink></entry>
<entry></entry>
</row>
<row>

283
docs/Xen.xml
View File

@ -1,283 +0,0 @@
<?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>

22
docs/XenMyWay-Routed.xml
View File

@ -43,9 +43,8 @@
<section id="Before">
<title>Before Xen</title>
<para>Prior to adopting <ulink url="Xen.html">Xen</ulink>, I had a home
office crowded with 5 systems, three monitors a scanner and a printer. The
systems were:</para>
<para>Prior to adopting Xen, I had a home office crowded with 5 systems,
three monitors a scanner and a printer. The systems were:</para>
<orderedlist>
<listitem>
@ -161,15 +160,14 @@
<para>As the developer of Shorewall, I have enough experience to be very
comfortable with Linux networking and Shorewall/iptables. I arrived at
this configuration after a fair amount of trial and error
experimentation (see <ulink url="Xen.html">Xen and Shorewall</ulink> and
<ulink url="XenMyWay.html">Xen and the art of Consolidation</ulink>). If
you are a Linux networking novice, I recommend that you do not attempt a
configuration like this one for your first Shorewall installation. You
are very likely to frustrate both yourself and the Shorewall support
team. Rather I suggest that you start with something simple like a
<ulink url="standalone.htm">standalone installation</ulink> in a DomU;
once you are comfortable with that then you will be ready to try
something more substantial.</para>
experimentation (see <ulink url="XenMyWay.html">Xen and the art of
Consolidation</ulink>). If you are a Linux networking novice, I
recommend that you do not attempt a configuration like this one for your
first Shorewall installation. You are very likely to frustrate both
yourself and the Shorewall support team. Rather I suggest that you start
with something simple like a <ulink url="standalone.htm">standalone
installation</ulink> in a DomU; once you are comfortable with that then
you will be ready to try something more substantial.</para>
<para>As Paul Gear says: <emphasis>Shorewall might make iptables easy,
but it doesn't make understanding fundamental networking principles,

76
docs/XenMyWay.xml
View File

@ -47,12 +47,67 @@
running kernel 2.6.20 or later.</para>
</caution>
<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 id="Before">
<title>Before Xen</title>
<para>Prior to adopting <ulink url="Xen.html">Xen</ulink>, I had a home
office crowded with 5 systems, three monitors a scanner and a printer. The
systems were:</para>
<para>Prior to adopting Xen, I had a home office crowded with 5 systems,
three monitors a scanner and a printer. The systems were:</para>
<orderedlist>
<listitem>
@ -110,10 +165,6 @@
personal Linux desktop system and our Linux Laptop run
<trademark>Ubuntu</trademark> "Dapper Drake".</para>
<para>If you are unfamiliar with Xen networking, I recommend that you read
the first section of the companion <ulink url="Xen.html">Xen and
Shorewall</ulink> article.</para>
<para><emphasis role="bold">The configuration described below uses a
bridged Xen Networking configuration; if you want to see how to accomplish
a similar configuration using a Routed Xen configuration then please see
@ -176,12 +227,11 @@
<para>As the developer of Shorewall, I have enough experience to be very
comfortable with Linux networking and Shorewall/iptables. I arrived at
this configuration after a fair amount of trial and error
experimentation (see <ulink url="Xen.html">Xen and Shorewall</ulink>).
If you are a Linux networking novice, I recommend that you do not
attempt a configuration like this one for your first Shorewall
installation. You are very likely to frustrate both yourself and the
Shorewall support team. Rather I suggest that you start with something
simple like a <ulink url="standalone.htm">standalone
experimentation. If you are a Linux networking novice, I recommend that
you do not attempt a configuration like this one for your first
Shorewall installation. You are very likely to frustrate both yourself
and the Shorewall support team. Rather I suggest that you start with
something simple like a <ulink url="standalone.htm">standalone
installation</ulink> in a domU; once you are comfortable with that then
you will be ready to try something more substantial.</para>