mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-22 07:33:43 +01:00
1305 lines
61 KiB
XML
1305 lines
61 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<!-- $Id$ -->
|
|
<article id="two-interface">
|
|
<articleinfo>
|
|
<title>Basic Two-Interface Firewall</title>
|
|
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2002-2009</year>
|
|
|
|
<year>2016-2017</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><emphasis role="bold">This article applies to Shorewall 4.4 and
|
|
later. If you are running a version of Shorewall earlier than Shorewall
|
|
4.4.0 then please see the documentation for that
|
|
release.</emphasis></para>
|
|
</caution>
|
|
|
|
<section id="Intro">
|
|
<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 id="Figure1"
|
|
label="1">
|
|
<title>Common two interface firewall configuration</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata align="center" fileref="images/basics.png" format="PNG"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure> <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.sourceforge.net/projects/dos2unix"><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 id="System">
|
|
<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 id="Conventions">
|
|
<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 Debian and it's derivatives
|
|
are marked with <inlinegraphic fileref="images/openlogo-nd-25.png"
|
|
format="GIF"/>.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="PPTP">
|
|
<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 id="Concepts">
|
|
<title>Shorewall Concepts</title>
|
|
|
|
<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.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif"
|
|
format="GIF"/><important>
|
|
<para>After you have <ulink url="Install.htm">installed
|
|
Shorewall</ulink>, locate the two-interfaces samples:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>If you installed using an RPM, the samples will be in the
|
|
Samples/two-interfaces/ subdirectory of the Shorewall
|
|
documentation directory. If you don't know where the Shorewall
|
|
documentation directory is, you can find the samples using this
|
|
command:</para>
|
|
|
|
<programlisting>~# rpm -ql shorewall | fgrep two-interfaces
|
|
/usr/share/doc/packages/shorewall/Samples/two-interfaces
|
|
/usr/share/doc/packages/shorewall/Samples/two-interfaces/interfaces
|
|
/usr/share/doc/packages/shorewall/Samples/two-interfaces/snat
|
|
/usr/share/doc/packages/shorewall/Samples/two-interfaces/policy
|
|
/usr/share/doc/packages/shorewall/Samples/two-interfaces/rules
|
|
/usr/share/doc/packages/shorewall/Samples/two-interfaces/zones
|
|
~#</programlisting>
|
|
|
|
<para>When running Shorewall 5.0.14 or later:</para>
|
|
|
|
<programlisting>~# rpm -ql shorewall | fgrep three-interfaces
|
|
/usr/share/doc/packages/shorewall/Samples/three-interfaces
|
|
/usr/share/doc/packages/shorewall/Samples/three-interfaces/interfaces
|
|
/usr/share/doc/packages/shorewall/Samples/three-interfaces/policy
|
|
/usr/share/doc/packages/shorewall/Samples/three-interfaces/rules
|
|
/usr/share/doc/packages/shorewall/Samples/three-interfaces/snat
|
|
/usr/share/doc/packages/shorewall/Samples/three-interfaces/zones
|
|
~#</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you installed using the tarball, the samples are in the
|
|
Samples/two-interfaces directory in the tarball.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you installed using a Shorewall 3.x .deb, the samples are
|
|
in /usr/share/doc/shorewall/examples/two-interfaces. You must
|
|
install the shorewall-doc package.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><graphic align="left"
|
|
fileref="images/openlogo-nd-25.png"/>If you installed using a
|
|
Shorewall 4.x .deb, the samples are in <emphasis
|
|
role="bold"><filename
|
|
class="directory">/usr/share/doc/shorewall/examples/two-interfaces</filename>.</emphasis>
|
|
You do not need the shorewall-doc package to have access to the
|
|
samples.</para>
|
|
|
|
<warning>
|
|
<para><emphasis role="bold">Note to Debian and Ubuntu
|
|
Users</emphasis></para>
|
|
|
|
<para>If you install using the .deb, you will find that your
|
|
<filename class="directory">/etc/shorewall</filename> directory
|
|
is practially 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>
|
|
</warning>
|
|
</listitem>
|
|
</orderedlist>
|
|
</important></para>
|
|
|
|
<para>As each file is introduced, I suggest that you look at the actual
|
|
file on your system and that you look at the <ulink
|
|
url="configuration_file_basics.htm#Manpages">man page</ulink> for that
|
|
file. For example, to look at the man page for the
|
|
<filename>/etc/shorewall/zones</filename> file, type <command>man
|
|
shorewall-zones</command> at a shell prompt.</para>
|
|
|
|
<para>Note: Beginning with Shorewall 4.4.20.1, there are versions of the
|
|
sample files that are annotated with the corresponding manpage contents.
|
|
These files have names ending in '.annotated'. You might choose to look at
|
|
those files instead.</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:</para>
|
|
|
|
<para><programlisting>#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
|
|
fw firewall
|
|
net ipv4
|
|
loc ipv4</programlisting>Zones are defined in the <ulink
|
|
url="manpages/shorewall-zones.html"><filename
|
|
class="directory">/etc/shorewall/</filename><filename>zones</filename></ulink>
|
|
file.</para>
|
|
|
|
<para>Note that Shorewall recognizes the firewall system as its own zone -
|
|
when the /etc/shorewall/zones file is processed, the name of the firewall
|
|
zone is stored in the shell variable $FW which may be used to refer to the
|
|
firewall zone throughout the Shorewall configuration.</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="manpages/shorewall-policy.html"><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="manpages/shorewall-rules.html"><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">common action</ulink> defined for
|
|
the policy in <filename>/etc/shorewall/actions</filename> or
|
|
<filename>/usr/share/shorewall/actions.std</filename> then that action is
|
|
performed before the action is applied. The purpose of the common action
|
|
is two-fold:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>It silently drops or rejects harmless common traffic that would
|
|
otherwise clutter up your log — Broadcasts for example.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If ensures that traffic critical to correct operation is allowed
|
|
through the firewall — ICMP <emphasis>fragmentation-needed</emphasis>
|
|
for example.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<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 LOGLEVEL LIMIT
|
|
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 LOGLEVEL LIMIT
|
|
$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> The word <firstterm>info</firstterm> in the LOG LEVEL
|
|
column for the DROP and REJECT policies indicates that packets dropped or
|
|
rejected under those policies should be <ulink
|
|
url="shorewall_logging.html">logged at that level</ulink>.</para>
|
|
|
|
<para>It is important to note that Shorewall policies (and rules) refer to
|
|
<emphasis role="bold">connections</emphasis> and not packet flow. With the
|
|
policies defined in the <filename
|
|
class="directory">/etc/shorewall/policy</filename> file shown above,
|
|
connections are allowed from the <emphasis>loc</emphasis> zone to the
|
|
<emphasis>net</emphasis> zone even though connections are not allowed from
|
|
the <emphasis>loc</emphasis> zone to the firewall itself.</para>
|
|
|
|
<para>Some people want to consider their firewall to be part of their
|
|
local network from a security perspective. If you want to do this, add
|
|
these two policies:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOGLEVEL LIMIT
|
|
loc $FW ACCEPT
|
|
$FW loc ACCEPT</programlisting>
|
|
|
|
<para><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 id="Interfaces">
|
|
<title>Network Interfaces</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata align="center" 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>
|
|
|
|
<caution>
|
|
<para>Be sure you know which interface is your external interface. Many
|
|
hours have been spent floundering by users who have configured the wrong
|
|
interface. If you are unsure, then as root type <command>ip route
|
|
ls</command> at the command line. The device listed in the last
|
|
(default) route should be your external interface.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting>root@lists:~# ip route ls
|
|
192.168.1.1 dev eth0 scope link
|
|
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
|
|
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
|
|
10.13.10.0/24 dev tun1 scope link
|
|
192.168.2.0/24 via 192.168.2.2 dev tun0
|
|
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.254
|
|
206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176
|
|
10.10.10.0/24 dev tun1 scope link
|
|
default via 206.124.146.254 dev <emphasis role="bold">eth0</emphasis>
|
|
root@lists:~# </programlisting>
|
|
|
|
<para>In that example, <filename class="devicefile">eth0</filename> is
|
|
the external interface.</para>
|
|
</caution>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF"/></para>
|
|
|
|
<para>I<emphasis role="bold">f 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></emphasis>.</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><emphasis role="bold">Do not connect the internal and external
|
|
interface to the same hub or switch except for testing</emphasis>.You
|
|
can test using this kind of configuration if you specify the <emphasis
|
|
role="bold">arp_filter</emphasis> option or the <emphasis
|
|
role="bold">arp_ignore</emphasis> option in <filename
|
|
class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
|
for all interfaces connected to the common hub/switch. <emphasis
|
|
role="bold">Using such a setup with a production firewall is strongly
|
|
recommended against</emphasis>.</para>
|
|
</warning><warning>
|
|
<para><emphasis role="bold">Do not configure a default route on your
|
|
internal interface.</emphasis> Your firewall should have exactly one
|
|
default route via your ISP's Router.</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> 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 <emphasis role="bold">you must
|
|
add the <varname>routeback</varname> option to the option
|
|
list.</emphasis></para>
|
|
</tip></para>
|
|
|
|
<para>Prior to Shorewall 5.1.9, you will also need to modify the snat and
|
|
stopped rules file, replacing eth1 with the name of your internal
|
|
interface.</para>
|
|
</section>
|
|
|
|
<section id="Addresses">
|
|
<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>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 id="Diagram">The remainder of this guide will assume that you have
|
|
configured your network as shown here: <mediaobject>
|
|
<imageobject>
|
|
<imagedata align="center" 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 <emphasis role="bold">you will need to select a DIFFERENT
|
|
RFC 1918 subnet for your local network.</emphasis></para>
|
|
</warning></para>
|
|
</section>
|
|
|
|
<section id="SNAT">
|
|
<title>IP Masquerading (SNAT)</title>
|
|
|
|
<para>The addresses reserved by RFC 1918 are sometimes referred to as
|
|
<firstterm>non-routable</firstterm> 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 in the <link
|
|
linkend="Diagram">above diagram</link>) 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 appear to the destination
|
|
Internet host 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 <ulink url="manpages/shorewall-masq.html"><filename
|
|
class="directory">/etc/shorewall/</filename><filename>masq</filename></ulink>
|
|
file (<filename>/etc/shorewall/snat</filename> when running Shorewall
|
|
5.0.14 or later). 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 <link linkend="Concepts">the sample</link>. Otherwise, edit
|
|
<filename
|
|
class="directory">/etc/shorewall/</filename><filename>masq</filename> or
|
|
<filename>/etc/shorewall/snat</filename> and change it to match your
|
|
configuration.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF"/></para>
|
|
|
|
<para>If your external <acronym>IP</acronym> is static then, if you are
|
|
running Shorewall 5.0.13 or earlier, you can enter our static IP 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 (Masquerade). Entering your static <acronym>IP</acronym> in
|
|
column 3 (SNAT) makes the processing of outgoing packets a little more
|
|
efficient.</para>
|
|
|
|
<para>When running Shorewall 5.0.14 or later, the rule in
|
|
/etc/shorewall/snat must be change from a MASQUERADE rule to an SNAT
|
|
rule.</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO PORT
|
|
<emphasis role="bold">SNAT(<replaceable>static-ip</replaceable>)</emphasis> ...</programlisting>
|
|
|
|
<para><graphic align="left"
|
|
fileref="images/openlogo-nd-25.png"/>I<emphasis role="bold">f you are
|
|
using the Debian package, please check your
|
|
<filename>shorewall.conf</filename> file to ensure that the following is
|
|
set correctly; if it is not, change it appropriately:</emphasis>
|
|
<itemizedlist spacing="compact">
|
|
<listitem>
|
|
<para><varname>IP_FORWARDING=On</varname></para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
</section>
|
|
|
|
<section id="Logging">
|
|
<title>Logging</title>
|
|
|
|
<para>Shorewall does not maintain a log itself but rather relies on your
|
|
<ulink url="shorewall_logging.htm">system's logging configuration</ulink>.
|
|
The following <ulink url="manpages/shorewall.html">commands</ulink> rely
|
|
on knowing where Netfilter messages are logged:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><command>shorewall show log</command> (Displays the last 20
|
|
netfilter log messages)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>shorewall logwatch</command> (Polls the log at a
|
|
settable interval</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>shorewall dump</command> (Produces an extensive report
|
|
for inclusion in Shorewall problem reports)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>It is important that these commands work properly because when you
|
|
encounter connection problems when Shorewall is running, the first thing
|
|
that you should do is to look at the Netfilter log; with the help of
|
|
<ulink url="FAQ.htm#faq17">Shorewall FAQ 17</ulink>, you can usually
|
|
resolve the problem quickly.</para>
|
|
|
|
<para>The Netfilter log location is distribution-dependent:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Debian and its derivatives log Netfilter messages to
|
|
<filename>/var/log/kern.log</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Recent <trademark>SuSE/OpenSuSE</trademark> releases come
|
|
preconfigured with syslog-ng and log netfilter messages to
|
|
<filename>/var/log/firewall</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For other distributions, Netfilter messages are most commonly
|
|
logged to <filename>/var/log/messages</filename>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF"/></para>
|
|
|
|
<para>If you are running a distribution that logs netfilter messages to a
|
|
log other than <filename>/var/log/messages</filename>, then modify the
|
|
LOGFILE setting in <filename>/etc/shorewall/shorewall.conf</filename> to
|
|
specify the name of your log.</para>
|
|
|
|
<important>
|
|
<para>The LOGFILE setting does not control where the Netfilter log is
|
|
maintained -- it simply tells the /sbin/<filename>shorewall</filename>
|
|
utility where to find the log.</para>
|
|
</important>
|
|
</section>
|
|
|
|
<section id="Modules">
|
|
<title>Kernel Module Loading</title>
|
|
|
|
<para>Beginning in Shorewall 4.4.7,
|
|
<filename>/etc/shorewall/shorewall.conf</filename> contains a
|
|
LOAD_HELPERS_ONLY option which is set to <option>Yes</option> in the
|
|
samples. This causes Shorewall to attempt to load the modules listed in
|
|
<filename>/usr/share/shorewall/helpers</filename>. In addition, it sets
|
|
<emphasis role="bold">sip_direct_media=0</emphasis> when loading the
|
|
nf_conntrack_sip module. That setting is somewhat less secure than
|
|
<emphasis role="bold">sip_direct_media=1</emphasis>, but it generally
|
|
makes VOIP through the firewall work much better.</para>
|
|
|
|
<para>The modules in <filename>/usr/share/shorewall/helpers</filename> are
|
|
those that are not autoloaded. If your kernel does not support module
|
|
autoloading and you want Shorewall to attempt to load all netfilter
|
|
modules that it might require, then set LOAD_HELPERS_ONLY=No. That will
|
|
cause Shorewall to try to load the modules listed in
|
|
<filename>/usr/share/shorewall/modules</filename>. That file does not set
|
|
<emphasis role="bold">sip_direct_media=0</emphasis>.</para>
|
|
|
|
<para>If you need to modify either
|
|
<filename>/usr/share/shorewall/helpers</filename> or
|
|
<filename>/usr/share/shorewall/modules</filename> then copy the file to
|
|
<filename>/etc/shorewall</filename> and modify the copy.</para>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF"/></para>
|
|
|
|
<para>Modify the setting of LOAD_HELPER_ONLY as necessary.</para>
|
|
|
|
<important>
|
|
<para>In Shorewall 5.2.3, the LOAD_HELPERS_ONLY option was removed, and
|
|
the behavior is the same as if LOAD_HELPERS_ONLY=Yes was
|
|
specified.</para>
|
|
</important>
|
|
</section>
|
|
|
|
<section id="DNAT">
|
|
<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><link
|
|
linkend="SNAT">SNAT</link></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>For forwarding connections from the <emphasis>net</emphasis> zone to
|
|
a server in the <emphasis>loc</emphasis> zone, 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 DPORT
|
|
DNAT net loc:<emphasis><server local ip address></emphasis>[:<emphasis><server port></emphasis>] <emphasis><protocol></emphasis> <emphasis><port></emphasis></programlisting><important>
|
|
<para><emphasis role="bold">If you want to forward traffic from the
|
|
<emphasis>loc</emphasis> zone to a server in the
|
|
<emphasis>loc</emphasis> zone, see <ulink url="FAQ.htm#faq2">Shorewall
|
|
FAQ 2</ulink>.</emphasis></para>
|
|
</important><important>
|
|
<para>Be sure to add your rules after the line that reads <emphasis
|
|
role="bold">SECTION NEW.</emphasis></para>
|
|
</important><important>
|
|
<para>The server must have a static IP address. If you assign IP
|
|
addresses to your local system using DHCP, you need to configure your
|
|
DHCP server to always assign the same IP address to systems that are
|
|
the target of a DNAT rule.</para>
|
|
</important>Shorewall has <ulink url="Macros.html">macros</ulink> for
|
|
many popular applications. Look at the output of <command>shorewall show
|
|
macros</command> to see what is available in your release. Macros simplify
|
|
creating DNAT rules by supplying the protocol and port(s) as shown in the
|
|
following examples.</para>
|
|
|
|
<para><example id="Example1" label="1">
|
|
<title>Web Server</title>
|
|
|
|
<para>You run a Web Server on computer 2 in <link
|
|
linkend="Diagram">the above diagram</link> and you want to forward
|
|
incoming <acronym>TCP</acronym> port 80 to that system:
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
Web(DNAT) net loc:10.10.10.2</programlisting></para>
|
|
</example> <example id="Example2" label="2">
|
|
<title>FTP Server</title>
|
|
|
|
<para>You run an <acronym>FTP</acronym> Server on <link
|
|
linkend="Diagram">computer 1</link> so you want to forward incoming
|
|
<acronym>TCP</acronym> port 21 to that system: <programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
FTP(DNAT) net loc:10.10.10.1</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
|
|
(<filename>nf_conntrack_ftp</filename> and
|
|
<filename>nf_nat_ftp</filename> in later 2.6 kernels) 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>. See the <ulink
|
|
url="FTP.html">Shorewall FTP documentation</ulink> for more
|
|
information.</para>
|
|
</example> A couple of important points to keep in mind: <itemizedlist>
|
|
<listitem>
|
|
<para>The Shorewall-provided macros assume that the service is using
|
|
its standard port and will not work with a service listening on a
|
|
non-standard port.</para>
|
|
</listitem>
|
|
|
|
<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 DPORT
|
|
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>
|
|
|
|
<important>
|
|
<para>When testing DNAT rules like those shown above, you must test from
|
|
a client OUTSIDE YOUR FIREWALL (in the 'net' zone). You cannot test
|
|
these rules from inside the firewall!</para>
|
|
|
|
<para>For DNAT troubleshooting tips, <ulink url="FAQ.htm#faq1a">see FAQs
|
|
1a and 1b</ulink>.</para>
|
|
</important>
|
|
|
|
<para>For information about DNAT when there are multiple external IP
|
|
addresses, see the <ulink
|
|
url="Shorewall_and_Aliased_Interfaces.html">Shorewall Aliased Interface
|
|
documentation</ulink> and the <ulink
|
|
url="shorewall_setup_guide.htm#dnat">Shorewall Setup Guide</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="DNS">
|
|
<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 DPORT
|
|
DNS(ACCEPT)loc $FW</programlisting></para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
</section>
|
|
|
|
<section id="Open">
|
|
<title>Other Connections</title>
|
|
|
|
<para>The two-interface sample includes the following rules:
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
DNS(ACCEPT) $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>DNS</quote>(ACCEPT)is an example of
|
|
a <emphasis>macro invocation</emphasis>. Shorewall includes a number of
|
|
macros (command <emphasis role="bold">shorewall show macros</emphasis>)
|
|
and <ulink url="Macros.html">you can add your own</ulink>.</para>
|
|
|
|
<para>You don't have to use defined macros when coding a rule in
|
|
<filename>/etc/shorewall/rules</filename>; Shorewall will start slightly
|
|
faster if you code your rules directly rather than using macros. The the
|
|
rule shown above could also have been coded as follows:<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
ACCEPT $FW net udp 53
|
|
ACCEPT $FW net tcp 53</programlisting></para>
|
|
|
|
<para>In cases where Shorewall doesn't include a defined macro to meet
|
|
your needs, you can either define the macro yourself or you can simply
|
|
code the appropriate rules directly.</para>
|
|
|
|
<para>The sample also includes: <programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
SSH(ACCEPT) 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 a macro is: <programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
<macro>(ACCEPT) $FW <emphasis><destination zone></emphasis></programlisting>The
|
|
general format when not using defined macros is:<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
ACCEPT $FW <emphasis><destination zone> <protocol> <port></emphasis></programlisting><example
|
|
id="Example3">
|
|
<title>Web Server on Firewall</title>
|
|
|
|
<para>You want to run a Web Server on your firewall system:
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT
|
|
Web(ACCEPT) net $FW
|
|
Web(ACCEPT) 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 DPORT
|
|
SSH(ACCEPT) 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 DPORT
|
|
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 id="Other">
|
|
<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 id="Starting">
|
|
<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 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 must edit /etc/shorewall/shorewall.conf and set
|
|
STARTUP_ENABLED=Yes.<graphic align="left"
|
|
fileref="images/openlogo-nd-25.png"/><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> While you are editing <filename>shorewall.conf</filename>,
|
|
it is a good idea to check the value of the SUBSYSLOCK option. You can
|
|
find a description of this option by typing 'man shorewall.conf' at a
|
|
shell prompt and searching for SUBSYSLOCK.</para>
|
|
|
|
<para>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="manpages/shorewall-routestopped.html">routestopped</ulink></filename>
|
|
(Shorewall 4.5.7 and earlier) or in<filename> <ulink
|
|
url="manpages/shorewall-stoppedrules.html">/etc/shorewall/stoppedrules</ulink></filename>.
|
|
A running firewall may be restarted using the <quote><command>shorewall
|
|
reload</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 either:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Used ADMINISABSENTMINDED=Yes in
|
|
<filename>/etc/shorewall/shorewall.conf</filename>; or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>added an entry for the <acronym>IP</acronym> address that
|
|
you are connected from to <filename
|
|
class="directory">/etc/shorewall/</filename><filename>routestopped</filename>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Also, I don't recommend using <quote><command>shorewall
|
|
reload</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>
|
|
|
|
<para>The firewall will start after your network interfaces have been
|
|
brought up. This leaves a small window between the time that the network
|
|
interfaces are working and when the firewall is controlling connections
|
|
through those interfaces. If this is a concern, you can close that window
|
|
by installing the <ulink url="Shorewall-init.html">Shorewall Init
|
|
Package</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="Trouble">
|
|
<title>If it Doesn't Work</title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Re-check each of the items flagged with a red arrow
|
|
above.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Check your <ulink
|
|
url="shorewall_logging.html">log</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Check the <ulink url="troubleshoot.htm">Troubleshooting
|
|
Guide</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Check the <ulink url="FAQ.htm">FAQ</ulink>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Disabling your existing Firewall</title>
|
|
|
|
<para>Before starting Shorewall for the first time, it's a good idea to
|
|
stop your existing firewall. On older Redhat/CentOS/Fedora:</para>
|
|
|
|
<programlisting><command>service iptables stop</command></programlisting>
|
|
|
|
<para>On recent Fedora systems that run systemd, the command is:</para>
|
|
|
|
<programlisting><command>systemctl stop iptables.service</command></programlisting>
|
|
|
|
<para>If you are running SuSE, use Yast or Yast2 to stop
|
|
SuSEFirewall.</para>
|
|
|
|
<para>On other systems that use a classic SysV init system:</para>
|
|
|
|
<programlisting><command>/etc/init.d/iptables stop</command></programlisting>
|
|
|
|
<para>Once you have Shorewall running to your satisfaction, you should
|
|
totally disable your existing firewall. On older
|
|
Redhat/CentOS/Fedora:</para>
|
|
|
|
<programlisting><command>chkconfig --del iptables</command></programlisting>
|
|
|
|
<para>On Debian systems:</para>
|
|
|
|
<programlisting><command>update-rc.d iptables disable</command></programlisting>
|
|
|
|
<para>On recent Fedora system running systemd:</para>
|
|
|
|
<programlisting><command>systemctl disable iptables.service</command></programlisting>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif"/></para>
|
|
|
|
<para>At this point, disable your existing firewall service.</para>
|
|
</section>
|
|
|
|
<section id="Reading">
|
|
<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. Also, <ulink
|
|
url="starting_and_stopping_shorewall.htm">Operating Shorewall and
|
|
Shorewall Lite</ulink> contains a lot of useful operational hints.</para>
|
|
</section>
|
|
|
|
<section id="Wireless">
|
|
<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>
|
|
|
|
<para><emphasis role="bold">Update</emphasis>: Distributions are
|
|
getting better about this. <trademark>SuSE</trademark> now associates
|
|
a unique interface name with each MAC address. Other distributions
|
|
have add-on packages to manage the relationship between MAC addresses
|
|
and device names.</para>
|
|
</caution></para>
|
|
|
|
<para>Your new network will look similar to what is shown in the following
|
|
figure.<graphic align="center" 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 OPTIONS
|
|
loc wlan0 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 may need to add an entry to the
|
|
<filename>/etc/shorewall/masq</filename> file to masquerade traffic
|
|
from the wireless network to the Internet. If you file looks like
|
|
this:</para>
|
|
|
|
<programlisting>#INTERFACE SOURCE ADDRESS PROTO DPORT IPSEC MARK
|
|
eth0 10.0.0.0/8,\
|
|
169.254.0.0/16,\
|
|
172.16.0.0/12,\
|
|
192.168.0.0/16
|
|
</programlisting>
|
|
|
|
<para>or of you are running Shorewall 5.0.14 or later, then you do
|
|
<emphasis role="bold">not</emphasis> need to change the
|
|
contents.</para>
|
|
|
|
<para>Otherwise, 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 SOURCE ADDRESS
|
|
eth0 10.10.11.0/24</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>
|