forked from extern/shorewall_code
9fd5780f36
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1439 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
783 lines
46 KiB
XML
783 lines
46 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">
|
|
<!-- $Id$ -->
|
|
<article id="two-interface">
|
|
<articleinfo>
|
|
<title>Basic Two-Interface Firewall</title>
|
|
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
|
|
<pubdate>2003-06-11</pubdate>
|
|
|
|
<copyright>
|
|
<year>2002</year>
|
|
|
|
<year>2003</year>
|
|
|
|
<year>2004</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>Introduction</title>
|
|
|
|
<para>Setting up a Linux system as a firewall for a small network is a
|
|
fairly straight-forward task if you understand the basics and follow the
|
|
documentation.</para>
|
|
|
|
<para>This guide doesn't attempt to acquaint you with all of the
|
|
features of Shorewall. It rather focuses on what is required to configure
|
|
Shorewall in its most common configuration:</para>
|
|
|
|
<itemizedlist mark="bullet" spacing="compact">
|
|
<listitem>
|
|
<para>Linux system used as a firewall/router for a small local
|
|
network.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Single public IP address.</emphasis> If
|
|
you have more than one public IP address, this is not the guide you
|
|
want -- see the <ulink url="shorewall_setup_guide.htm">Shorewall Setup
|
|
Guide</ulink> instead.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Internet connection through cable modem, DSL, ISDN, Frame Relay,
|
|
dial-up ...</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Here is a schematic of a typical installation: <figure label="1"><title>Common
|
|
two interface firewall configuration</title><mediaobject><imageobject><imagedata
|
|
fileref="images/basics.png" format="PNG" /></imageobject></mediaobject></figure>
|
|
<tip><title>Shorewall and <trademark>Mandrake</trademark> 9.0+</title><para>If
|
|
you are running Shorewall under <trademark>Mandrake</trademark> 9.0 or
|
|
later, you can easily configure the above setup using the
|
|
<trademark>Mandrake</trademark> <quote>Internet Connection Sharing</quote>
|
|
applet. From the <emphasis><interface>Mandrake Control Center</interface></emphasis>,
|
|
select <quote><guimenuitem>Network</guimenuitem> &
|
|
<guisubmenu>Internet</guisubmenu></quote> then <quote><interface>Connection
|
|
Sharing</interface></quote>.</para><para>Note however, that the Shorewall
|
|
configuration produced by <emphasis>Mandrake Internet Connection Sharing</emphasis>
|
|
is strange and is apt to confuse you if you use the rest of this
|
|
documentation (it has two local zones; <varname>loc</varname> and
|
|
<varname>masq</varname> where <varname>loc</varname> is empty; this
|
|
conflicts with this documentation which assumes a single local zone
|
|
<varname>loc</varname>). We therefore recommend that once you have set up
|
|
this sharing that you uninstall the <trademark>Mandrake</trademark>
|
|
Shorewall RPM and install the one from the <ulink url="download.htm">download</ulink>
|
|
page then follow the instructions in this Guide.</para></tip><note><para><emphasis
|
|
role="bold">The above Shorewall Issue is corrected in Mandrake 10.0 and
|
|
later.</emphasis></para></note> <caution><para>If you edit your
|
|
configuration files on a <trademark>Windows</trademark> system, you must
|
|
save them as <trademark>Unix</trademark> files if your editor supports
|
|
that option or you must run them through <command>dos2unix</command>
|
|
before trying to use them. Similarly, if you copy a configuration file
|
|
from your <trademark>Windows</trademark> hard drive to a floppy disk, you
|
|
must run <command>dos2unix</command> against the copy before using it with
|
|
Shorewall. <itemizedlist><listitem><para><ulink
|
|
url="http://www.simtel.net/pub/pd/51438.html"><trademark>Windows</trademark>
|
|
Version of <command>dos2unix</command></ulink></para></listitem><listitem><para><ulink
|
|
url="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version of
|
|
<command>dos2unix</command></ulink></para></listitem></itemizedlist></para></caution></para>
|
|
|
|
<section>
|
|
<title>System Requirements</title>
|
|
|
|
<para>Shorewall requires that you have the <command>iproute</command>/<command>iproute2</command>
|
|
package installed (on <trademark>RedHat</trademark>, the package is
|
|
called <command>iproute</command>). You can tell if this package is
|
|
installed by the presence of an <command>ip</command> program on your
|
|
firewall system. As <systemitem class="username">root</systemitem>, you
|
|
can use the <command>which</command> command to check for this program:
|
|
<programlisting>[root@gateway root]# <command>which ip</command>
|
|
/sbin/ip
|
|
[root@gateway root]#</programlisting> I recommend that you first read through
|
|
the guide to familiarize yourself with what's involved then go back
|
|
through it again making your configuration changes.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Conventions</title>
|
|
|
|
<para>Points at which configuration changes are recommended are flagged
|
|
with <inlinegraphic fileref="images/BD21298_.gif" format="GIF" />.</para>
|
|
|
|
<para>Configuration notes that are unique to LEAF/Bering are marked with
|
|
<inlinegraphic fileref="images/leaflogo.gif" format="GIF" />.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section>
|
|
<title>PPTP/ADSL</title>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>If you have an <acronym>ADSL</acronym> Modem and you use
|
|
<acronym>PPTP</acronym> to communicate with a server in that modem, you
|
|
must make the changes recommended <ulink url="PPTP.htm#PPTP_ADSL">here</ulink>
|
|
in addition to those detailed below. <acronym>ADSL</acronym> with
|
|
<acronym>PPTP</acronym> is most commonly found in Europe, notably in
|
|
Austria.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Shorewall Concepts</title>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>The configuration files for Shorewall are contained in the directory
|
|
<filename class="directory">/etc/shorewall</filename> -- for simple
|
|
setups, you will only need to deal with a few of these as described in
|
|
this guide.<warning><para><emphasis role="bold">Note to Debian Users</emphasis></para><para>If
|
|
you install using the .deb, you will find that your <filename
|
|
class="directory">/etc/shorewall</filename> directory is empty. This is
|
|
intentional. The released configuration file skeletons may be found on
|
|
your system in the directory <filename class="directory">/usr/share/doc/shorewall/default-config</filename>.
|
|
Simply copy the files you need from that directory to <filename
|
|
class="directory">/etc/shorewall</filename> and modify the copies.</para><para>Note
|
|
that you must copy <filename class="directory">/usr/share/doc/shorewall/default-config/shorewall.conf</filename>
|
|
and /usr/share/doc/shorewall/default-config/modules to <filename
|
|
class="directory">/etc/shorewall</filename> even if you do not modify
|
|
those files.</para></warning></para>
|
|
|
|
<para><tip><para>After you have <ulink url="Install.htm">installed
|
|
Shorewall</ulink>, download the <ulink
|
|
url="http://www1.shorewall.net/pub/shorewall/Samples/">two-interface
|
|
sample</ulink>, un-tar it (<command>tar <option>-zxvf</option>
|
|
<filename>two-interfaces.tgz</filename></command>) and and copy the files
|
|
to <filename class="directory">/etc/shorewall</filename> <emphasis
|
|
role="bold">(these files will replace files with the same name)</emphasis>.</para></tip>
|
|
As each file is introduced, I suggest that you look through the actual
|
|
file on your system -- each file contains detailed configuration
|
|
instructions and default entries.</para>
|
|
|
|
<para>Shorewall views the network where it is running as being composed of
|
|
a set of zones. In the two-interface sample configuration, the following
|
|
zone names are used: <informaltable frame="all" pgwide="0"><tgroup
|
|
align="left" cols="2"><thead valign="middle"><row valign="middle"><entry
|
|
align="left">Name</entry><entry align="left">Description</entry></row></thead><tbody
|
|
valign="middle"><row valign="middle"><entry align="left"><varname>net</varname></entry><entry
|
|
align="left">The Internet</entry></row><row valign="middle"><entry
|
|
align="left"><varname>loc</varname></entry><entry align="left">Your Local
|
|
Network</entry></row></tbody></tgroup></informaltable> Zones are defined
|
|
in the <ulink url="Documentation.htm#Zones"><filename class="directory">/etc/shorewall/</filename><filename>zones</filename></ulink>
|
|
file.</para>
|
|
|
|
<para>Shorewall also recognizes the firewall system as its own zone - by
|
|
default, the firewall itself is known as <emphasis role="bold"><varname>fw</varname></emphasis>.</para>
|
|
|
|
<para>Rules about what traffic to allow and what traffic to deny are
|
|
expressed in terms of zones. <itemizedlist spacing="compact"><listitem><para>You
|
|
express your default policy for connections from one zone to another zone
|
|
in the <ulink url="Documentation.htm#Policy"><filename class="directory">/etc/shorewall/</filename><filename>policy</filename></ulink>
|
|
file.</para></listitem><listitem><para>You define exceptions to those
|
|
default policies in the <ulink url="Documentation.htm#Rules"><filename
|
|
class="directory">/etc/shorewall/</filename><filename>rules</filename></ulink>
|
|
file.</para></listitem></itemizedlist> For each connection request
|
|
entering the firewall, the request is first checked against the <filename
|
|
class="directory">/etc/shorewall/</filename><filename>rules</filename>
|
|
file. If no rule in that file matches the connection request then the
|
|
first policy in <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
|
that matches the request is applied. If there is a <ulink
|
|
url="shorewall_extension_scripts.htm">comon action</ulink> defined for the
|
|
policy in <filename>/etc/shorewall/actions</filename> or
|
|
<filename>/usr/share/shorewall/actions.std</filename> then that action is
|
|
peformed before the action is applied.</para>
|
|
|
|
<para>The <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
|
file included with the two-interface sample has the following policies:
|
|
<programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
|
loc net ACCEPT
|
|
net all DROP info
|
|
all all REJECT info</programlisting> In the two-interface
|
|
sample, the line below is included but commented out. If you want your
|
|
firewall system to have full access to servers on the internet, uncomment
|
|
that line. <programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
|
fw net ACCEPT</programlisting> The above policy will:
|
|
<itemizedlist><listitem><para>Allow all connection requests from your
|
|
local network to the internet</para></listitem><listitem><para>Drop
|
|
(ignore) all connection requests from the internet to your firewall or
|
|
local network</para></listitem><listitem><para>Optionally accept all
|
|
connection requests from the firewall to the internet (if you uncomment
|
|
the additional policy)</para></listitem><listitem><para>reject all other
|
|
connection requests.</para></listitem></itemizedlist> <inlinegraphic
|
|
fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>At this point, edit your <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
|
and make any changes that you wish.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Network Interfaces</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/basics.png" format="PNG" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
|
|
<para>The firewall has two network interfaces. Where Internet connectivity
|
|
is through a cable or <acronym>DSL</acronym> <quote>Modem</quote>, the
|
|
<emphasis>External Interface</emphasis> will be the ethernet adapter that
|
|
is connected to that <quote>Modem</quote> (e.g., <filename
|
|
class="devicefile">eth0</filename>) unless you connect via
|
|
<emphasis>Point-to-Point Protocol</emphasis> over Ethernet (<acronym>PPPoE</acronym>)
|
|
or <emphasis>Point-to-Point Tunneling Protocol</emphasis> (<acronym>PPTP</acronym>)
|
|
in which case the External Interface will be a <literal>ppp</literal>
|
|
interface (e.g., <filename class="devicefile">ppp0</filename>). If you
|
|
connect via a regular modem, your External Interface will also be
|
|
<filename class="devicefile">ppp0</filename>. If you connect via
|
|
<acronym>ISDN</acronym>, your external interface will be <filename
|
|
class="devicefile">ippp0</filename>.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>If your external interface is <filename class="devicefile">ppp0</filename>
|
|
or <filename class="devicefile">ippp0</filename> then you will want to set
|
|
<varname>CLAMPMSS=yes</varname> in <filename class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>.</para>
|
|
|
|
<para>Your <emphasis>Internal Interface</emphasis> will be an ethernet
|
|
adapter (<filename class="devicefile">eth1</filename> or <filename
|
|
class="devicefile">eth0</filename>) and will be connected to a hub or
|
|
switch. Your other computers will be connected to the same hub/switch
|
|
(note: If you have only a single internal system, you can connect the
|
|
firewall directly to the computer using a cross-over cable).
|
|
<warning><para>Do not connect the internal and external interface to the
|
|
same hub or switch except for testing AND you are running Shorewall
|
|
version 1.4.7 or later. When using these recent versions, you can test
|
|
using this kind of configuration if you specify the arp_filter option in
|
|
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
|
for all interfaces connected to the common hub/switch. Using such a setup
|
|
with a production firewall is strongly recommended against.</para></warning>
|
|
<inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>The Shorewall two-interface sample configuration assumes that the
|
|
external interface is <filename class="devicefile">eth0</filename> and the
|
|
internal interface is <filename class="devicefile">eth1</filename>. If
|
|
your configuration is different, you will have to modify the sample
|
|
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
|
file accordingly. While you are there, you may wish to review the list of
|
|
options that are specified for the interfaces. Some hints: <tip><para>If
|
|
your external interface is <filename class="devicefile">ppp0</filename> or
|
|
<filename class="devicefile">ippp0</filename>, you can replace the
|
|
<varname>detect</varname> in the second column with a <quote>-</quote>
|
|
(minus the quotes).</para></tip><tip><para>If your external interface is
|
|
<filename class="devicefile">ppp0</filename> or <filename
|
|
class="devicefile">ippp0</filename> or if you have a static
|
|
<acronym>IP</acronym> address, you can remove <varname>dhcp</varname> from
|
|
the option list.</para></tip><tip><para>If your internal interface is a
|
|
bridge create using the <command>brctl</command> utility then you must add
|
|
the <varname>routeback</varname> option to the option list.</para></tip><tip><para>If
|
|
you specify <emphasis>norfc1918</emphasis> for your external interface,
|
|
you will want to check the <ulink url="errata.htm">Shorewall Errata</ulink>
|
|
periodically for updates to the <filename>/usr/share/shorewall/rfc1918
|
|
file</filename>. Alternatively, you can copy <filename>/usr/share/shorewall/rfc1918</filename>
|
|
to <filename>/etc/shorewall/rfc1918</filename> then <ulink
|
|
url="myfiles.htm#RFC1918">strip down your <filename>/etc/shorewall/rfc1918</filename>
|
|
file as I do</ulink>.</para></tip></para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>IP Addresses</title>
|
|
|
|
<para>Before going further, we should say a few words about Internet
|
|
Protocol (<acronym>IP</acronym>) addresses. Normally, your
|
|
<acronym>ISP</acronym> will assign you a single Public IP address. This
|
|
address may be assigned via the Dynamic Host Configuration Protocol (<acronym>DHCP</acronym>)
|
|
or as part of establishing your connection when you dial in (standard
|
|
modem) or establish your <acronym>PPP</acronym> connection. In rare cases,
|
|
your <acronym>ISP</acronym> may assign you a static <acronym>IP</acronym>
|
|
address; that means that you configure your firewall's external
|
|
interface to use that address permanently. However your external address
|
|
is assigned, it will be shared by all of your systems when you access the
|
|
Internet. You will have to assign your own addresses in your internal
|
|
network (the Internal Interface on your firewall plus your other
|
|
computers). <emphasis role="bold">RFC 1918</emphasis> reserves several
|
|
<emphasis>Private</emphasis> <acronym>IP</acronym> address ranges for this
|
|
purpose: <programlisting>10.0.0.0 - 10.255.255.255
|
|
172.16.0.0 - 172.31.255.255
|
|
192.168.0.0 - 192.168.255.255</programlisting> <inlinegraphic
|
|
fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>Before starting Shorewall, you should look at the IP address of your
|
|
external interface and if it is one of the above ranges, you should remove
|
|
the 'norfc1918' option from the external interface's entry in
|
|
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>.</para>
|
|
|
|
<para>You will want to assign your addresses from the same sub-network
|
|
(subnet). For our purposes, we can consider a subnet to consists of a
|
|
range of addresses <varname>x.y.z.0 - x.y.z.255</varname>. Such a subnet
|
|
will have a Subnet Mask of <systemitem class="netmask">255.255.255.0</systemitem>.
|
|
The address <varname>x.y.z.0</varname> is reserved as the
|
|
<emphasis>Subnet Address</emphasis> and <varname>x.y.z.255</varname> is
|
|
reserved as the <emphasis>Subnet Broadcast Address</emphasis>. In
|
|
Shorewall, a subnet is described using <ulink
|
|
url="shorewall_setup_guide.htm#Subnets">Classless InterDomain Routing
|
|
(CIDR) notation</ulink> with consists of the subnet address followed by
|
|
<varname>/24</varname>. The <quote>24</quote> refers to the number of
|
|
consecutive leading <quote>1</quote> bits from the left of the subnet
|
|
mask. <informaltable frame="all" label="Example sub-network" pgwide="0"><!--
|
|
Orientation types for tables are not supported by fop yet so we'll fake it by using boldface on left side entries.
|
|
--><tgroup align="left" cols="2"><tbody valign="middle"><row
|
|
valign="middle"><entry align="left"><emphasis role="bold">Range:</emphasis></entry><entry><systemitem
|
|
class="ipaddress">10.10.10.0</systemitem> - <systemitem class="ipaddress">10.10.10.255</systemitem></entry></row><row><entry
|
|
align="left"><emphasis role="bold">Subnet Address:</emphasis></entry><entry
|
|
align="left"><systemitem class="netmask">10.10.10.0</systemitem></entry></row><row><entry
|
|
align="left"><emphasis role="bold">Broadcast Address:</emphasis></entry><entry
|
|
align="left"><systemitem class="ipaddress">10.10.10.255</systemitem></entry></row><row><entry
|
|
align="left"><emphasis role="bold">CIDR Notation:</emphasis></entry><entry
|
|
align="left"><systemitem class="ipaddress">10.10.10.0/24</systemitem></entry></row></tbody></tgroup></informaltable>
|
|
It is conventional to assign the internal interface either the first
|
|
usable address in the subnet (<systemitem class="ipaddress">10.10.10.1</systemitem>
|
|
in the above example) or the last usable address (<systemitem
|
|
class="ipaddress">10.10.10.254</systemitem>).</para>
|
|
|
|
<para>One of the purposes of subnetting is to allow all computers in the
|
|
subnet to understand which other computers can be communicated with
|
|
directly. To communicate with systems outside of the subnetwork, systems
|
|
send packets through a gateway (router).</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>Your local computers (computer 1 and computer 2 in the above
|
|
diagram) should be configured with their default gateway to be the
|
|
<acronym>IP</acronym> address of the firewall's internal interface.</para>
|
|
|
|
<para>The foregoing short discussion barely scratches the surface
|
|
regarding subnetting and routing. If you are interested in learning more
|
|
about <acronym>IP</acronym> addressing and routing, I highly recommend
|
|
<quote>IP Fundamentals: What Everyone Needs to Know about Addressing &
|
|
Routing</quote>, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0
|
|
(<ulink
|
|
url="http://www.phptr.com/browse/product.asp?product_id={58D4F6D4-54C5-48BA-8EDD-86EBD7A42AF6}">link</ulink>).</para>
|
|
|
|
<para>The remainder of this quide will assume that you have configured
|
|
your network as shown here: <mediaobject><imageobject><imagedata
|
|
fileref="images/basics1.png" format="PNG" /></imageobject></mediaobject>
|
|
The default gateway for computer's 1 & 2 would be <systemitem
|
|
class="ipaddress">10.10.10.254</systemitem>. <warning><para>Your
|
|
<acronym>ISP</acronym> might assign your external interface an <emphasis
|
|
role="bold">RFC 1918</emphasis> address. If that address is in the
|
|
<systemitem class="ipaddress">10.10.10.0/24</systemitem> subnet then you
|
|
will need to select a DIFFERENT RFC 1918 subnet for your local network.</para></warning></para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>IP Masquerading (SNAT)</title>
|
|
|
|
<para>The addresses reserved by RFC 1918 are sometimes referred to as
|
|
non-routable because the Internet backbone routers don't forward
|
|
packets which have an RFC-1918 destination address. When one of your local
|
|
systems (let's assume computer 1) sends a connection request to an
|
|
internet host, the firewall must perform <emphasis>Network Address
|
|
Translation</emphasis> (<acronym>NAT</acronym>). The firewall rewrites the
|
|
source address in the packet to be the address of the firewall's
|
|
external interface; in other words, the firewall makes it look as if the
|
|
firewall itself is initiating the connection. This is necessary so that
|
|
the destination host will be able to route return packets back to the
|
|
firewall (remember that packets whose destination address is reserved by
|
|
RFC 1918 can't be routed across the internet so the remote host
|
|
can't address its response to computer 1). When the firewall receives
|
|
a return packet, it rewrites the destination address back to <systemitem
|
|
class="ipaddress">10.10.10.1</systemitem> and forwards the packet on to
|
|
computer 1.</para>
|
|
|
|
<para>On Linux systems, the above process is often referred to as
|
|
<emphasis>IP Masquerading</emphasis> but you will also see the term
|
|
<emphasis>Source Network Address Translation</emphasis> (<acronym>SNAT</acronym>)
|
|
used. Shorewall follows the convention used with Netfilter:
|
|
<itemizedlist><listitem><para><emphasis>Masquerade</emphasis> describes
|
|
the case where you let your firewall system automatically detect the
|
|
external interface address.</para></listitem><listitem><para><emphasis><acronym>SNAT</acronym></emphasis>
|
|
refers to the case when you explicitly specify the source address that you
|
|
want outbound packets from your local network to use.</para></listitem></itemizedlist>
|
|
In Shorewall, both <emphasis>Masquerading</emphasis> and
|
|
<emphasis><acronym>SNAT</acronym></emphasis> are configured with entries
|
|
in the <filename class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
|
file. You will normally use Masquerading if your external
|
|
<acronym>IP</acronym> is dynamic and <acronym>SNAT</acronym> if the
|
|
<acronym>IP</acronym> is static.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>If your external firewall interface is <filename class="devicefile">eth0</filename>,
|
|
you do not need to modify the file provided with the sample. Otherwise,
|
|
edit <filename class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
|
and change the first column to the name of your external interface and the
|
|
second column to the name of your internal interface.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>If your external <acronym>IP</acronym> is static, you can enter it
|
|
in the third column in the <filename class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
|
entry if you like although your firewall will work fine if you leave that
|
|
column empty. Entering your static <acronym>IP</acronym> in column 3 makes
|
|
processing outgoing packets a little more efficient.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>If you are using the Debian package, please check your
|
|
<filename>shorewall.conf</filename> file to ensure that the following are
|
|
set correctly; if they are not, change them appropriately: <itemizedlist
|
|
spacing="compact"><listitem><para><varname>NAT_ENABLED=Yes</varname>
|
|
(Shorewall versions earlier than 1.4.6)</para></listitem><listitem><para><varname>IP_FORWARDING=On</varname></para></listitem></itemizedlist></para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Port Forwarding (DNAT)</title>
|
|
|
|
<para>One of your goals may be to run one or more servers on your local
|
|
computers. Because these computers have RFC-1918 addresses, it is not
|
|
possible for clients on the internet to connect directly to them. It is
|
|
rather necessary for those clients to address their connection requests to
|
|
the firewall who rewrites the destination address to the address of your
|
|
server and forwards the packet to that server. When your server responds,
|
|
the firewall automatically performs <acronym>SNAT</acronym> to rewrite the
|
|
source address in the response.</para>
|
|
|
|
<para>The above process is called <emphasis>Port Forwarding</emphasis> or
|
|
<emphasis>Destination Network Address Translation</emphasis> (<acronym>DNAT</acronym>).
|
|
You configure port forwarding using <acronym>DNAT</acronym> rules in the
|
|
<filename class="directory">/etc/shorewall/</filename><filename>rules</filename>
|
|
file.</para>
|
|
|
|
<para>The general form of a simple port forwarding rule in <filename
|
|
class="directory">/etc/shorewall/</filename><filename>rules</filename> is:
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
DNAT net loc:<emphasis><server local ip address></emphasis>[:<emphasis><server port></emphasis>] <emphasis><protocol></emphasis> <emphasis><port></emphasis></programlisting>
|
|
<example label="1"><title>Web Server</title><para>You run a Web Server on
|
|
computer 2 and you want to forward incoming <acronym>TCP</acronym> port 80
|
|
to that system: <programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
DNAT net loc:10.10.10.2 tcp 80</programlisting></para></example>
|
|
<example label="2"><title>FTP Server</title><para>You run an
|
|
<acronym>FTP</acronym> Server on computer 1 so you want to forward
|
|
incoming <acronym>TCP</acronym> port 21 to that system:
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
DNAT net loc:10.10.10.1 tcp 21</programlisting> For
|
|
<acronym>FTP</acronym>, you will also need to have <acronym>FTP</acronym>
|
|
connection tracking and <acronym>NAT</acronym> support in your kernel. For
|
|
vendor-supplied kernels, this means that the <filename class="libraryfile">ip_conntrack_ftp</filename>
|
|
and <filename class="libraryfile">ip_nat_ftp</filename> modules must be
|
|
loaded. Shorewall will automatically load these modules if they are
|
|
available and located in the standard place under <filename
|
|
class="directory">/lib/modules/<kernel
|
|
version>/kernel/net/ipv4/netfilter</filename>.</para></example> A
|
|
couple of important points to keep in mind: <itemizedlist><listitem><para>You
|
|
must test the above rule from a client outside of your local network
|
|
(i.e., don't test from a browser running on computers 1 or 2 or on the
|
|
firewall). If you want to be able to access your web server and/or
|
|
<acronym>FTP</acronym> server from inside your firewall using the
|
|
<acronym>IP</acronym> address of your external interface, see <ulink
|
|
url="FAQ.htm#faq2">Shorewall FAQ #2</ulink>.</para></listitem><listitem><para>Many
|
|
<acronym>ISP</acronym>s block incoming connection requests to port 80. If
|
|
you have problems connecting to your web server, try the following rule
|
|
and try connecting to port 5000.</para><programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
DNAT net loc:10.10.10.2:80 tcp 5000</programlisting></listitem></itemizedlist>
|
|
<inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>At this point, modify <filename class="directory">/etc/shorewall/</filename><filename>rules</filename>
|
|
to add any <acronym>DNAT</acronym> rules that you require.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Domain Name Server (DNS)</title>
|
|
|
|
<para>Normally, when you connect to your ISP, as part of getting an IP
|
|
address your firewall's <emphasis>Domain Name Service</emphasis> (<acronym>DNS</acronym>)
|
|
resolver will be automatically configured (e.g., the <filename
|
|
class="directory">/etc/</filename><filename>resolv.conf</filename> file
|
|
will be written). Alternatively, your ISP may have given you the
|
|
<acronym>IP</acronym> address of a pair of <acronym>DNS</acronym> name
|
|
servers for you to manually configure as your primary and secondary name
|
|
servers. Regardless of how <acronym>DNS</acronym> gets configured on your
|
|
firewall, it is your responsibility to configure the resolver in your
|
|
internal systems. You can take one of two approaches: <itemizedlist
|
|
spacing="compact"><listitem><para>You can configure your internal systems
|
|
to use your ISP's name servers. If your ISP gave you the addresses of
|
|
their servers or if those addresses are available on their web site, you
|
|
can configure your internal systems to use those addresses. If that
|
|
information isn't available, look in /etc/resolv.conf on your firewall
|
|
system -- the name servers are given in "nameserver" records in
|
|
that file.</para></listitem><listitem><para><anchor id="cachingdns" /> You
|
|
can configure a <emphasis>Caching Name Server</emphasis> on your firewall.
|
|
<trademark>Red Hat</trademark> has an <acronym>RPM</acronym> for a caching
|
|
name server (the <acronym>RPM</acronym> also requires the
|
|
<command>bind</command><acronym>RPM</acronym>) and for Bering users, there
|
|
is <command>dnscache.lrp</command>. If you take this approach, you
|
|
configure your internal systems to use the firewall itself as their
|
|
primary (and only) name server. You use the internal <acronym>IP</acronym>
|
|
address of the firewall (<systemitem class="ipaddress">10.10.10.254</systemitem>
|
|
in the example above) for the name server address. To allow your local
|
|
systems to talk to your caching name server, you must open port 53 (both
|
|
<acronym>UDP</acronym> and <acronym>TCP</acronym>) from the local network
|
|
to the firewall; you do that by adding the following rules in <filename
|
|
class="directory">/etc/shorewall/</filename><filename>rules</filename>.
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
AllowDNS loc fw</programlisting></para></listitem></itemizedlist></para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Other Connections</title>
|
|
|
|
<para>The two-interface sample includes the following rules:
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
AllowDNS fw net</programlisting>This rule allows <acronym>DNS</acronym>
|
|
access from your firewall and may be removed if you uncommented the line
|
|
in <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
|
allowing all connections from the firewall to the internet.</para>
|
|
|
|
<para>In the rule shown above, <quote>AllowDNS</quote> is an example of a
|
|
<emphasis>defined action</emphasis>. Shorewall includes a number of
|
|
defined actions and <ulink url="User_defined_Actions.html">you can add
|
|
your own</ulink>. To see the list of actions included with your version of
|
|
Shorewall, look in the file <filename>/etc/shorewall/actions.std</filename>.
|
|
Those actions that accept connection requests have names that begin with
|
|
<quote>Allow</quote>.</para>
|
|
|
|
<para>You don't have to use defined actions when coding a rule in
|
|
<filename>/etc/shorewall/rules</filename>; the generated Netfilter ruleset
|
|
is slightly more efficient if you code your rules directly rather than
|
|
using defined actions. The the rule shown above could also have been coded
|
|
as follows:<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT fw net udp 53
|
|
ACCEPT fw net tcp 53</programlisting></para>
|
|
|
|
<para>In cases where Shorewall doesn't include a defined action to
|
|
meet your needs, you can either define the action yourself or you can
|
|
simply code the appropriate rules directly.</para>
|
|
|
|
<para>The sample also includes: <programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
AllowSSH loc fw</programlisting> That rule allows you to run an
|
|
<acronym>SSH</acronym> server on your firewall and connect to that server
|
|
from your local systems.</para>
|
|
|
|
<para>If you wish to enable other connections from your firewall to other
|
|
systems, the general format using an <quote>Allow</quote> action is:
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
<action> fw <emphasis><destination zone></emphasis></programlisting>The
|
|
general format when not using defined actions is:<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT fw <emphasis><destination zone> <protocol> <port></emphasis></programlisting><example><title>Web
|
|
Server on Firewall</title><para>You want to run a Web Server on your
|
|
firewall system: <programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
AllowWeb net fw
|
|
AllowWeb loc fw</programlisting> Those two rules would of course be in
|
|
addition to the rules listed above under <quote><link linkend="cachingdns">You
|
|
can configure a Caching Name Server on your firewall</link></quote>.</para></example>
|
|
If you don't know what port and protocol a particular application
|
|
uses, look <ulink url="ports.htm">here</ulink>. <important><para>I
|
|
don't recommend enabling <command>telnet</command> to/from the
|
|
internet because it uses clear text (even for login!). If you want shell
|
|
access to your firewall from the internet, use <acronym>SSH</acronym>:</para><programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
AllowSSH net fw</programlisting></important> <inlinegraphic
|
|
fileref="images/leaflogo.gif" format="GIF" />Bering users will want to add
|
|
the following two rules to be compatible with Jacques's Shorewall
|
|
configuration.<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT loc fw udp 53 #Allow DNS Cache to work
|
|
ACCEPT loc fw tcp 80 #Allow Weblet to work</programlisting>
|
|
<inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>Now edit your <filename class="directory">/etc/shorewall/</filename><filename>rules</filename>
|
|
file to add or delete other connections as required.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Some Things to Keep in Mind</title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">You cannot test your firewall from the
|
|
inside</emphasis>. Just because you send requests to your firewall
|
|
external IP address does not mean that the request will be associated
|
|
with the external interface or the <quote>net</quote> zone. Any
|
|
traffic that you generate from the local network will be associated
|
|
with your local interface and will be treated as loc->fw traffic.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">IP addresses are properties of systems,
|
|
not of interfaces</emphasis>. It is a mistake to believe that your
|
|
firewall is able to forward packets just because you can ping the IP
|
|
address of all of the firewall's interfaces from the local
|
|
network. The only conclusion you can draw from such pinging success is
|
|
that the link between the local system and the firewall works and that
|
|
you probably have the local system's default gateway set
|
|
correctly.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">All IP addresses configured on firewall
|
|
interfaces are in the $FW (fw) zone</emphasis>. If 192.168.1.254 is
|
|
the IP address of your internal interface then you can write
|
|
<quote><emphasis role="bold">$FW:192.168.1.254</emphasis></quote> in a
|
|
rule but you may not write <quote><emphasis role="bold">loc:192.168.1.254</emphasis></quote>.
|
|
Similarly, it is nonsensical to add 192.168.1.254 to the <emphasis
|
|
role="bold">loc</emphasis> zone using an entry in
|
|
<filename>/etc/shorewall/hosts</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Reply packets do NOT automatically follow
|
|
the reverse path of the one taken by the original request</emphasis>.
|
|
All packets are routed according to the routing table of the host at
|
|
each step of the way. This issue commonly comes up when people install
|
|
a Shorewall firewall parallel to an existing gateway and try to use
|
|
DNAT through Shorewall without changing the default gateway of the
|
|
system receiving the forwarded requests. Requests come in through the
|
|
Shorewall firewall where the destination IP address gets rewritten but
|
|
replies go out unmodified through the old gateway.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">Shorewall itself has no notion of inside
|
|
or outside</emphasis>. These concepts are embodied in how Shorewall is
|
|
configured.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Starting and Stopping Your Firewall</title>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>The <ulink url="Install.htm">installation procedure</ulink>
|
|
configures your system to start Shorewall at system boot but beginning
|
|
with Shorewall version 1.3.9 startup is disabled so that your system
|
|
won't try to start Shorewall before configuration is complete. Once
|
|
you have completed configuration of your firewall, you can enable
|
|
Shorewall startup by removing the file <filename class="directory">/etc/shorewall/</filename><filename>startup_disabled</filename>.
|
|
<important><para>Users of the .deb package must edit <filename
|
|
class="directory">/etc/default/</filename><filename>shorewall</filename>
|
|
and set <varname>startup=1</varname>.</para></important> The firewall is
|
|
started using the <quote><command>shorewall start</command></quote>
|
|
command and stopped using <quote><command>shorewall stop</command></quote>.
|
|
When the firewall is stopped, routing is enabled on those hosts that have
|
|
an entry in <filename class="directory">/etc/shorewall/</filename><filename><ulink
|
|
url="Documentation.htm#Routestopped">routestopped</ulink></filename>. A
|
|
running firewall may be restarted using the <quote><command>shorewall
|
|
restart</command></quote> command. If you want to totally remove any trace
|
|
of Shorewall from your Netfilter configuration, use <quote><command>shorewall
|
|
clear</command></quote>.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>The two-interface sample assumes that you want to enable routing
|
|
to/from <filename class="devicefile">eth1</filename> (the local network)
|
|
when Shorewall is stopped. If your local network isn't connected to
|
|
<filename class="devicefile">eth1</filename> or if you wish to enable
|
|
access to/from other hosts, change <filename class="directory">/etc/shorewall/</filename><filename>routestopped</filename>
|
|
accordingly. <warning><para>If you are connected to your firewall from the
|
|
internet, do not issue a <quote><command>shorewall stop</command></quote>
|
|
command unless you have added an entry for the <acronym>IP</acronym>
|
|
address that you are connected from to <filename class="directory">/etc/shorewall/</filename><filename>routestopped</filename>.
|
|
Also, I don't recommend using <quote><command>shorewall restart</command></quote>;
|
|
it is better to create an alternate configuration and test it using the
|
|
<quote><command>shorewall try</command></quote> command.</para></warning></para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Additional Recommended Reading</title>
|
|
|
|
<para>I highly recommend that you review the <ulink
|
|
url="configuration_file_basics.htm">Common Configuration File Features
|
|
page</ulink> -- it contains helpful tips about Shorewall features than
|
|
make administering your firewall easier.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Adding a Wireless Segment to your Two-Interface Firewall</title>
|
|
|
|
<para>Once you have the two-interface setup working, the next logical step
|
|
is to add a Wireless Network. The first step involves adding an additional
|
|
network card to your firewall, either a Wireless card or an ethernet card
|
|
that is connected to a Wireless Access Point.<caution><para>When you add a
|
|
network card, it won't necessarily be detected as the next highest
|
|
ethernet interface. For example, if you have two ethernet cards in your
|
|
system (<filename class="devicefile">eth0</filename> and <filename
|
|
class="devicefile">eth1</filename>) and you add a third card that uses the
|
|
same driver as one of the other two, that third card won't necessarily
|
|
be detected as <filename class="devicefile">eth2</filename>; it could
|
|
rather be detected as <filename class="devicefile">eth0</filename> or
|
|
<filename class="devicefile">eth1</filename>! You can either live with
|
|
that or you can shuffle the cards around in the slots until the new card
|
|
is detected as <filename class="devicefile">eth2</filename>.</para></caution></para>
|
|
|
|
<para>Your new network will look similar to what is shown in the following
|
|
figure.<graphic fileref="images/basics2.png" /></para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>The first thing to note is that the computers in your wireless
|
|
network will be in a different subnet from those on your wired local LAN.
|
|
In the above example, we have chosen to use the network 10.10.11.0/24.
|
|
Computers 3 and 4 would be configured with a default gateway IP address of
|
|
10.10.11.254.</para>
|
|
|
|
<para>Second, we have chosen to include the wireless network as part of
|
|
the local zone. Since Shorewall allows intra-zone traffic by default,
|
|
traffic may flow freely between the local wired network and the wireless
|
|
network.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
|
|
|
|
<para>There are only two changes that need to be made to the Shorewall
|
|
configuration:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>An entry needs to be added to <filename>/etc/shorewall/interfaces</filename>
|
|
for the wireless network interface. If the wireless interface is
|
|
<filename class="devicefile">wlan0</filename>, the entry might look
|
|
like:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
loc wlan0 detect maclist</programlisting>
|
|
|
|
<para>As shown in the above entry, I recommend using the <ulink
|
|
url="MAC_Validation.html">maclist option</ulink> for the wireless
|
|
segment. By adding entries for computers 3 and 4 in
|
|
<filename>/etc/shorewall/maclist</filename>, you help ensure that your
|
|
neighbors aren't getting a free ride on your internet connection.
|
|
Start by omitting that option; when you have everything working, then
|
|
add the option and configure your <filename>/etc/shorewall/maclist</filename>
|
|
file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You need to add an entry to the <filename>/etc/shorewall/masq</filename>
|
|
file to masquerade traffic from the wireless network to the internet.
|
|
If your internet interface is <filename class="devicefile">eth0</filename>
|
|
and your wireless interface is <filename class="devicefile">wlan0</filename>,
|
|
the entry would be:</para>
|
|
|
|
<programlisting>#INTERFACE SUBNET ADDRESS
|
|
eth0 wlan0</programlisting>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>One other thing to note. To get <trademark>Microsoft</trademark>
|
|
networking working between the wireless and wired networks, you will need
|
|
either a WINS server or a PDC. I personally use Samba configured as a WINS
|
|
server running on my firewall. Running a WINS server on your firewall
|
|
requires the rules listed in the <ulink url="samba.htm">Shorewall/Samba
|
|
documentation</ulink>.</para>
|
|
</section>
|
|
</article> |