holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity
5b9b519183
shorewall_code/STABLE/documentation/Documentation.htm
teastep 36aa2c8e88 Release changes for 1.3.12 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@385 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2002-12-28 15:38:03 +00:00

3174 lines
172 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.3 Documentation</title>
<base target="_self">
<meta name="Microsoft Theme" content="none, default">
<meta name="Microsoft Border" content="none, default">
</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.3 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.</li>
<li><a href="#Scripts"><b> icmp.def</b> </a>-- a parameter
file installed in /etc/shorewall and that specifies the default
handling of ICMP packets when the applicable policy is DROP or REJECT.</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><EFBFBD> /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<6F> 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=noping,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 noping,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<6F> "-". 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>you must have iproute installed</li>
<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).<2E></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> noping</b> - ICMP echo-request (ping) packets addressed to
the firewall will be ignored by this interface.<br>
<br>
<b>filterping </b>- ICMP echo-request (ping) packets addressed
to the firewall will be handled according to the /etc/shorewall/rules
and /etc/shorewall/policy file. If the applicable policy is DROP or
REJECT and you have supplied your own /etc/shorewall/icmpdef file then
these 'ping' requests will be passed through the rules in that file
before being dropped or rejected. If neither <b>noping </b>nor <b>filterping</b>
is specified then the firewall will automatically ACCEPT these 'ping'
requests. If both <b>noping</b> and <b>filterping </b>are specified,
<b>filterping</b> takes precedence.</p>
<p> <b> routestopped</b> - Beginning with Shorewall 1.3.4, this option
is deprecated in favor of the <a href="#Routestopped">/etc/shorewall/routestopped</a>
file. When the firewall is stopped, traffic to and from this interface
will be accepted and routing will occur between this interface
and other <i>routestopped </i>interfaces.</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> multi</b> - The interface has multiple addresses and
you want to be able to route between them. Example: you have two
addresses on your single local interface eth1, one each in subnets
192.168.1.0/24 and 192.168.2.0/24 and you want to route between
these subnets. Because you only have one interface in the local
zone, Shorewall won't normally create a rule to forward packets from
eth1 to eth1. Adding "multi" to the entry for eth1 will cause
Shorewall to create the loc2loc chain and the appropriate forwarding
rule.</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,filterping,norfc1918,routefilter</b></li>
<li>Internal Interface -- <b>routestopped</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>,<b>multi</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 ignore ping requests
from the internet and 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,noping,norfc1918,blacklist</td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>detect</td>
<td><EFBFBD></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><EFBFBD></td>
<td><EFBFBD></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><EFBFBD></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 options.</li>
</ul>
<blockquote>
<p><b>routestopped</b> - Beginning with Shorewall
1.3.4, this option is deprecated in favor of the
<a href="#Routestopped">/etc/shorewall/routestopped</a>
file. When the firewall is stopped, traffic to and from
this host (these hosts) will be accepted and routing will occur
between this host and other <i>routestopped </i>interfaces and hosts.<br>
<br>
<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 1: </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><font color="#ff0000" size="4"><b>Note 2: </b>
</font> The setting of the MERGE_HOSTS variable
in <a href="#Conf">/etc/shorewall/shorewall.conf</a>
has an important effect on how the host file
is processed. Please read the description of
that variable carefully.</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<32></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,noping,norfc1918</td>
</tr>
<tr>
<td>-</td>
<td>eth1</td>
<td>detect</td>
<td><EFBFBD></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><EFBFBD></td>
</tr>
<tr>
<td>loc2</td>
<td>eth1:192.168.1.128/25</td>
<td>routestopped</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.<2E></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="configuration_file_basics.htm#Levels">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.<2E></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><EFBFBD></td>
<td><EFBFBD></td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td><EFBFBD></td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
<td><EFBFBD></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><EFBFBD>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><EFBFBD></td>
<td><EFBFBD></td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td><EFBFBD></td>
</tr>
<tr>
<td>loc</td>
<td>loc</td>
<td>REJECT</td>
<td>info</td>
<td><EFBFBD></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,noping,norfc1918</td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>detect</td>
<td>routestopped</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><EFBFBD></td>
</tr>
<tr>
<td>sam</td>
<td>eth0:206.191.149.197</td>
<td>routestopped</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><EFBFBD> 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><EFBFBD></td>
</tr>
<tr>
<td>sam</td>
<td>all</td>
<td>CONTINUE</td>
<td><EFBFBD></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><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></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><EFBFBD></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><EFBFBD></td>
</tr>
<tr>
<td>...</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></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> <20></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><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
</tr>
<tr>
<td>...</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
</tr>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>fw</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td><EFBFBD></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><EFBFBD></td>
</tr>
<tr>
<td>...</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></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.<2E><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 or REJECT. 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>REDIRECT -- Causes the connection request to be redirected
to a port on the local (firewall) system.</li>
</ul>
<p>The ACTION may optionally be followed by ":" and a <a
href="file:///home/teastep/Shorewall-docs/configuration_file_basics.htm#Levels">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.<br>
<br>
The use of DNAT or REDIRECT requires that you have <a
href="#NatEnabled">NAT enabled</a>.<br>
<20> </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, "all" or "related". Specifies the protocol
of the connection request. "related" should be specified only
if you have given ALLOWRELATED="no" in /etc/shorewall/shorewall.conf
and you wish to override that setting for related connections originating
with the client(s) and server(s) specified in this rule. When "related"
is given for the protocol, the remainder of the columns should
be left blank.</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:<3A> </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<41><54><EFBFBD><EFBFBD> loc<u>:192.168.1.0/24</u><EFBFBD><EFBFBD><EFBFBD>
loc:192.168.1.3<EFBFBD><EFBFBD><EFBFBD> tcp<63><70><EFBFBD> www<77><77><EFBFBD> -<2D><><EFBFBD> 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.<2E></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><EFBFBD></td>
<td><EFBFBD></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><EFBFBD></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><EFBFBD></td>
<td><EFBFBD></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><EFBFBD></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>loc</td>
<td>dmz:155.186.235.222</td>
<td>tcp</td>
<td>www</td>
<td><EFBFBD></td>
<td><EFBFBD></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><EFBFBD></td>
<td><EFBFBD></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<74> 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><EFBFBD></td>
<td><EFBFBD></td>
<td><EFBFBD></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>
PORTS(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.</blockquote>
<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<6F> (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.</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.<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.</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:<3A><><EFBFBD><EFBFBD></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><EFBFBD></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><EFBFBD></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>
<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>To learn how I use Proxy ARP in my DMZ, see <a href="myfiles.htm">my configuration
files</a>.</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.<2E></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><EFBFBD><EFBFBD><EFBFBD><EFBFBD> qt service ipsec stop</p>
<p>In /etc/shorewall/start, include:</p>
<p><EFBFBD><EFBFBD><EFBFBD> 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.</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.
<b> Note:</b> If two or more NATed systems are connected to the
same firewall interface and you want them to be able to communicate
using their EXTERNAL IP addresses, then you will want to specify the
<b>multi</b> option in the <a href="#Interfaces">/etc/shorewall/interface</a>
entry for that interface.</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<65>
<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
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.<2E></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> <20></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>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="file:///home/teastep/Shorewall-docs/Documentation.htm#rfc1918">'norfc1918'
mechanism </a><EFBFBD>are logged. The value must be a valid <a
href="file:///home/teastep/Shorewall-docs/configuration_file_basics.htm#Levels">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="file:///home/teastep/Shorewall-docs/configuration_file_basics.htm#Levels">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<68><a
href="file:///home/teastep/Shorewall-docs/configuration_file_basics.htm#Levels">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>FORWARDPING</b> - Added in Version 1.3.7<br>
When set to "Yes" or "yes", ICMP echo-request (ping) packets
from interfaces that specify "filterping" are ACCEPTed by the firewall.
When set to "No" or "no", such ping requests are silently dropped
unless they are handled by an explicit entry in the <a
href="#Rules">rules file</a>. If not specified, "No" is assumed.</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<68><a
href="file:///home/teastep/Shorewall-docs/configuration_file_basics.htm#Levels">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.<br>
<20></li>
<li><b>MERGE_HOSTS </b>- Added in Version 1.3.5<br>
Prior to 1.3.5, when the <a href="#Hosts">/etc/shorewall/hosts</a>
file included an entry for a zone then the entire zone had to be
defined in the /etc/shorewall/hosts file and any associations between
the zone and interfaces in the <a href="#Interfaces">/etc/shorewall/interfaces</a>
file were ignored. This behavior is preserved if MERGE_HOSTS=No or
if MERGE_HOSTS is not set or is set to the empty value.<br>
<br>
Beginning with version 1.3.5, if MERGE_HOSTS=Yes, then zone
assignments in the /etc/shorewall/hosts file are ADDED to those
in the /etc/shorewall/interfaces file. <br>
<br>
Example:<br>
<br>
Interfaces File:<br>
<20>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
id="AutoNumber2">
<tbody>
<tr>
<td><u><b>ZONE</b></u></td>
<td><u><b>HOSTS</b></u></td>
<td><u><b>BROADCAST</b></u></td>
<td><u><b>OPTIONS</b></u></td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>-</td>
<td>dhcp</td>
</tr>
<tr>
<td>-</td>
<td>ppp+</td>
<td><EFBFBD></td>
<td><EFBFBD></td>
</tr>
</tbody>
</table>
<p><br>
Hosts File:<br>
<20></p>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
id="AutoNumber3">
<tbody>
<tr>
<td><u><b>ZONE</b></u></td>
<td><u><b>HOSTS</b></u></td>
</tr>
<tr>
<td>loc</td>
<td>ppp+:192.168.12.0/24</td>
</tr>
</tbody>
</table>
<p><font face="Courier"><br>
</font>With MERGE_HOSTS=No, the<b> loc</b> zone consists of
only ppp+:192.168.12.0/24; with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0
and ppp+:192.168.12.0/24.<br>
<20> </p>
</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>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>
<20>
<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> ALLOWRELATED</b><br>
This parameter must be assigned the value "Yes"
("yes") or "No" ("no") and specifies whether Shorewall allows
connection requests that are related to an already allowed connection.
If you say "No" ("no"), you can still override this setting by
including "related" rules in /etc/shorewall/rules ("related" given
as the protocol). If you specify ALLOWRELATED=No, you will need to
include rules in <a href="shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>
to handle common ICMP packet types.</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>
<20><><EFBFBD> LOGRATE=10/minute<br>
<20><><EFBFBD> LOGBURST=5<br>
<20></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.<2E>NAT operations include:<br>
<br>
<20><><EFBFBD> Static NAT<br>
<20><><EFBFBD> Port Forwarding<br>
<20><><EFBFBD> Port Redirection<br>
<20><><EFBFBD> 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>
<20><><EFBFBD> On or on - packet forwarding will be enabled.<br>
<20><><EFBFBD> Off or off - packet forwarding will be disabled.<br>
<20><><EFBFBD> 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="file:///home/teastep/Shorewall-docs/configuration_file_basics.htm#Levels">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;<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD></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.<2E>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<EFBFBD> "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><EFBFBD> -- 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.<2E> 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="2"> Updated 12/20/2002 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
<20> <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
</p>
<font face="Century Gothic, Arial, Helvetica">
</font> <br>
<br>
<br>
</body>
</html>
View Git Blame Copy Permalink