forked from extern/shorewall_code
f158c11a41
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@208 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2712 lines
139 KiB
HTML
2712 lines
139 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.3 Documentation</title>
|
||
|
||
|
||
<base target="_self">
|
||
<meta name="Microsoft Theme" content="none, default">
|
||
<meta name="Microsoft Border" content="none, default">
|
||
</head>
|
||
<body>
|
||
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" width="100%" id="AutoNumber4" bgcolor="#400169" height="90">
|
||
<tr>
|
||
<td width="100%">
|
||
<h1 align="center"><font color="#FFFFFF">Shorewall 1.3 Reference</font></h1>
|
||
</td>
|
||
</tr>
|
||
</table>
|
||
|
||
|
||
|
||
<h2 align="center">This documentation is intended primarily for reference.
|
||
Step-by-step instructions for configuring Shorewall in common setups may
|
||
be found in the <a href="shorewall_quickstart_guide.htm">QuickStart Guides</a>.</h2>
|
||
|
||
|
||
|
||
<h2>Components</h2>
|
||
|
||
<p>Shorewall consists of the following components: </p>
|
||
|
||
<ul>
|
||
<li><b><a href="#Variables">params</a></b> -- a parameter file installed in
|
||
/etc/shorewall that can be used to establish the values of shell variables
|
||
for use in other files.</li>
|
||
<li><b>
|
||
<a href="#Conf">shorewall.conf</a></b> -- a parameter file installed in /etc/shorewall
|
||
that is used to set several firewall parameters.</li>
|
||
<li><b>
|
||
<a href="#Zones">zones</a></b> - a parameter file installed in /etc/shorewall that defines
|
||
a network partitioning into "zones"</li>
|
||
<li><b>
|
||
<a href="#Policy">policy</a></b> -- a parameter file installed in /etc/shorewall/ that
|
||
establishes overall firewall policy.</li>
|
||
<li><b>
|
||
<a href="#Rules">rules</a> </b> -- a parameter file installed in /etc/shorewall and used
|
||
to express firewall rules that are exceptions to the high-level
|
||
policies established in /etc/shorewall/policy.</li>
|
||
<li><b><a href="#Blacklist">blacklist</a> -- </b>a parameter file installed in /etc/shorewall and used
|
||
to list blacklisted IP/subnet/MAC addresses.</li>
|
||
<li><b>
|
||
functions</b> -- a set of shell functions used by both the firewall and
|
||
shorewall shell programs. Installed in /etc/shorewall prior to version 1.3.2
|
||
and in /var/lib/shorewall in later versions.</li>
|
||
<li><b>
|
||
<a href="#modules">modules</a></b> -- a parameter file installed in /etc/shorewall and that
|
||
specifies kernel modules and their parameters. Shorewall will automatically
|
||
load the modules specified in this file.</li>
|
||
<li><a href="#TOS"><b>
|
||
tos</b> </a>-- a parameter file installed in /etc/shorewall that is used to
|
||
specify how the Type of Service (TOS) field in packets is to be set.</li>
|
||
<li><a href="#Scripts"><b>
|
||
icmp.def</b> </a>-- a parameter file installed in /etc/shorewall and that
|
||
specifies the default handling of ICMP packets when the applicable policy is
|
||
DROP or REJECT.</li>
|
||
<li><b><a href="#Scripts">common.def</a></b> -- a parameter file installed in
|
||
in /etc/shorewall that defines firewall-wide rules that are applied before a
|
||
DROP or REJECT policy is applied.</li>
|
||
<li><b>
|
||
<a href="#Interfaces">interfaces</a> </b> -- a parameter file installed in /etc/shorewall/ and
|
||
used to describe the interfaces on the firewall system.</li>
|
||
<li><a href="#Hosts"><b>
|
||
hosts</b> </a>-- a parameter file installed in /etc/shorewall/ and used
|
||
to describe individual hosts or subnetworks in zones.</li>
|
||
<li><b>
|
||
<a href="#Masq">masq</a></b> - This file also describes IP masquerading under Shorewall
|
||
and is installed in /etc/shorewall.</li>
|
||
<li><b><a href="#Structure">firewall</a></b> -- a shell program that reads the configuration files in
|
||
/etc/shorewall and configures your firewall. This file is
|
||
installed in your init.d directory (/etc/rc.d/init.d ) where it is renamed <i>shorewall.</i>
|
||
/etc/shorewall/firewall (/var/lib/shorewall/firewall in version 1.3.2 and
|
||
later) is a symbolic link to this program.</li>
|
||
<li><b>
|
||
<a href="#NAT">nat</a></b> -- a parameter file in /etc/shorewall used to define <a href="#NAT">
|
||
static NAT</a>
|
||
.</li>
|
||
<li><b>
|
||
<a href="#ProxyArp">proxyarp</a></b> -- a parameter file in /etc/shorewall used to define <a href="#ProxyArp">
|
||
Proxy Arp</a>
|
||
.</li>
|
||
<li><b><a href="#Routestopped">routestopped</a></b> -- a parameter file in
|
||
/etc/shorewall used to define those hosts that can access the firewall when
|
||
Shorewall is stopped.</li>
|
||
<li><a href="traffic_shaping.htm#tcrules"><b>tcrules</b> </a>-- a parameter file in /etc/shorewall used to define rules for
|
||
classifying packets for <a href="traffic_shaping.htm">Traffic
|
||
Shaping/Control</a>.</li>
|
||
<li><b>
|
||
<a href="#Tunnels">tunnels</a></b> -- a parameter file in /etc/shorewall used to define
|
||
IPSec tunnels.</li>
|
||
<li><b>
|
||
<a href="#Starting">shorewall</a> </b> -- a shell program (requiring a Bourne
|
||
shell or derivative) used to control and monitor
|
||
the firewall. This should be placed in /sbin or in /usr/sbin
|
||
(the install.sh script and the rpm install this file in /sbin).</li>
|
||
<li><b>
|
||
<a href="#Version">version</a></b> -- a file created in /etc/shorewall/
|
||
(/var/lib/shorewall in version 1.3.2 and later) that describes
|
||
the version of<6F> Shorewall installed on your system.</li>
|
||
</ul>
|
||
|
||
|
||
<h2><a name="Variables"></a>
|
||
/etc/shorewall/params</h2>
|
||
|
||
<p>You may use the file /etc/shorewall/params
|
||
file to set shell variables that you can then use in some of the other
|
||
configuration files.</p>
|
||
|
||
<p>It is suggested that variable names begin with an upper case letter<font size="1">
|
||
</font>to distinguish them from variables used internally within the
|
||
Shorewall programs</p>
|
||
|
||
<p>Example:</p>
|
||
|
||
<pre><font face="Courier"> NET_IF=eth0
|
||
NET_BCAST=130.252.100.255
|
||
NET_OPTIONS=noping,norfc1918</font></pre>
|
||
<p>Example (/etc/shorewall/interfaces record):</p>
|
||
<pre> <font face="Courier">net $NET_IF $NET_BCAST $NET_OPTIONS</font></pre>
|
||
<p>The result will be the same as if the record had been written</p>
|
||
<pre> <font face="Courier">net eth0 130.252.100.255 noping,norfc1918</font></pre>
|
||
<p>Variables may be used anywhere in the
|
||
other configuration files.</p>
|
||
|
||
<h2><b><a name="Zones"></a>
|
||
</b>/etc/shorewall/zones</h2>
|
||
|
||
<p>This file is used
|
||
to define the network zones. There is one entry in /etc/shorewall/zones
|
||
for each zone; Columns in an entry are:</p>
|
||
|
||
<ul>
|
||
<li><b>
|
||
ZONE</b> - short name for the zone. The name should be 5 characters or less in
|
||
length and consist of lower-case letters or numbers. Short names must begin
|
||
with a letter and the name assigned to the firewall is reserved for use by Shorewall itself. Note that the output produced
|
||
by iptables is much easier to read if you select short names that
|
||
are three characters or less in length. The name "all" may not be used as
|
||
a zone name nor may the zone name assigned to the firewall itself via the FW
|
||
variable in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
||
<li><b>
|
||
DISPLAY</b> - The name of the zone as displayed during Shorewall startup.</li>
|
||
<li><b>
|
||
COMMENTS</b> - Any comments that you want to make about the zone. Shorewall
|
||
ignores these comments.</li>
|
||
</ul>
|
||
|
||
|
||
<p>The /etc/shorewall/zones file released with Shorewall
|
||
is as follows:</p>
|
||
|
||
<table border="1" style="border-collapse: collapse" cellpadding="2">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
DISPLAY</b></td>
|
||
<td><b>
|
||
COMMENTS</b></td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td>net</td>
|
||
<td>Net</td>
|
||
<td>Internet</td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>Local</td>
|
||
<td>Local networks</td>
|
||
</tr>
|
||
<tr>
|
||
<td>dmz</td>
|
||
<td>DMZ</td>
|
||
<td>Demilitarized zone</td>
|
||
</tr>
|
||
|
||
</tbody>
|
||
</table>
|
||
<p>You may
|
||
add, delete and modify entries in the /etc/shorewall/zones file as desired
|
||
so long as you have at least one zone defined.</p>
|
||
|
||
<p><b><font size="5" color="#ff0000">
|
||
Warning 1: </font><font color="#ff0000"> If you rename or delete a zone,
|
||
you should perform "shorewall stop; shorewall start" to install the change
|
||
rather than "shorewall restart".</font></b></p>
|
||
|
||
<p><b><font size="5" color="#FF0000">Warning 2: </font><font color="#FF0000">The
|
||
order of entries in the /etc/shorewall/zones file is significant <a href="#Nested">in
|
||
some cases</a>.</font></b></p>
|
||
|
||
<h2><font color="#660066"><a name="Interfaces"></a>
|
||
</font>/etc/shorewall/interfaces</h2>
|
||
|
||
<p>This file
|
||
is used to tell the firewall which of your firewall's network interfaces
|
||
are connected to which zone. There will be one entry in /etc/shorewall/interfaces
|
||
for each of your interfaces. Columns in an entry are:</p>
|
||
<ul>
|
||
<li><b>
|
||
ZONE</b> - A zone defined in the <a href="#Zones">/etc/shorewall/zones</a>
|
||
file or<6F> "-". If you specify "-", you must use the <a href="#Hosts">
|
||
/etc/shorewall/hosts</a>
|
||
file to define the zones accessed via this interface.</li>
|
||
<li><b>
|
||
INTERFACE</b> - the name of the interface (examples: eth0, ppp0, ipsec+)</li>
|
||
<li><b>
|
||
BROADCAST</b> - the broadcast address(es) for the sub-network(s) attached to the
|
||
interface. This should be left empty for P-T-P interfaces (ppp*, ippp*); if
|
||
you need to specify options for such an interface, enter "-" in this column.
|
||
If you supply the special value "detect" in this column, the firewall will
|
||
automatically determine the broadcast address. In order to use "detect":<ul>
|
||
<li>you must have iproute installed</li>
|
||
<li>the interface must be up before you start your firewall</li>
|
||
<li>the interface must only be attached to
|
||
a single sub-network (i.e., there must have a single broadcast address). </li>
|
||
</ul>
|
||
|
||
</li>
|
||
<li><b>
|
||
OPTIONS</b> - a comma-separated list of options. Possible options include:
|
||
<p>
|
||
<b>blacklist</b> - This option causes incoming packets on this
|
||
interface to be checked against the <a href="#Blacklist">blacklist</a>.<b><br>
|
||
<br>
|
||
dhcp</b> - The interface is assigned an IP address via DHCP or is used
|
||
by a DHCP server running on the firewall. The firewall will be configured
|
||
to allow DHCP traffic to and from the interface even when the firewall
|
||
is stopped. You may also wish to use this option if you have a static IP but
|
||
you are on a LAN segment that has a lot of Laptops that use DHCP and you
|
||
select the <b>norfc1918 </b>option (see below).</p>
|
||
|
||
<p>
|
||
<b>
|
||
noping</b> - ICMP echo-request (ping) packets addressed to the firewall will be ignored by this
|
||
interface.<br>
|
||
<br>
|
||
<b>filterping </b>- ICMP echo-request (ping) packets addressed to the firewall
|
||
will be handled according to the /etc/shorewall/rules and
|
||
/etc/shorewall/policy file. If the applicable policy is DROP or REJECT and you
|
||
have supplied your own /etc/shorewall/icmpdef file then these 'ping' requests
|
||
will be passed through the rules in that file before being dropped or
|
||
rejected. If neither <b>noping </b>nor <b>filterping</b> is specified then the
|
||
firewall will automatically ACCEPT these 'ping' requests. If both <b>noping</b>
|
||
and <b>filterping </b>are specified, <b>filterping</b> takes precedence.</p>
|
||
|
||
<p>
|
||
<b>
|
||
routestopped</b> - Beginning with Shorewall 1.3.4, this option is deprecated
|
||
in favor of the <a href="#Routestopped">/etc/shorewall/routestopped</a> file. When the firewall is stopped, traffic to and from
|
||
this interface will be accepted and routing will occur between this
|
||
interface and other <i>routestopped </i>interfaces.</p>
|
||
|
||
<p>
|
||
<b>
|
||
norfc1918</b> - Packets arriving on this interface and that have a source
|
||
address that is reserved in RFC 1918 or in other RFCs will be dropped after
|
||
being optionally logged. If <a href="#Conf">packet mangling is
|
||
enabled in /etc/shorewall/shorewall.conf</a>
|
||
, then packets arriving on this interface that have a destination address
|
||
that is reserved by one of these RFCs will also be logged and dropped.<br>
|
||
<br>
|
||
Addresses blocked by the standard <a href="#rfc1918"> <b>rfc1918 </b>file</a>
|
||
include those addresses reserved by RFC1918 plus other ranges reserved by the
|
||
IANA or by other RFCs.</p>
|
||
|
||
<p>
|
||
Beware that as IPv4 addresses become in increasingly short supply, ISPs are
|
||
beginning to use RFC 1918 addresses within their own infrastructure. Also,
|
||
many cable and DSL "modems" have an RFC 1918 address that can be used through
|
||
a web browser for management and monitoring functions. If you want to specify
|
||
<b>norfc1918</b> on your external interface but need to allow access to
|
||
certain addresses from the above list, see <a href="FAQ.htm#faq14">FAQ 14.</a></p>
|
||
|
||
<p>
|
||
<b>
|
||
routefilter</b> - Invoke the Kernel's route filtering (anti-spoofing) facility on this
|
||
interface. The kernel will reject any packets incoming on this interface
|
||
that have a source address that would be routed outbound through another
|
||
interface on the firewall. <font color="#ff0000">Warning: </font>If
|
||
you specify this option for an interface then the interface must be
|
||
up prior to starting the firewall.</p>
|
||
|
||
<p>
|
||
<b>
|
||
multi</b> - The interface has multiple addresses and you want to be able
|
||
to route between them. Example: you have two addresses on your single
|
||
local interface eth1, one each in subnets 192.168.1.0/24 and 192.168.2.0/24
|
||
and you want to route between these subnets. Because you only have
|
||
one interface in the local zone, Shorewall won't normally create a
|
||
rule to forward packets from eth1 to eth1. Adding "multi" to the entry
|
||
for eth1 will cause Shorewall to create the loc2loc chain and the
|
||
appropriate forwarding rule.</p>
|
||
<p><b>dropunclean</b> - Packets from this interface that
|
||
are selected by the 'unclean' match target in iptables will
|
||
be <a href="#LogUnclean">optionally logged</a> and then dropped. <font color="#FF0000"><b>Warning: This feature
|
||
requires that UNCLEAN match support be configured in your
|
||
kernel, either in the kernel itself or as a module. UNCLEAN
|
||
support is broken in some versions of the kernel but appears
|
||
to work ok in 2.4.17-rc1.<br>
|
||
<br>
|
||
Update 12/17/2001: </b></font>The unclean match patch from
|
||
2.4.17-rc1 is <a href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean.patch">available
|
||
for download</a>. I am currently running this patch applied
|
||
to kernel 2.4.16.</p>
|
||
<p><b><font color="#FF6633">Update
|
||
12/20/2001: </font></b>I've
|
||
seen a number of tcp connection requests with OPT (020405B4<u>0000080A</u>...)
|
||
being dropped in the <i>badpkt</i> chain. This appears to be
|
||
a bug in the remote TCP stack whereby it is 8-byte aligning
|
||
a timestamp (TCP option 8) but rather than padding with 0x01
|
||
it is padding with 0x00. It's a tough call whether to deny
|
||
people access to your servers because of this rather minor
|
||
bug in their networking software. If you wish to disable the
|
||
check that causes these connections to be dropped, <a href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean1.patch">here's
|
||
a kernel patch</a> against 2.4.17-rc2.</p>
|
||
<p><b>logunclean
|
||
</b>- This option works like <b>dropunclean</b>
|
||
with the exception that packets selected by the 'unclean'
|
||
match target in iptables are logged <i>but not dropped</i>.
|
||
The level at which the packets are logged is determined by
|
||
the setting of <a href="#LogUnclean">LOGUNCLEAN</a> and if
|
||
LOGUNCLEAN has not been set, "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>.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>Example
|
||
1: You have a conventional firewall setup in which eth0 connects to a
|
||
Cable or DSL modem and eth1 connects to your local network and eth0 gets
|
||
its IP address via DHCP. You want to ignore ping requests from the internet
|
||
and you want to check all packets entering from the internet
|
||
against the <a href="#Blacklist">black list</a>. Your /etc/shorewall/interfaces file would be as follows:</p>
|
||
|
||
<blockquote> </font>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
INTERFACE</b></td>
|
||
<td><b>
|
||
BROADCAST</b></td>
|
||
<td><b>
|
||
OPTIONS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>net</td>
|
||
<td>eth0</td>
|
||
<td>detect</td>
|
||
<td>dhcp,noping,norfc1918,blacklist</td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>eth1</td>
|
||
<td>detect</td>
|
||
<td> </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> </td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
|
||
<p>Example 3: You have local interface eth1 with two IP
|
||
addresses - 192.168.1.1/24 and 192.168.12.1/24</p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
INTERFACE</b></td>
|
||
<td><b>
|
||
BROADCAST</b></td>
|
||
<td><b>
|
||
OPTIONS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>eth1</td>
|
||
|
||
<td>192.168.1.255,192.168.12.255</td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
</table>
|
||
</blockquote>
|
||
|
||
<h2><font color="#660066"><a name="Hosts"></a>
|
||
</font>/etc/shorewall/hosts Configuration</h2>
|
||
|
||
<p>For most applications, specifying zones entirely
|
||
in terms of network interfaces is sufficient. There may be times though
|
||
where you need to define a zone to be a more general collection of hosts.
|
||
This is the purpose of the /etc/shorewall/hosts file.</p>
|
||
|
||
|
||
<p><b><font color="#FF0000">WARNING: </font>90% of
|
||
Shorewall users don't need to put entries in this file and
|
||
80% of those who try to add such entries do it wrong.
|
||
Unless you are ABSOLUTELY SURE that you need entries in
|
||
this file, don't touch it.</b></p>
|
||
|
||
|
||
<p>Columns in this
|
||
file are:</p>
|
||
|
||
|
||
<ul>
|
||
<li><b>
|
||
ZONE </b> - A zone defined in the <a href="#Zones">/etc/shorewall/zones</a>
|
||
file.</li>
|
||
<li><b>
|
||
HOST(S)</b> - The name of a network interface followed by a colon (":")
|
||
followed by either:</li>
|
||
</ul>
|
||
|
||
|
||
<blockquote>
|
||
|
||
<ol>
|
||
|
||
<li>An IP address (example - eth1:192.168.1.3)</li>
|
||
|
||
<li>A subnet in the form <i><subnet address>/<width>
|
||
</i>(example - eth2:192.168.2.0/2)</li>
|
||
|
||
</ol>
|
||
|
||
<p>The interface name much match an entry in
|
||
/etc/shorewall/interfaces.</p>
|
||
</blockquote>
|
||
|
||
|
||
<ul>
|
||
<li><b>
|
||
OPTIONS</b> - A comma-separated list of options. Currently only a single
|
||
option is defined:</li>
|
||
</ul>
|
||
|
||
|
||
<blockquote>
|
||
|
||
<p><b>routestopped</b> - Beginning with Shorewall
|
||
1.3.4, this option is deprecated in favor of the
|
||
<a href="#Routestopped">/etc/shorewall/routestopped</a>
|
||
file. When the firewall is stopped,
|
||
traffic to and from this host (these hosts) will be accepted and routing
|
||
will occur between this host and other <i>routestopped </i>interfaces
|
||
and hosts.</p>
|
||
</blockquote>
|
||
|
||
<p>If you don't define any hosts for a zone, the
|
||
hosts in the zone default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0,
|
||
i1, ... are the interfaces to the zone.</p>
|
||
|
||
<p><b><font size="4" color="#ff0000">Note 1: </font></b>
|
||
You probably DON'T want to specify any hosts for your internet zone
|
||
since the hosts that you specify will be the only ones that you will be
|
||
able to access without adding additional rules.</p>
|
||
|
||
<p><font color="#ff0000" size="4"><b>Note 2:
|
||
</b>
|
||
</font>
|
||
The setting of the MERGE_HOSTS variable in
|
||
<a href="#Conf">/etc/shorewall/shorewall.conf</a> has
|
||
an important effect on how the host file is processed.
|
||
Please read the description of that variable
|
||
carefully.</p>
|
||
|
||
<p>Example:</p>
|
||
|
||
<p>Your local interface is eth1 and you have two
|
||
groups of local hosts that you want to make into separate zones:</p>
|
||
|
||
|
||
<ul>
|
||
<li>192.168.1.0/25<32></li>
|
||
<li>192.168.1.128/25</li>
|
||
</ul>
|
||
|
||
<p>
|
||
Your /etc/shorewall/interfaces file might look like:</p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
INTERFACE</b></td>
|
||
<td><b>
|
||
BROADCAST</b></td>
|
||
<td><b>
|
||
OPTIONS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>net</td>
|
||
<td>eth0</td>
|
||
<td>detect</td>
|
||
<td>dhcp,noping,norfc1918</td>
|
||
</tr>
|
||
<tr>
|
||
<td>-</td>
|
||
<td>eth1</td>
|
||
<td>detect</td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
|
||
<p>
|
||
The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces
|
||
to multiple zones.</p>
|
||
|
||
<p>
|
||
Your /etc/shorewall/hosts file might look like:</p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
HOST(S)</b></td>
|
||
<td><b>
|
||
OPTIONS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc1</td>
|
||
<td>eth1:192.168.1.0/25</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
|
||
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>loc2</td>
|
||
<td>eth1:192.168.1.128/25</td>
|
||
<td>routestopped</td>
|
||
</tr>
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
|
||
<p>
|
||
Hosts in 'loc2' can communicate with the firewall while Shorewall is stopped
|
||
-- those in 'loc1' cannot.</p>
|
||
|
||
<h4><font color="#660066"><a name="Nested"></a>
|
||
Nested and Overlapping Zones</font></h4>
|
||
|
||
<p>
|
||
The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow you
|
||
to define nested or overlapping zones. Such overlapping/nested zones are
|
||
allowed and Shorewall processes zones in the order that they appear in
|
||
the /etc/shorewall/zones file. So if you have nested zones, you want the
|
||
sub-zone to appear before the super-zone and in the case of overlapping
|
||
zones, the rules that will apply to hosts that belong to both zones is determined
|
||
by which zone appears first in /etc/shorewall/zones.</p>
|
||
|
||
<p>
|
||
Hosts that belong to more than
|
||
one zone may be managed by the rules of all of those zones. This is done through
|
||
use of the special <a href="#CONTINUE">CONTINUE policy</a>
|
||
described below.</p>
|
||
|
||
<h2><font color="#660066"><a name="Policy"></a>
|
||
</font>/etc/shorewall/policy Configuration.</h2>
|
||
|
||
<p>This file is used to describe the firewall
|
||
policy regarding establishment of connections. Connection establishment
|
||
is described in terms of <i>clients</i> who initiate connections and <i>
|
||
servers </i>who receive those connection requests. Policies defined in
|
||
/etc/shorewall/policy describe which zones are allowed to establish connections
|
||
with other zones.</p>
|
||
|
||
<p>Policies established in /etc/shorewall/policy
|
||
can be viewed as default policies. If no rule in /etc/shorewall/rules
|
||
applies to a particular connection request then the policy from /etc/shorewall/policy
|
||
is applied.</p>
|
||
|
||
<p>Four policies are defined:</p>
|
||
|
||
|
||
<ul>
|
||
<li><b>
|
||
ACCEPT</b> - The connection is allowed.</li>
|
||
<li><b>
|
||
DROP</b> - The connection request is ignored.</li>
|
||
<li><b>
|
||
REJECT</b> - The connection request is rejected with an RST (TCP) or an ICMP destination-unreachable
|
||
packet being returned to the client.</li>
|
||
<li><b>
|
||
CONTINUE </b> - The connection is neither ACCEPTed, DROPped nor REJECTed.
|
||
CONTINUE may be used when one or both of the zones named in the entry are
|
||
sub-zones of or intersect with another zone. For more information, see
|
||
below.<2E></li>
|
||
</ul>
|
||
|
||
<p>
|
||
For each policy specified in /etc/shorewall/policy, you can indicate
|
||
that you want a message sent to your system log each time that the policy
|
||
is applied.</p>
|
||
|
||
<p>
|
||
Entries in /etc/shorewall/policy have four columns as follows:</p>
|
||
|
||
<ol>
|
||
|
||
<li>
|
||
<b>
|
||
SOURCE</b> - The name of a client zone (a zone defined in the <a href="#Zones">
|
||
/etc/shorewall/zones file</a>
|
||
, the <a href="#FW">name of the firewall</a> zone or "all").</li>
|
||
|
||
<li>
|
||
<b>
|
||
DEST</b> - The name of a destination zone (a zone defined in the <a href="#Zones">
|
||
/etc/shorewall/zones file</a>
|
||
, the <a href="#FW">name of the firewall</a> zone or "all").</li>
|
||
|
||
<li>
|
||
<b>
|
||
POLICY</b> - The default policy for connection requests from the SOURCE
|
||
zone to the DESTINATION zone.</li>
|
||
|
||
<li>
|
||
<b>
|
||
LOG LEVEL</b> - Optional. If left empty, no log message is generated when
|
||
the policy is applied. Otherwise, this column should contain an integer
|
||
or name indicating a syslog level. See the syslog.conf man page for
|
||
a description of each log level.</li>
|
||
|
||
<li>
|
||
<b>LIMIT:BURST </b>- Optional. If left empty, TCP
|
||
connection requests from the <b>SOURCE</b> zone to the <b>DEST</b> zone will
|
||
not be rate-limited. Otherwise, this column specifies the maximum rate at
|
||
which TCP connection requests will be accepted followed by a colon (":")
|
||
followed by the maximum burst size that will be tolerated. Example: <b>
|
||
10/sec:40</b> specifies that the maximum rate of TCP connection requests
|
||
allowed will be 10 per second and a burst of 40 connections will be tolerated.
|
||
Connection requests in excess of these limits will be dropped.</li>
|
||
|
||
</ol>
|
||
|
||
<p>
|
||
In the SOURCE and DEST columns, you can enter "all" to indicate all
|
||
zones.<2E></p>
|
||
|
||
<p>
|
||
The policy file installed by default is as follows:</p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
POLICY</b></td>
|
||
<td><b>
|
||
LOG LEVEL</b></td>
|
||
<td><b>LIMIT:BURST</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>net</td>
|
||
<td>ACCEPT</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
|
||
|
||
<td> </td>
|
||
|
||
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>net</td>
|
||
<td>all</td>
|
||
<td>DROP</td>
|
||
<td>info</td>
|
||
<td> </td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>REJECT</td>
|
||
<td>info</td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
|
||
<p>
|
||
This table may be interpreted as follows:</p>
|
||
|
||
<ul>
|
||
<li>All connection requests from the local network to hosts on the internet
|
||
are accepted.</li>
|
||
<li>All connection requests originating from the internet are ignored and
|
||
logged at level KERNEL.INFO.</li>
|
||
<li>All other connection requests are rejected and logged.</li>
|
||
</ul>
|
||
<p><b><font size="4" color="#ff0000">
|
||
WARNING:</font></b></p>
|
||
<p><font color="#ff0000"><b>
|
||
The firewall script processes</b> <b><EFBFBD>the /etc/shorewall/policy file
|
||
from top to bottom and <u>uses the first applicable policy that it finds.</u>
|
||
For example, in the following policy file, the policy for (loc, loc)
|
||
connections would be ACCEPT as specified in the first entry even though
|
||
the third entry in the file specifies REJECT.</b></font></p>
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>POLICY</b></td>
|
||
<td><b>LOG LEVEL</b></td>
|
||
<td><b>LIMIT:BURST</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>all</td>
|
||
<td>ACCEPT</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>net</td>
|
||
<td>all</td>
|
||
<td>DROP</td>
|
||
<td>info</td>
|
||
<td> </td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>loc</td>
|
||
<td>REJECT</td>
|
||
<td>info</td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
<h4><font color="#660066"><a name="CONTINUE"></a>
|
||
The CONTINUE policy</font></h4>
|
||
<p>
|
||
Where zones are <a href="#Nested">nested or overlapping</a>
|
||
, the CONTINUE policy allows hosts that are within multiple zones to be
|
||
managed under the rules of all of these zones. Let's look at an example:</p>
|
||
<p>
|
||
/etc/shorewall/zones:</p>
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
DISPLAY</b></td>
|
||
<td><b>
|
||
COMMENTS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>sam</td>
|
||
<td>Sam</td>
|
||
<td>Sam's system at home</td>
|
||
</tr>
|
||
<tr>
|
||
<td>net</td>
|
||
<td>Internet</td>
|
||
<td>The Internet</td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>Loc</td>
|
||
<td>Local Network</td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
<p>
|
||
/etc/shorewall/interfaces:</p>
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
INTERFACE</b></td>
|
||
<td><b>
|
||
BROADCAST</b></td>
|
||
<td><b>
|
||
OPTIONS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>-</td>
|
||
<td>eth0</td>
|
||
<td>detect</td>
|
||
<td>dhcp,noping,norfc1918</td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>eth1</td>
|
||
<td>detect</td>
|
||
<td>routestopped</td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
<p>
|
||
/etc/shorewall/hosts:</p>
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
ZONE</b></td>
|
||
<td><b>
|
||
HOST(S)</b></td>
|
||
<td><b>
|
||
OPTIONS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>net</td>
|
||
<td>eth0:0.0.0.0/0</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>sam</td>
|
||
<td>eth0:206.191.149.197</td>
|
||
<td>routestopped</td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
<p>
|
||
Note that Sam's home system is a member of both the <b>sam</b> zone and
|
||
the <b>net</b> zone and <a href="#Nested">
|
||
as described above</a>
|
||
, that means that <b>sam</b> must be listed before <b>net</b><EFBFBD> in /etc/shorewall/zones.</p>
|
||
<p>
|
||
/etc/shorewall/policy:</p>
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
SOURCE</b></td>
|
||
<td><b>
|
||
DEST</b></td>
|
||
<td><b>
|
||
POLICY</b></td>
|
||
<td><b>
|
||
LOG LEVEL</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>net</td>
|
||
<td>ACCEPT</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>sam</td>
|
||
<td>all</td>
|
||
<td>CONTINUE</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>net</td>
|
||
<td>all</td>
|
||
<td>DROP</td>
|
||
<td>info</td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>REJECT</td>
|
||
<td>info</td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
</table></blockquote>
|
||
<p>
|
||
The second entry above says that when Sam is the client, connection requests
|
||
should first be process under rules where the source zone is <b>sam</b> and
|
||
if there is no match then the connection request should be treated under
|
||
rules where the source zone is <b>net</b>. It is important that this policy
|
||
be listed BEFORE the next policy (<b>net</b> to <b>all</b>).</p>
|
||
<p>
|
||
Partial /etc/shorewall/rules:</p>
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td><b>ACTION</b></td>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
PROTO</b></td>
|
||
<td><b>DEST<br>
|
||
PORT(S)</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>ORIGINAL<br>
|
||
DEST</b></td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td>...</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>DNAT</td>
|
||
<td>sam</td>
|
||
<td>loc:192.168.1.3</td>
|
||
<td>tcp</td>
|
||
<td>ssh</td>
|
||
<td>-</td>
|
||
<td> </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> </td>
|
||
</tr>
|
||
<tr>
|
||
<td>...</td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </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>
|
||
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tr>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td><b>ACTION</b></td>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
PROTO</b></td>
|
||
<td><b>DEST<br>
|
||
PORT(S)</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>ORIGINAL<br>
|
||
DEST</b></td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
<tr>
|
||
<td>...</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td>DNAT</td>
|
||
<td>sam</td>
|
||
<td>fw</td>
|
||
<td>tcp</td>
|
||
<td>ssh</td>
|
||
<td>-</td>
|
||
<td> </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> </td>
|
||
</tr>
|
||
<tr>
|
||
<td>...</td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
|
||
</table>
|
||
</blockquote>
|
||
|
||
<p>The first rule allows Sam SSH
|
||
access to the firewall. The second
|
||
rule says that any clients from the
|
||
net zone with the exception of those
|
||
in the 'sam' zone should have their
|
||
connection port forwarded to
|
||
192.168.1.3. If you need to exclude
|
||
more than one zone in this way, you
|
||
can list the zones separated by
|
||
commas (e.g., net!sam,joe,fred).
|
||
This technique also may be used when
|
||
the ACTION is REDIRECT.</p>
|
||
|
||
|
||
<h2><font color="#660066"><a name="Rules"></a>
|
||
</font>/etc/shorewall/rules</h2>
|
||
|
||
|
||
<p>The /etc/shorewall/rules file
|
||
defines exceptions to the policies established in the /etc/shorewall/policy
|
||
file. There is one entry in /etc/shorewall/rules for each of these rules.<2E></p>
|
||
|
||
|
||
<p>Entries in the file have the
|
||
following columns:</p>
|
||
<ul>
|
||
<li><b>ACTION</b><ul>
|
||
<li>ACCEPT, DROP or REJECT. These have the same meaning here as in the
|
||
policy file above.</li>
|
||
<li>DNAT -- Causes the connection request to be forwarded to the system
|
||
specified in the DEST column (port forwarding). "DNAT" stands for "<u>D</u>estination
|
||
<u>N</u>etwork <u>A</u>ddress <u>T</u>ranslation"</li>
|
||
<li>REDIRECT -- Causes the connection request to be redirected to a port on
|
||
the local (firewall) system.</li>
|
||
</ul>
|
||
<p>The ACTION may optionally be followed by
|
||
":" and a syslogd log level (example: REJECT:info). This causes the
|
||
packet to be logged at the specified level prior to being processed according
|
||
to the specified ACTION.<br>
|
||
<br>
|
||
The use of DNAT or REDIRECT requires that you have <a href="#NatEnabled">NAT enabled</a>.<br>
|
||
</li>
|
||
<li><b>SOURCE</b> - Describes the source hosts to which the rule applies.. The contents of this field must begin
|
||
with the name of a zone defined in /etc/shorewall/zones or $FW. If the
|
||
ACTION is DNAT or REDIRECT, sub-zones may be excluded from the rule by
|
||
following the initial zone name with "!' and a comma-separated list of those
|
||
sub-zones to be excluded. There is an <a href="#Exclude">example</a> above.<br>
|
||
<br>
|
||
The source may be further restricted by adding a colon (":") followed by a
|
||
comma-separated list of qualifiers. Qualifiers are may
|
||
include:
|
||
<ul>
|
||
<li>An interface name - refers to any connection requests arriving on
|
||
the specified interface (example loc:eth4).</li>
|
||
<li>An IP address - refers to a connection request from the host with
|
||
the specified address (example net:155.186.235.151)</li>
|
||
<li>A MAC Address in <a href="#MAC">Shorewall format</a>.</li>
|
||
<li>A subnet - refers to a connection request from any host in the specified
|
||
subnet (example net:155.186.235.0/24).</li>
|
||
</ul>
|
||
</li>
|
||
<li><b>DEST</b> - Describes the destination host(s) to which the rule applies. May take any of the forms described
|
||
above for SOURCE plus the following two additional forms:
|
||
<ul>
|
||
<li>An IP address followed by a colon and the port <u>number</u> that
|
||
the server is listening on (service names from /etc/services are not
|
||
allowed - example loc:192.168.1.3:80). </li>
|
||
<li>A single port number (again, service names are not allowed) -- this form is only allowed
|
||
if the ACTION is REDIRECT and refers to a server running on the firewall itself and
|
||
listening on the specified port.</li>
|
||
</ul>
|
||
</li>
|
||
<li><b>
|
||
PROTO</b> - Protocol. Must be a protocol name from /etc/protocols, a number,
|
||
"all" or "related". Specifies the protocol
|
||
of the connection request. "related" should be specified only if you
|
||
have given ALLOWRELATED="no" in /etc/shorewall/shorewall.conf and
|
||
you wish to override that setting for related connections originating
|
||
with the client(s) and server(s) specified in this rule. When "related"
|
||
is given for the protocol, the remainder of the columns should be left
|
||
blank.</li>
|
||
<li><b>
|
||
DEST
|
||
PORT(S)</b> - Port or port range (<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.</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.</li>
|
||
<li><b>ORIGINAL DEST</b> - This column may only be non-empty if the ACTION is DNAT
|
||
or
|
||
REDIRECT.<br>
|
||
<br>
|
||
If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column is left empty,
|
||
any connection request arriving at the firewall from the SOURCE that matches
|
||
the rule will be forwarded or redirected. This works fine for connection
|
||
requests arriving from the internet where the firewall has only a single
|
||
external IP address. When the firewall has multiple external IP addresses or
|
||
when the SOURCE is other than the internet, there will usually be a desire
|
||
for the rule to only apply to those connection requests directed to a
|
||
particular IP address (see Example 2 below for another usage). That IP
|
||
address (or a comma-separated list of such addresses) is specified in the
|
||
ORIGINAL DEST column.<br>
|
||
<br>
|
||
The IP address may be optionally followed by ":" and a
|
||
second IP address. This latter address, if present, is used as the source
|
||
address for packets forwarded to the server (This is called "Source NAT" or
|
||
SNAT).<br>
|
||
<br>
|
||
<b><font color="#ff6633">Note:<3A> </font>
|
||
When using SNAT, it is a good idea to qualify the source with an IP address
|
||
or subnet. Otherwise, it is likely that SNAT will occur on connections other
|
||
than those described in the rule. The reason for this is that SNAT occurs in
|
||
the Netfilter POSTROUTING hook where it is not possible to restrict the scope
|
||
of a rule by incoming interface. <br>
|
||
<br>
|
||
</b>Example: DNAT 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.<2E></p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td><b>ACTION</b></td>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
PROTO</b></td>
|
||
<td><b>DEST<br>
|
||
PORT(S)</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>ORIGINAL<br>
|
||
DEST</b></td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td>DNAT</td>
|
||
<td>net</td>
|
||
<td>loc:192.168.1.3</td>
|
||
<td>tcp</td>
|
||
<td>ssh</td>
|
||
<td> </td>
|
||
<td> </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>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td><b>ACTION</b></td>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
PROTO</b></td>
|
||
<td><b>DEST<br>
|
||
PORT(S)</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>ORIGINAL<br>
|
||
DEST</b></td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td>REDIRECT</td>
|
||
<td>loc</td>
|
||
<td>3128</td>
|
||
<td>tcp</td>
|
||
<td>www</td>
|
||
<td> </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> </td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
|
||
</table></blockquote>
|
||
|
||
<p><b>
|
||
Example 3. </b> You want to run a web server at 155.186.235.222 in your
|
||
DMZ and have it accessible remotely and locally. the DMZ is managed by
|
||
Proxy ARP or by classical sub-netting.</p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td><b>ACTION</b></td>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
PROTO</b></td>
|
||
<td><b>DEST<br>
|
||
PORT(S)</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>ORIGINAL<br>
|
||
DEST</b></td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td>ACCEPT</td>
|
||
<td>net</td>
|
||
<td>dmz:155.186.235.222</td>
|
||
<td>tcp</td>
|
||
<td>www</td>
|
||
<td>-</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td> </td>
|
||
</tr>
|
||
</font>
|
||
<tr>
|
||
<td>ACCEPT</td>
|
||
<td>loc</td>
|
||
<td>dmz:155.186.235.222</td>
|
||
<td>tcp</td>
|
||
<td>www</td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
|
||
</table></blockquote>
|
||
|
||
<p><b>
|
||
Example 4. </b> You want to run wu-ftpd on 192.168.2.2 in your masqueraded
|
||
DMZ. Your internet interface address is 155.186.235.151 and you want the
|
||
FTP server to be accessible from the internet in addition to the local 192.168.1.0/24 and dmz 192.168.2.0/24
|
||
subnetworks. Note that since the server is in the 192.168.2.0/24 subnetwork,
|
||
we can assume that access to the server from that subnet will not involve
|
||
the firewall (<a href="FAQ.htm#faq2">but see FAQ 2</a>). Note that unless you
|
||
have more than one external
|
||
IP address, you can leave
|
||
the ORIGINAL DEST column
|
||
blank in the first rule. You
|
||
cannot leave it blank in the
|
||
second rule though because
|
||
then <u>all ftp connections</u>
|
||
originating in the local
|
||
subnet 192.168.1.0/24 would
|
||
be sent to 192.168.2.2 <u>
|
||
regardless of the site that
|
||
the user was trying to
|
||
connect to</u>. That is
|
||
clearly not what you want
|
||
<img border="0" src="images/SY00079.gif" width="20" height="20" align="top">.</p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td><b>ACTION</b></td>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
PROTO</b></td>
|
||
<td><b>DEST<br>
|
||
PORT(S)</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>ORIGINAL<br>
|
||
DEST</b></td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td>DNAT</td>
|
||
<td>net</td>
|
||
<td>dmz:192.168.2.2</td>
|
||
<td>tcp</td>
|
||
<td>ftp</td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
<tr>
|
||
<td>DNAT</td>
|
||
<td>loc:192.168.1.0/24</td>
|
||
<td>dmz:192.168.2.2</td>
|
||
<td>tcp</td>
|
||
<td>ftp</td>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td>-</td>
|
||
</font>
|
||
<td>155.186.235.151</td>
|
||
</tr>
|
||
|
||
|
||
</tbody>
|
||
|
||
|
||
</table></blockquote>
|
||
|
||
|
||
<p>If you are running
|
||
wu-ftpd, you should restrict the range of passive in your /etc/ftpaccess
|
||
file. I only need a few simultaneous FTP sessions so I use port range
|
||
65500-65535. In /etc/ftpaccess, this entry is appropriate:</p>
|
||
|
||
|
||
<blockquote>
|
||
|
||
|
||
<p> passive ports<74>
|
||
0.0.0.0/0 65500 65534</p>
|
||
</blockquote>
|
||
|
||
|
||
<p>If you are running
|
||
pure-ftpd, you would include "-p 65500:65534" on the pure-ftpd runline.</p>
|
||
|
||
|
||
<p>The important
|
||
point here is to ensure that the port range used for FTP passive connections
|
||
is unique and will not overlap with any usage on the firewall system.</p>
|
||
|
||
|
||
<p><b>Example 5. </b>You
|
||
wish to allow unlimited
|
||
DMZ access to the host
|
||
with MAC address
|
||
02:00:08:E3:FA:55.</p>
|
||
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tr>
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
<td><b>ACTION</b></td>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>
|
||
PROTO</b></td>
|
||
<td><b>DEST<br>
|
||
PORT(S)</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>ORIGINAL<br>
|
||
DEST</b></td>
|
||
</font>
|
||
</tr>
|
||
<tr>
|
||
<td>ACCEPT</td>
|
||
<td>loc:~02-00-08-E3-FA-55</td>
|
||
<td>dmz</td>
|
||
<td>all</td>
|
||
<td> </td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
|
||
|
||
</table>
|
||
</blockquote>
|
||
|
||
|
||
<p><a href="ports.htm">
|
||
Look here for information on other services.</a>
|
||
</p>
|
||
|
||
|
||
<h2><a name="Common">
|
||
</a>/etc/shorewall/common</h2>
|
||
|
||
|
||
<p>Shorewall allows
|
||
definition of rules that
|
||
apply between all zones.
|
||
By default, these rules
|
||
are defined in the file
|
||
/etc/shorewall/common.def
|
||
but may be modified to
|
||
suit individual
|
||
requirements. Rather
|
||
than modify
|
||
/etc/shorewall/common.def,
|
||
you should copy that
|
||
file to
|
||
/etc/shorewall/common
|
||
and modify that file.</p>
|
||
|
||
|
||
<p>The
|
||
/etc/shorewall/common
|
||
file is expected to
|
||
contain iptables
|
||
commands; rather than
|
||
running iptables
|
||
directly, you should run
|
||
it indirectly using the
|
||
Shorewall function 'run_iptables'.
|
||
That way, if iptables
|
||
encounters an error, the
|
||
firewall will be safely
|
||
stopped.</p>
|
||
|
||
|
||
<h2><a name="Masq"></a>
|
||
/etc/shorewall/masq</h2>
|
||
|
||
|
||
<p>The /etc/shorewall/masq
|
||
file is used to define classical IP Masquerading and Source Network Address Translation (SNAT). There is one entry in
|
||
the file for each subnet that you want to masquerade. In order to make
|
||
use of this feature, you must have <a href="#NatEnabled">NAT enabled</a>
|
||
.</p>
|
||
|
||
|
||
<p> Columns are:</p>
|
||
<ul>
|
||
<li><b>
|
||
INTERFACE</b> - The interface that will masquerade the subnet; this is
|
||
normally your internet interface. This interface name can be optionally
|
||
qualified by adding ":" and a subnet or host IP. When this qualification
|
||
is added, only packets addressed to that host or subnet will be masqueraded.</li>
|
||
<li><b>
|
||
SUBNET</b> - The subnet that you want to have masqueraded through the
|
||
INTERFACE. This may be expressed as a single IP address, a subnet or an
|
||
interface name. In the latter instance, the interface must be configured and
|
||
started before Shorewall is started as Shorewall will determine the subnet
|
||
based on information obtained from the 'ip' utility.<br>
|
||
<br>
|
||
The subnet may be optionally followed by "!'
|
||
and a comma-separated list of addresses and/or subnets that are to be
|
||
excluded from masquerading.</li>
|
||
<li><b>ADDRESS</b> - The source address to be used
|
||
for outgoing packets. This column is optional and if left blank, the current
|
||
primary IP address of the interface in the first column is used. If you have
|
||
a static IP on that interface, listing it here makes processing of output
|
||
packets a little less expensive for the firewall.</li>
|
||
</ul>
|
||
|
||
<p><b>
|
||
Example 1: </b> You have eth0 connected to a cable modem and eth1 connected
|
||
to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq file
|
||
would look like:<3A><><EFBFBD><EFBFBD></p>
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
<tr>
|
||
<td><b>
|
||
INTERFACE</b></td>
|
||
<td><b>
|
||
SUBNET</b></td>
|
||
<td><b>ADDRESS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>eth0</td>
|
||
<td>192.168.9.0/24</td>
|
||
<td> </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> </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">
|
||
<tr>
|
||
<td><b>
|
||
INTERFACE</b></td>
|
||
<td><b>
|
||
SUBNET</b></td>
|
||
<td><b>ADDRESS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>eth0</td>
|
||
<td>192.168.10.0/24</td>
|
||
<td>206.124.146.176</td>
|
||
</tr>
|
||
|
||
|
||
</table>
|
||
</blockquote>
|
||
|
||
<p><b>Example 4: </b>
|
||
Same as example 3
|
||
except that you wish
|
||
to exclude
|
||
192.168.10.44 and
|
||
192.168.10.45 from
|
||
the SNAT rule.</p>
|
||
|
||
|
||
<blockquote>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse">
|
||
<tr>
|
||
<td><b>
|
||
INTERFACE</b></td>
|
||
<td><b>
|
||
SUBNET</b></td>
|
||
<td><b>ADDRESS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>eth0</td>
|
||
<td>192.168.10.0/24!192.168.10.44,192.168.10.45</td>
|
||
<td>206.124.146.176</td>
|
||
</tr>
|
||
|
||
|
||
</table>
|
||
</blockquote>
|
||
|
||
<h2><font color="#660066"><b><a name="ProxyArp"></a>
|
||
</b></font>/etc/shorewall/proxyarp</h2>
|
||
|
||
|
||
<p>If you want to
|
||
use proxy ARP on an
|
||
entire sub-network,
|
||
I suggest that you
|
||
look at
|
||
<a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">
|
||
http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>.
|
||
If you decide to use
|
||
the technique
|
||
described in that
|
||
HOWTO, you can set
|
||
the proxy_arp flag
|
||
for an interface
|
||
(/proc/sys/net/ipv4/conf/<i><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>To learn how I use Proxy ARP
|
||
in my DMZ, see <a href="myfiles.htm">my configuration files</a>.</p>
|
||
|
||
<p><font color="#FF6633"><b>Warning: </b></font>Do not use Proxy ARP and
|
||
FreeS/Wan on the same system unless you are prepared to suffer the
|
||
consequences. If you start or restart Shorewall with an IPSEC tunnel active,
|
||
the proxied IP addresses are mistakenly assigned to the IPSEC tunnel device
|
||
(ipsecX) rather than to the interface that you specify in the INTERFACE column
|
||
of /etc/shorewall/proxyarp. I haven't had the time to debug this problem so I
|
||
can't say if it is a bug in the Kernel or in FreeS/Wan. </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.</li>
|
||
<li><b>
|
||
INTERNAL </b> - Internal IP address.</li>
|
||
<li><b>ALL
|
||
INTERFACES</b>
|
||
- If Yes
|
||
or yes (or
|
||
left
|
||
empty),
|
||
NAT will
|
||
be
|
||
effective
|
||
from all
|
||
hosts. If
|
||
No or no
|
||
then NAT
|
||
will be
|
||
effective
|
||
only
|
||
through
|
||
the
|
||
interface
|
||
named in
|
||
the
|
||
INTERFACE
|
||
column. <b>
|
||
Note:</b> If two or more NATed systems are connected to the same firewall
|
||
interface and you want them to be able to communicate using their EXTERNAL IP
|
||
addresses, then you will want to specify the <b>multi</b> option in the
|
||
<a href="#Interfaces">/etc/shorewall/interface</a> entry for that interface.</li>
|
||
<li><b>LOCAL</b> - If Yes or yes and the ALL INTERFACES column contains Yes
|
||
or yes, NAT will be effective from the firewall system. <b>Note: </b>For this
|
||
to work, you must be running kernel 2.4.19 or later and iptables 1.2.6a or
|
||
later and you must have enabled <b>CONFIG_IP_NF_NAT_LOCAL</b> in your
|
||
kernel.</li>
|
||
</ul>
|
||
<p><b><a href="NAT.htm">
|
||
Look here for additional information and an example.</a>
|
||
</b></p>
|
||
|
||
<h2><font color="#660066"><a name="Tunnels"></a>
|
||
</font>/etc/shorewall/tunnels</h2>
|
||
|
||
<p>
|
||
The /etc/shorewall/tunnels file allows you to define IPSec, GRE and IPIP tunnels
|
||
with end-points on your firewall. To use ipsec, you must install version
|
||
1.9, 1.91 or the current <a href="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</a>
|
||
development snapshot.<2E></p>
|
||
|
||
<p>
|
||
Note: For kernels 2.4.4 and above, you will need to use version 1.91 or
|
||
a development snapshot as patching with version 1.9 results in kernel compilation
|
||
errors.</p>
|
||
|
||
<p><b><a href="IPSEC.htm">
|
||
Instructions for setting up IPSEC tunnels may be found here</a>
|
||
</b>and <b><a href="IPIP.htm">instructions for IPIP tunnels are here</a>
|
||
. </b>Look <a href="PPTP.htm">here</a> for information about setting up PPTP
|
||
tunnels under
|
||
Shorewall.</p>
|
||
|
||
<h2><font color="#660066"><a name="Conf"></a>
|
||
</font>/etc/shorewall/shorewall.conf</h2>
|
||
|
||
<p>
|
||
This file is used to set the following firewall parameters:</p>
|
||
<ul>
|
||
<li><b>FORWARDPING</b> - Added in Version 1.3.7<br>
|
||
When set to "Yes" or "yes", ICMP echo-request (ping) packets from interfaces
|
||
that specify "filterping" are ACCEPTed by the firewall. When set to "No" or
|
||
"no", such ping requests are silently dropped unless they are handled by an
|
||
explicit entry in the <a href="#Rules">rules file</a>. If not specified, "No"
|
||
is assumed.</li>
|
||
<li><b>LOGNEWNOTSYN</b> - Added in Version 1.3.6<br>
|
||
Beginning with version 1.3.6, Shorewall drops non-SYN TCP packets that are
|
||
not part of an existing connection. If you would like to log these packets,
|
||
set LOGNEWNOTSYN to the syslog level at which you want the packets logged.
|
||
Example: LOGNEWNOTSYN=debug|<br>
|
||
<br>
|
||
<b>Note: </b>Packets logged under this option are usually the result of
|
||
broken remote IP stacks rather than the result of any sort of attempt to
|
||
breach your firewall.<br>
|
||
</li>
|
||
<li><b>MERGE_HOSTS </b>- Added in Version 1.3.5<br>
|
||
Prior to 1.3.5, when the <a href="#Hosts">/etc/shorewall/hosts</a> file
|
||
included an entry for a zone then the entire zone had to be defined in the
|
||
/etc/shorewall/hosts file and any associations between the zone and
|
||
interfaces in the <a href="#Interfaces">/etc/shorewall/interfaces</a> file
|
||
were ignored. This behavior is preserved if MERGE_HOSTS=No or if MERGE_HOSTS
|
||
is not set or is set to the empty value.<br>
|
||
<br>
|
||
Beginning with version 1.3.5, if MERGE_HOSTS=Yes, then zone assignments in
|
||
the /etc/shorewall/hosts file are ADDED to those in the
|
||
/etc/shorewall/interfaces file. <br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
Interfaces File:<br>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse" id="AutoNumber2">
|
||
<tr>
|
||
<td><u><b>ZONE</b></u></td>
|
||
<td><u><b>HOSTS</b></u></td>
|
||
<td><u><b>BROADCAST</b></u></td>
|
||
<td><u><b>OPTIONS</b></u></td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>eth1</td>
|
||
<td>-</td>
|
||
<td>dhcp</td>
|
||
</tr>
|
||
<tr>
|
||
<td>-</td>
|
||
<td>ppp+</td>
|
||
<td> </td>
|
||
<td> </td>
|
||
</tr>
|
||
</table>
|
||
<p><br>
|
||
Hosts File:<br>
|
||
</p>
|
||
<table border="1" cellpadding="2" style="border-collapse: collapse" id="AutoNumber3">
|
||
<tr>
|
||
<td><u><b>ZONE</b></u></td>
|
||
<td><u><b>HOSTS</b></u></td>
|
||
</tr>
|
||
<tr>
|
||
<td>loc</td>
|
||
<td>ppp+:192.168.12.0/24</td>
|
||
</tr>
|
||
</table>
|
||
<p><font face="Courier"><br>
|
||
</font>With MERGE_HOSTS=No, the<b> loc</b> zone consists of only ppp+:192.168.12.0/24;
|
||
with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0 and ppp+:192.168.12.0/24.<br>
|
||
</li>
|
||
<li><b>MULTIPORT</b> - Added in Version 1.3.2<br>
|
||
If set to "Yes" or "yes", Shorewall will use the Netfilter multiport
|
||
facility. In order to use this facility, your kernel must have multiport
|
||
support (CONFIG_IP_NF_MATCH_MULTIPORT). When this support is used, Shorewall
|
||
will generate a single rule from each record in the /etc/shorewall/rules file
|
||
that meets these criteria:<br>
|
||
<ul>
|
||
<li>No port range(s) specified</li>
|
||
<li>Specifies 15 or fewer ports</li>
|
||
</ul>
|
||
<p>Rules not meeting those criteria will continue to generate an individual
|
||
rule for each listed port or port range.</li>
|
||
<li><b>NAT_BEFORE_RULES</b><br>
|
||
If set to "No" or "no", port forwarding rules can override the contents of
|
||
the <a href="#NAT">/etc/shorewall/nat</a> file. If set to "Yes" or "yes",
|
||
port forwarding rules cannot override static NAT. If not set or set to an
|
||
empty value, "Yes" is assumed.</li>
|
||
<li><b>FW<br>
|
||
</b>This
|
||
parameter
|
||
specifies the
|
||
name of the
|
||
firewall zone.
|
||
If not set or
|
||
if set to an
|
||
empty string,
|
||
the value
|
||
"fw"
|
||
is assumed.</li>
|
||
<li><b>SUBSYSLOCK</b><br>
|
||
This parameter should be set to the name of a file that the firewall
|
||
should create if it starts successfully and remove when it stops. Creating
|
||
and removing this file allows Shorewall to work with your distribution's
|
||
initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall.
|
||
For Debian, the value is /var/state/shorewall and in LEAF it is
|
||
/var/run/shorwall.
|
||
Example:
|
||
SUBSYSLOCK=/var/lock/subsys/shorewall.</li>
|
||
<li><b>
|
||
STATEDIR</b><br>
|
||
This parameter specifies the name of a directory where Shorewall
|
||
stores state information. If the directory doesn't exist when Shorewall
|
||
starts, it will create the directory. Example: STATEDIR=/tmp/shorewall.<br>
|
||
<br>
|
||
<b>NOTE:</b> If you change the STATEDIR variable while the firewall is
|
||
running, create the new directory if necessary then copy the contents of the
|
||
old directory to the new directory. </li>
|
||
<li><b>
|
||
ALLOWRELATED</b><br>
|
||
This parameter must be assigned the value "Yes" ("yes") or
|
||
"No" ("no") and specifies whether Shorewall allows connection requests
|
||
that are related to an already allowed connection. If you say "No" ("no"),
|
||
you can still override this setting by including "related" rules in
|
||
/etc/shorewall/rules ("related" given as the protocol). If you specify
|
||
ALLOWRELATED=No, you will need to include rules in
|
||
<a href="shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a> to
|
||
handle common ICMP packet types.</li>
|
||
<li><b>
|
||
MODULESDIR</b><br>
|
||
This parameter specifies the directory where your kernel netfilter
|
||
modules may be found. If you leave the variable empty, Shorewall will
|
||
supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.</li>
|
||
<li><b>
|
||
LOGRATE </b> and <b> LOGBURST</b><br>
|
||
These parameters set the match rate and initial burst size for logged
|
||
packets. Please see the iptables man page for a description of the behavior
|
||
of these parameters (the iptables option --limit is set by LOGRATE and
|
||
--limit-burst is set by LOGBURST). If both parameters are
|
||
set empty, no rate-limiting will occur.<br>
|
||
<br>
|
||
Example:<br>
|
||
LOGRATE=10/minute<br>
|
||
LOGBURST=5<br>
|
||
</li>
|
||
<li><b>LOGFILE</b><br>
|
||
This parameter
|
||
tells the
|
||
/sbin/shorewall
|
||
program where
|
||
to look for
|
||
Shorewall
|
||
messages when
|
||
processing the
|
||
"show
|
||
log",
|
||
"monitor",
|
||
"status"
|
||
and
|
||
"hits"
|
||
commands. If
|
||
not assigned
|
||
or if assigned
|
||
an empty
|
||
value,
|
||
/var/log/messages
|
||
is assumed.</li>
|
||
<li><b>NAT_ENABLED</b><br>
|
||
This parameter determines whether Shorewall supports NAT operations.<2E>NAT
|
||
operations include:<br>
|
||
<br>
|
||
<20><><EFBFBD> Static NAT<br>
|
||
<20><><EFBFBD> Port Forwarding<br>
|
||
<20><><EFBFBD> Port Redirection<br>
|
||
<20><><EFBFBD> Masquerading<br>
|
||
<br>
|
||
If the parameter has no value or has a value of "Yes" or "yes"
|
||
then NAT is enabled. If the parameter has a value of "no" or "No"
|
||
then NAT is disabled.<br>
|
||
|
||
</li>
|
||
<li><b>
|
||
MANGLE_ENABLED</b><br>
|
||
This parameter determines if packet mangling is enabled. If the
|
||
parameter has no value or has a value of "Yes" or "yes" than
|
||
packet mangling is enabled. If the parameter has a value of "no"
|
||
or "No" then packet mangling is disabled. If packet mangling is disabled,
|
||
the /etc/shorewall/tos file is ignored.<br>
|
||
|
||
</li>
|
||
<li><b>
|
||
IP_FORWARDING</b><br>
|
||
This parameter determines whether Shorewall enables or disables
|
||
IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values
|
||
are:<br>
|
||
<br>
|
||
<20><><EFBFBD> On or on - packet forwarding will be enabled.<br>
|
||
<20><><EFBFBD> Off or off - packet forwarding will be disabled.<br>
|
||
<20><><EFBFBD> Keep or keep - Shorewall will neither enable nor disable
|
||
packet forwarding.<br>
|
||
<br>
|
||
If this variable is not set or is given an empty value (IP_FORWARD="")
|
||
then IP_FORWARD=On is assumed.<br>
|
||
|
||
</li>
|
||
<li><b>ADD_IP_ALIASES</b><br>
|
||
This parameter determines whether Shorewall automatically adds the
|
||
<i>external
|
||
</i>address(es) in <a href="#NAT">/etc/shorewall/nat</a>
|
||
. If the variable is set to "Yes" or "yes" then Shorewall automatically
|
||
adds these aliases. If it is set to "No" or "no", you must add
|
||
these aliases yourself using your distribution's network configuration
|
||
tools.<br>
|
||
<br>
|
||
If this variable is not set or is given an empty value (ADD_IP_ALIASES="")
|
||
then ADD_IP_ALIASES=Yes is assumed.</li>
|
||
<li><b>ADD_SNAT_ALIASES</b><br>
|
||
This parameter determines whether Shorewall automatically adds the SNAT <i>
|
||
ADDRESS </i>in <a href="#Masq">/etc/shorewall/masq</a>. If the variable is
|
||
set to "Yes" or "yes" then Shorewall automatically adds these addresses. If
|
||
it is set to "No" or "no", you must add these addresses yourself using your
|
||
distribution's network configuration tools.<br>
|
||
<br>
|
||
If this variable is not set or is given an empty value (ADD_SNAT_ALIASES="")
|
||
then ADD_SNAT_ALIASES=No is assumed.<br>
|
||
</li>
|
||
<li><b>LOGUNCLEAN</b><br>
|
||
This parameter
|
||
determines the
|
||
logging level
|
||
of
|
||
mangled/invalid
|
||
packets
|
||
controlled by
|
||
the '<a href="#Unclean">dropunclean
|
||
and logunclean</a>'
|
||
interface
|
||
options. If
|
||
LOGUNCLEAN is
|
||
empty
|
||
(LOGUNCLEAN=)
|
||
then packets
|
||
selected by
|
||
'dropclean' are
|
||
dropped
|
||
silently
|
||
('logunclean'
|
||
packets are
|
||
logged under
|
||
the 'info' log
|
||
level).
|
||
Otherwise,
|
||
these packets
|
||
are logged at
|
||
the specified
|
||
level
|
||
(Example:
|
||
LOGUNCLEAN=debug).</li>
|
||
<li><b>BLACKLIST_DISPOSITION</b><br>
|
||
This parameter
|
||
determines the
|
||
disposition of
|
||
packets from
|
||
blacklisted
|
||
hosts. It may
|
||
have the value
|
||
DROP if the
|
||
packets are to
|
||
be dropped or
|
||
REJECT if the
|
||
packets are to
|
||
be replied
|
||
with an ICMP
|
||
port
|
||
unreachable
|
||
reply or a TCP
|
||
RST (tcp
|
||
only). If you
|
||
do not assign
|
||
a value or if
|
||
you assign an
|
||
empty value
|
||
then DROP is
|
||
assumed.</li>
|
||
<li><b>BLACKLIST_LOGLEVEL</b><br>
|
||
This paremter
|
||
determines if
|
||
packets from
|
||
blacklisted
|
||
hosts are
|
||
logged and it
|
||
determines the
|
||
syslog level
|
||
that they are
|
||
to be logged
|
||
at. Its value
|
||
is a syslog
|
||
log level
|
||
(Example:
|
||
BLACKLIST_LOGLEVEL=debug).
|
||
If you do not
|
||
assign a value
|
||
or if you
|
||
assign an
|
||
empty value
|
||
then packets
|
||
from
|
||
blacklisted
|
||
hosts are not
|
||
logged.</li>
|
||
<li><b>CLAMPMSS</b><br>
|
||
This parameter
|
||
enables the
|
||
TCP Clamp MSS
|
||
to PMTU
|
||
feature of
|
||
Netfilter and
|
||
is usually
|
||
required when
|
||
your internet
|
||
connection is
|
||
through PPPoE
|
||
or PPTP. If
|
||
set to
|
||
"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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD></i></p>
|
||
|
||
|
||
<blockquote>
|
||
|
||
|
||
|
||
<p>is
|
||
the name of the modules without the trailing ".o" (example ip_conntrack).</p>
|
||
</blockquote>
|
||
|
||
|
||
<p><i>
|
||
<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.<2E>In order for this file to be processed
|
||
by Shorewall, you must have <a href="#MangleEnabled">mangle support enabled</a>
|
||
.</p>
|
||
|
||
|
||
|
||
<p>
|
||
Entries in the file have the following columns:</p>
|
||
|
||
|
||
<ul>
|
||
<li><b>
|
||
SOURCE</b> -- The source zone. May be qualified by following the zone name
|
||
with a colon (":") and either an IP address, an IP subnet, a MAC address
|
||
in <a href="#MAC">Shorewall Format</a> or the
|
||
name of an interface. This column may also contain the <a href="#FW">name of
|
||
the firewall</a>
|
||
zone to indicate
|
||
packets originating on the firewall itself or "all" to indicate any
|
||
source.</li>
|
||
<li><b>
|
||
DEST</b> -- The destination zone. May be qualified by following the zone
|
||
name with a colon (":") and either an IP address or an IP subnet.
|
||
Because packets are marked prior to routing, you may not specify the
|
||
name of an interface. This column may also contain<69> "all" to indicate
|
||
any destination.</li>
|
||
<li><b>
|
||
PROTOCOL</b> -- The name of a protocol in /etc/protocols or the protocol's
|
||
number.</li>
|
||
<li><b>
|
||
SOURCE PORT(S)</b> -- The source port or a port range. For all ports, place
|
||
a hyphen ("-") in this column.</li>
|
||
<li><b>
|
||
DEST PORT(S)</b> -- The destination port or a port range. To indicate
|
||
all ports, place a hyphen ("-") in this column.</li>
|
||
<li><b>
|
||
TOS</b> -- The type of service. Must be one of the following:</li>
|
||
</ul>
|
||
|
||
<blockquote>
|
||
|
||
<blockquote>
|
||
|
||
<p>
|
||
Minimize-Delay (16)<br>
|
||
Maximize-Throughput (8)<br>
|
||
Maximize-Reliability (4)<br>
|
||
Minimize-Cost (2)<br>
|
||
Normal-Service (0)</p>
|
||
</blockquote>
|
||
</blockquote>
|
||
|
||
<p>
|
||
The /etc/shorewall/tos file that is included with Shorewall contains the
|
||
following entries.</p>
|
||
|
||
<blockquote>
|
||
<table border="2" cellpadding="2" style="border-collapse: collapse">
|
||
<tbody>
|
||
|
||
<tr>
|
||
<td><b>SOURCE</b></td>
|
||
<td><b>DEST</b></td>
|
||
<td><b>PROTOCOL</b></td>
|
||
<td><b>SOURCE<br>
|
||
PORT(S)</b></td>
|
||
<td><b>DEST PORT(S)</b></td>
|
||
<td><b>TOS</b></td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>tcp</td>
|
||
<td>-</td>
|
||
<td>ssh</td>
|
||
<td>16</td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>tcp</td>
|
||
<td>ssh</td>
|
||
<td>-</td>
|
||
<td>16</td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>tcp</td>
|
||
<td>-</td>
|
||
<td>ftp</td>
|
||
<td>16</td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>tcp</td>
|
||
<td>ftp</td>
|
||
<td>-</td>
|
||
<td>16</td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>tcp</td>
|
||
<td>-</td>
|
||
<td>ftp-data</td>
|
||
<td>8</td>
|
||
</tr>
|
||
<tr>
|
||
<td>all</td>
|
||
<td>all</td>
|
||
<td>tcp</td>
|
||
<td>ftp-data</td>
|
||
<td>-</td>
|
||
<td>8</td>
|
||
</tr>
|
||
|
||
|
||
|
||
</tbody>
|
||
|
||
|
||
|
||
</table></blockquote>
|
||
|
||
<p><b>WARNING: </b>Users have reported that odd routing problems result from adding the ESP and AH protocols to the /etc/shorewall/tos file.
|
||
</p>
|
||
|
||
<h2><a name="Blacklist"></a>/etc/shorewall/blacklist</h2>
|
||
|
||
<p>Each
|
||
line
|
||
in
|
||
/etc/shorewall/blacklist
|
||
contains
|
||
an
|
||
IP
|
||
address, a MAC address in <a href="#MAC">Shorewall Format</a>
|
||
or
|
||
subnet
|
||
address.
|
||
Example:</p>
|
||
|
||
<pre> 130.252.100.69
|
||
206.124.146.0/24</pre>
|
||
|
||
<p>Packets
|
||
<u><b>from</b></u>
|
||
hosts
|
||
listed
|
||
in
|
||
the
|
||
blacklist
|
||
file
|
||
will
|
||
be
|
||
disposed
|
||
of
|
||
according
|
||
to
|
||
the
|
||
value
|
||
assigned
|
||
to
|
||
the <a href="#Conf">BLACKLIST_DISPOSITION</a>
|
||
and <a href="#Conf">BLACKLIST_LOGLEVEL </a>variables
|
||
in
|
||
/etc/shorewall/shorewall.conf.
|
||
Only
|
||
packets
|
||
arriving
|
||
on
|
||
interfaces
|
||
that
|
||
have
|
||
the
|
||
'<a href="#Interfaces">blacklist</a>'
|
||
option
|
||
in
|
||
/etc/shorewall/interfaces
|
||
are
|
||
checked
|
||
against
|
||
the
|
||
blacklist. The black list is designed to prevent listed hosts/subnets from accessing services on <u><b>your</b></u> network.</p>
|
||
|
||
<p>Shorewall also has a <a href="blacklisting_support.htm">dynamic blacklist capability.</a></p>
|
||
|
||
<p><font color="#CC6666"><b>IMPORTANT: The Shorewall blacklist file is <u>NOT</u> designed to police your users' web browsing -- to do that, I suggest that you install and configure Squid (<a href="http://www.squid-cache.org">http://www.squid-cache.org</a>). </b></font></p>
|
||
|
||
|
||
|
||
<h2><a name="rfc1918"></a>/etc/shorewall/rfc1918 (Added in Version 1.3.1)</h2>
|
||
|
||
|
||
|
||
<p>This file lists the subnets affected by the <a href="#Interfaces"><i>norfc1918</i> interface option</a>. Columns in the file are:</p>
|
||
|
||
|
||
|
||
<ul>
|
||
<li><b>SUBNET</b> - The subnet using VLSM notation (e.g., 192.168.0.0/16).</li>
|
||
<li><b>TARGET<i> </i></b>- What to do with packets to/from the SUBNET:<ul>
|
||
<li><b>RETURN</b> - Process the packet normally thru the rules and policies.</li>
|
||
<li><b>DROP</b> - Silently drop the packet.</li>
|
||
<li><b>logdrop</b> - Log then drop the packet.</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
|
||
|
||
<h2><a name="Routestopped"></a>25. /etc/shorewall/routestopped (Added in Version 1.3.4)</h2>
|
||
|
||
|
||
|
||
<p>This fine defines the hosts that are accessible from the firewall when the firewall is stopped. 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">
|
||
<tr>
|
||
<td><u><b>INTERFACE</b></u></td>
|
||
<td><u><b>HOST(S)</b></u></td>
|
||
</tr>
|
||
<tr>
|
||
<td>eth2</td>
|
||
<td>192.168.1.0/24</td>
|
||
</tr>
|
||
<tr>
|
||
<td>eth1</td>
|
||
<td>-</td>
|
||
</tr>
|
||
</table>
|
||
</blockquote>
|
||
|
||
|
||
|
||
<p><font size="2">
|
||
Updated 8/22/2002 - <a href="support.htm">Tom
|
||
Eastep</a>
|
||
</font></p>
|
||
|
||
|
||
|
||
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
|
||
<20> <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
|
||
|
||
|
||
|
||
<font face="Century Gothic, Arial, Helvetica">
|
||
|
||
|
||
|
||
</font></body></html> |