extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-23 06:38:53 +01:00
Code Issues Packages Projects Releases Wiki Activity
580cfb6c61
shorewall_code/Shorewall-docs/Documentation.htm
teastep 72f67478b2 Shorewall-1.3.7 Changes 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@207 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2002-08-22 21:21:41 +00:00

2712 lines
139 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">
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">Shorewall 1.3 Reference</font></h1>
</td>
</tr>
</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
and in /var/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="#Masq">masq</a></b> - This file also describes IP masquerading under Shorewall
and is installed in /etc/shorewall.</li>
<li><b><a href="#Structure">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>&nbsp;
/etc/shorewall/firewall (/var/lib/shorewall/firewall in version 1.3.2 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="#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>
<a href="#Version">version</a></b> -- a file created in /etc/shorewall/
(/var/lib/shorewall in version 1.3.2 and later) 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
NET_BCAST=130.252.100.255
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 &quot;all&quot; 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+)</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 &quot;-&quot; in this column.
If you supply the special value &quot;detect&quot; in this column, the firewall will
automatically determine the broadcast address. In order to use &quot;detect&quot;:<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).&nbsp;</li>
</ul>
</li>
<li><b>
OPTIONS</b> - a comma-separated list of options. Possible options include:
<p>
<b>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 &quot;modems&quot; 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><b><font color="#FF6633">Update
12/20/2001: </font></b>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, &quot;info&quot; 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>.</p>
</li>
</ul>
<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> </font>
<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>&nbsp;</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>&nbsp;</td>
<td>&nbsp;</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">
<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>&nbsp;</td>
</tr>
</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 the form <i>&lt;subnet address&gt;/&lt;width&gt;
</i>(example - eth2:192.168.2.0/2)</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. Currently only a single
option is defined:</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.</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>&nbsp;</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>
<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>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
</tr>
</font>
<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="#FW">name of the firewall</a> zone 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="#FW">name of the firewall</a> zone or "all").</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 syslog level. See the syslog.conf man page for
a description of each log level.</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 (&quot;:&quot;)
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>
<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>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</font>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
<td>&nbsp;</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>
<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>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</font>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>loc</td>
<td>loc</td>
<td>REJECT</td>
<td>info</td>
<td>&nbsp;</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>
<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>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
</tr>
</font>
<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>
<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>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
</tr>
</font>
<tr>
<td>sam</td>
<td>all</td>
<td>CONTINUE</td>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
</tr>
</font>
<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>
<table border="1" cellpadding="2" style="border-collapse: collapse">
<tbody>
<tr>
<font face="Century Gothic, Arial, Helvetica">
<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>
</font>
</tr>
<tr>
<td>...</td>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</font>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td>&nbsp;</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>&nbsp;</td>
</tr>
<tr>
<td>...</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</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>
&nbsp;</p>
<table border="1" cellpadding="2" style="border-collapse: collapse">
<tr>
<font face="Century Gothic, Arial, Helvetica">
<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>
</font>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>...</td>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</font>
</tr>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>fw</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td>&nbsp;</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>&nbsp;</td>
</tr>
<tr>
<td>...</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</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></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). &quot;DNAT&quot; stands for &quot;<u>D</u>estination
<u>N</u>etwork <u>A</u>ddress <u>T</u>ranslation&quot;</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
&quot;:&quot; and a syslogd log level (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>
&nbsp;</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 or $FW. If the
ACTION is DNAT or REDIRECT, sub-zones may be excluded from the rule by
following the initial zone name with &quot;!' and a comma-separated list of those
sub-zones to be excluded. There is an <a href="#Exclude">example</a> above.<br>
<br>
The source may be further restricted by adding a colon (&quot;:&quot;) 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).</li>
<li>An IP address - refers to a connection request from the host with
the specified address (example net:155.186.235.151)</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).&nbsp;</li>
<li>A single port number (again, service names are not allowed) -- this form is only allowed
if the ACTION is REDIRECT and refers to a server running on the firewall itself and
listening on the specified port.</li>
</ul>
</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 &quot;-&quot; 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 &quot;:&quot; 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 &quot;Source NAT&quot; 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&nbsp;&nbsp;&nbsp;&nbsp; loc<u>:192.168.1.0/24</u>&nbsp;&nbsp;&nbsp;
loc:192.168.1.3&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; www&nbsp;&nbsp;&nbsp;
-&nbsp;&nbsp;&nbsp; 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>
<table border="1" cellpadding="2" style="border-collapse: collapse">
<tbody>
<tr>
<font face="Century Gothic, Arial, Helvetica">
<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>
</font>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td>&nbsp;</td>
<td>&nbsp;</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 &quot;!&quot;)</a> originally
destined to 206.124.146.177 are
redirected to local port 3128.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse">
<tbody>
<tr>
<font face="Century Gothic, Arial, Helvetica">
<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>
</font>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc</td>
<td>3128</td>
<td>tcp</td>
<td>www</td>
<td>&nbsp;</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>&nbsp;</td>
<td>&nbsp;</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>
<table border="1" cellpadding="2" style="border-collapse: collapse">
<tbody>
<tr>
<font face="Century Gothic, Arial, Helvetica">
<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>
</font>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>dmz:155.186.235.222</td>
<td>tcp</td>
<td>www</td>
<td>-</td>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
</tr>
</font>
<tr>
<td>ACCEPT</td>
<td>loc</td>
<td>dmz:155.186.235.222</td>
<td>tcp</td>
<td>www</td>
<td>&nbsp;</td>
<td>&nbsp;</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>
<table border="1" cellpadding="2" style="border-collapse: collapse">
<tbody>
<tr>
<font face="Century Gothic, Arial, Helvetica">
<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>
</font>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>dmz:192.168.2.2</td>
<td>tcp</td>
<td>ftp</td>
<td>&nbsp;</td>
<td>&nbsp;</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>
<font face="Century Gothic, Arial, Helvetica">
<td>-</td>
</font>
<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>
<table border="1" cellpadding="2" style="border-collapse: collapse">
<tr>
<font face="Century Gothic, Arial, Helvetica">
<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>
</font>
</tr>
<tr>
<td>ACCEPT</td>
<td>loc:~02-00-08-E3-FA-55</td>
<td>dmz</td>
<td>all</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</table>
</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&nbsp; (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 &quot;!'
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>&nbsp;</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>&nbsp;</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">
<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>
</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">
<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>
</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
&quot;Yes&quot;
or
&quot;yes&quot;.
If you want
Shorewall to add
the route, the
column should
contain
&quot;No&quot;
or
&quot;no&quot;.</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 &quot;tcpdump
-nei &lt;external interface&gt; host &lt;IP addr&gt;&quot;), 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
&quot;Yes&quot; 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.&nbsp;</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>&nbsp;&nbsp;&nbsp;&nbsp; qt service ipsec stop</p>
<p>In /etc/shorewall/start, include:</p>
<p>&nbsp;&nbsp;&nbsp; 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&nbsp; <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 and IPIP 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>and <b><a href="IPIP.htm">instructions for IPIP tunnels are here</a>
. </b>Look <a href="PPTP.htm">here</a> for information about setting up PPTP
tunnels under
Shorewall.</p>
<h2><font color="#660066"><a name="Conf"></a>
</font>/etc/shorewall/shorewall.conf</h2>
<p>
This file is used to set the following firewall parameters:</p>
<ul>
<li><b>FORWARDPING</b> - Added in Version 1.3.7<br>
When set to &quot;Yes&quot; or &quot;yes&quot;, ICMP echo-request (ping) packets from interfaces
that specify &quot;filterping&quot; are ACCEPTed by the firewall. When set to &quot;No&quot; or
&quot;no&quot;, 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, &quot;No&quot;
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 syslog level at which you want the packets logged.
Example: LOGNEWNOTSYN=debug|<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>
&nbsp;</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>
&nbsp;<table border="1" cellpadding="2" style="border-collapse: collapse" id="AutoNumber2">
<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>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</table>
<p><br>
Hosts File:<br>
&nbsp;</p>
<table border="1" cellpadding="2" style="border-collapse: collapse" id="AutoNumber3">
<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>
</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>
&nbsp;</li>
<li><b>MULTIPORT</b> - Added in Version 1.3.2<br>
If set to &quot;Yes&quot; or &quot;yes&quot;, 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>
&nbsp;<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.</li>
<li><b>NAT_BEFORE_RULES</b><br>
If set to &quot;No&quot; or &quot;no&quot;, port forwarding rules can override the contents of
the <a href="#NAT">/etc/shorewall/nat</a> file. If set to &quot;Yes&quot; or &quot;yes&quot;,
port forwarding rules cannot override static NAT. If not set or set to an
empty value, &quot;Yes&quot; 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
&quot;fw&quot;
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>
&nbsp;&nbsp;&nbsp; LOGRATE=10/minute<br>
&nbsp;&nbsp;&nbsp; LOGBURST=5<br>
&nbsp;</li>
<li><b>LOGFILE</b><br>
This parameter
tells the
/sbin/shorewall
program where
to look for
Shorewall
messages when
processing the
&quot;show
log&quot;,
&quot;monitor&quot;,
&quot;status&quot;
and
&quot;hits&quot;
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 &quot;Yes&quot; or &quot;yes&quot; then Shorewall automatically adds these addresses. If
it is set to &quot;No&quot; or &quot;no&quot;, 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 syslog
log level
(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
&quot;Yes&quot;
or
&quot;yes&quot;,
the feature is
enabled. If
left blank or
set to
&quot;No&quot;
or
&quot;no&quot;,
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 &quot;Yes&quot; or &quot;yes&quot; then route filtering
(anti-spoofing) is
enabled on all network interfaces. The default value is &quot;no&quot;.</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<69> "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>&nbsp; -- 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
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.</p>
<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.</li>
</ul>
</li>
</ul>
<h2><a name="Routestopped"></a>25. /etc/shorewall/routestopped (Added in Version 1.3.4)</h2>
<p>This fine defines the hosts that are accessible from the firewall when the firewall is stopped.&nbsp; 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 &quot;-&quot; 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">
<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>
</table>
</blockquote>
<p><font size="2">
Updated 8/22/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></p>
<font face="Century Gothic, Arial, Helvetica">
</font></body></html>
Reference in New Issue View Git Blame Copy Permalink