2002-08-13 22:45:21 +02:00
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
|
|
|
|
<html>
|
|
|
|
|
|
<head>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<meta http-equiv="Content-Type"
|
|
|
|
|
|
content="text/html; charset=windows-1252">
|
2002-08-13 22:45:21 +02:00
|
|
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
2003-02-20 00:21:55 +01:00
|
|
|
|
<title>Shorewall 1.4 Documentation</title>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<base target="_self">
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<meta name="Microsoft Theme" content="none, default">
|
|
|
|
|
|
<meta name="Microsoft Border" content="none, default">
|
2003-02-20 00:21:55 +01:00
|
|
|
|
<meta name="author" content="Tom Eastep">
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</head>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<body>
|
2003-12-03 00:51:46 +01:00
|
|
|
|
<h1 style="text-align: center;">Shorewall 1.4 Reference<br>
|
|
|
|
|
|
</h1>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<h2>Components</h2>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p>Shorewall consists of the following components: </p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-12-03 00:51:46 +01:00
|
|
|
|
<li><span style="font-weight: bold;">init.sh </span>-- a shell
|
|
|
|
|
|
script installed in /etc/init.d to automatically start Shorewall during
|
|
|
|
|
|
boot.<br>
|
|
|
|
|
|
<b> </b></li>
|
|
|
|
|
|
<li><b><a href="#Interfaces">interfaces</a> </b> -- a parameter
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2003-12-03 00:51:46 +01:00
|
|
|
|
<li><b>firewall</b> --
|
2003-08-09 19:14:58 +02:00
|
|
|
|
a shell program that reads the configuration files in /etc/shorewall
|
2003-12-03 00:51:46 +01:00
|
|
|
|
and configures your firewall. This file is installed in
|
|
|
|
|
|
/usr/share/shorewall.</li>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<li><b> <a href="#NAT">nat</a></b> -- a parameter file in
|
2003-12-03 00:51:46 +01:00
|
|
|
|
/etc/shorewall used to define <a href="#NAT">one-to-one NAT</a> .</li>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<li><a href="Accounting.html"><span style="font-weight: bold;">accounting</span></a>
|
|
|
|
|
|
-- a parameter file in /etc/shorewall used to define traffic accounting
|
|
|
|
|
|
rules. This file was added in version 1.4.7.<br>
|
|
|
|
|
|
</li>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-12-09 19:32:39 +01:00
|
|
|
|
<li><a href="UserSets.html" style="font-weight: bold;">users and
|
|
|
|
|
|
usersets</a> - files in /etc/shorewall allowing connections originating
|
|
|
|
|
|
on the firewall to be policed by the user id and/or group id of the
|
|
|
|
|
|
user.</li>
|
|
|
|
|
|
<li><a href="User_defined_Actions.html"><span
|
|
|
|
|
|
style="font-weight: bold;">actions and action.template</span></a> -
|
|
|
|
|
|
files in /etc/shorewall that allow you to define your own actions for
|
|
|
|
|
|
rules in /etc/shorewall/rules.<br>
|
|
|
|
|
|
</li>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p>It is suggested that variable names begin with an upper case letter<font
|
2003-08-09 19:14:58 +02:00
|
|
|
|
size="1"> </font>to distinguish them from variables used internally
|
|
|
|
|
|
within the Shorewall programs</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p>Example:</p>
|
2003-01-22 01:37:23 +01:00
|
|
|
|
<pre><font face="Courier"> NET_IF=eth0<br> NET_BCAST=130.252.100.255<br> NET_OPTIONS=blacklist,norfc1918</font></pre>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<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>
|
2003-01-22 01:37:23 +01:00
|
|
|
|
<pre> <font face="Courier">net eth0 130.252.100.255 blacklist,norfc1918</font></pre>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p>The /etc/shorewall/zones file released with Shorewall is as follows:</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" style="border-collapse: collapse;" cellpadding="2">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p><b><font size="5" color="#ff0000">Warning 2: </font><font
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2003-07-07 16:18:52 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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":
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</li>
|
|
|
|
|
|
<li><b> OPTIONS</b> - a comma-separated list of options. Possible
|
|
|
|
|
|
options include:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;">arp_filter </span>(Added in
|
|
|
|
|
|
version 1.4.7) - This option causes
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
|
|
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
|
|
|
|
hosts that are routed out of that interface. Setting this option
|
|
|
|
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
|
|
|
|
are connected to the same HUB/Switch (all interface connected to the
|
|
|
|
|
|
single HUB/Switch should have this option specified). Note that using
|
|
|
|
|
|
such a configuration in a production environment is strongly
|
|
|
|
|
|
recommended against.<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
|
2003-07-16 20:59:33 +02:00
|
|
|
|
href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean1.patch">here's
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2002-12-28 16:38:03 +01:00
|
|
|
|
<p>My recommendations concerning options:<br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</p>
|
2002-12-28 16:38:03 +01:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-12-28 16:38:03 +01:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
<p>Example 2: You have a standalone dialup GNU/Linux System. Your
|
|
|
|
|
|
/etc/shorewall/interfaces file would be:</p>
|
|
|
|
|
|
<blockquote>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
</ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<b>IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS
|
|
|
|
|
|
THEN DON'T TOUCH THIS FILE!!</b>
|
|
|
|
|
|
<p>Columns in this file are:</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<blockquote>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<li><b> OPTIONS</b> - A comma-separated list of option</li>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<p>Example 1:</p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p>Your local interface is eth1 and you have two groups of local hosts
|
|
|
|
|
|
that you want to make into separate zones:</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<li>192.168.1.0/25 </li>
|
|
|
|
|
|
<li>192.168.1.128/</li>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<p>Your /etc/shorewall/interfaces file might look like:</p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<blockquote>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<p>Example 2:</p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<li>192.168.1.0/25 </li>
|
|
|
|
|
|
<li>192.168.1.128/25</li>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p> Your /etc/shorewall/interfaces file might look like:</p>
|
|
|
|
|
|
<blockquote>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-02-20 00:21:55 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
<p> Your /etc/shorewall/hosts file might look like:</p>
|
|
|
|
|
|
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
|
2003-07-07 16:18:52 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-07 16:18:52 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
If you are running Shorewall 1.4.6 or later, your hosts file may look
|
|
|
|
|
|
like:<br>
|
|
|
|
|
|
<blockquote>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
<h4><font color="#660066"><a name="Nested"></a> Nested and Overlapping
|
2003-07-16 20:59:33 +02:00
|
|
|
|
Zones</font></h4>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<p>Four policies are defined:</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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.
|
2003-10-07 00:38:40 +02:00
|
|
|
|
Connection requests in excess of these limits will be dropped. See the <a
|
|
|
|
|
|
href="#Rules">rules file documentation</a> for an explaination of how
|
|
|
|
|
|
rate limiting works.<br>
|
|
|
|
|
|
</li>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-02-04 16:26:02 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
<p> This table may be interpreted as follows:</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<p><b><font size="4" color="#ff0000">WARNING:</font></b></p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<h4><a name="IntraZone"></a>IntraZone Traffic</h4>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ol>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
<p> /etc/shorewall/interfaces:</p>
|
|
|
|
|
|
<blockquote>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
<p> /etc/shorewall/hosts:</p>
|
|
|
|
|
|
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
|
2002-11-09 19:06:34 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-11-09 19:06:34 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-01-22 01:37:23 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-02-25 20:24:41 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-03-22 01:25:40 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>...</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>...</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<table style="border-collapse: collapse;" cellpadding="2" border="1">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>...</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>DNAT</td>
|
|
|
|
|
|
<td>sam</td>
|
|
|
|
|
|
<td>fw</td>
|
|
|
|
|
|
<td>tcp</td>
|
|
|
|
|
|
<td>ssh</td>
|
|
|
|
|
|
<td>-</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>...</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2002-11-09 19:06:34 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<li><b>ACTION</b>
|
2003-07-04 18:41:22 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-12-03 00:51:46 +01:00
|
|
|
|
<li>QUEUE - Forward the packet to a user-space application. This
|
|
|
|
|
|
facility is provided to allow interfacing to <a
|
|
|
|
|
|
href="http://p2pwall.sourceforge.net">ftwall</a> for <a
|
|
|
|
|
|
href="Shorewall_and_Kazaa.html">Kazaa filtering</a>. Note: When the
|
|
|
|
|
|
protocol specified in the PROTO column is TCP ("tcp", "TCP" or "6"),
|
|
|
|
|
|
Shorewall will only pass connection requests (SYN packets) to user
|
|
|
|
|
|
space. This is for compatibility with ftwall.</li>
|
2003-12-09 19:32:39 +01:00
|
|
|
|
<li>A <a href="User_defined_Actions.html"><user-defined
|
|
|
|
|
|
action></a> (Shorewall 1.4.9 and later)<br>
|
|
|
|
|
|
</li>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<p>Beginning with Shorewall version 1.4.7, you may rate-limit the
|
|
|
|
|
|
rule by optionally following ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
< <rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate> is the number of connections per <br>
|
|
|
|
|
|
|
|
|
|
|
|
<interval> ("sec" or "min") and <burst> is the largest
|
|
|
|
|
|
burst permitted. If no burst value is given, a value of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no whitespace embedded in the
|
|
|
|
|
|
specification. <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Let's take an example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT<2/sec:4>
|
|
|
|
|
|
net dmz tcp 80<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
|
|
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
|
|
|
|
After this, it will be 500ms (1 second divided by the rate of 2) before
|
|
|
|
|
|
a packet will be accepted from this rule, regardless of how many
|
|
|
|
|
|
packets reach it. Also, every 500ms which passes without matching a
|
|
|
|
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
|
|
|
|
for 2 second, the burst will be fully recharged; back where we started.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;">Warning: </span>When rate
|
|
|
|
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST fields
|
|
|
|
|
|
below, the limit will apply to each pair of zones individually rather
|
|
|
|
|
|
than as a single limit for all pairs of zones covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Rate limiting may also be specified in the RATE LIMIT column below; in
|
|
|
|
|
|
that case, it must not be specified as part of the ACTION column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The ACTION (and rate limit) may optionally be followed by ":" and a <a
|
|
|
|
|
|
href="shorewall_logging.html">syslog level</a> (example: REJECT:info
|
|
|
|
|
|
or ACCEPT<2/sec:4>:debugging).
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<li> <br>
|
|
|
|
|
|
</li>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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:
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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:
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
Restrictions:<br>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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
|
2003-10-07 00:38:40 +02:00
|
|
|
|
the SNAT address.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li><span style="font-weight: bold;">RATE LIMIT </span>- Beginning
|
|
|
|
|
|
with Shorewall version 1.4.7, you may rate-limit ACCEPT, DNAT[-],
|
|
|
|
|
|
REDIRECT[-] or LOG rules with an entry in this column. Entries have the
|
|
|
|
|
|
form<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate>/<interval>[:<burst>] <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate> is the number of connections per <br>
|
|
|
|
|
|
|
|
|
|
|
|
<interval> ("sec" or "min") and <burst> is the largest
|
|
|
|
|
|
burst permitted. If no burst value is given, a value of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no whitespace embedded in the
|
|
|
|
|
|
specification. <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Let's take an example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT<2/sec:4>
|
|
|
|
|
|
net dmz tcp 80<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
|
|
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
|
|
|
|
After this, it will be 500ms (1 second divided by the rate of 2) before
|
|
|
|
|
|
a packet will be accepted from this rule, regardless of how many
|
|
|
|
|
|
packets reach it. Also, every 500ms which passes without matching a
|
|
|
|
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
|
|
|
|
for 2 second, the burst will be fully recharged; back where we started.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;">Warning: </span>When rate
|
|
|
|
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST fields
|
|
|
|
|
|
below, the limit will apply to each pair of zones individually rather
|
|
|
|
|
|
than as a single limit for all pairs of zones covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Rate limiting may also be specified in the ACTION column above; in that
|
|
|
|
|
|
case, it must not be specified as part of the RATE LIMIT column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If you want to specify any following columns but no rate limit, place
|
|
|
|
|
|
"-" in this column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li><span style="font-weight: bold;">USER SET </span>- Beginning
|
|
|
|
|
|
with Shorewall release 1.4.7, output rules from the firewall itself may
|
|
|
|
|
|
be restricted to a particular set of users and/or user groups. See the <a
|
|
|
|
|
|
href="UserSets.html">User Set Documentation </a>for details.<br>
|
|
|
|
|
|
</li>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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
|
2003-10-07 00:38:40 +02:00
|
|
|
|
192.168.1.3. You wish to limit the number of connections to
|
|
|
|
|
|
4/minute with a burst of 8 (Shorewall 1.4.7 and later only): </p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET<br>
|
|
|
|
|
|
</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td>DNAT<4/min:8></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<td>net</td>
|
|
|
|
|
|
<td>loc:192.168.1.3</td>
|
|
|
|
|
|
<td>tcp</td>
|
|
|
|
|
|
<td>ssh</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET<br>
|
|
|
|
|
|
</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
|
|
|
|
<td>ACCEPT</td>
|
|
|
|
|
|
<td>fw</td>
|
|
|
|
|
|
<td>net</td>
|
|
|
|
|
|
<td>tcp</td>
|
|
|
|
|
|
<td>www</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td> <br>
|
|
|
|
|
|
</td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-04-13 17:28:32 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2003-04-13 17:28:32 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
|
|
|
|
|
<b>Example 6.</b> You wish to allow access to the SMTP server in your
|
|
|
|
|
|
DMZ from all zones.<br>
|
|
|
|
|
|
<blockquote>
|
2003-06-18 22:03:19 +02:00
|
|
|
|
<table cellpadding="2" cellspacing="0" border="1">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><b>ORIGINAL<br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
DEST<br>
|
|
|
|
|
|
</b></td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2003-06-18 22:03:19 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-06-18 22:03:19 +02:00
|
|
|
|
<table cellpadding="2" cellspacing="0" border="1">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><b>ORIGINAL<br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
DEST<br>
|
|
|
|
|
|
</b></td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2003-01-14 18:18:42 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-07-04 18:41:22 +02:00
|
|
|
|
<table cellpadding="2" cellspacing="0" border="1">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><b>ORIGINAL<br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
DEST<br>
|
|
|
|
|
|
</b></td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2003-07-04 18:41:22 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-07-04 18:41:22 +02:00
|
|
|
|
<table cellpadding="2" cellspacing="0" border="1">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><b>ORIGINAL<br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
DEST<br>
|
|
|
|
|
|
</b></td>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">RATE<br>
|
|
|
|
|
|
LIMIT<br>
|
|
|
|
|
|
</span></td>
|
|
|
|
|
|
<td style="vertical-align: top;"><span
|
|
|
|
|
|
style="font-weight: bold;">USER<br>
|
|
|
|
|
|
SET</span></td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
|
|
|
|
|
<td style="vertical-align: top;"><br>
|
|
|
|
|
|
</td>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<p> Columns are:</p>
|
|
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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
|
2003-10-07 00:38:40 +02:00
|
|
|
|
ADD_SNAT_ALIASES enabled in <a href="#Conf">/etc/shorewall/shorewall.conf.</a>
|
|
|
|
|
|
Beginning with Shorewall version 1.4.6, you may include a range of IP
|
|
|
|
|
|
addresses in this column to indicate that Netfilter should use the
|
|
|
|
|
|
addresses in the range in round-robin fashion. Beginning with Shorewall
|
|
|
|
|
|
version 1.4.7, you may include a list of ranges and/or addresses in
|
|
|
|
|
|
this column; again, Netfilter will use all listed ranges/addresses in
|
|
|
|
|
|
rounde-robin fashion.</li>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<p><b>Example 1: </b> You have eth0 connected to a cable modem and
|
2003-08-09 19:14:58 +02:00
|
|
|
|
eth1 connected to your local subnetwork 192.168.9.0/24. Your
|
|
|
|
|
|
/etc/shorewall/masq file would look like: </p>
|
|
|
|
|
|
<blockquote>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-03-07 00:41:31 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-01-31 22:50:51 +01:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-01-31 22:50:51 +01:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<table border="1" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</blockquote>
|
2003-10-07 00:38:40 +02:00
|
|
|
|
<span style="font-weight: bold;">Example 6 (Shorewall version >=
|
|
|
|
|
|
1.4.7): </span>You want to use both 206.124.146.177 and
|
|
|
|
|
|
206.124.146.179 for SNAT of the subnet 192.168.12.0/24. Each address
|
|
|
|
|
|
will be used on alternate outbound connections.<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</td>
|
|
|
|
|
|
<td>192.168.12.0/24</td>
|
|
|
|
|
|
<td>206.124.146.177,206.124.146.179</td>
|
|
|
|
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
|
|
|
|
|
</table>
|
|
|
|
|
|
</blockquote>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-05-18 20:27:36 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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
|
2003-07-16 20:59:33 +02:00
|
|
|
|
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>)
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p>In /etc/shorewall/init, include:</p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p> qt service ipsec stop</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p>In /etc/shorewall/start, include:</p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p> qt service ipsec start</p>
|
|
|
|
|
|
<h2><font color="#660066"><b><a name="NAT"></a> </b></font>/etc/shorewall/nat</h2>
|
2003-12-03 00:51:46 +01:00
|
|
|
|
<p>The /etc/shorewall/nat file is used to define one-to-one NAT. There
|
|
|
|
|
|
is
|
|
|
|
|
|
one entry in the file for each one-to-one NAT relationship that you
|
|
|
|
|
|
wish to
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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
|
2003-12-03 00:51:46 +01:00
|
|
|
|
one-to-one NAT. Port forwarding can be accomplished with simple entries
|
|
|
|
|
|
in
|
2003-08-09 19:14:58 +02:00
|
|
|
|
the <a href="#Rules"> rules file</a>. Also, in most cases <a
|
2003-12-03 00:51:46 +01:00
|
|
|
|
href="#ProxyArp"> Proxy ARP</a> provides a superior solution to
|
|
|
|
|
|
one-to-one NAT because the internal systems are accessed using the same
|
|
|
|
|
|
IP address
|
2003-08-09 19:14:58 +02:00
|
|
|
|
internally and externally.</b></font></p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p>Columns in an entry are:</p>
|
|
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>,
|
|
|
|
|
|
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> </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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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
|
2003-10-07 00:38:40 +02:00
|
|
|
|
for PPTP tunnels are here</a>, <a href="6to4.htm">instructions for
|
|
|
|
|
|
6to4 tunnels are here</a> and <a href="GenericTunnels.html">instructions
|
|
|
|
|
|
for integrating Shorewall with other types of tunnels are here</a>.<br>
|
|
|
|
|
|
</b></p>
|
2002-12-28 16:38:03 +01:00
|
|
|
|
<h2><a name="Conf"></a>/etc/shorewall/shorewall.conf</h2>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p> This file is used to set the following firewall parameters:</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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,
|
|
|
|
|
|
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>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
LOGFORMAT="fp=%s:%d a=%s "<br>
|
|
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<li>No port range(s) specified</li>
|
|
|
|
|
|
<li>Specifies 15 or fewer ports</li>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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
|
2003-12-03 00:51:46 +01:00
|
|
|
|
"yes", port forwarding rules cannot override one-to-one NAT. If not set
|
|
|
|
|
|
or
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2003-12-03 00:51:46 +01:00
|
|
|
|
One-to-one NAT<br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p>where</p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="2" cellpadding="2" style="border-collapse: collapse;">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<h2><a name="Blacklist"></a>/etc/shorewall/blacklist</h2>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-01-31 22:50:51 +01:00
|
|
|
|
<pre> 130.252.100.69<br> 206.124.146.0/24</pre>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<p>Beginning with Shorewall 1.3.8, the blacklist file has three columns:<br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</p>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<p>Shorewall also has a <a href="blacklisting_support.htm">dynamic
|
|
|
|
|
|
blacklist capability.</a></p>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<p><font color="#cc6666"><b>IMPORTANT: The Shorewall blacklist file is <u>NOT</u>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
designed to police your users' web browsing -- to do that, I suggest
|
|
|
|
|
|
that you install and configure Squid (<a
|
2003-10-07 00:38:40 +02:00
|
|
|
|
href="http://www.squid-cache.org">http://www.squid-cache.org</a>) with
|
|
|
|
|
|
SquidGuard (<a href="http://www.squidguard.org/">http://www.squidguard.org/</a>).
|
|
|
|
|
|
</b></font></p>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<h2><a name="rfc1918"></a>/etc/shorewall/rfc1918 (Added in Version
|
|
|
|
|
|
1.3.1)</h2>
|
2003-07-16 20:59:33 +02:00
|
|
|
|
<p>This file lists the subnets affected by the <a href="#Interfaces"><i>norfc1918</i>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
interface option</a>. Columns in the file are:</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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:
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</li>
|
2003-05-15 21:39:23 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2003-05-15 21:39:23 +02:00
|
|
|
|
</ul>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
<table border="2" style="border-collapse: collapse;" id="AutoNumber1"
|
|
|
|
|
|
cellpadding="2">
|
2003-08-09 19:14:58 +02:00
|
|
|
|
<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>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</table>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</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>
|
2003-02-25 20:24:41 +01:00
|
|
|
|
<h2><a name="ECN"></a>/etc/shorewall/ecn (Added in Version 1.4.0)</h2>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
This file is described in the <a href="ECN.html">ECN Control
|
|
|
|
|
|
Documentation</a>.<br>
|
2003-12-09 19:32:39 +01:00
|
|
|
|
<p><font size="-1"> Updated 12/08/2003 - <a href="support.htm">Tom
|
2003-10-07 00:38:40 +02:00
|
|
|
|
Eastep</a>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</font></p>
|
|
|
|
|
|
<p><a href="copyright.htm"><font size="2">Copyright</font> <20> <font
|
2003-01-14 18:18:42 +01:00
|
|
|
|
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
|
2003-08-09 19:14:58 +02:00
|
|
|
|
</p>
|
2002-09-16 19:13:10 +02:00
|
|
|
|
</body>
|
|
|
|
|
|
</html>
|
