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