extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-15 20:24:09 +01:00
Code Issues Packages Projects Releases Wiki Activity
5f0d26d1b9
shorewall_code/Shorewall-docs/Documentation.htm
teastep bcefe5a0c8 Make iproute required 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@459 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-02-21 22:22:19 +00:00

3593 lines
209 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> 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 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:
<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>90% of
Shorewall users don't need to put entries in this file and
80% of those who try to add such entries do it wrong.
Unless you are ABSOLUTELY SURE that you need entries in
this file, don't touch it.</b></p>
<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>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:</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/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>-</td>
<td>eth1</td>
<td>detect</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> Hosts in 'loc2' can communicate with the firewall while Shorewall is
stopped -- those in 'loc1' cannot.</p>
<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>
</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><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>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 any 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.<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 (or a comma-separated
list of such addresses) 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> and PPTP
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>, and
<b><a href="PPTP.htm">instructions for PPTP tunnels are here</a>.</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>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 IP address(es)
of the interface(es) to the source zone and will include this (these)
address(es) in DNAT rules as the original destination IP address.
If set to "No" or "no", Shorewall will not detect this (these) address(es)
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.<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.<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>
<br>
<p><font size="-1"> Updated 2/18/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>
<br>
<br>
<br>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink