forked from extern/shorewall_code
a44e4a46f8
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1143 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
343 lines
41 KiB
HTML
343 lines
41 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Three-Interface Firewall</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="three-interface"></a>Three-Interface Firewall</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2002-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>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
|
||
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-12</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2803947">Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#id2807729">Requirements</a></span></dt><dt><span class="section"><a href="#id2807804">Before you start</a></span></dt><dt><span class="section"><a href="#id2810224">Conventions</a></span></dt></dl></dd><dt><span class="section"><a href="#id2810263">PPTP/ADSL</a></span></dt><dt><span class="section"><a href="#id2810295">Shorewall Concepts</a></span></dt><dt><span class="section"><a href="#id2859594">Network Interfaces</a></span></dt><dt><span class="section"><a href="#id2859977">IP Addresses</a></span></dt><dt><span class="section"><a href="#id2806632">IP Masquerading (SNAT)</a></span></dt><dt><span class="section"><a href="#id2806881">Port Forwarding (DNAT)</a></span></dt><dt><span class="section"><a href="#id2865302">Domain Name Server (DNS)</a></span></dt><dt><span class="section"><a href="#id2865536">Other Connections</a></span></dt><dt><span class="section"><a href="#id2865767">Starting and Stopping Your Firewall</a></span></dt><dt><span class="section"><a href="#id2865997">Additional Recommended Reading</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2803947"></a>Introduction</h2></div></div><div></div></div><p>Setting up a Linux system as a firewall for a small network with DMZ
|
||
is a fairly straight-forward task if you understand the basics and follow
|
||
the documentation.</p><p>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 one of its more popular configurations:</p><div class="itemizedlist"><ul type="disc"><li><p>Linux system used as a firewall/router for a small local
|
||
network.</p></li><li><p>Single public IP address.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you have more than one public IP address, this is not the
|
||
guide you want -- see the <a href="shorewall_setup_guide.htm" target="_self">Shorewall
|
||
Setup Guide</a> instead.</p></div></li><li><p>DMZ connected to a separate ethernet interface.</p></li><li><p>Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up,
|
||
...</p></li></ul></div><p>Here is a schematic of a typical installation.</p><div class="figure"><a id="id2807700"></a><p class="title"><b>Figure 1. schematic of a typical installation</b></p><div class="mediaobject" align="center"><img src="images/dmz1.png" align="middle" alt="schematic of a typical installation" /></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807729"></a>Requirements</h3></div></div><div></div></div><p>Shorewall requires that you have the <span><b class="command">iproute</b></span>/<span><b class="command">iproute2</b></span>
|
||
package installed (on <span class="trademark">RedHat</span>™, the package is
|
||
called <span><b class="command">iproute</b></span>). You can tell if this package is
|
||
installed by the presence of an <span><b class="command">ip</b></span> program on your
|
||
firewall system. As <tt class="systemitem">root</tt>, you
|
||
can use the <span><b class="command">which</b></span> command to check for this program:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">[root@gateway root]# <span><b class="command">which ip</b></span>
|
||
/sbin/ip
|
||
[root@gateway root]#</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807804"></a>Before you start</h3></div></div><div></div></div><p>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.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>If you edit your configuration files on a
|
||
<span class="trademark">Windows</span>™ system, you must save them as
|
||
<span class="trademark">Unix</span>™ files if your editor supports that option
|
||
or you must run them through <span><b class="command">dos2unix</b></span> before trying
|
||
to use them. Similarly, if you copy a configuration file from your
|
||
<span class="trademark">Windows</span>™ hard drive to a floppy disk, you must
|
||
run <span><b class="command">dos2unix</b></span> against the copy before using it with
|
||
Shorewall.</p><div class="itemizedlist"><ul type="disc"><li><p><a href="http://www.simtel.net/pub/pd/51438.html" target="_self">Windows
|
||
Version of dos2unix</a></p></li><li><p><a href="http://www.megaloman.com/%7Ehany/software/hd2u/" target="_self">Linux
|
||
Version of dos2unix</a></p></li></ul></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810224"></a>Conventions</h3></div></div><div></div></div><p>Points at which configuration changes are recommended are flagged
|
||
with <img src="images/BD21298_.gif" />.</p><p>Configuration notes that are unique to LEAF/Bering are marked with
|
||
<img src="images/leaflogo.gif" />.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810263"></a>PPTP/ADSL</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>If you have an ADSL Modem and you use PPTP to communicate with a
|
||
server in that modem, you must make the <a href="PPTP.htm#PPTP_ADSL" target="_self">changes
|
||
recommended here</a> in addition to those detailed below. ADSL with
|
||
PPTP is most commonly found in Europe, notably in Austria.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810295"></a>Shorewall Concepts</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>The configuration files for Shorewall are contained in the directory
|
||
<tt class="filename">/etc/shorewall</tt> -- for simple setups, you will only
|
||
need to deal with a few of these as described in this guide. After you
|
||
have installed Shorewall, download the three-interface sample, un-tar it (<span><b class="command">tar
|
||
<tt class="option">-zxvf</tt> <tt class="filename">three-interfaces.tgz</tt></b></span>)
|
||
and and copy the files to <tt class="filename">/etc/shorewall</tt> (the files
|
||
will replace files with the same names that were placed in
|
||
<tt class="filename">/etc/shorewall</tt> when Shorewall was installed).</p><p>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.</p><p>Shorewall views the network where it is running as being composed of
|
||
a set of zones. In the three-interface sample configuration, the following
|
||
zone names are used:</p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><thead valign="middle"><tr><th align="center">Name</th><th align="center">Description</th></tr></thead><tbody><tr><td align="left">net</td><td align="left">The Internet</td></tr><tr><td align="left">loc</td><td align="left">Your Local Network</td></tr><tr><td align="left">dmz</td><td align="left">Demilitarized Zone</td></tr></tbody></table></div><p>Zone names are defined in <tt class="filename">/etc/shorewall/zones</tt>.</p><p>Shorewall also recognizes the firewall system as its own zone - by
|
||
default, the firewall itself is known as <tt class="varname">fw</tt>.</p><p>Rules about what traffic to allow and what traffic to deny are
|
||
expressed in terms of zones.</p><div class="itemizedlist"><ul type="disc"><li><p>You express your default policy for connections from one zone to
|
||
another zone in the <tt class="filename">/etc/shorewall/policy</tt> file.</p></li><li><p>You define exceptions to those default policies in the
|
||
<tt class="filename">/etc/shorewall/rules</tt> file.</p></li></ul></div><p>For each connection request entering the firewall, the request is
|
||
first checked against the <tt class="filename">/etc/shorewall/rules</tt> file.
|
||
If no rule in that file matches the connection request then the first
|
||
policy in <tt class="filename">/etc/shorewall/policy</tt> that matches the
|
||
request is applied. If that policy is REJECT or DROP the request is first
|
||
checked against the rules in <tt class="filename">/etc/shorewall/common</tt> if
|
||
that file exists; otherwise the file <tt class="filename">/etc/shorewall/common.def</tt>
|
||
is checked</p><p>The <tt class="filename">/etc/shorewall/policy</tt> file included with
|
||
the three-interface sample has the following policies:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||
loc net ACCEPT
|
||
net all DROP info
|
||
all all REJECT info</pre></td></tr></table><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>In the three-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.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
|
||
fw net ACCEPT</pre></td></tr></table></div><p>The above policy will:</p><div class="orderedlist"><ol type="1"><li><p>allow all connection requests from your local network to the
|
||
internet</p></li><li><p>drop (ignore) all connection requests from the internet to your
|
||
firewall or local network</p></li><li><p>optionally accept all connection requests from the firewall to
|
||
the internet (if you uncomment the additional policy)</p></li><li><p>reject all other connection requests.</p></li></ol></div><p><img src="images/BD21298_.gif" /></p><p>At this point, edit your <tt class="filename">/etc/shorewall/policy</tt>
|
||
file and make any changes that you wish.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859594"></a>Network Interfaces</h2></div></div><div></div></div><div class="figure"><a id="id2859601"></a><p class="title"><b>Figure 2. DMZ</b></p><div class="mediaobject" align="center"><img src="images/dmz1.png" align="middle" alt="DMZ" /></div></div><p>The firewall has three network interfaces. Where Internet
|
||
connectivity is through a cable or DSL “<span class="quote">Modem</span>”, the External
|
||
Interface will be the ethernet adapter that is connected to that
|
||
“<span class="quote">Modem</span>” (e.g., <tt class="filename">eth0</tt>)
|
||
unless you connect via <span class="emphasis"><em>Point-to-Point Protocol</em></span> over
|
||
Ethernet (PPPoE) or <span class="emphasis"><em>Point-to-Point Tunneling Protocol</em></span>
|
||
(PPTP) in which case the External Interface will be a <tt class="literal">ppp</tt>
|
||
interface (e.g., <tt class="filename">ppp0</tt>). If you
|
||
connect via a regular modem, your External Interface will also be
|
||
<tt class="filename">ppp0</tt>. If you connect using ISDN,
|
||
you external interface will be <tt class="filename">ippp0</tt>.</p><p><img src="images/BD21298_.gif" /></p><p>If your external interface is <tt class="filename">ppp0</tt>
|
||
or <tt class="filename">ippp0</tt> then you will want to set
|
||
<tt class="varname">CLAMPMSS=yes</tt> in <tt class="filename">/etc/shorewall/shorewall.conf</tt>.</p><p>Your Local Interface will be an ethernet adapter (<tt class="filename">eth0</tt>, <tt class="filename">eth1</tt>
|
||
or <tt class="filename">eth2</tt>) and will be connected to
|
||
a hub or switch. Your local computers will be connected to the same switch
|
||
(note: If you have only a single local system, you can connect the
|
||
firewall directly to the computer using a cross-over cable).</p><p>Your DMZ Interface will also be an ethernet adapter (<tt class="filename">eth0</tt>, <tt class="filename">eth1</tt>
|
||
or <tt class="filename">eth2</tt>) and will be connected to
|
||
a hub or switch. Your DMZ computers will be connected to the same switch
|
||
(note: If you have only a single DMZ system, you can connect the firewall
|
||
directly to the computer using a cross-over cable).</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>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
|
||
<tt class="filename">/etc/shorewall/interfaces</tt> for all interfaces
|
||
connected to the common hub/switch. Using such a setup with a production
|
||
firewall is strongly recommended against.</p></div><p><img src="images/BD21298_.gif" /></p><p>The Shorewall three-interface sample configuration assumes that the
|
||
external interface is <tt class="filename">eth0</tt>, the
|
||
local interface is <tt class="filename">eth1</tt> and the
|
||
DMZ interface is <tt class="filename">eth2</tt>. If your
|
||
configuration is different, you will have to modify the sample
|
||
<tt class="filename">/etc/shorewall/interfaces</tt> file accordingly. While you
|
||
are there, you may wish to review the list of options that are specified
|
||
for the interfaces. Some hints:</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>If your external interface is <tt class="filename">ppp0</tt>
|
||
or <tt class="filename">ippp0</tt>, you can replace the
|
||
“<span class="quote">detect</span>” in the second column with “<span class="quote">-</span>”
|
||
(without the quotes).</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>If your external interface is <tt class="filename">ppp0</tt>
|
||
or <tt class="filename">ippp0</tt> or if you have a static
|
||
IP address, you can remove “<span class="quote">dhcp</span>” from the option list.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859977"></a>IP Addresses</h2></div></div><div></div></div><p>Before going further, we should say a few words about Internet
|
||
Protocol (IP) addresses. Normally, your ISP will assign you a single
|
||
Public IP address. This address may be assigned via the Dynamic Host
|
||
Configuration Protocol (DHCP) or as part of establishing your connection
|
||
when you dial in (standard modem) or establish your PPP connection. In
|
||
rare cases, your ISP may assign you a static IP address; that means that
|
||
you configure your firewall's external interface to use that address
|
||
permanently. Regardless of how the 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 for your internal network (the local and DMZ
|
||
Interfaces on your firewall plus your other computers). RFC 1918 reserves
|
||
several Private IP address ranges for this purpose:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="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</pre></td></tr></table><p><img src="images/BD21298_.gif" /></p><p>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 <tt class="varname">norfc1918</tt> option from the external interface's
|
||
entry in <tt class="filename">/etc/shorewall/interfaces</tt>.</p><p>You will want to assign your local addresses from one sub-network or
|
||
subnet and your DMZ addresses from another subnet. For our purposes, we
|
||
can consider a subnet to consists of a range of addresses <tt class="systemitem">x.y.z.0</tt> - <tt class="systemitem">x.y.z.255</tt>.
|
||
Such a subnet will have a Subnet Mask of <tt class="systemitem">255.255.255.0</tt>.
|
||
The address <tt class="systemitem">x.y.z.0</tt> is reserved
|
||
as the Subnet Address and <tt class="systemitem">x.y.z.255</tt>
|
||
is reserved as the Subnet Broadcast Address. In Shorewall, a subnet is
|
||
described using Classless InterDomain Routing (CIDR) notation with
|
||
consists of the subnet address followed by <tt class="varname">/24</tt>. The
|
||
<tt class="varname">24</tt> refers to the number of consecutive “<span class="quote">1</span>”
|
||
bits from the left of the subnet mask.</p><div class="table"><a id="id2809952"></a><p class="title"><b>Table 1. Example sub-network</b></p><table summary="Example sub-network" border="1"><colgroup><col align="left" /><col /></colgroup><tbody><tr><td align="left">Range:</td><td><tt class="systemitem">10.10.10.0</tt> -
|
||
<tt class="systemitem">10.10.10.255</tt></td></tr><tr><td align="left">Subnet Address:</td><td><tt class="systemitem">10.10.10.0</tt></td></tr><tr><td align="left">Broadcast Address:</td><td><tt class="systemitem">10.10.10.255</tt></td></tr><tr><td align="left">CIDR Notation:</td><td><tt class="systemitem">10.10.10.0/24</tt></td></tr></tbody></table></div><p>It is conventional to assign the internal interface either the first
|
||
usable address in the subnet (<tt class="systemitem">10.10.10.1</tt>
|
||
in the above example) or the last usable address (<tt class="systemitem">10.10.10.254</tt>).</p><p>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).</p><p><img src="images/BD21298_.gif" /></p><p>Your local computers (Local Computers 1 & 2) should be
|
||
configured with their default gateway set to the IP address of the
|
||
firewall's internal interface and your DMZ computers (DMZ Computers 1
|
||
& 2) should be configured with their default gateway set to the IP
|
||
address of the firewall's DMZ interface.</p><p>The foregoing short discussion barely scratches the surface
|
||
regarding subnetting and routing. If you are interested in learning more
|
||
about IP addressing and routing, I highly recommend “<span class="quote">IP
|
||
Fundamentals: What Everyone Needs to Know about Addressing & Routing</span>”,
|
||
Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p><p>The remainder of this quide will assume that you have configured
|
||
your network as shown here:</p><div class="figure"><a id="id2810143"></a><p class="title"><b>Figure 3. DMZ</b></p><div class="mediaobject"><img src="images/dmz2.png" alt="DMZ" /><div class="caption"><p>The default gateway for the DMZ computers would be <tt class="systemitem">10.10.11.254</tt> and the default gateway
|
||
for the Local computers would be <tt class="systemitem">10.10.10.254</tt>.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Your ISP might assign your external interface an RFC 1918
|
||
address. If that address is in the <tt class="systemitem">10.10.10.0/24</tt>
|
||
subnet then you will need to select a DIFFERENT RFC 1918 subnet
|
||
for your local network and if it is in the <tt class="systemitem">10.10.11.0/24</tt> subnet then you will
|
||
need to select a different RFC 1918 subnet for your DMZ.</p></div></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806632"></a>IP Masquerading (SNAT)</h2></div></div><div></div></div><p>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 local computer 1) sends a connection request to
|
||
an internet host, the firewall must perform Network Address Translation
|
||
(NAT). 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 accross
|
||
the internet). When the firewall receives a return packet, it rewrites the
|
||
destination address back to 10.10.10.1 and forwards the packet on to local
|
||
computer 1.</p><p>On Linux systems, the above process is often referred to as IP
|
||
Masquerading and you will also see the term Source Network Address
|
||
Translation (SNAT) used. Shorewall follows the convention used with
|
||
Netfilter: </p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Masquerade</em></span>
|
||
describes the case where you let your firewall system automatically detect
|
||
the external interface address.</p></li><li><p><span class="emphasis"><em>SNAT</em></span>
|
||
refers to the case when you explicitly specify the source address that you
|
||
want outbound packets from your local network to use.</p></li></ul></div><p>
|
||
In Shorewall, both Masquerading and SNAT are configured with entries in
|
||
the <tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
|
||
file.</p><p><img src="images/BD21298_.gif" /></p><p>If your external firewall interface is <tt class="filename">eth0</tt>,
|
||
your local interface <tt class="filename">eth1</tt> and your
|
||
DMZ interface is <tt class="filename">eth2</tt> then you do
|
||
not need to modify the file provided with the sample. Otherwise, edit
|
||
<tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
|
||
and change it to match your configuration.</p><p>If, despite all advice to the contrary, you are using this guide and
|
||
want to use one-to-one NAT or Proxy ARP for your DMZ, remove the entry for
|
||
eth2 from <tt class="filename">/etc/shorewall/masq</tt>.</p><p><img src="images/BD21298_.gif" /></p><p>If your external IP is static, you can enter it in the third column
|
||
in the <tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
|
||
entry if you like although your firewall will work fine if you leave that
|
||
column empty. Entering your static IP in column 3 makes processing
|
||
outgoing packets a little more efficient.</p><p><img src="images/BD21298_.gif" /></p><p>If you are using the Debian package, please check your
|
||
<tt class="filename">shorewall.conf</tt> file to ensure that the following are
|
||
set correctly; if they are not, change them appropriately:
|
||
</p><div class="itemizedlist"><ul type="disc"><li><p><tt class="varname">NAT_ENABLED=Yes</tt>
|
||
(Shorewall versions earlier than 1.4.6)</p></li><li><p><tt class="varname">IP_FORWARDING=On</tt></p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806881"></a>Port Forwarding (DNAT)</h2></div></div><div></div></div><p>One of your goals will be to run one or more servers on your DMZ
|
||
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
|
||
your 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 SNAT to rewrite the source address in
|
||
the response.</p><p>The above process is called <span class="emphasis"><em>Port Forwarding</em></span> or
|
||
<span class="emphasis"><em>Destination Network Address Translation</em></span> (DNAT). You
|
||
configure port forwarding using DNAT rules in the <tt class="filename">/etc/shorewall/</tt><tt class="filename">rules</tt>
|
||
file.</p><p>The general form of a simple port forwarding rule in <tt class="filename">/etc/shorewall/</tt><tt class="filename">rules</tt> is:
|
||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
DNAT net dmz:<span class="emphasis"><em><server local ip address></em></span>[:<span class="emphasis"><em><server port></em></span>] <span class="emphasis"><em><protocol></em></span> <span class="emphasis"><em><port></em></span></pre></td></tr></table><p>
|
||
If you don't specify the <span class="emphasis"><em><tt class="varname"><server port></tt></em></span>,
|
||
it is assumed to be the same as <span class="emphasis"><em><tt class="varname"><port></tt></em></span>.</p><div class="example"><a id="id2807001"></a><p class="title"><b>Example 1. You run a Web Server on DMZ Computer 2 and you want to forward
|
||
incoming TCP port 80 to that system</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
DNAT net dmz:10.10.11.2 tcp 80
|
||
ACCEPT loc dmz:10.10.11.2 tcp 80</pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Entry
|
||
1 forwards port 80 from the Internet.</p></li><li><p>Entry
|
||
2 allows connections from the local network.</p></li></ul></div><p>
|
||
Several important points to keep in mind:</p><div class="itemizedlist"><ul type="disc"><li><p>When
|
||
you are connecting to your server from your local systems, you must use
|
||
the server's internal IP address (<tt class="systemitem">10.10.11.2</tt>).</p></li><li><p>Many
|
||
ISPs 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 (e.g., connect to <tt class="literal">http://w.x.y.z:5000 where
|
||
w.x.y.z</tt> is your external IP).</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE
|
||
# PORT(S)
|
||
DNAT net dmz:10.10.11.2:80 tcp 80 5000</pre></td></tr></table></li><li><p>If
|
||
you want to be able to access your server from the local network using
|
||
your external address, then if you have a static external IP you can
|
||
replace the loc->dmz rule above with:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||
# PORT(S) DEST
|
||
DNAT loc dmz:10.10.11.2 tcp 80 - <span class="emphasis"><em><external ip></em></span></pre></td></tr></table><p>If
|
||
you have a dynamic ip then you must ensure that your external interface
|
||
is up before starting Shorewall and you must take steps as follows
|
||
(assume that your external interface is <tt class="filename">eth0</tt>):</p><div class="orderedlist"><ol type="1"><li><p>Include
|
||
the following in /etc/shorewall/params:</p><p><span><b class="command">ETH0_IP=$(find_interface_address
|
||
eth0)</b></span></p></li><li><p>Make your
|
||
<tt class="literal">loc->dmz</tt> rule: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
|
||
# PORT(S) DEST
|
||
DNAT loc dmz:10.10.11.2 tcp 80 - $ETH0_IP</pre></td></tr></table></li></ol></div></li><li><p>If
|
||
you want to access your server from the DMZ using your external IP
|
||
address, see <a href="FAQ.htm#faq2a" target="_self">FAQ 2a</a>.</p></li></ul></div></div><p><img src="images/BD21298_.gif" /></p><p>At this point, add the DNAT and ACCEPT rules for your servers.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865302"></a>Domain Name Server (DNS)</h2></div></div><div></div></div><p>Normally, when you connect to your ISP, as part of getting an IP
|
||
address your firewall's <span class="emphasis"><em>Domain Name Service</em></span> (DNS)
|
||
resolver will be automatically configured (e.g., the <tt class="filename">/etc/resolv.conf</tt>
|
||
file will be written). Alternatively, your ISP may have given you the IP
|
||
address of a pair of DNS name servers for you to manually configure as
|
||
your primary and secondary name servers. It is your responsibility to
|
||
configure the resolver in your internal systems. You can take one of two
|
||
approaches: </p><div class="itemizedlist"><ul type="disc"><li><p>You can configure your internal
|
||
systems to use your ISP's name servers. If you 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 <tt class="filename">/etc/resolv.conf</tt>
|
||
on your firewall system -- the name servers are given in “<span class="quote">nameserver</span>”
|
||
records in that file.</p></li><li><p><img src="images/BD21298_.gif" /></p><p>You can
|
||
configure a <span class="emphasis"><em>Caching Name Server</em></span> on your firewall or
|
||
in your DMZ. <span class="trademark">Red Hat</span>™ has an RPM for a caching name
|
||
server (which also requires the '<span><b class="command">bind</b></span>' RPM) and
|
||
for Bering users, there is <tt class="filename">dnscache.lrp</tt>. If you take
|
||
this approach, you configure your internal systems to use the caching name
|
||
server as their primary (and only) name server. You use the internal IP
|
||
address of the firewall (<tt class="systemitem">10.10.10.254</tt>
|
||
in the example above) for the name server address if you choose to run the
|
||
name server on your firewall. To allow your local systems to talk to your
|
||
caching name server, you must open port 53 (both UDP and TCP) from the
|
||
local network to the server; you do that by adding the rules in
|
||
<tt class="filename">/etc/shorewall/rules</tt>.</p></li></ul></div><p>
|
||
If you run the name server on the firewall:
|
||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
AllowDNS loc fw
|
||
AllowDNS dmz fw </pre></td></tr></table><p> Run name server on DMZ
|
||
computer 1: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
AllowDNS loc dmz:10.10.11.1
|
||
AllowDNS fw dmz:10.10.11.1 </pre></td></tr></table><p>In the rules shown above, “<span class="quote">AllowDNS</span>” is an example of a
|
||
<span class="emphasis"><em>defined action</em></span>. Shorewall includes a number of
|
||
defined actions and <a href="User_defined_Actions.html" target="_self">you can add
|
||
your own</a>. To see the list of actions included with your version of
|
||
Shorewall, look in the file <tt class="filename">/etc/shorewall/actions.std</tt>.
|
||
Those actions that accept connection requests have names that begin with
|
||
“<span class="quote">Allow</span>”.</p><p>You don't have to use defined actions when coding a rule in
|
||
<tt class="filename">/etc/shorewall/rules</tt>; the generated Netfilter ruleset
|
||
is slightly more efficient if you code your rules directly rather than
|
||
using defined actions. The first example above (name server on the
|
||
firewall) could also have been coded as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
ACCEPT loc fw tcp 53
|
||
ACCEPT loc fw udp 53
|
||
ACCEPT dmz fw tcp 53
|
||
ACCEPT dmz fw udp 53 </pre></td></tr></table><p>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.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865536"></a>Other Connections</h2></div></div><div></div></div><p>The three-interface sample includes the following rule:
|
||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
AllowDNS fw net </pre></td></tr></table><p>That rule allow DNS access from
|
||
your firewall and may be removed if you commented out the line in
|
||
<tt class="filename">/etc/shorewall/policy</tt> allowing all connections from
|
||
the firewall to the internet.</p><p>The sample also includes: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
AllowSSH loc fw
|
||
AllowSSH loc dmz </pre></td></tr></table><p>Those rules allow you to run
|
||
an SSH server on your firewall and in each of your DMZ systems and to
|
||
connect to those servers from your local systems.</p><p>If you wish to enable other connections between your systems, the
|
||
general format for using a defined action is:
|
||
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
<<span class="emphasis"><em>action</em></span>> <span class="emphasis"><em><source zone> <destination zone></em></span></pre></td></tr></table><p>The general format when not using a defined action is:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
ACCEPT <span class="emphasis"><em><source zone> <destination zone> <protocol> <port> </em></span></pre></td></tr></table><div class="example"><a id="id2865625"></a><p class="title"><b>Example 2. You want to run a publicly-available DNS server on your firewall
|
||
system</b></p><p>Using defined actions:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
AllowDNS net fw</pre></td></tr></table><p>Not using defined actions:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
ACCEPT net fw tcp 53
|
||
ACCEPT net fw udp 53 </pre></td></tr></table><p>Those rules would of course be in addition to the rules listed
|
||
above under "If you run the name server on your firewall".</p></div><p>If you don't know what port and protocol a particular
|
||
application uses, <a href="ports.htm" target="_self">look here</a>.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>I don't recommend enabling telnet to/from the internet because
|
||
it uses clear text (even for login!). If you want shell access to your
|
||
firewall from the internet, use SSH: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
AllowSSH net fw</pre></td></tr></table></div><p><img src="images/leaflogo.gif" /> Bering
|
||
users will want to add the following two rules to be compatible with
|
||
Jacques's Shorewall configuration: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||
ACCEPT loc fw udp 53
|
||
ACCEPT net fw tcp 80 </pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Entry
|
||
1 allows the DNS Cache to be used.</p></li><li><p>Entry
|
||
2 allows the “<span class="quote">weblet</span>” to work.</p></li></ul></div><p><img src="images/BD21298_.gif" /></p><p>Now modify <tt class="filename">/etc/shorewall/rules</tt> to add or
|
||
remove other connections as required.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865767"></a>Starting and Stopping Your Firewall</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>The <a href="Install.htm" target="_self">installation procedure</a>
|
||
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 <tt class="filename">/etc/shorewall/startup_disabled</tt>.
|
||
</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>Users of the <tt class="filename">.deb</tt> package must edit
|
||
<tt class="filename">/etc/default/shorewall</tt> and set <tt class="varname">startup=1</tt>.</p></div><p>
|
||
The firewall is started using the <span><b class="command">shorewall start</b></span>
|
||
command and stopped using <span><b class="command">shorewall stop</b></span>. When the
|
||
firewall is stopped, routing is enabled on those hosts that have an entry
|
||
in <a href="Documentation.htm#Routestopped" target="_self"><tt class="filename">/etc/shorewall/routestopped</tt></a>.
|
||
A running firewall may be restarted using the <span><b class="command">shorewall restart</b></span>
|
||
command. If you want to totally remove any trace of Shorewall from your
|
||
Netfilter configuration, use <span><b class="command">shorewall clear</b></span>.</p><p><img src="images/BD21298_.gif" /></p><p>The three-interface sample assumes that you want to enable routing
|
||
to/from <tt class="filename">eth1</tt> (your local network)
|
||
and <tt class="filename">eth2</tt> (DMZ) when Shorewall is
|
||
stopped. If these two interfaces don't connect to your local network
|
||
and DMZ or if you want to enable a different set of hosts, modify
|
||
<tt class="filename">/etc/shorewall/routestopped</tt> accordingly.
|
||
</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you are connected to your firewall from the internet, do
|
||
not issue a <span><b class="command">shorewall stop</b></span> command unless you have
|
||
added an entry for the IP address that you are connected from to <a href="Documentation.htm#Routestopped" target="_self"><tt class="filename">/etc/shorewall/routestopped</tt></a>.
|
||
Also, I don't recommend using <span><b class="command">shorewall restart</b></span>; it
|
||
is better to create an <a href="configuration_file_basics.htm#Levels" target="_self">alternate
|
||
configuration</a> and test it using the <a href="starting_and_stopping_shorewall.htm" target="_self"><span><b class="command">shorewall try</b></span>
|
||
command</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865997"></a>Additional Recommended Reading</h2></div></div><div></div></div><p>I highly recommend that you review the <a href="configuration_file_basics.htm" target="_self">Common Configuration File Features</a>
|
||
page -- it contains helpful tips about Shorewall features than make
|
||
administering your firewall easier.</p></div></div></body></html>
|