holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity
d6262099c6
shorewall_code/STABLE/documentation/Documentation.htm
teastep e70a63f267 Shorewall-1.4.4a 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@573 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-05-28 19:20:23 +00:00

3017 lines
174 KiB
HTML
Raw Blame History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Shorewall 1.4 Documentation</title>
<base
target="_self">
<meta name="Microsoft Theme" content="none, default">
<meta name="Microsoft Border" content="none, default">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall 1.4 Reference</font></h1>
</td>
</tr>
</tbody>
</table>
<h2 align="center">This documentation is intended primarily for reference.
Step-by-step instructions for configuring Shorewall
in common setups may be found in the <a
href="shorewall_quickstart_guide.htm">QuickStart Guides</a>.</h2>
<h2>Components</h2>
<p>Shorewall consists of the following components: </p>
<ul>
<li><b><a href="#Variables">params</a></b>
-- a parameter file installed in /etc/shorewall that
can be used to establish the values of shell variables
for use in other files.</li>
<li><b> <a href="#Conf">shorewall.conf</a></b>
-- a parameter file installed in /etc/shorewall
that is used to set several firewall parameters.</li>
<li><b> <a href="#Zones">zones</a></b>
- a parameter file installed in /etc/shorewall that defines
a network partitioning into "zones"</li>
<li><b> <a
href="#Policy">policy</a></b> -- a parameter file installed
in /etc/shorewall/ that establishes overall firewall policy.</li>
<li><b> <a href="#Rules">rules</a>
</b> -- a parameter file installed in /etc/shorewall
and used to express firewall rules that are exceptions
to the high-level policies established in /etc/shorewall/policy.</li>
<li><b><a href="#Blacklist">blacklist</a>
-- </b>a parameter file installed in /etc/shorewall
and used to list blacklisted IP/subnet/MAC addresses.</li>
<li><b><a href="#ECN">ecn</a></b> -- a parameter file installed
in /etc/shorewall and used to selectively disable Explicit Congestion
Notification (ECN - RFC 3168).<br>
</li>
<li><b> functions</b> -- a
set of shell functions used by both the firewall and
shorewall shell programs. Installed in /etc/shorewall prior
to version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8
and in /usr/lib/shorewall in later versions.</li>
<li><b> <a
href="#modules">modules</a></b> -- a parameter file installed
in /etc/shorewall and that specifies kernel modules and their
parameters. Shorewall will automatically load the modules
specified in this file.</li>
<li><a href="#TOS"><b> tos</b> </a>-- a parameter file installed
in /etc/shorewall that is used to specify how the Type
of Service (TOS) field in packets is to be set.<br>
</li>
<li><b><a href="#Scripts">common.def</a></b>
-- a parameter file installed in in /etc/shorewall
that defines firewall-wide rules that are applied before a
DROP or REJECT policy is applied.</li>
<li><b> <a
href="#Interfaces">interfaces</a> </b> -- a parameter
file installed in /etc/shorewall/ and used to describe the
interfaces on the firewall system.</li>
<li><a href="#Hosts"><b> hosts</b>
</a>-- a parameter file installed in /etc/shorewall/
and used to describe individual hosts or subnetworks
in zones.</li>
<li><b><a href="#Maclist">maclist</a>
</b>-- a parameter file installed in /etc/shorewall and
used to verify the MAC address (and possibly also the IP address(es))
of devices.<br>
</li>
<li><b> <a href="#Masq">masq</a></b>
- This file also describes IP masquerading under Shorewall
and is installed in /etc/shorewall.</li>
<li><b><a
href="shorewall_firewall_structure.htm">firewall</a></b> -- a shell
program that reads the configuration files in /etc/shorewall
and configures your firewall. This file is installed
in your init.d directory (/etc/rc.d/init.d ) where
it is renamed <i>shorewall.</i> /etc/shorewall/firewall
(/var/lib/shorewall/firewall in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall
in 1.3.9 and later) is a symbolic link to this program.</li>
<li><b> <a href="#NAT">nat</a></b>
-- a parameter file in /etc/shorewall used to define <a
href="#NAT"> static NAT</a> .</li>
<li><b> <a
href="#ProxyArp">proxyarp</a></b> -- a parameter file in
/etc/shorewall used to define <a href="#ProxyArp"> Proxy Arp</a>
.</li>
<li><b><a href="#rfc1918">rfc1918</a></b>
-- a parameter file in /etc/shorewall used to define the
treatment of packets under the <a href="#Interfaces">norfc1918
interface option</a>.</li>
<li><b><a
href="#Routestopped">routestopped</a></b> -- a parameter
file in /etc/shorewall used to define those hosts that can
access the firewall when Shorewall is stopped.</li>
<li><a
href="traffic_shaping.htm#tcrules"><b>tcrules</b> </a>-- a
parameter file in /etc/shorewall used to define rules for classifying
packets for <a href="traffic_shaping.htm">Traffic Shaping/Control</a>.</li>
<li><b> <a
href="#Tunnels">tunnels</a></b> -- a parameter file in
/etc/shorewall used to define IPSec tunnels.</li>
<li><b> <a
href="#Starting">shorewall</a> </b> -- a shell program
(requiring a Bourne shell or derivative) used to
control and monitor the firewall. This should be placed in
/sbin or in /usr/sbin (the install.sh script and the
rpm install this file in /sbin).</li>
<li><b> version</b> -- a
file created in /etc/shorewall/ (/var/lib/shorewall
in version 1.3.2-1.3.8 and /usr/lib/shorewall beginning
in version 1.3.9) that describes the version of Shorewall
installed on your system.</li>
</ul>
<h2><a name="Variables"></a> /etc/shorewall/params</h2>
<p>You may use the file /etc/shorewall/params file to set shell variables
that you can then use in some of the other configuration
files.</p>
<p>It is suggested that variable names begin with an upper case letter<font
size="1"> </font>to distinguish them from variables used internally
within the Shorewall programs</p>
<p>Example:</p>
<pre><font face="Courier"> NET_IF=eth0<br> NET_BCAST=130.252.100.255<br> NET_OPTIONS=blacklist,norfc1918</font></pre>
<p>Example (/etc/shorewall/interfaces record):</p>
<pre> <font face="Courier">net $NET_IF $NET_BCAST $NET_OPTIONS</font></pre>
<p>The result will be the same as if the record had been written</p>
<pre> <font face="Courier">net eth0 130.252.100.255 blacklist,norfc1918</font></pre>
<p>Variables may be used anywhere in the other configuration
files.</p>
<h2><b><a name="Zones"></a> </b>/etc/shorewall/zones</h2>
<p>This file is used to define the network zones. There is one entry
in /etc/shorewall/zones for each zone; Columns in an
entry are:</p>
<ul>
<li><b> ZONE</b> - short name
for the zone. The name should be 5 characters or less in
length (4 characters or less if you are running Shorewall 1.4.4 or
later) and consist of lower-case letters or numbers. Short names
must begin with a letter and the name assigned to the firewall
is reserved for use by Shorewall itself. Note that the output
produced by iptables is much easier to read if you select
short names that are three characters or less in length. The
name "all" may not be used as a zone name nor may the zone name
assigned to the firewall itself via the FW variable in <a
href="#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b> DISPLAY</b> - The
name of the zone as displayed during Shorewall startup.</li>
<li><b> COMMENTS</b> - Any
comments that you want to make about the zone. Shorewall
ignores these comments.</li>
</ul>
<p>The /etc/shorewall/zones file released with Shorewall is as follows:</p>
<table border="1" style="border-collapse: collapse;" cellpadding="2">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> DISPLAY</b></td>
<td><b> COMMENTS</b></td>
</tr>
<tr>
<td>net</td>
<td>Net</td>
<td>Internet</td>
</tr>
<tr>
<td>loc</td>
<td>Local</td>
<td>Local networks</td>
</tr>
<tr>
<td>dmz</td>
<td>DMZ</td>
<td>Demilitarized zone</td>
</tr>
</tbody>
</table>
<p>You may add, delete and modify entries in the /etc/shorewall/zones file
as desired so long as you have at least one zone defined.</p>
<p><b><font size="5" color="#ff0000"> Warning 1: </font><font
color="#ff0000"> If you rename or delete a zone, you should perform "shorewall
stop; shorewall start" to install the change rather
than "shorewall restart".</font></b></p>
<p><b><font size="5" color="#ff0000">Warning 2: </font><font
color="#ff0000">The order of entries in the /etc/shorewall/zones file is
significant <a href="#Nested">in some cases</a>.</font></b></p>
<h2><font color="#660066"><a name="Interfaces"></a> </font>/etc/shorewall/interfaces</h2>
<p>This file is used to tell the firewall which of your firewall's network
interfaces are connected to which zone. There will
be one entry in /etc/shorewall/interfaces for each of your
interfaces. Columns in an entry are:</p>
<ul>
<li><b> ZONE</b> - A zone
defined in the <a href="#Zones">/etc/shorewall/zones</a>
file or "-". If you specify "-", you must use the
<a href="#Hosts"> /etc/shorewall/hosts</a> file to
define the zones accessed via this interface.</li>
<li><b> INTERFACE</b> - the
name of the interface (examples: eth0, ppp0, ipsec+).
Each interface can be listed on only one record in this file.
<font color="#ff0000"><b>D</b><b>O NOT INCLUDE THE LOOPBACK
INTERFACE (lo) IN THIS FILE!!!</b></font></li>
<li><b> BROADCAST</b> - the
broadcast address(es) for the sub-network(s) attached
to the interface. This should be left empty for P-T-P interfaces
(ppp*, ippp*); if you need to specify options for such an
interface, enter "-" in this column. If you supply the special
value "detect" in this column, the firewall will automatically
determine the broadcast address. In order to use "detect":
<ul>
<li>the interface must be up before you start your firewall</li>
<li>the interface must only
be attached to a single sub-network (i.e., there must
have a single broadcast address). </li>
</ul>
</li>
<li><b> OPTIONS</b> - a comma-separated
list of options. Possible options include:<br>
<br>
<b>routeback </b>(Added in version 1.4.2) - This option causes
Shorewall to set up handling for routing packets that arrive on this interface
back out the same interface. If this option is specified, the ZONE column
may not contain "-".<br>
<p> <b>tcpflags </b>(added in version 1.3.11) - This option causes
Shorewall to make sanity checks on the header flags in TCP packets arriving
on this interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH;
these flag combinations are typically used for "silent" port scans. Packets
failing these checks are logged according to the TCP_FLAGS_LOG_LEVEL option
in<a href="#Conf"> /etc/shorewall/shorewall.conf</a> and are disposed of
according to the TCP_FLAGS_DISPOSITION option.<br>
<b><br>
blacklist</b> - This option causes incoming
packets on this interface to be checked against
the <a href="#Blacklist">blacklist</a>.<b><br>
<br>
dhcp</b> - The interface is assigned
an IP address via DHCP or is used by a DHCP server
running on the firewall. The firewall will be configured
to allow DHCP traffic to and from the interface even
when the firewall is stopped. You may also wish to use this option
if you have a static IP but you are on a LAN segment that has
a lot of Laptops that use DHCP and you select the <b>norfc1918
</b>option (see below).</p>
<p> <b>norfc1918</b> - Packets arriving on this interface and that
have a source address that is reserved in RFC 1918 or in other
RFCs will be dropped after being optionally logged. If
<a href="#Conf">packet mangling is enabled in /etc/shorewall/shorewall.conf</a>
, then packets arriving on this interface that have
a destination address that is reserved by one of these RFCs
will also be logged and dropped.<br>
<br>
Addresses blocked by the standard
<a href="#rfc1918"> <b>rfc1918 </b>file</a> include
those addresses reserved by RFC1918 plus other ranges reserved
by the IANA or by other RFCs.</p>
<p> Beware that as IPv4 addresses become in increasingly short supply,
ISPs are beginning to use RFC 1918 addresses within
their own infrastructure. Also, many cable and DSL "modems"
have an RFC 1918 address that can be used through a web browser
for management and monitoring functions. If you want to specify
<b>norfc1918</b> on your external interface but need to
allow access to certain addresses from the above list, see
<a href="FAQ.htm#faq14">FAQ 14.</a></p>
<p> <b> routefilter</b> - Invoke the Kernel's route filtering
(anti-spoofing) facility on this interface. The kernel
will reject any packets incoming on this interface that
have a source address that would be routed outbound through
another interface on the firewall. <font
color="#ff0000">Warning: </font>If you specify this option
for an interface then the interface must be up prior to starting
the firewall.</p>
<p> <b>dropunclean</b> - Packets from this interface that
are selected by the 'unclean' match target in iptables will
be <a href="#LogUnclean">optionally logged</a> and then dropped.
<font color="#ff0000"><b>Warning: This feature requires
that UNCLEAN match support be configured in your
kernel, either in the kernel itself or as a module. UNCLEAN
support is broken in some versions of the kernel but
appears to work ok in 2.4.17-rc1.<br>
<br>
Update 12/17/2001:
</b></font>The unclean match patch from
2.4.17-rc1 is <a
href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean.patch">available
for download</a>. I am currently running
this patch applied to kernel 2.4.16.</p>
<p><font color="#ff0000"><b>Update 12/20/2001: </b></font>I've
seen a number of tcp connection requests
with OPT (020405B4<u>0000080A</u>...)
being dropped in the <i>badpkt</i> chain. This appears to
be a bug in the remote TCP stack whereby it is 8-byte
aligning a timestamp (TCP option 8) but rather than
padding with 0x01 it is padding with 0x00. It's
a tough call whether to deny people access to your
servers because of this rather minor bug in their
networking software. If you wish to disable the
check that causes these connections to be dropped, <a
href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean1.patch">here's
a kernel patch</a> against 2.4.17-rc2.</p>
<p><b>logunclean </b>- This option works like <b>dropunclean</b>
with the exception that packets selected
by the 'unclean' match target in iptables
are logged <i>but not dropped</i>.
The level at which the packets are logged is determined by
the setting of <a href="#LogUnclean">LOGUNCLEAN</a> and
if LOGUNCLEAN has not been set, "info" is assumed.</p>
<p><b>proxyarp </b>(Added in version 1.3.5) - This option causes
Shorewall to set /proc/sys/net/ipv4/conf/<i>&lt;interface&gt;</i>/proxy_arp
and is used when implementing Proxy
ARP Sub-netting as described at
<a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">
http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>. Do
<u> not</u> set this option if you are implementing
Proxy ARP through entries in <a
href="#ProxyArp"> /etc/shorewall/proxyarp</a>.<br>
<br>
<b>maclist</b> (Added in version
1.3.10) - If this option is specified, all connection requests
from this interface are subject to <a
href="MAC_Validation.html">MAC Verification</a>. May only be specified
for ethernet interfaces.</p>
</li>
</ul>
<p>My recommendations concerning options:<br>
</p>
<ul>
<li>External Interface -- <b>tcpflags,blacklist,norfc1918,routefilter</b></li>
<li>Wireless Interface -- <b>maclist,routefilter,tcpflags</b><br>
</li>
<li>Don't use <b>dropunclean</b> -- It's
broken in my opinion</li>
<li>Use <b>logunclean</b> only when you
are trying to debug a problem</li>
<li>Use <b>dhcp </b>and <b>proxyarp</b>
when needed.<br>
</li>
</ul>
<p> </p>
<p>Example 1: You have a conventional firewall setup in which eth0 connects
to a Cable or DSL modem and eth1 connects to your local
network and eth0 gets its IP address via DHCP. You want
to check all packets entering from the internet against the
<a href="#Blacklist">black list</a>. Your /etc/shorewall/interfaces
file would be as follows:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918,blacklist</td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>detect</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces
file would be:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>ppp0</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>Example 3: You have local interface eth1 with two IP addresses -
192.168.1.1/24 and 192.168.12.1/24</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>192.168.1.255,192.168.12.255</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<h2><font color="#660066"><a name="Hosts"></a> </font>/etc/shorewall/hosts
Configuration</h2>
<p>For most applications, specifying zones entirely in terms of network
interfaces is sufficient. There may be times though where you need to define
a zone to be a more general collection of hosts. This is the purpose of
the /etc/shorewall/hosts file.</p>
<p><b><font color="#ff0000">WARNING: </font>The only times that you need entries
in /etc/shorewall/hosts are:<br>
</b></p>
<ol>
<li><b>You have more than one zone connecting through a single
interface; or</b></li>
<li><b>You have a zone that has multiple subnetworks that connect
through a single interface and you want the Shorewall box to route traffic
between those subnetworks.</b><br>
</li>
</ol>
<b>IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN DON'T TOUCH
THIS FILE!!</b>
<p>Columns in this file are:</p>
<ul>
<li><b> ZONE </b> - A zone
defined in the <a href="#Zones">/etc/shorewall/zones</a>
file.</li>
<li><b> HOST(S)</b> - The
name of a network interface followed by a colon (":")
followed by either:</li>
</ul>
<blockquote>
<ol>
<li>An IP address
(example - eth1:192.168.1.3)</li>
<li>A subnet
in CIDR notation<i> </i>(example -
eth2:192.168.2.0/24)</li>
</ol>
<p>The interface name much match an entry in /etc/shorewall/interfaces.</p>
</blockquote>
<ul>
<li><b> OPTIONS</b> - A comma-separated
list of option</li>
</ul>
<blockquote>
<p><b>routeback </b>(Added in version 1.4.2) - This option causes Shorewall
to set up handling for routing packets sent by this host group back back
to the same group.<b><br>
<br>
maclist - </b>Added in version 1.3.10. If specified, connection
requests from the hosts specified in this entry are subject
to <a href="MAC_Validation.html">MAC Verification</a>. This option is
only valid for ethernet interfaces.<br>
</p>
</blockquote>
<p>If you don't define any hosts for a zone, the hosts in the zone default
to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ...
are the interfaces to the zone.</p>
<p><b><font size="4" color="#ff0000">Note: </font></b> You probably DON'T
want to specify any hosts for your internet zone since the hosts
that you specify will be the only ones that you will be able to access
without adding additional rules.</p>
<p>Example 1:</p>
<p>Your local interface is eth1 and you have two groups of local hosts that
you want to make into separate zones:</p>
<ul>
<li>192.168.1.0/25 </li>
<li>192.168.1.128/</li>
</ul>
<p>Your /etc/shorewall/interfaces file might look like:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918</td>
</tr>
<tr>
<td>-</td>
<td>eth1</td>
<td>192.168.1.127,192.168.1.255<br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces
to multiple zones.</p>
<p> Your /etc/shorewall/hosts file might look like:</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica">
</font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>loc1</td>
<td>eth1:192.168.1.0/25</td>
<td> <br>
</td>
</tr>
<tr>
<td>loc2</td>
<td>eth1:192.168.1.128/25</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>Example 2:</p>
<p>Your local interface is eth1 and you have two groups of local hosts that
you want to consider as one zone and you want Shorewall to route between
them:</p>
<ul>
<li>192.168.1.0/25 </li>
<li>192.168.1.128/25</li>
</ul>
<p> Your /etc/shorewall/interfaces file might look like:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918</td>
</tr>
<tr>
<td>loc<br>
</td>
<td>eth1</td>
<td>192.168.1.127,192.168.1.255<br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Your /etc/shorewall/hosts file might look like:</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica">
</font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>loc</td>
<td>eth1:192.168.1.0/25</td>
<td> <br>
</td>
</tr>
<tr>
<td>loc</td>
<td>eth1:192.168.1.128/25</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<h4><font color="#660066"><a name="Nested"></a> Nested and Overlapping Zones</font></h4>
<p> The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow
you to define nested or overlapping zones. Such overlapping/nested zones
are allowed and Shorewall processes zones in the order
that they appear in the /etc/shorewall/zones file. So if
you have nested zones, you want the sub-zone to appear before
the super-zone and in the case of overlapping zones, the rules
that will apply to hosts that belong to both zones is determined
by which zone appears first in /etc/shorewall/zones.</p>
<p> Hosts that belong to more than one zone may be managed by the rules
of all of those zones. This is done through use of the
special <a href="#CONTINUE">CONTINUE policy</a> described below.</p>
<h2><font color="#660066"><a name="Policy"></a> </font>/etc/shorewall/policy
Configuration.</h2>
<p>This file is used to describe the firewall policy regarding establishment
of connections. Connection establishment is described
in terms of <i>clients</i> who initiate connections and <i>
servers </i>who receive those connection requests. Policies
defined in /etc/shorewall/policy describe which zones are
allowed to establish connections with other zones.</p>
<p>Policies established in /etc/shorewall/policy can be viewed as default
policies. If no rule in /etc/shorewall/rules applies
to a particular connection request then the policy from /etc/shorewall/policy
is applied.</p>
<p>Four policies are defined:</p>
<ul>
<li><b> ACCEPT</b> - The connection
is allowed.</li>
<li><b> DROP</b> - The connection
request is ignored.</li>
<li><b> REJECT</b> - The connection
request is rejected with an RST (TCP) or an ICMP destination-unreachable
packet being returned to the client.</li>
<li><b> CONTINUE </b> - The
connection is neither ACCEPTed, DROPped nor REJECTed.
CONTINUE may be used when one or both of the zones named
in the entry are sub-zones of or intersect with another zone.
For more information, see below.</li>
<li><b>NONE</b> - (Added in version 1.4.1) - Shorewall should
not set up any infrastructure for handling traffic from the SOURCE zone
to the DEST zone. When this policy is specified, the <b>LOG LEVEL </b>and
<b>BURST:LIMIT </b>columns must be left blank.<br>
</li>
</ul>
<p> For each policy specified in /etc/shorewall/policy, you can indicate
that you want a message sent to your system log each
time that the policy is applied.</p>
<p> Entries in /etc/shorewall/policy have four columns as follows:</p>
<ol>
<li>
<b> SOURCE</b> - The name of a client zone (a zone
defined in the <a href="#Zones"> /etc/shorewall/zones
file</a> , the <a href="#Conf">name of the firewall zone</a>
or "all").</li>
<li>
<b> DEST</b> - The name of a destination zone (a zone
defined in the <a href="#Zones"> /etc/shorewall/zones file</a>
, the <a href="#Conf">name of the firewall zone</a> or "all").
Shorewall automatically allows all traffic from the firewall to
itself so the <a href="#Conf">name of the firewall zone</a> cannot
appear in both the SOURCE and DEST columns.</li>
<li>
<b> POLICY</b> - The default policy for connection
requests from the SOURCE zone to the DESTINATION zone.</li>
<li>
<b> LOG LEVEL</b> - Optional. If left empty, no log
message is generated when the policy is applied. Otherwise,
this column should contain an integer or name indicating
a <a href="shorewall_logging.html">syslog level</a>.</li>
<li>
<b>LIMIT:BURST </b>- Optional. If left empty,
TCP connection requests from the <b>SOURCE</b> zone to the
<b>DEST</b> zone will not be rate-limited. Otherwise, this
column specifies the maximum rate at which TCP connection
requests will be accepted followed by a colon (":") followed
by the maximum burst size that will be tolerated. Example:
<b> 10/sec:40</b> specifies that the maximum rate of TCP
connection requests allowed will be 10 per second and a burst
of 40 connections will be tolerated. Connection requests in excess
of these limits will be dropped.</li>
</ol>
<p> In the SOURCE and DEST columns, you can enter "all" to indicate all
zones. </p>
<p> The policy file installed by default is as follows:</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica">
</font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> POLICY</b></td>
<td><b> LOG LEVEL</b></td>
<td><b>LIMIT:BURST</b></td>
</tr>
<tr>
<td>loc</td>
<td>net</td>
<td>ACCEPT</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td> <br>
</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> This table may be interpreted as follows:</p>
<ul>
<li>All connection requests
from the local network to hosts on the internet
are accepted.</li>
<li>All connection requests
originating from the internet are ignored and logged
at level KERNEL.INFO.</li>
<li>All other connection requests
are rejected and logged.</li>
</ul>
<p><b><font size="4" color="#ff0000">WARNING:</font></b></p>
<p><font color="#ff0000"><b> The firewall script processes</b> <b> the
/etc/shorewall/policy file from top to bottom and <u>uses
the first applicable policy that it finds.</u> For example,
in the following policy file, the policy for (loc, loc) connections
would be ACCEPT as specified in the first entry even though
the third entry in the file specifies REJECT.</b></font></p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>POLICY</b></td>
<td><b>LOG LEVEL</b></td>
<td><b>LIMIT:BURST</b></td>
</tr>
<tr>
<td>loc</td>
<td>all</td>
<td>ACCEPT</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td> <br>
</td>
</tr>
<tr>
<td>loc</td>
<td>loc</td>
<td>REJECT</td>
<td>info</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<h4><a name="IntraZone"></a>IntraZone Traffic</h4>
Shorewall allows a zone to be associated with more than one interface
or with multiple networks that interface through a single interface.
Beginning with Shorewall 1.4.1, Shorewall will ACCEPT all traffic from
a zone to itself provided that there is no explicit policy governing traffic
from that zone to itself (an explicit policy does not specify "all" in
either the SOURCE or DEST column) and that there are no rules concerning
connections from that zone to itself. If there is an explicit policy or
if there are one or more rules, then traffic within the zone is handled
just like traffic between zones is.<br>
<p>Any time that you have multiple interfaces associated with a single zone,
you should ask yourself if you really want traffic routed between those
interfaces. Cases where you might not want that behavior are:<br>
</p>
<ol>
<li>Multiple 'net' interfaces to different ISPs. You don't want
to route traffic from one ISP to the other through your firewall.</li>
<li>Multiple VPN clients. You don't necessarily want them to all
be able to communicate between themselves using your gateway/router.<br>
</li>
</ol>
<h4><font color="#660066"><a name="CONTINUE"></a> The CONTINUE
policy</font></h4>
<p> Where zones are <a href="#Nested">nested or overlapping</a> , the
CONTINUE policy allows hosts that are within multiple
zones to be managed under the rules of all of these zones.
Let's look at an example:</p>
<p> /etc/shorewall/zones:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> DISPLAY</b></td>
<td><b> COMMENTS</b></td>
</tr>
<tr>
<td>sam</td>
<td>Sam</td>
<td>Sam's system at home</td>
</tr>
<tr>
<td>net</td>
<td>Internet</td>
<td>The Internet</td>
</tr>
<tr>
<td>loc</td>
<td>Loc</td>
<td>Local Network</td>
</tr>
</tbody>
</table>
</blockquote>
<p> /etc/shorewall/interfaces:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>-</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918</td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>detect</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> /etc/shorewall/hosts:</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0:0.0.0.0/0</td>
<td> <br>
</td>
</tr>
<tr>
<td>sam</td>
<td>eth0:206.191.149.197</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Note that Sam's home system is a member of both the <b>sam</b> zone
and the <b>net</b>
zone and <a href="#Nested"> as described above</a> , that
means that <b>sam</b> must be listed before <b>net</b> in /etc/shorewall/zones.</p>
<p> /etc/shorewall/policy:</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> SOURCE</b></td>
<td><b> DEST</b></td>
<td><b> POLICY</b></td>
<td><b> LOG LEVEL</b></td>
</tr>
<tr>
<td>loc</td>
<td>net</td>
<td>ACCEPT</td>
<td> <br>
</td>
</tr>
<tr>
<td>sam</td>
<td>all</td>
<td>CONTINUE</td>
<td> <br>
</td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
</tr>
</tbody>
</table>
</blockquote>
<p> The second entry above says that when Sam is the client, connection
requests should first be process under rules where the
source zone is <b>sam</b> and if there is no match then the
connection request should be treated under rules where the
source zone is <b>net</b>. It is important that this policy
be listed BEFORE the next policy (<b>net</b> to <b>all</b>).</p>
<p> Partial /etc/shorewall/rules:</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td> <br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>loc:192.168.1.5</td>
<td>tcp</td>
<td>www</td>
<td>-</td>
<td> <br>
</td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Given these two rules, Sam can connect to the firewall's internet interface
with ssh and the connection request will be forwarded
to 192.168.1.3. Like all hosts in the <b>net</b> zone, Sam
can connect to the firewall's internet interface on TCP
port 80 and the connection request will be forwarded to 192.168.1.5.
The order of the rules is not significant.</p>
<p> <a name="Exclude"></a>Sometimes it is necessary to suppress port forwarding
for a sub-zone. For example, suppose that all hosts
can SSH to the firewall and be forwarded to 192.168.1.5
EXCEPT Sam. When Sam connects to the firewall's external IP,
he should be connected to the firewall itself. Because of the
way that Netfilter is constructed, this requires two rules as
follows:</p>
<blockquote>
<p> </p>
<font face="Century Gothic, Arial, Helvetica">
</font><font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>fw</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td> <br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>net!sam</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td> <br>
</td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>The first rule allows Sam SSH access to the firewall. The second
rule says that any clients from the net zone
with the exception of those in the 'sam'
zone should have their connection
port forwarded to 192.168.1.3. If
you need to exclude more than
one zone in this way, you
can list the zones separated by commas
(e.g., net!sam,joe,fred). This technique also
may be used when the ACTION is REDIRECT.</p>
<h2><font color="#660066"><a name="Rules"></a> </font>/etc/shorewall/rules</h2>
<p>The /etc/shorewall/rules file defines exceptions to the policies established
in the /etc/shorewall/policy file. There is one entry
in /etc/shorewall/rules for each of these rules. <br>
</p>
<p>Shorewall automatically enables firewall-&gt;firewall traffic over the
loopback interface (lo) -- that traffic cannot be regulated
using rules and any rule that tries to regulate such traffic
will generate a warning and will be ignored.<br>
</p>
<p>Entries in the file have the following columns:</p>
<ul>
<li><b>ACTION</b>
<ul>
<li>ACCEPT, DROP, REJECT,
CONTINUE. These have the same meaning here as in the
policy file above.</li>
<li>DNAT -- Causes the connection
request to be forwarded to the system specified in
the DEST column (port forwarding). "DNAT" stands for "<u>D</u>estination
<u>N</u>etwork <u>A</u>ddress <u>T</u>ranslation"</li>
<li>DNAT- -- The above ACTION (DNAT) generates
two iptables rules: 1) and header-rewriting rule in the Netfilter
'nat' table and; 2) an ACCEPT rule in the Netfilter 'filter' table.
DNAT- works like DNAT but only generates the header-rewriting rule.<br>
</li>
<li>REDIRECT -- Causes the
connection request to be redirected to a port on the
local (firewall) system.</li>
<li>REDIRECT- -- The above ACTION (REDIRECT) generates two iptables
rules: 1) and header-rewriting rule in the Netfilter 'nat' table
and; 2) an ACCEPT rule in the Netfilter 'filter' table. REDIRECT-
works like REDIRECT but only generates the header-rewriting rule.<br>
</li>
<li>LOG - Log the packet -- requires a syslog level (see
below).</li>
</ul>
<p>The ACTION may optionally be followed by ":" and a <a
href="shorewall_logging.html">syslog level</a> (example: REJECT:info). This
causes the packet to be logged at the specified level prior to being
processed according to the specified ACTION. Note: if the ACTION
is LOG then you MUST specify a syslog level.<br>
<br>
The use of DNAT or REDIRECT
requires that you have <a href="#NatEnabled">NAT enabled</a>.<br>
</p>
</li>
<li><b>SOURCE</b> - Describes
the source hosts to which the rule applies.. The contents
of this field must begin with the name of a zone defined
in /etc/shorewall/zones, $FW or "all". If the ACTION is
DNAT or REDIRECT, sub-zones may be excluded from the rule by
following the initial zone name with "!' and a comma-separated
list of those sub-zones to be excluded. There is an <a
href="#Exclude">example</a> above.<br>
<br>
If the source is not 'all' then
the source may be further restricted by adding a colon (":")
followed by a comma-separated list of qualifiers. Qualifiers
are may include:
<ul>
<li>An interface name - refers
to any connection requests arriving on the specified
interface (example loc:eth4). Beginning with Shorwall 1.3.9,
the interface name may optionally be followed by a colon (":") and
an IP address or subnet (examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).</li>
<li>An IP address - refers
to a connection request from the host with the
specified address (example net:155.186.235.151). If the ACTION
is DNAT, this must not be a DNS name.</li>
<li>A MAC Address in <a
href="#MAC">Shorewall format</a>.</li>
<li>A subnet - refers to a
connection request from any host in the specified
subnet (example net:155.186.235.0/24).</li>
</ul>
</li>
<li><b>DEST</b> - Describes
the destination host(s) to which the rule applies. May
take most of the forms described above for SOURCE plus
the following two additional forms:
<ul>
<li>An IP address followed
by a colon and the port <u>number</u> that
the server is listening on (service names from /etc/services
are not allowed - example loc:192.168.1.3:80).
<br>
</li>
<li>A single port number (again,
service names are not allowed) -- this form is only allowed
if the ACTION is REDIRECT and refers to a server running on
the firewall itself and listening on the specified port.</li>
</ul>
Restrictions:<br>
<ul>
<li>MAC addresses may not be specified.</li>
<li>In DNAT rules, only an IP address may be given -- DNS
names are not permitted.</li>
<li>You may not specify both an IP address and an interface
name in the DEST column.<br>
</li>
</ul>
</li>
<li><b> PROTO</b> - Protocol.
Must be a protocol name from /etc/protocols, a number or
"all". Specifies the protocol of the connection request.</li>
<li><b> DEST PORT(S)</b>
- Port or port range (&lt;low port&gt;:&lt;high port&gt;)
being connected to. May only be specified if the protocol
is tcp, udp or icmp. For icmp, this column's contents
are interpreted as an icmp type. If you don't want to specify
DEST PORT(S) but need to include information in one of the columns
to the right, enter "-" in this column. You may give a list of
ports and/or port ranges separated by commas. Port numbers may be
either integers or service names from /etc/services.</li>
<li><b> SOURCE</b> <b>PORTS(S)
</b>- May be used to restrict the rule to a particular
client port or port range (a port range is specified as
&lt;low port number&gt;:&lt;high port number&gt;). If you don't
want to restrict client ports but want to specify something in
the next column, enter "-" in this column. If you wish to specify
a list of port number or ranges, separate the list elements
with commas (with no embedded white space). Port numbers may be
either integers or service names from /etc/services.</li>
<li><b>ORIGINAL DEST</b> - This
column may only be non-empty if the ACTION is DNAT
or REDIRECT.<br>
<br>
If DNAT or REDIRECT is the ACTION
and the ORIGINAL DEST column is left empty, any connection
request arriving at the firewall from the SOURCE that matches
the rule will be forwarded or redirected. This works fine
for connection requests arriving from the internet where
the firewall has only a single external IP address. When the
firewall has multiple external IP addresses or when the SOURCE
is other than the internet, there will usually be a desire for
the rule to only apply to those connection requests directed to
a particular IP address (see Example 2 below for another usage).
That IP address is specified in the ORIGINAL DEST column.<br>
<br>
The IP address may be optionally
followed by ":" and a second IP address. This latter address,
if present, is used as the source address for packets
forwarded to the server (This is called "Source NAT" or SNAT).<br>
<br>
<b><font color="#ff6633">Note: </font> When using
SNAT, it is a good idea to qualify the source with an IP address
or subnet. Otherwise, it is likely that SNAT will occur on connections
other than those described in the rule. The reason for this is that
SNAT occurs in the Netfilter POSTROUTING hook where it is not possible
to restrict the scope of a rule by incoming interface. <br>
<br>
</b>Example: DNAT
loc<u>:192.168.1.0/24</u> loc:192.168.1.3 tcp
www - 206.124.146.179:192.168.1.3<b><br>
<br>
</b>If SNAT is not used
(no ":" and second IP address), the original source
address is used. If you want any destination address to match
the rule but want to specify SNAT, simply use a colon followed
by the SNAT address.</li>
</ul>
<p><b> <font face="Century Gothic, Arial, Helvetica"> <a
name="PortForward"></a> </font>Example 1. </b> You wish to forward all
ssh connection requests from the internet to local
system 192.168.1.3. </p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 2. </b> You want to redirect all local www connection requests
EXCEPT
those to your own http server (206.124.146.177)
to a Squid transparent proxy running
on the firewall and listening on port 3128. Squid will of
course require access to remote web servers. This example shows yet
another use for the ORIGINAL
DEST column; here, connection
requests that were NOT
<a href="#GettingStarted"> (notice the "!")</a> originally
destined to 206.124.146.177 are
redirected to local port 3128.</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc</td>
<td>3128</td>
<td>tcp</td>
<td>www</td>
<td> -<br>
</td>
<td>!206.124.146.177</td>
</tr>
<tr>
<td>ACCEPT</td>
<td>fw</td>
<td>net</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b>Example 3. </b> You want to run a web server at 155.186.235.222 in your
DMZ and have it accessible remotely and locally. the DMZ is managed
by Proxy ARP or by classical sub-netting.</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>dmz:155.186.235.222</td>
<td>tcp</td>
<td>www</td>
<td>-</td>
<td> <br>
</td>
</tr>
<tr>
<td>ACCEPT</td>
<td>loc</td>
<td>dmz:155.186.235.222</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 4. </b> You want to run wu-ftpd on 192.168.2.2 in your masqueraded
DMZ. Your internet interface address is 155.186.235.151
and you want the FTP server to be accessible from the internet
in addition to the local 192.168.1.0/24 and dmz 192.168.2.0/24
subnetworks. Note that since the server is in the 192.168.2.0/24
subnetwork, we can assume that access to the server from that
subnet will not involve the firewall (<a
href="FAQ.htm#faq2">but see FAQ 2</a>). Note that unless you
have more than one external IP address,
you can leave the ORIGINAL DEST column
blank in the first rule. You
cannot leave it blank
in the second rule though
because then <u>all
ftp connections</u> originating in the local subnet 192.168.1.0/24
would be sent to 192.168.2.2 <u>
regardless of the site that
the user was trying to
connect to</u>. That is
clearly not what you want
<img border="0"
src="images/SY00079.gif" width="20" height="20" align="top">
.</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>dmz:192.168.2.2</td>
<td>tcp</td>
<td>ftp</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>loc:192.168.1.0/24</td>
<td>dmz:192.168.2.2</td>
<td>tcp</td>
<td>ftp</td>
<td>-</td>
<td>155.186.235.151</td>
</tr>
</tbody>
</table>
</blockquote>
<p>If you are running wu-ftpd, you should restrict the range of passive
in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions
so I use port range 65500-65535. In /etc/ftpaccess,
this entry is appropriate:</p>
<blockquote>
<p> passive ports 0.0.0.0/0 65500 65534</p>
</blockquote>
<p>If you are running pure-ftpd, you would include "-p 65500:65534" on
the pure-ftpd runline.</p>
<p>The important point here is to ensure that the port range used for FTP
passive connections is unique and will not overlap with
any usage on the firewall system.</p>
<p><b>Example 5. </b>You wish to allow unlimited
DMZ access to the host with MAC address
02:00:08:E3:FA:55.</p>
<blockquote> <font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>loc:~02-00-08-E3-FA-55</td>
<td>dmz</td>
<td>all</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<b>Example 6.</b> You wish to allow access to the SMTP
server in your DMZ from all zones.<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ACTION</b><br>
</td>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DEST<br>
</b></td>
<td valign="top"><b>PROTO<br>
</b></td>
<td valign="top"><b>DEST<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>SOURCE<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>ORIGINAL<br>
DEST<br>
</b></td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">all<br>
</td>
<td valign="top">dmz<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
Note: When 'all' is used as a source or
destination, intra-zone traffic is not affected. In this example,
if there were two DMZ interfaces then the above rule would NOT
enable SMTP traffic between hosts on these interfaces.<br>
</blockquote>
<b>Example 7 (For advanced users running Shorewall
version 1.3.13 or later). </b>From the internet, you with to
forward tcp port 25 directed to 192.0.2.178 and 192.0.2.179 to
host 192.0.2.177 in your DMZ. You also want to allow access from
the internet directly to tcp port 25 on 192.0.2.177. <br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ACTION</b><br>
</td>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DEST<br>
</b></td>
<td valign="top"><b>PROTO<br>
</b></td>
<td valign="top"><b>DEST<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>SOURCE<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>ORIGINAL<br>
DEST<br>
</b></td>
</tr>
<tr>
<td valign="top">DNAT-<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">dmz:192.0.2.177<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">192.0.2.178<br>
</td>
</tr>
<tr>
<td valign="top">DNAT-<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">dmz:192.0.2.177<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">192.0.2.179<br>
</td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">dmz:192.0.2.177<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
Using "DNAT-" rather than "DNAT" avoids two
extra copies of the third rule from being generated.<br>
<p><a href="ports.htm">Look here for information on other services.</a>
</p>
<h2><a name="Common"> </a>/etc/shorewall/common</h2>
<p>Shorewall allows definition of rules that apply between
all zones. By default, these rules
are defined in the file
/etc/shorewall/common.def
but may be modified to
suit individual
requirements. Rather than modify /etc/shorewall/common.def,
you should copy that
file to
/etc/shorewall/common
and modify that file.</p>
<p>The /etc/shorewall/common
file is expected to contain iptables
commands; rather than
running iptables
directly, you should run
it indirectly using the
Shorewall function 'run_iptables'.
That way, if iptables encounters
an error, the firewall will be safely
stopped.</p>
<h2><a name="Masq"></a> /etc/shorewall/masq</h2>
<p>The /etc/shorewall/masq file is used to define classical IP Masquerading
and Source Network Address Translation (SNAT). There
is one entry in the file for each subnet that you want to
masquerade. In order to make use of this feature, you must have
<a href="#NatEnabled">NAT enabled</a> .</p>
<p> Columns are:</p>
<ul>
<li><b> INTERFACE</b> - The
interface that will masquerade the subnet; this is
normally your internet interface. This interface name can
be optionally qualified by adding ":" and a subnet or host IP.
When this qualification is added, only packets addressed to
that host or subnet will be masqueraded. Beginning with Shorewall
version 1.3.14, if you have set ADD_SNAT_ALIASES=Yes in <a
href="#Conf">/etc/shorewall/shorewall.conf</a>, you can cause Shorewall
to create an alias <i>label </i>of the form <i>interfacename:digit
</i>(e.g., eth0:0) by placing that label in this column. See
example 5 below. Alias labels created in this way allow the alias
to be visible to the ipconfig utility. <b>THAT IS THE ONLY THING
THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR
SHOREWALL CONFIGURATION.</b></li>
<li><b> SUBNET</b> - The subnet
that you want to have masqueraded through the INTERFACE.
This may be expressed as a single IP address, a subnet or
an interface name. In the latter instance, the interface
must be configured and started before Shorewall is started as
Shorewall will determine the subnet based on information
obtained from the 'ip' utility. <b><font color="#ff0000">When
using Shorewall 1.3.13 or earlier, when an interface name is specified,
Shorewall will only masquerade traffic from the first subnetwork on
the named interface; if the interface interfaces to more that one
subnetwork, you will need to add additional entries to this file for
each of those other subnetworks. Beginning with Shorewall 1.3.14, shorewall
will masquerade/SNAT traffic from any host that is routed through the
named interface.</font></b><br>
<br>
The subnet may be optionally
followed by "!' and a comma-separated list of addresses
and/or subnets that are to be excluded from masquerading.</li>
<li><b>ADDRESS</b> - The source
address to be used for outgoing packets. This column is
optional and if left blank, the current primary IP address
of the interface in the first column is used. If you have a
static IP on that interface, listing it here makes processing of output
packets a little less expensive for the firewall. If you specify
an address in this column, it must be an IP address configured on the
INTERFACE or you must have ADD_SNAT_ALIASES enabled in <a
href="#Conf">/etc/shorewall/shorewall.conf.</a></li>
</ul>
<p><b> Example 1: </b> You have eth0 connected to a cable modem and eth1
connected to your local subnetwork 192.168.9.0/24.
Your /etc/shorewall/masq file would look like: </p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0</td>
<td>192.168.9.0/24</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 2:</b> You have a number of IPSEC tunnels through ipsec0
and you want to masquerade traffic from your 192.168.9.0/24
subnet to the remote subnet 10.1.0.0/16 only.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>ipsec0:10.1.0.0/16</td>
<td>192.168.9.0/24</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 3:</b> You have a DSL line connected on eth0 and a local
network (192.168.10.0/24)
connected to eth1. You want all local-&gt;net
connections to use
source address
206.124.146.176.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0</td>
<td>192.168.10.0/24</td>
<td>206.124.146.176</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b>Example 4: </b> Same as example 3 except that
you wish to exclude 192.168.10.44
and 192.168.10.45 from
the SNAT rule.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0</td>
<td>192.168.10.0/24!192.168.10.44,192.168.10.45</td>
<td>206.124.146.176</td>
</tr>
</tbody>
</table>
</blockquote>
<b>Example 5 (Shorewall version &gt;= 1.3.14): </b>You have
a second IP address (206.124.146.177) assigned to you and wish to
use it for SNAT of the subnet 192.168.12.0/24. You want to give that
address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes in <a
href="#Conf">/etc/shorewall/shorewall.conf</a>.<br>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0:0</td>
<td>192.168.12.0/24</td>
<td>206.124.146.177</td>
</tr>
</tbody>
</table>
</blockquote>
<h2><font color="#660066"><b><a name="ProxyArp"></a>
</b></font>/etc/shorewall/proxyarp</h2>
<p>If you want to use proxy ARP on an entire sub-network,
I suggest that you
look at <a
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">
http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>.
If you decide to use the technique
described in that
HOWTO, you can set
the proxy_arp flag
for an interface
(/proc/sys/net/ipv4/conf/<i>&lt;interface&gt;</i>/proxy_arp)
by including the <b> proxyarp</b>
option in the interface's
record in
<a href="#Interfaces">
/etc/shorewall/interfaces</a>.
When using Proxy ARP
sub-netting, you do <u>NOT</u> include
any entries in
/etc/shorewall/proxyarp. </p>
<p>The /etc/shorewall/proxyarp file is used to define <a
href="ProxyARP.htm">Proxy ARP</a>. The file is
typically used for
enabling Proxy ARP on a
small set of systems
since you need
one entry in this file for each
system using proxy ARP. Columns
are:</p>
<ul>
<li><b> ADDRESS</b> - address
of the system.</li>
<li><b> INTERFACE</b> - the
interface that connects to the system. If the interface
is obvious from the subnetting, you may enter "-" in
this column.</li>
<li><b> EXTERNAL</b> - the
external interface that you want to honor ARP requests
for the ADDRESS specified in the first column.</li>
<li><b>HAVEROUTE</b> - If
you already have
a route through
INTERFACE
to ADDRESS,
this column should contain "Yes"
or "yes". If you want Shorewall to add
the route, the
column should contain
"No"
or
"no".</li>
</ul>
<p><font color="#cc6666"><b>Note: After you have made a change to the /etc/shorewall/proxyarp
file, you may need to flush the ARP cache of all routers
on the LAN segment connected to the interface specified in
the EXTERNAL column of the change/added entry(s). If you are
having problems communicating between an individual host
(A) on that segment and a system whose entry has changed, you
may need to flush the ARP cache on host A as well.</b></font></p>
<p><font color="#cc6666"><b>ISPs typically have ARP configured with long TTL
(hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump
-nei &lt;external interface&gt; host &lt;IP addr&gt;"), it may take a long
while to time out. I personally have had to contact my ISP and ask them
to delete a stale entry in order to restore a system to working order after
changing my proxy ARP settings. </b></font></p>
<p><b>Example: </b> You have public IP addresses 155.182.235.0/28. You
configure your firewall as follows:</p>
<ul>
<li>eth0 - 155.186.235.1 (internet
connection)</li>
<li>eth1 - 192.168.9.0/24 (masqueraded
local systems)</li>
<li>eth2 - 192.168.10.1 (interface
to your DMZ)</li>
</ul>
<p> In your DMZ, you want to install a Web/FTP server with public address
155.186.235.4. On the Web server, you subnet just like
the firewall's eth0 and you configure 155.186.235.1 as
the default gateway. In your /etc/shorewall/proxyarp file,
you will have:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ADDRESS</b></td>
<td><b> INTERFACE</b></td>
<td><b> EXTERNAL</b></td>
<td><b>HAVEROUTE</b></td>
</tr>
<tr>
<td>155.186.235.4</td>
<td>eth2</td>
<td>eth0</td>
<td>No</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Note: You may want to configure the servers in your DMZ with a subnet
that is smaller than the subnet of your internet interface.
See the Proxy ARP Subnet Mini HOWTO (<a
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>)
for details. In this case you will want to place "Yes"
in the HAVEROUTE column.</p>
<p><font color="#ff6633"><b>Warning: </b></font>Do not use Proxy ARP and FreeS/Wan
on the same system unless you are prepared to suffer the consequences.
If you start or restart Shorewall with an IPSEC tunnel active,
the proxied IP addresses are mistakenly assigned to the
IPSEC tunnel device (ipsecX) rather than to the interface
that you specify in the INTERFACE column of /etc/shorewall/proxyarp.
I haven't had the time to debug this problem so I can't say if
it is a bug in the Kernel or in FreeS/Wan. </p>
<p>You <b>might</b> be able to work around this problem using the following
(I haven't tried it):</p>
<p>In /etc/shorewall/init, include:</p>
<p> qt service ipsec stop</p>
<p>In /etc/shorewall/start, include:</p>
<p> qt service ipsec start</p>
<h2><font color="#660066"><b><a name="NAT"></a>
</b></font>/etc/shorewall/nat</h2>
<p>The /etc/shorewall/nat file is used to define static NAT. There is one
entry in the file for each static NAT relationship
that you wish to define. In order to make use of this feature,
you must have <a href="#NatEnabled">NAT enabled</a> .</p>
<p> <font
color="#ff0000"> <b>IMPORTANT: If all you want to do
is forward ports
to servers behind your firewall, you
do NOT want to use
static NAT. Port
forwarding can be
accomplished
with simple entries in
the <a href="#Rules"> rules
file</a>. Also, in most
cases <a href="#ProxyArp">
Proxy ARP</a>
provides a
superior solution
to static NAT because
the internal
systems
are accessed using the same IP address internally
and externally.</b></font></p>
<p>Columns in an entry are:</p>
<ul>
<li><b> EXTERNAL</b> - External
IP address - <u>This should NOT be the primary IP
address of the interface named in the next column.</u></li>
<li><b> INTERFACE</b> - Interface
that you want the EXTERNAL IP address to appear on.
Beginning with Shorewall version 1.3.14, if you have set ADD_IP_ALIASES=Yes
in <a href="#Conf">/etc/shorewall/shorewall.conf</a>, <20>you can specify
an alias label of the form <i>interfacename:digit </i>(e.g., eth0:0)
and Shorewall will create the alias with that label. Alias labels created
in this way allow the alias to be visible to the ipconfig utility.
<b>THAT IS THE ONLY THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT
APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.</b><EFBFBD></li>
<li><b> INTERNAL </b> - Internal
IP address.</li>
<li><b>ALL
INTERFACES</b>
- If Yes
or yes (or
left
empty),
NAT will be effective
from all hosts.
If No or no
then NAT
will be
effective
only
through the interface
named in the
INTERFACE column.</li>
<li><b>LOCAL</b> - If Yes or
yes and the ALL INTERFACES column contains Yes or yes,
NAT will be effective from the firewall system. <b>Note:
</b>For this to work, you must be running kernel 2.4.19
or later and iptables 1.2.6a or later and you must have enabled
<b>CONFIG_IP_NF_NAT_LOCAL</b> in your kernel.</li>
</ul>
<p><b><a href="NAT.htm"> Look here for additional information and an example.</a>
</b></p>
<h2><font color="#660066"><a name="Tunnels"></a>
</font>/etc/shorewall/tunnels</h2>
<p> The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP,
<a href="http://openvpn.sourceforge.net/">OpenVPN</a>, PPTP and
6to4.tunnels with end-points on your firewall. To use ipsec, you
must install version 1.9, 1.91 or the current <a
href="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</a> development snapshot.
</p>
<p> Note: For kernels 2.4.4 and above, you will need to use version 1.91
or a development snapshot as patching with version
1.9 results in kernel compilation errors.</p>
<p><b><a href="IPSEC.htm"> Instructions for setting up IPSEC tunnels may
be found here,</a></b> <b><a href="IPIP.htm">instructions
for IPIP and GRE tunnels are here</a></b>, <b><a
href="OPENVPN.html">instructions for OpenVPN tunnels are here</a></b>,
<b><a href="PPTP.htm">instructions for PPTP tunnels are here</a>
and <a href="6to4.htm">instructions for 6to4 tunnels</a> are here.</b></p>
<h2><a name="Conf"></a>/etc/shorewall/shorewall.conf</h2>
<p> This file is used to set the following firewall parameters:</p>
<ul>
<li><b>LOGFORMAT - </b>Added
at version 1.4.4.<br>
The value of this variable generate the --log-prefix setting for Shorewall
logging rules. It contains a 'printf' formatting template which accepts three
arguments (the chain name, logging rule number (optional) and the disposition).
To use LOGFORMAT with fireparse (<a href="http://www.fireparse.com">http://www.fireparse.com</a>),
set it as:<br>
<20><br>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> LOGFORMAT="fp=%s:%d a=%s "<br>
<20><br>
If the LOGFORMAT value contains the substring '%d' then the logging rule
number is calculated and formatted in that position; if that substring is
not included then the rule number is not included. If not supplied or supplied
as empty (LOGFORMAT="") then "Shorewall:%s:%s:" is assumed.<br>
<br>
<b>CAUTION: </b>/sbin/shorewall uses the leading part of the LOGFORMAT
string (up to but not including the first '%') to find log messages in
the 'show log', 'status' and 'hits' commands. This part should not be omitted
(the LOGFORMAT should not begin with "%") and the leading part should be
sufficiently unique for /sbin/shorewall to identify Shorewall messages.<br>
</li>
<li><b>CLEAR_TC</b> - Added at version 1.3.13<br>
If this option is set to 'No' then Shorewall won't
clear the current traffic control rules during [re]start. This setting
is intended for use by people that prefer to configure traffic shaping
when the network interfaces come up rather than when the firewall
is started. If that is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No
and do not supply an /etc/shorewall/tcstart file. That way, your
traffic shaping rules can still use the 'fwmark' classifier based on
packet marking defined in /etc/shorewall/tcrules. If not specified,
CLEAR_TC=Yes is assumed.<br>
</li>
<li><b>MARK_IN_FORWARD_CHAIN </b>- Added at version
1.3.12<br>
If your kernel has a FORWARD chain in the mangle
table, you may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking
specified in the <a href="traffic_shaping.htm#tcrules">tcrules
file</a> to occur in that chain rather than in the PREROUTING
chain. This permits you to mark inbound traffic based on its destination
address when SNAT or Masquerading are in use. To determine if your
kernel has a FORWARD chain in the mangle table, use the "/sbin/shorewall
show mangle" command; if a FORWARD chain is displayed then your
kernel will support this option. If this option is not specified or
if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then
MARK_IN_FORWARD_CHAIN=No is assumed.<br>
</li>
<li><b>RFC1918_LOG_LEVEL - </b>Added at version
1.3.12<br>
This parameter determines the level at which
packets logged under the <a
href="Documentation.htm#rfc1918">'norfc1918' mechanism </a>
are logged. The value must be a valid <a
href="shorewall_logging.html">syslog level</a> and if no level is given,
then info is assumed. Prior to Shorewall version 1.3.12, these
packets are always logged at the info level.</li>
<li><b>TCP_FLAGS_DISPOSITION - </b>Added
in Version 1.3.11<br>
Determines the disposition of TCP packets that
fail the checks enabled by the <a href="#Interfaces%5C">tcpflags</a>
interface option and must have a value of ACCEPT (accept the
packet), REJECT (send an RST response) or DROP (ignore the packet).
If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="")
then TCP_FLAGS_DISPOSITION=DROP is assumed.</li>
<li><b>TCP_FLAGS_LOG_LEVEL - </b>Added
in Version 1.3.11<br>
Determines the <a
href="shorewall_logging.html">syslog level</a> for logging packets
that fail the checks enabled by the <a href="#Interfaces">tcpflags</a>
interface option.The value must be a valid syslogd log level.
If you don't want to log these packets, set to the empty value
(e.g., TCP_FLAGS_LOG_LEVEL="").<br>
</li>
<li><b>MACLIST_DISPOSITION </b>- Added
in Version 1.3.10<br>
Determines the disposition of connections
requests that fail <a href="MAC_Validation.html">MAC Verification</a>
and must have the value ACCEPT (accept the connection request anyway),
REJECT (reject the connection request) or DROP (ignore the connection
request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="")
then MACLIST_DISPOSITION=REJECT is assumed.</li>
<li><b>MACLIST_LOG_LEVEL </b>- Added
in Version 1.3.10<br>
Determines the <a
href="shorewall_logging.html">syslog level</a> for logging connection
requests that fail <a href="MAC_Validation.html">MAC Verification</a>.
The value must be a valid syslogd log level. If you don't
want to log these connection requests, set to the empty value
(e.g., MACLIST_LOG_LEVEL="").<br>
</li>
<li><b>NEWNOTSYN </b>- Added in Version
1.3.8<br>
When set to "Yes" or "yes", Shorewall
will filter TCP packets that are not part of an established
connention and that are not SYN packets (SYN flag on - ACK
flag off). If set to "No", Shorewall will silently drop such
packets. If not set or set to the empty value (e.g., "NEWNOTSYN="),
NEWNOTSYN=No is assumed.<br>
<br>
If you have a HA setup with failover
to another firewall, you should have NEWNOTSYN=Yes on
both firewalls. You should also select NEWNOTSYN=Yes if you
have asymmetric routing.<br>
</li>
<li><b>LOGNEWNOTSYN</b> - Added
in Version 1.3.6<br>
Beginning with version 1.3.6,
Shorewall drops non-SYN TCP packets that are not part
of an existing connection. If you would like to log these
packets, set LOGNEWNOTSYN to the <a
href="shorewall_logging.html">syslog level</a> at which you want
the packets logged. Example: LOGNEWNOTSYN=ULOG|<br>
<br>
<b>Note: </b>Packets logged
under this option are usually the result of broken
remote IP stacks rather than the result of any sort of attempt
to breach your firewall.</li>
<li><b>DETECT_DNAT_ADDRS</b>
- Added in Version 1.3.4<br>
If set to "Yes" or "yes", Shorewall will detect the first
IP address of the interface to the source zone and will include this
address in DNAT rules as the original destination IP address. If set
to "No" or "no", Shorewall will not detect this address and any
destination IP address will match the DNAT rule. If not specified
or empty, "DETECT_DNAT_ADDRS=Yes" is assumed.<br>
</li>
<li><b></b><b>MULTIPORT</b> -
Added in Version 1.3.2<br>
If set to "Yes" or "yes", Shorewall
will use the Netfilter multiport facility. In order
to use this facility, your kernel must have multiport
support (CONFIG_IP_NF_MATCH_MULTIPORT). When this support is
used, Shorewall will generate a single rule from each record
in the /etc/shorewall/rules file that meets these criteria:<br>
<ul>
<li>No port range(s) specified</li>
<li>Specifies 15 or fewer
ports</li>
</ul>
<p>Rules not meeting those criteria will continue to generate an individual
rule for each listed port or port range. </p>
</li>
<li><b>NAT_BEFORE_RULES</b><br>
If set to "No" or "no", port
forwarding rules can override the contents of the
<a href="#NAT">/etc/shorewall/nat</a> file. If set to "Yes"
or "yes", port forwarding rules cannot override static NAT.
If not set or set to an empty value, "Yes" is assumed.</li>
<li><b>FW<br>
</b>This
parameter specifies
the name of the
firewall zone.
If not
set or
if set to an empty string, the value
"fw" is assumed.</li>
<li><b>SUBSYSLOCK</b><br>
This parameter should
be set to the name of a file that the firewall should
create if it starts successfully and remove when it stops.
Creating and removing this file allows Shorewall to work with
your distribution's initscripts. For RedHat, this should be
set to /var/lock/subsys/shorewall. For Debian, the value
is /var/state/shorewall and in LEAF it is /var/run/shorwall.
Example: SUBSYSLOCK=/var/lock/subsys/shorewall.</li>
<li><b> STATEDIR</b><br>
This parameter specifies
the name of a directory where Shorewall stores
state information. If the directory doesn't exist when Shorewall
starts, it will create the directory. Example: STATEDIR=/tmp/shorewall.<br>
<br>
<b>NOTE:</b> If you change the
STATEDIR variable while the firewall is running, create
the new directory if necessary then copy the contents of the
old directory to the new directory. </li>
<li><b>MODULESDIR</b><br>
This parameter specifies
the directory where your kernel netfilter modules
may be found. If you leave the variable empty, Shorewall will
supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.</li>
<li><b> LOGRATE </b> and <b>
LOGBURST</b><br>
These parameters set the
match rate and initial burst size for logged packets.
Please see the iptables man page for a description of the
behavior of these parameters (the iptables option --limit is
set by LOGRATE and --limit-burst is set by LOGBURST). If
both parameters are set empty, no rate-limiting will occur.<br>
<br>
Example:<br>
LOGRATE=10/minute<br>
LOGBURST=5<br>
</li>
<li><b>LOGFILE</b><br>
This parameter
tells the /sbin/shorewall
program where
to look for
Shorewall
messages when
processing the "show log",
"monitor", "status"
and "hits"
commands. If not assigned
or if assigned
an empty
value,
/var/log/messages
is assumed.</li>
<li><b>NAT_ENABLED</b><br>
This parameter determines
whether Shorewall supports NAT operations. NAT
operations include:<br>
<br>
Static NAT<br>
Port Forwarding<br>
Port Redirection<br>
Masquerading<br>
<br>
If the parameter has no
value or has a value of "Yes" or "yes" then NAT is
enabled. If the parameter has a value of "no" or "No"
then NAT is disabled.<br>
</li>
<li><b> MANGLE_ENABLED</b><br>
This parameter determines
if packet mangling is enabled. If the parameter
has no value or has a value of "Yes" or "yes" than packet
mangling is enabled. If the parameter has a value of "no"
or "No" then packet mangling is disabled. If packet mangling
is disabled, the /etc/shorewall/tos file is ignored.<br>
</li>
<li><b> IP_FORWARDING</b><br>
This parameter determines
whether Shorewall enables or disables IPV4 Packet
Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values
are:<br>
<br>
On or on - packet
forwarding will be enabled.<br>
Off or off - packet
forwarding will be disabled.<br>
Keep or keep - Shorewall
will neither enable nor disable packet forwarding.<br>
<br>
If this variable is not
set or is given an empty value (IP_FORWARD="")
then IP_FORWARD=On is assumed.<br>
</li>
<li><b>ADD_IP_ALIASES</b><br>
This parameter determines
whether Shorewall automatically adds the
<i>external </i>address(es) in
<a href="#NAT">/etc/shorewall/nat</a> . If the variable
is set to "Yes" or "yes" then Shorewall automatically adds these
aliases. If it is set to "No" or "no", you must add these
aliases yourself using your distribution's network configuration
tools. <b>RESTRICTION: </b>Shorewall can only add addresses to
the first subnetwork configured on an interface.<br>
<br>
If this variable is not
set or is given an empty value (ADD_IP_ALIASES="")
then ADD_IP_ALIASES=Yes is assumed.</li>
<li><b>ADD_SNAT_ALIASES</b><br>
This parameter determines whether
Shorewall automatically adds the SNAT <i> ADDRESS
</i>in <a href="#Masq">/etc/shorewall/masq</a>. If the variable
is set to "Yes" or "yes" then Shorewall automatically adds
these addresses. If it is set to "No" or "no", you must add these
addresses yourself using your distribution's network configuration
tools. <b>RESTRICTION: </b>Shorewall can only add addresses
to the first subnetwork configured on an interface.<br>
<br>
If this variable is not
set or is given an empty value (ADD_SNAT_ALIASES="")
then ADD_SNAT_ALIASES=No is assumed.<br>
</li>
<li><b>LOGUNCLEAN</b><br>
This parameter
determines the
logging level of
mangled/invalid
packets
controlled by
the '<a
href="#Unclean">dropunclean and logunclean</a>'
interface
options. If
LOGUNCLEAN is empty (LOGUNCLEAN=)
then packets selected by
'dropclean' are
dropped silently
('logunclean'
packets are
logged under
the 'info' log level). Otherwise,
these packets are logged at
the specified
level (Example:
LOGUNCLEAN=debug).</li>
<li><b>BLACKLIST_DISPOSITION</b><br>
This parameter
determines the
disposition of
packets from
blacklisted
hosts. It may have the value DROP if the
packets are to
be dropped or
REJECT if the packets
are to be
replied
with an ICMP
port
unreachable
reply or a TCP RST (tcp only). If you
do not assign a value or if
you assign an
empty value
then DROP is
assumed.</li>
<li><b>BLACKLIST_LOGLEVEL</b><br>
This paremter
determines if packets
from blacklisted
hosts are
logged and it
determines the syslog
level that they are to be logged
at. Its value
is a <a href="shorewall_logging.html">syslog
level</a> (Example:
BLACKLIST_LOGLEVEL=debug).
If you do not assign a value or
if you assign an empty
value then packets
from blacklisted
hosts are not
logged.</li>
<li><b>CLAMPMSS</b><br>
This parameter
enables the TCP
Clamp MSS to PMTU
feature of
Netfilter and
is usually
required when
your internet
connection is through PPPoE
or PPTP. If
set to "Yes"
or
"yes", the feature
is enabled.
If left
blank or
set to
"No"
or "no",
the feature
is not
enabled. Note: This option requires
CONFIG_IP_NF_TARGET_TCPMSS
<a href="kernel.htm">in your
kernel</a>.</li>
<li><b>ROUTE_FILTER</b><br>
If this parameter is given the
value "Yes" or "yes" then route filtering (anti-spoofing)
is enabled on all network interfaces. The default value
is "no".</li>
</ul>
<h2><a name="modules"></a> /etc/shorewall/modules Configuration</h2>
<p>The file /etc/shorewall/modules contains commands for loading the kernel
modules required by Shorewall-defined firewall rules.
Shorewall will source this file during start/restart provided
that it exists and that the directory specified by the MODULESDIR
parameter exists (see <a href="#Conf">/etc/shorewall/shorewall.conf</a>
above).</p>
<p>The file that is released with Shorewall calls the Shorewall function
"loadmodule" for the set of modules that I load.</p>
<p>The <i>loadmodule</i> function is called as follows:</p>
<blockquote>
<p>loadmodule <i>&lt;modulename&gt; </i>[
<i> &lt;module parameters&gt; </i>]</p>
</blockquote>
<p>where</p>
<blockquote>
<p><i>&lt;modulename&gt; </i></p>
<blockquote>
<p>is the name of the modules without the trailing ".o" (example
ip_conntrack).</p>
</blockquote>
<p><i> &lt;module parameters&gt;</i></p>
<blockquote>
<p> Optional parameters to the insmod utility.</p>
</blockquote>
</blockquote>
<p> The function determines if the module named by <i>&lt;modulename&gt;
</i> is already loaded and if not then the function
determines if the ".o" file corresponding to the module
exists in the <i>moduledirectory</i>; if so, then the
following command is executed:</p>
<blockquote>
<p> insmod <i>moduledirectory</i>/<i>&lt;modulename&gt;</i>.o <i>&lt;module
parameters&gt;</i></p>
</blockquote>
<p> If the file doesn't exist, the function determines of the ".o.gz"
file corresponding to the module exists in the <i>moduledirectory</i>. If
it does, the function assumes that the running configuration supports compressed
modules and execute the following command:</p>
<blockquote>
<p> insmod <i>moduledirectory/&lt;modulename&gt;.</i>o.gz &lt;<i>module
parameters&gt;</i></p>
</blockquote>
<h2><a name="TOS"></a> /etc/shorewall/tos Configuration</h2>
<p> The /etc/shorewall/tos file allows you to set the Type of Service field
in packet headers based on packet source, packet destination,
protocol, source port and destination port. In order
for this file to be processed by Shorewall, you must have
<a href="#MangleEnabled">mangle support enabled</a> .</p>
<p> Entries in the file have the following columns:</p>
<ul>
<li><b> SOURCE</b> -- The
source zone. May be qualified by following the zone name
with a colon (":") and either an IP address, an IP subnet,
a MAC address in <a href="#MAC">Shorewall Format</a> or the
name of an interface. This column may also contain the <a
href="#FW">name of
the firewall</a>
zone to indicate packets originating
on the firewall itself or "all" to indicate any source.</li>
<li><b> DEST</b> -- The destination
zone. May be qualified by following the zone name
with a colon (":") and either an IP address or an IP subnet.
Because packets are marked prior to routing, you may not specify
the name of an interface. This column may also contain
"all" to indicate any destination.</li>
<li><b> PROTOCOL</b> -- The
name of a protocol in /etc/protocols or the protocol's
number.</li>
<li><b> SOURCE PORT(S)</b>
-- The source port or a port range. For all ports, place
a hyphen ("-") in this column.</li>
<li><b> DEST PORT(S)</b>
-- The destination port or a port range. To indicate
all ports, place a hyphen ("-") in this column.</li>
<li><b> TOS</b> -- The type
of service. Must be one of the following:</li>
</ul>
<blockquote>
<blockquote>
<p> Minimize-Delay (16)<br>
Maximize-Throughput (8)<br>
Maximize-Reliability (4)<br>
Minimize-Cost (2)<br>
Normal-Service (0)</p>
</blockquote>
</blockquote>
<p> The /etc/shorewall/tos file that is included with Shorewall contains
the following entries.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTOCOL</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>DEST PORT(S)</b></td>
<td><b>TOS</b></td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>-</td>
<td>ssh</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>-</td>
<td>ftp</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>ftp</td>
<td>-</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>-</td>
<td>ftp-data</td>
<td>8</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>ftp-data</td>
<td>-</td>
<td>8</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b>WARNING: </b>Users have reported that odd routing problems result from
adding the ESP and AH protocols to the /etc/shorewall/tos
file. </p>
<h2><a name="Blacklist"></a>/etc/shorewall/blacklist</h2>
<p>Each line in
/etc/shorewall/blacklist
contains
an IP
address, a MAC address in <a href="#MAC">Shorewall Format</a>
or
subnet
address. Example:</p>
<pre> 130.252.100.69<br> 206.124.146.0/24</pre>
<p>Packets <u><b>from</b></u>
hosts
listed
in the
blacklist file
will be
disposed of
according
to
the value assigned
to
the <a href="#Conf">BLACKLIST_DISPOSITION</a>
and <a href="#Conf">BLACKLIST_LOGLEVEL </a>variables in
/etc/shorewall/shorewall.conf.
Only
packets arriving
on interfaces
that
have the
'<a href="#Interfaces">blacklist</a>'
option in
/etc/shorewall/interfaces
are
checked against the
blacklist. The black list is designed to prevent listed
hosts/subnets from accessing services on <u><b>your</b></u>
network.<br>
</p>
<p>Beginning with Shorewall 1.3.8, the blacklist file has three columns:<br>
</p>
<ul>
<li><b>ADDRESS/SUBNET - </b>As
described above.</li>
<li><b>PROTOCOL</b> - Optional.
If specified, only packets specifying this protocol will
be blocked.</li>
<li><b>PORTS - </b>Optional; may
only be given if PROTOCOL is tcp, udp or icmp. Expressed
as a comma-separated list of port numbers or service names
(from /etc/services). If present, only packets destined for the
specified protocol and one of the listed ports are blocked. When
the PROTOCOL is icmp, the PORTS column contains a comma-separated
list of ICMP type numbers or names (see "iptables -h icmp").<br>
</li>
</ul>
<p>Shorewall also has a <a href="blacklisting_support.htm">dynamic blacklist
capability.</a></p>
<p><font color="#cc6666"><b>IMPORTANT: The Shorewall blacklist file is <u>NOT</u>
designed to police your users' web browsing -- to do that,
I suggest that you install and configure Squid (<a
href="http://www.squid-cache.org">http://www.squid-cache.org</a>). </b></font></p>
<h2><a name="rfc1918"></a>/etc/shorewall/rfc1918 (Added in Version 1.3.1)</h2>
<p>This file lists the subnets affected by the <a href="#Interfaces"><i>norfc1918</i>
interface option</a>. Columns in the file are:</p>
<ul>
<li><b>SUBNET</b> - The
subnet using VLSM notation (e.g., 192.168.0.0/16).</li>
<li><b>TARGET<i> </i></b>-
What to do with packets to/from the SUBNET:
<ul>
<li><b>RETURN</b> -
Process the packet normally thru the rules and policies.</li>
<li><b>DROP</b> - Silently
drop the packet.</li>
<li><b>logdrop</b>
- Log then drop the packet -- see the <a href="#Conf">RFC1918_LOG_LEVEL</a>
parameter above.</li>
</ul>
</li>
</ul>
<h2><a name="Routestopped"></a>/etc/shorewall/routestopped (Added in Version
1.3.4)</h2>
<p>This file defines the hosts that are accessible from the firewall when
the firewall is stopped. Columns in the file are:</p>
<ul>
<li><b>INTERFACE </b>-
The firewall interface through which the host(s) comminicate
with the firewall.</li>
<li><b>HOST(S) </b>-
(Optional) - A comma-separated list of IP/Subnet addresses.
If not supplied or supplied as "-" then 0.0.0.0/0 is assumed.</li>
</ul>
<p>Example: When your firewall is stopped, you want firewall accessibility
from local hosts 192.168.1.0/24 and from your DMZ. Your
DMZ interfaces through eth1 and your local hosts through
eth2.</p>
<blockquote>
<table border="2" style="border-collapse: collapse;" id="AutoNumber1"
cellpadding="2">
<tbody>
<tr>
<td><u><b>INTERFACE</b></u></td>
<td><u><b>HOST(S)</b></u></td>
</tr>
<tr>
<td>eth2</td>
<td>192.168.1.0/24</td>
</tr>
<tr>
<td>eth1</td>
<td>-</td>
</tr>
</tbody>
</table>
</blockquote>
<h2><a name="Maclist"></a>/etc/shorewall/maclist (Added in Version 1.3.10)</h2>
This file is described in the <a
href="MAC_Validation.html">MAC Validation Documentation</a>.<br>
<h2><a name="ECN"></a>/etc/shorewall/ecn (Added in Version 1.4.0)</h2>
This file is described in the <a
href="ECN.html">ECN Control Documentation</a>.<br>
<br>
<p><font size="-1"> Updated 5/27/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> <20> <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
</body>
</html>
View Git Blame Copy Permalink