2005-05-20 00:17:37 +02:00
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
2003-12-30 02:19:52 +01:00
|
|
|
|
<html>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<head>
|
|
|
|
|
|
<meta name="generator" content=
|
|
|
|
|
|
"HTML Tidy for Linux (vers 1st April 2002), see www.w3.org">
|
|
|
|
|
|
<meta http-equiv="Content-Type" content=
|
|
|
|
|
|
"text/html; charset=UTF-8">
|
|
|
|
|
|
|
|
|
|
|
|
<title>Shorewall News</title>
|
|
|
|
|
|
</head>
|
|
|
|
|
|
|
|
|
|
|
|
<body>
|
|
|
|
|
|
<h1 style="text-align: left;">Shorewall News and
|
|
|
|
|
|
Announcements<br>
|
|
|
|
|
|
</h1>
|
|
|
|
|
|
<span style="font-weight: bold;">Tom Eastep<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span>Copyright © 2001-2005 Thomas M. Eastep<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Permission is granted to copy, distribute and/or modify this
|
|
|
|
|
|
document under the terms of the GNU Free Documentation License,
|
|
|
|
|
|
Version 1.2 or any later version published by the Free Software
|
|
|
|
|
|
Foundation; with no Invariant Sections, with no Front-Cover,
|
|
|
|
|
|
and with no Back-Cover Texts. A copy of the license is included
|
|
|
|
|
|
in the section entitled “<span class="quote"><a href=
|
|
|
|
|
|
"GnuCopyright.htm" target="_self">GNU Free Documentation
|
|
|
|
|
|
License</a></span>”.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>2005-09-12<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
<hr style="width: 100%; height: 2px;">
|
|
|
|
|
|
<span style="font-weight: bold;">09/12/2005 Shorewall 2.4.4<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>An incorrect comment in the /etc/shorewall/proxyarp file
|
|
|
|
|
|
has been removed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The message generated when a duplicate policy has been
|
|
|
|
|
|
entered is now more informative. Previously, only the POLICY
|
|
|
|
|
|
column contents appeared in the message. Now the SOURCE, DEST
|
|
|
|
|
|
and POLICY column contents are shown.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now clears the Netfilter "raw" table during
|
|
|
|
|
|
"shorewall [re]start", "shorewall stop" and "shorewall clear"
|
|
|
|
|
|
processing.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Tunnel types "openvpnserver" and "openvpnclient" have
|
|
|
|
|
|
been added to reflect the introduction of client and server
|
|
|
|
|
|
OpenVPN configurations in OpenVPN 2.0.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The COMMAND variable is now set to 'restore' in restore
|
|
|
|
|
|
scripts. The value of this variable is sometimes of interest
|
|
|
|
|
|
to programmers providing custom /etc/shorewall/tcstart
|
|
|
|
|
|
scripts.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">08/16/2005 Shorewall 2.4.3<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall is no longer dependent on the 'which'
|
|
|
|
|
|
utility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'shorewall add' command failed if there existed a
|
|
|
|
|
|
zone in the configuration that specified the 'ipsec' option
|
|
|
|
|
|
in /etc/shorewall/hosts.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall is no longer dependent on /bin/echo.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A CLASSIFY rule with $FW in the SOURCE column
|
|
|
|
|
|
(tcrules) no longer results in a "shorewall start"
|
|
|
|
|
|
error.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You may now use port lists in the DEST PORT and SOURCE
|
|
|
|
|
|
PORT columns of the /etc/shorewall/accounting file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall show capabilities" command now accurately
|
|
|
|
|
|
reports the availability of "Packet type match" independent
|
|
|
|
|
|
of the setting of PKTTYPE in shorewall.conf.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Tuomo Soini, all of the files have been
|
|
|
|
|
|
siginificantly cleaned up in terms of formatting and extra
|
|
|
|
|
|
white-space.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>New Allow.Submission and Allow.NTPbrd actions have been
|
|
|
|
|
|
added. Users of the Allow.NTP action that use NTP
|
|
|
|
|
|
broadcasting should switch to use of Allow.NTPbrd
|
|
|
|
|
|
instead.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The kernel version string is now included in the output
|
|
|
|
|
|
of "shorewall status".<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">07/30/2005 Shorewall 2.2.6<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li><a href="#20050717">MACLIST_TTL Vulnerability</a>
|
|
|
|
|
|
fix.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of
|
|
|
|
|
|
iptables.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The bogons file has been updated to reflect recent IANA
|
|
|
|
|
|
allocations.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">07/21/2005 Shorewall 2.4.2<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<ol>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>The /etc/shorewall/hosts file now includes information
|
|
|
|
|
|
about defining a zone using one or more ipsets.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A <a href="#20050717">vulnerability involving MACLIST_TTL
|
|
|
|
|
|
> 0 or MACLIST_DISPOSITION=ACCEPT</a> has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is now possible to specify !<address> in the
|
|
|
|
|
|
SUBNET column of /etc/shorewall/masq. Previously, it was
|
|
|
|
|
|
necessary to write 0.0.0.0/0!<address>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When <network1>!<network2> was specified in
|
|
|
|
|
|
the SUBNET column of /etc/shorewall/masq, IPSEC policies were
|
|
|
|
|
|
not correctly applied to the resulting rules. This usually
|
|
|
|
|
|
resulted in IPSEC not working through the interface specified
|
|
|
|
|
|
in the INTERFACES column.<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
</li>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<li>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
A 'loose' provider option has been added. If you wish to be
|
|
|
|
|
|
able to use marking to specify the gateway used by
|
|
|
|
|
|
connections originating on the firewall itself, the specify
|
|
|
|
|
|
'loose' for each provider. It has bee reported that 'loose'
|
|
|
|
|
|
may break the effect of 'track' so beware if you need
|
|
|
|
|
|
'track' functionality (you shouldn't be originating many
|
|
|
|
|
|
connections from your firewall to the net anyway).<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
To use 'loose', you also need to add two entries in
|
|
|
|
|
|
/etc/shorewall/masq:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">#INTERFACE SUBNET ADDRESS<br>
|
|
|
|
|
|
$IF_ISP1 $IP_ISP2 $IP_ISP1<br>
|
|
|
|
|
|
$IF_ISP2 $IP_ISP1 $IP_ISP2</span>
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
$IF_ISP1 is the interface to ISP 1.<br>
|
|
|
|
|
|
$IF_ISP2 is the interface to ISP 2.<br>
|
|
|
|
|
|
$IP_ISP1 is the IP address of $IF_ISP1<br>
|
|
|
|
|
|
$IP_ISP2 is the IP address of $IF_ISP2
|
|
|
|
|
|
</pre>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
</li>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<li>/sbin/shorewall now issues a warning each time that it
|
|
|
|
|
|
finds that startup is disabled.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new COPY column has been added to the
|
|
|
|
|
|
/etc/shorewall/providers file. Normally, when a table
|
|
|
|
|
|
name/number is given in the DUPLICATE column, the entire
|
|
|
|
|
|
table (less default routes) is copied. The COPY column allows
|
|
|
|
|
|
you to limit the routes copied to those that go through an
|
|
|
|
|
|
interface listed in COPY. For example, if you enter eth0 in
|
|
|
|
|
|
INTERFACE, "eth1,eth2" in COPY and 'main' in DUPLICATE then
|
|
|
|
|
|
the new table created will contain those routes through the
|
|
|
|
|
|
interfaces eth0, eth1 and eth2.<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
</li>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<hr style="width: 100%; height: 2px;">
|
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="20050717"></a><font color="#ff0000">07/17/2005
|
|
|
|
|
|
Security vulnerability in MACLIST processing</font></h2>
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Description</h3>
|
|
|
|
|
|
|
|
|
|
|
|
<p>A security vulnerability has been discovered which affects
|
|
|
|
|
|
all supported stable versions of Shorewall. This
|
|
|
|
|
|
vulnerability enables a client accepted by MAC address
|
|
|
|
|
|
filtering to bypass any other rule. If MACLIST_TTL is set
|
|
|
|
|
|
to a value greater than 0 or MACLIST_DISPOSITION is set to
|
|
|
|
|
|
"ACCEPT" in /etc/shorewall/shorewall.conf (default is
|
|
|
|
|
|
MACLIST_TTL=0 and MACLIST_DISPOSITION=REJECT), and a client is
|
|
|
|
|
|
positively identified through its MAC address, it bypasses all
|
|
|
|
|
|
other policies/rules in place, thus gaining access to all open
|
|
|
|
|
|
services on the firewall.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Fix</h3>
|
|
|
|
|
|
|
|
|
|
|
|
<h4>Workaround</h4>
|
|
|
|
|
|
|
|
|
|
|
|
<p>For Shorewall 2.2.x or 2.4.x, set MACLIST_TTL=0 or
|
|
|
|
|
|
MACLIST_DISPOSITION=REJECT in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. For Shorewall 2.0.x, set
|
|
|
|
|
|
MACLIST_DISPOSITION=REJECT in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. MACLIST filtering is of
|
|
|
|
|
|
limited value on Internet-connected hosts, and the Shorewall
|
|
|
|
|
|
team recommends this approach to be used if possible.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<h4>Upgrade</h4>
|
|
|
|
|
|
|
|
|
|
|
|
<p>For Shorewall 2.4.x, a fixed version of the 'firewall'
|
|
|
|
|
|
script is available at: <a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
|
|
|
|
|
|
http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
|
|
|
|
|
|
and its mirrors, <a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
|
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
|
|
|
|
|
|
and <a href=
|
|
|
|
|
|
"http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
|
|
|
|
|
|
http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>For Shorewall 2.2.x, a fixed version of the 'firewall'
|
|
|
|
|
|
script is available at: <a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
|
|
|
|
|
|
http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
|
|
|
|
|
|
and its mirrors, <a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
|
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
|
|
|
|
|
|
and <a href=
|
|
|
|
|
|
"http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
|
|
|
|
|
|
http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>For Shorewall 2.0.x, a fixed version of the 'firewall'
|
|
|
|
|
|
script is available at: <a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
|
|
|
|
|
|
and its mirrors, <a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall">
|
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
|
|
|
|
|
|
and <a href=
|
|
|
|
|
|
"http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall">
|
|
|
|
|
|
http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Users of any version before 2.0.17 are urged to upgrade to a
|
|
|
|
|
|
supported version of Shorewall (preferably 2.4.1) before using
|
|
|
|
|
|
the fixed files. Only the most recent version of the
|
|
|
|
|
|
2.0.x and 2.2.x streams will be supported by the development
|
|
|
|
|
|
team, and the 1.x branches are no longer maintained at
|
|
|
|
|
|
all. Future releases of Shorewall will include this
|
|
|
|
|
|
fix.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This information was based on <a href=
|
|
|
|
|
|
"http://seclists.org/lists/fulldisclosure/2005/Jul/0409.html">Patrick
|
|
|
|
|
|
Blitz's post to the Full Disclosure mailing list</a>.
|
|
|
|
|
|
Thanks to Supernaut (supernaut at ns dot sympatico dot ca) for
|
|
|
|
|
|
reporting this bug.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;">Version Upgrade<br>
|
|
|
|
|
|
</span></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The vulnerability is corrected in Shorewall 2.4.2 and in
|
|
|
|
|
|
Shorewall 2.2.6.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
<hr style="width: 100%; height: 2px;">
|
|
|
|
|
|
<span style="font-weight: bold;">07/13/2005 Shorewall 2.4.1<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shell variables may now be used in the zones file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /usr/share/shorewall/bogons file has been updated to
|
|
|
|
|
|
reflect recent IANA allocations.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now detects an error where multiple providers
|
|
|
|
|
|
specify the 'track' option on the same interface.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The remnants of the GATEWAY column in
|
|
|
|
|
|
/etc/shorewall/interfaces have been removed. This column
|
|
|
|
|
|
appeared briefly in one of the Beta versions and was
|
|
|
|
|
|
immediately removed but some vestiges remained.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now correctly restores a load-balancing default
|
|
|
|
|
|
route during processing of the 'shorewall restore' and
|
|
|
|
|
|
'shorewall -f start' commands. The latter command is normally
|
|
|
|
|
|
executed by the Shorewall init script during reboot.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A log level of "None!" is now allowed on builtin actions
|
|
|
|
|
|
such as ACCEPT and DROP.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, LIMIT:BURST parameters in
|
|
|
|
|
|
/etc/shorewall/policy were not correctly applied when the
|
|
|
|
|
|
policy was QUEUE.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'chkconfig' command on FC4 and Mandriva previously
|
|
|
|
|
|
created symbolic links with incorrect names ("S-1shorewall").
|
|
|
|
|
|
The init script has been changed to prevent this incorrect
|
|
|
|
|
|
behavior.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DHCP traffic forwarded through a bridge could, under some
|
|
|
|
|
|
configurations, be filtered by the 'maclist' option even
|
|
|
|
|
|
though the 'dhcp' option was specified. This has been
|
|
|
|
|
|
corrected.<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
</li>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">06/05/2005 Shorewall 2.4.0<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
Note:</span> Because of the short time that has elapsed since
|
|
|
|
|
|
the release of Shorewall 2.2.0, Shorewall 2.0 will be supported
|
|
|
|
|
|
until 1 December 2005 or until the release of Shorewall 2.6.0,
|
|
|
|
|
|
whichever occurs first.<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
2004-10-25 17:52:26 +02:00
|
|
|
|
<ol>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>Shorewall 2.4.0 includes support for multiple internet
|
|
|
|
|
|
interfaces to different ISPs.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The file /etc/shorewall/providers may be used to define the
|
|
|
|
|
|
different providers. It can actually be used to define
|
|
|
|
|
|
alternate routing tables so uses like transparent proxy can
|
|
|
|
|
|
use the file as well.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Columns are:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
NAME
|
|
|
|
|
|
The provider name.</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
NUMBER
|
|
|
|
|
|
The provider number -- a number between 1 and 15</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
MARK
|
|
|
|
|
|
A FWMARK value used in your /etc/shorewall/tcrules file to
|
|
|
|
|
|
direct packets for this provider.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
DUPLICATE The name of an
|
|
|
|
|
|
existing table to duplicate. May</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">be 'main' or the name of a previous
|
|
|
|
|
|
provider.</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
INTERFACE The name of the
|
|
|
|
|
|
network interface to the</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">provider. Must be listed
|
|
|
|
|
|
in</span><span style=
|
|
|
|
|
|
"font-family: monospace;">/etc/shorewall/interfaces.</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
GATEWAY The
|
|
|
|
|
|
IP address of the provider's gateway router.</span> <span
|
|
|
|
|
|
style="font-family: monospace;">If you enter "detect" here
|
|
|
|
|
|
then Shorewall<br>
|
|
|
|
|
|
|
|
|
|
|
|
will</span> <span style="font-family: monospace;">attempt to
|
|
|
|
|
|
determine the gateway IP address</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">automatically.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
OPTIONS A
|
|
|
|
|
|
comma-separated list selected from the</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">following:</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
track If specified, connections FROM this
|
|
|
|
|
|
interface are</span> <span style="font-family: monospace;">to
|
|
|
|
|
|
be tracked so that responses may be<br>
|
|
|
|
|
|
|
|
|
|
|
|
routed</span> <span style="font-family: monospace;">back out
|
|
|
|
|
|
this same interface.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
You want specify 'track' if internet hosts will be</span>
|
|
|
|
|
|
<span style="font-family: monospace;">connecting to local
|
|
|
|
|
|
servers through<br>
|
|
|
|
|
|
|
|
|
|
|
|
this</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">provider.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
Because of limitations in the 'ip' utility and</span> <span
|
|
|
|
|
|
style="font-family: monospace;">policy routing, you may not
|
|
|
|
|
|
use the SAVE or</span><span style=
|
|
|
|
|
|
"font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
|
|
RESTORE tcrules options or use connection</span><span style=
|
|
|
|
|
|
"font-family: monospace;">marking on any traffic to or from
|
|
|
|
|
|
this</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
interface. For traffic control purposes, you</span> <span
|
|
|
|
|
|
style="font-family: monospace;">must mark packets in the
|
|
|
|
|
|
FORWARD chain (or</span><span style=
|
|
|
|
|
|
"font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
|
|
better yet, use the CLASSIFY target).</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
balance The providers that have 'balance' specified
|
|
|
|
|
|
will</span> <span style="font-family: monospace;">get
|
|
|
|
|
|
outbound traffic load-balanced among<br>
|
|
|
|
|
|
|
|
|
|
|
|
them. By</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">default, all interfaces with
|
|
|
|
|
|
'balance' specified</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">will have the same weight (1).<br>
|
|
|
|
|
|
|
|
|
|
|
|
You can change the</span><span style=
|
|
|
|
|
|
"font-family: monospace;">weight of the route out of the
|
|
|
|
|
|
interface by</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">specifiying
|
|
|
|
|
|
balance=<weight><br>
|
|
|
|
|
|
|
|
|
|
|
|
where <weight> is</span><span style=
|
|
|
|
|
|
"font-family: monospace;">the desired route weight.</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
Example: You run
|
|
|
|
|
|
squid in your DMZ on IP address 192.168.2.99. Your DMZ
|
|
|
|
|
|
interface is eth2<br>
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
#NAME NUMBER MARK DUPLICATE INTERFACE
|
|
|
|
|
|
GATEWAY OPTIONS</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
Squid 1
|
|
|
|
|
|
1
|
|
|
|
|
|
-
|
|
|
|
|
|
eth2 192.168.2.99
|
|
|
|
|
|
-</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Use of this feature requires that your kernel and iptabls
|
|
|
|
|
|
support CONNMARK target and conntrack match support. It does
|
|
|
|
|
|
NOT require the ROUTE target extension.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
WARNING: The current version of iptables (1.3.1) is broken
|
|
|
|
|
|
with respect to CONNMARK and iptables-save/iptables-restore.
|
|
|
|
|
|
This means that if you configure multiple ISPs, "shorewall
|
|
|
|
|
|
restore" may fail. You must patch your iptables using the
|
|
|
|
|
|
patch at <a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff">
|
|
|
|
|
|
http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff</a>.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
</li>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<li>Shorewall 2.3.0 supports the 'cmd-owner' option of the
|
|
|
|
|
|
owner match facility in Netfilter. Like all owner match
|
|
|
|
|
|
options, 'cmd-owner' may only be applied to traffic that
|
|
|
|
|
|
originates on the firewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The syntax of the USER/GROUP column in the following files
|
|
|
|
|
|
has been extended:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/accounting<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/tcrules<br>
|
|
|
|
|
|
|
|
|
|
|
|
/usr/share/shorewall/action.template<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a command, prefix the command name with "+".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
+mozilla-bin
|
|
|
|
|
|
#The program is named "mozilla-bin"</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
joe+mozilla-bin
|
|
|
|
|
|
#The program is named "mozilla-bin" and</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
#is being run by user "joe"</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
joe:users+mozilla-bin #The program is named
|
|
|
|
|
|
"mozilla-bin" and</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
#is being run by user "joe" with</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
#effective group "users".</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note that this is not a particularly robust
|
|
|
|
|
|
feature and I would never advertise it as a "Personal
|
|
|
|
|
|
Firewall" equivalent. Using symbolic links, it's easy to
|
|
|
|
|
|
alias command names to be anything you want.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support has been added for ipsets (see <a href=
|
|
|
|
|
|
"http://people.netfilter.org/kadlec/ipset/">http://people.netfilter.org/kadlec/ipset/</a>).<br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In most places where a host or network address may be used,
|
|
|
|
|
|
you may also use the name of an ipset prefaced by "+".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:
|
|
|
|
|
|
"+Mirrors"<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The name of the set may be optionally followed by:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) a number from 1 to 6 enclosed in square brackets ([]) --
|
|
|
|
|
|
this number indicates the maximum number of ipset binding
|
|
|
|
|
|
levels that are to be matched. Depending on the context where
|
|
|
|
|
|
the ipset name is used, either all "src" or all "dst" matches
|
|
|
|
|
|
will be used.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:
|
|
|
|
|
|
"+Mirrors[4]"<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) a series of "src" and "dst" options separated by commas
|
|
|
|
|
|
and inclosed in square brackets ([]). These will be passed
|
|
|
|
|
|
directly to iptables in the generated --set clause. See the
|
|
|
|
|
|
ipset documentation for details.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:
|
|
|
|
|
|
"+Mirrors[src,dst,src]"<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note that "+Mirrors[4]" used in the SOURCE column of the
|
|
|
|
|
|
rules file is equivalent to "+Mirrors[src,src,src,src]".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To generate a negative match, prefix the "+" with "!" as in
|
|
|
|
|
|
"!+Mirrors".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 1: Blacklist all hosts in an ipset named
|
|
|
|
|
|
"blacklist"<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/blacklist<br>
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
#ADDRESS/SUBNET
|
|
|
|
|
|
PROTOCOL
|
|
|
|
|
|
PORT</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
+blacklist</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 2: Allow SSH from all hosts in an ipset named
|
|
|
|
|
|
"sshok:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules<br>
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
#ACTION
|
|
|
|
|
|
SOURCE
|
|
|
|
|
|
DEST PROTO DEST
|
|
|
|
|
|
PORT(S)</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
ACCEPT
|
|
|
|
|
|
+sshok
|
|
|
|
|
|
fw
|
|
|
|
|
|
tcp 22</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall can automatically capture the contents of your
|
|
|
|
|
|
ipsets for you. If you specify SAVE_IPSETS=Yes in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf then "shorewall save" will save
|
|
|
|
|
|
the contents of your ipsets. The file where the sets are
|
|
|
|
|
|
saved is formed by taking the name where the Shorewall
|
|
|
|
|
|
configuration is stored and appending "-ipsets". So if you
|
|
|
|
|
|
enter the command "shorewall save standard" then your
|
|
|
|
|
|
Shorewall configuration will be saved in
|
|
|
|
|
|
var/lib/shorewall/standard and your ipset contents will be
|
|
|
|
|
|
saved in /var/lib/shorewall/standard-ipsets. Assuming the
|
|
|
|
|
|
default RESTOREFILE setting, if you just enter "shorewall
|
|
|
|
|
|
save" then your Shorewall configuration will be saved in
|
|
|
|
|
|
/var/lib/shorewall/restore and your ipset contents will be
|
|
|
|
|
|
saved in /var/lib/shorewall/restore-ipsets.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Regardless of the setting of SAVE_IPSETS, the "shorewall -f
|
|
|
|
|
|
start" and "shorewall restore" commands will restore the
|
|
|
|
|
|
ipset contents corresponding to the Shorewall configuration
|
|
|
|
|
|
restored provided that the saved Shorewall configuration
|
|
|
|
|
|
specified exists.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
For example, "shorewall restore standard" would restore the
|
|
|
|
|
|
ipset contents from /var/lib/shorewall/standard-ipsets
|
|
|
|
|
|
provided that /var/lib/shorewall/standard exists and is
|
|
|
|
|
|
executable and that /var/lib/shorewall/standard-ipsets exists
|
|
|
|
|
|
and is executable.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Also regardless of the setting of SAVE_IPSETS, the "shorewall
|
|
|
|
|
|
forget" command will purge the saved ipset information (if
|
|
|
|
|
|
any) associated with the saved shorewall configuration being
|
|
|
|
|
|
removed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You can also associate ipset contents with Shorewall
|
|
|
|
|
|
configuration directories using the following command:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipset -S > <config
|
|
|
|
|
|
directory>/ipsets<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipset -S >
|
|
|
|
|
|
/etc/shorewall/ipsets<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When you start or restart Shorewall (including using the
|
|
|
|
|
|
'try' command) from the configuration directory, your ipsets
|
|
|
|
|
|
will be configured from the saved ipsets file. Once again,
|
|
|
|
|
|
this behavior is independent of the setting of
|
|
|
|
|
|
SAVE_IPSETS.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Ipsets are well suited for large blacklists. You can maintain
|
|
|
|
|
|
your blacklist using the 'ipset' utility without ever having
|
|
|
|
|
|
to restart or refresh Shorewall. If you use the
|
|
|
|
|
|
SAVE_IPSETS=Yes feature just be sure to "shorewall save"
|
|
|
|
|
|
after altering the blacklist ipset(s).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example /etc/shorewall/blacklist:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
#ADDRESS/SUBNET
|
|
|
|
|
|
PROTOCOL
|
|
|
|
|
|
PORT</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
+Blacklist[src,dst]</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
+Blacklistnets[src,dst]</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Create the blacklist ipsets using:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipset
|
|
|
|
|
|
-N Blacklist iphash<br>
|
|
|
|
|
|
ipset
|
|
|
|
|
|
-N Blacklistnets nethash<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Add entries<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipset -A Blacklist
|
|
|
|
|
|
206.124.146.177<br>
|
|
|
|
|
|
ipset -A Blacklistnets
|
|
|
|
|
|
206.124.146.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To allow entries for individual ports<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipset -N SMTP portmap
|
|
|
|
|
|
--from 1 --to 31<br>
|
|
|
|
|
|
ipset -A SMTP 25<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipset -A Blacklist
|
|
|
|
|
|
206.124.146.177<br>
|
|
|
|
|
|
ipset -B Blacklist
|
|
|
|
|
|
206.124.146.177 -b SMTP<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Now only port 25 will be blocked from 206.124.146.177.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall 2.4.0 can now configure routing if your kernel
|
|
|
|
|
|
and iptables support the ROUTE target extension. This
|
|
|
|
|
|
extension is available in Patch-O-Matic-ng. This feature is
|
|
|
|
|
|
*EXPERIMENTAL* since the Netfilter team have no intention of
|
|
|
|
|
|
ever releasing the ROUTE target extension to kernel.org.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Routing is configured using the /etc/shorewall/routes file.
|
|
|
|
|
|
Columns in the file are as follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
SOURCE
|
|
|
|
|
|
Source of the packet. May be any of the</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">following:</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A host or network address</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A network interface name.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- The name of an ipset prefaced with "+"</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- $FW (for packets originating on the firewall)</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A MAC address in Shorewall format</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A range of IP addresses (assuming that your</span> <span
|
|
|
|
|
|
style="font-family: monospace;">kernel and iptables support
|
|
|
|
|
|
range match)</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A network interface name followed by ":"</span> <span
|
|
|
|
|
|
style="font-family: monospace;">and an address or address
|
|
|
|
|
|
range.</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
DEST
|
|
|
|
|
|
Destination of the packet. May be any of the</span> <span
|
|
|
|
|
|
style="font-family: monospace;">following:</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A host or network address</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A network interface name (determined from</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
routing table(s))</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- The name of an ipset prefaced with "+"</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
- A network interface name followed by ":"</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
and an address or address range.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
PROTO
|
|
|
|
|
|
Protocol - Must be "tcp", "udp", "icmp",</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">"ipp2p", a number, or "all".
|
|
|
|
|
|
"ipp2p" requires</span><span style=
|
|
|
|
|
|
"font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
|
|
ipp2p match support in your kernel and</span><span style=
|
|
|
|
|
|
"font-family: monospace;">iptables.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
PORT(S)
|
|
|
|
|
|
Destination Ports. A comma-separated list of</span> <span
|
|
|
|
|
|
style="font-family: monospace;">Port names (from
|
|
|
|
|
|
/etc/services), port<br>
|
|
|
|
|
|
|
|
|
|
|
|
numbers</span> <span style="font-family: monospace;">or port
|
|
|
|
|
|
ranges; if the protocol is "icmp", this</span><span style=
|
|
|
|
|
|
"font-family: monospace;">column is interpreted as the<br>
|
|
|
|
|
|
|
|
|
|
|
|
destination</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">icmp-type(s).</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
If the protocol is ipp2p, this column is</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">interpreted as an ipp2p option
|
|
|
|
|
|
without the</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
|
|
leading "--" (example "bit" for bit-torrent).</span> <span
|
|
|
|
|
|
style="font-family: monospace;">If no PORT is given, "ipp2p"
|
|
|
|
|
|
is assumed.</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
This column is ignored if PROTOCOL = all but</span> <span
|
|
|
|
|
|
style="font-family: monospace;">must be entered if any of the
|
|
|
|
|
|
following<br>
|
|
|
|
|
|
|
|
|
|
|
|
field</span> <span style="font-family: monospace;">is
|
|
|
|
|
|
supplied. In that case, it is suggested that</span> <span
|
|
|
|
|
|
style="font-family: monospace;">this field contain
|
|
|
|
|
|
"-"</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
SOURCE PORT(S) (Optional) Source port(s). If
|
|
|
|
|
|
omitted,</span> <span style="font-family: monospace;">any
|
|
|
|
|
|
source port is acceptable. Specified as a</span><span style=
|
|
|
|
|
|
"font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
|
|
comma-separated list of port names, port</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">numbers or port ranges.</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
TEST
|
|
|
|
|
|
Defines a test on the existing packet or</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">connection mark.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
The rule will match only if the test returns</span> <span
|
|
|
|
|
|
style="font-family: monospace;">true. Tests have the
|
|
|
|
|
|
format</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
|
|
[!]<value>[/<mask>][:C]</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
Where:</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
! Inverts the test (not
|
|
|
|
|
|
equal)</span> <span style=
|
|
|
|
|
|
"font-family: monospace;"><value> Value of the packet
|
|
|
|
|
|
or</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
|
|
connection mark.</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<mask> A mask to be applied to the</span> <span
|
|
|
|
|
|
style="font-family: monospace;">mark before testing</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
:C Designates a
|
|
|
|
|
|
connection</span> <span style="font-family: monospace;">mark.
|
|
|
|
|
|
If omitted, the packet</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">mark's value<br>
|
|
|
|
|
|
|
|
|
|
|
|
is tested.</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
INTERFACE The interface
|
|
|
|
|
|
that the packet is to be routed</span> <span style=
|
|
|
|
|
|
"font-family: monospace;">out of. If you do not specify
|
|
|
|
|
|
this<br>
|
|
|
|
|
|
|
|
|
|
|
|
field then</span> <span style="font-family: monospace;">you
|
|
|
|
|
|
must place "-" in this column and enter an</span> <span
|
|
|
|
|
|
style="font-family: monospace;">IP address in the GATEWAY<br>
|
|
|
|
|
|
|
|
|
|
|
|
column.</span><br style="font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
GATEWAY The
|
|
|
|
|
|
gateway that the packet is to be forewarded</span> <span
|
|
|
|
|
|
style="font-family: monospace;">through.</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Normally when Shorewall is stopped, starting or
|
|
|
|
|
|
restarting then connections are allowed from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped to the firewall and to other
|
|
|
|
|
|
hosts listed in /etc/shorewall/routestopped.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
A new 'source' option is added for entries in that file which
|
|
|
|
|
|
will cause Shorewall to allow traffic from the host listed in
|
|
|
|
|
|
the entry to ANY other host. When 'source' is specified in an
|
|
|
|
|
|
entry, it is unnecessary to also specify 'routeback'.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Similarly, a new 'dest' option is added which will cause
|
|
|
|
|
|
Shorewall to allow traffic to the host listed in the entry
|
|
|
|
|
|
from ANY other host. When 'source' is specified in an entry,
|
|
|
|
|
|
it is unnecessary to also specify 'routeback'.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>This change was implemented by Lorenzo Martignoni. It
|
|
|
|
|
|
provides two new commands: "safe-start" and
|
|
|
|
|
|
"safe-restart".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;">safe-start</span> starts
|
|
|
|
|
|
Shorewall then prompts you to ask you if everything looks ok.
|
|
|
|
|
|
If you answer "no" or if you don't answer within 60 seconds,
|
|
|
|
|
|
a "shorewall clear" is executed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;">safe-restart</span> saves
|
|
|
|
|
|
your current configuration to /var/lib/shorewall/safe-restart
|
|
|
|
|
|
then issues a "shorewall restart"; It then prompts you to ask
|
|
|
|
|
|
if you if you want to accept the new configuration. If you
|
|
|
|
|
|
answer "no" or if you don't answer within 60 seconds, the
|
|
|
|
|
|
configuration is restored to its prior state.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
These new commands require either that your /bin/sh supports
|
|
|
|
|
|
the "-t" option to the 'read' command or that you have
|
|
|
|
|
|
/bin/bash installed.<br>
|
2004-10-25 17:52:26 +02:00
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<span style="font-weight: bold;">05/20/2005 Shorewall CVS
|
|
|
|
|
|
Repository has Moved to Sourceforge<br>
|
2004-05-14 00:07:06 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>The CVS repository may now be accessed at <a target=
|
|
|
|
|
|
"_top" href=
|
|
|
|
|
|
"http://sourceforge.net/cvs/?group_id=22587">http://sourceforge.net/cvs/?group_id=22587</a>.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<span style="font-weight: bold;"><br>
|
|
|
|
|
|
05/20/2005 Shorewall 2.2.5<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>This will be my last 2.2 release. It contains a couple
|
|
|
|
|
|
of small bug fixes that I hadn't yet released.<br>
|
2004-05-14 00:07:06 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
-Tom<br>
|
2004-05-14 00:07:06 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Previously, if PKTTYPE=No in shorewall.conf then pkttype
|
|
|
|
|
|
match would still be used if the kernel supported it.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A typo in the 'tunnel' script has been corrected (Thanks
|
|
|
|
|
|
to Patrik Varmecký).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A warning is now generated if an invalid short zone name
|
|
|
|
|
|
is used in /etc/shorewall/zones.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">05/18/2005 Tom stepping away
|
|
|
|
|
|
from Shorewall development and support<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
It is with regret that I announce that my involvement in
|
|
|
|
|
|
Shorewall development and support is officially ending.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Unlike the originators of other successful open source
|
|
|
|
|
|
projects, I have not been able to attract a core of people who
|
|
|
|
|
|
believe in Shorewall and who are willing to make sacrifices to
|
|
|
|
|
|
ensure it's success. That is my weakness and I accept it. But
|
|
|
|
|
|
is means that I have been left with trying to develop,
|
|
|
|
|
|
document, and support Shorewall almost single-handedly. I
|
|
|
|
|
|
cannot do it any more.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
I will clean up what I have for a 2.3 release and place it on
|
|
|
|
|
|
the server as my last Shorewall release -- Shorewall 2.4.0.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Discussions aimed at continuing Shorewall development under new
|
|
|
|
|
|
leadership are continuing.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall will always be a part of my life that I look back on
|
|
|
|
|
|
with fondness.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Regards,<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
-Tom<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;">05/02/2005 Shorewall
|
|
|
|
|
|
2.2.4<br>
|
|
|
|
|
|
</span></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The error message:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Error: No appropriate
|
|
|
|
|
|
chain for zone <z1> to zone <z2><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
has been changed to one that is more self-explanatory:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Error: No policy defined
|
|
|
|
|
|
for zone <z1> to zone <z2></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When only an interface name appeared in the HOST(S)
|
|
|
|
|
|
column of an /etc/shorewall/hosts file entry, a misleading
|
|
|
|
|
|
iptables error message resulted. Now the following message is
|
|
|
|
|
|
generated:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Error: Invalid HOST(S)
|
|
|
|
|
|
column contents: <column contents></li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Support has been added for UPnP using linux-igd (<a
|
|
|
|
|
|
href=
|
|
|
|
|
|
"http://linux-idg.sourceforge.net/">http://linux-idg.sourceforge.net</a>).
|
|
|
|
|
|
UPnP is required by a number of popular applications
|
|
|
|
|
|
including MSN IM.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
<span style="font-weight: bold;">WARNING</span>:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
From a security architecture viewpoint, UPnP is a disaster.
|
|
|
|
|
|
It assumes that:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol style="list-style-type: lower-alpha;">
|
|
|
|
|
|
<li>All local systems and their users are completely
|
|
|
|
|
|
trustworthy.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>No local system is infected with any worm or
|
|
|
|
|
|
trojan.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
If either of these assumptions are not true then UPnP can
|
|
|
|
|
|
be used to totally defeat your firewall and to allow
|
|
|
|
|
|
incoming connections to arbitrary local systems on any port
|
|
|
|
|
|
whatsoever.<br>
|
|
|
|
|
|
In short: <span style="font-weight: bold;">USE UPnP AT YOUR
|
|
|
|
|
|
OWN RISK</span>.<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
<span style="font-weight: bold;">WARNING</span>:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
The linux-igd project appears to be inactive and the web
|
|
|
|
|
|
site does not display correctly on any open source browser
|
|
|
|
|
|
that I've tried.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Building and installing linux-igd is not for the faint of
|
|
|
|
|
|
heart. You must download the source from CVS and be
|
|
|
|
|
|
prepared to do quite a bit of fiddling with the include
|
|
|
|
|
|
files from libupnp (which is required to build and/or run
|
|
|
|
|
|
linux-igd).<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
Configuring linux-igd:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
In /etc/upnpd.conf, you will want:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
insert_forward_rules = yes<br>
|
|
|
|
|
|
|
|
|
|
|
|
prerouting_chain_name = UPnP<br>
|
|
|
|
|
|
|
|
|
|
|
|
forward_chain_name = forwardUPnP<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
Shorewall Configuration:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
In /etc/shorewall/interfaces, you need the 'upnp' option on
|
|
|
|
|
|
your external interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If your fw->loc policy is not ACCEPT then you need this
|
|
|
|
|
|
rule:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
allowoutUPnP
|
|
|
|
|
|
fw loc<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note: To use 'allowoutUPnP', your iptables and kernel must
|
|
|
|
|
|
support the 'owner match' feature (see the output of
|
|
|
|
|
|
"shorewall check").<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If your loc->fw policy is not ACCEPT then you need this
|
|
|
|
|
|
rule:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
allowinUPnP
|
|
|
|
|
|
loc fw<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You MUST have this rule:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
forwardUPnP
|
|
|
|
|
|
net loc<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
You must also ensure that you have a route to
|
|
|
|
|
|
224.0.0.0/4 on you internal (local) interface.<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<ol start="2" style="list-style-type: decimal;">
|
|
|
|
|
|
<li>A new 'started' extension script has been added.
|
|
|
|
|
|
The difference between this extension script and
|
|
|
|
|
|
/etc/shorewall/start is that this one is invoked after
|
|
|
|
|
|
delayed loading of the blacklist (DELAYBLACKLISTLOAD=Yes) and
|
|
|
|
|
|
after the 'shorewall' chain has been created (thus signaling
|
|
|
|
|
|
that the firewall is completely up.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/started should not change the firewall
|
|
|
|
|
|
configuration directly but may do so indirectly by running
|
|
|
|
|
|
/sbin/shorewall with the 'nolock' option.<br>
|
|
|
|
|
|
<br>
|
2004-05-14 00:07:06 +02:00
|
|
|
|
</li>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<li>By default, shorewall is started with the "-f" (fast)
|
|
|
|
|
|
option when your system boots. You can override that setting
|
|
|
|
|
|
by setting the OPTIONS variable in /etc/sysconfig/shorewall
|
|
|
|
|
|
(SuSE/Redhat) or /etc/default/shorewall (Debian/Bering). If
|
|
|
|
|
|
neither file exists, feel free to create one or the
|
|
|
|
|
|
other.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example: If you want Shorewall to always use the config files
|
|
|
|
|
|
even if there is a saved configuration, then specify:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
OPTIONS=""<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now has support for the SAME target. This
|
|
|
|
|
|
change affects the /etc/shorewall/masq and
|
|
|
|
|
|
/etc/shorewall/rules file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
SAME is useful when you specify multiple target IP addresses
|
|
|
|
|
|
(in the ADDRESSES column of /etc/shorewall/masq or in the
|
|
|
|
|
|
DEST column of /etc/shorewall/rules).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If you use normal SNAT then multiple connections from a given
|
|
|
|
|
|
local host to hosts on the internet can be assigned different
|
|
|
|
|
|
source IP addresses. This confuses some applications that use
|
|
|
|
|
|
multiple connections. To correct this problem, prefix the
|
|
|
|
|
|
list of address ranges in the ADDRESS column with "SAME:"<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Example: SAME:206.124.146.176-206.124.146.180<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If you want each internal system to use the same IP address
|
|
|
|
|
|
from the list regardless of which internet host it is talking
|
|
|
|
|
|
to then prefix the ranges with "SAME:nodst:".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
SAME:nodst:206.124.146.176-206.124.146.180<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note that it is not possible to map port numbers when using
|
|
|
|
|
|
SAME.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the rules file, when multiple connections from an internet
|
|
|
|
|
|
host match a SAME rule then all of the connections will be
|
|
|
|
|
|
sent to the same internal server. SAME rules are very similar
|
|
|
|
|
|
to DNAT rules with the keyword SAME replacing DNAT. As in the
|
|
|
|
|
|
masq file, changing the port number is not supported.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "shorewall show capabilities" command has been added to
|
|
|
|
|
|
report the capabilities of your kernel and iptables.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
gateway:~# shorewall show
|
|
|
|
|
|
capabilities<br>
|
|
|
|
|
|
Loading
|
|
|
|
|
|
/usr/share/shorewall/functions...<br>
|
|
|
|
|
|
Processing
|
|
|
|
|
|
/etc/shorewall/params ...<br>
|
|
|
|
|
|
Processing
|
|
|
|
|
|
/etc/shorewall/shorewall.conf...<br>
|
|
|
|
|
|
Loading Modules...<br>
|
|
|
|
|
|
Shorewall has detected the
|
|
|
|
|
|
following iptables/netfilter capabilities:<br>
|
|
|
|
|
|
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Extended Multi-port Match: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Connection Tracking Match: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Packet Type Match: Not available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Policy Match: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Physdev Match: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
IP range Match: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Recent Match: Available<br>
|
|
|
|
|
|
|
|
|
|
|
|
Owner Match: Available<br>
|
|
|
|
|
|
gateway:~#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "-v" option has been added to /sbin/shorewall.
|
|
|
|
|
|
Currently, this option only affects the "show log" command
|
|
|
|
|
|
(e.g., "shorewall -v show log") and the "monitor" command. In
|
|
|
|
|
|
these commands, it causes the MAC address in the log message
|
|
|
|
|
|
(if any) to be displayed. As previously, when "-v" is
|
|
|
|
|
|
omitted, the MAC address is suppressed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In /etc/shorewall/rules, a value of 'none' in either the
|
|
|
|
|
|
SOURCE or DEST columns now causes the rule to be ignored.
|
|
|
|
|
|
This is most useful when used with shell variables:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
AllowFTP
|
|
|
|
|
|
$FTP_CLIENTS fw<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When FTP_CLIENTS
|
|
|
|
|
|
is set to 'none', the above rule is ignored. Otherwise,
|
|
|
|
|
|
the rule is evaluated and generates Netfilter rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The installer now detects that it is running on a
|
|
|
|
|
|
Slackware system and adjusts the DEST and INIT variables
|
|
|
|
|
|
accordingly.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;">05/01/2005 Tom spoke at
|
|
|
|
|
|
LinuxFest NW 2005 -- Bellingham Technical College, Bellingham
|
|
|
|
|
|
Washington<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Tom's presentation was entitled "Shorewall and Native IPSEC"
|
|
|
|
|
|
and is available for download <a href=
|
|
|
|
|
|
"http://shorewall.net/LinuxFest.pdf">here (PDF Format)</a>.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;">04/07/2005 Shorewall 2.2.3<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>If a zone is defined in /etc/shorewall/hosts using
|
|
|
|
|
|
<interface>:!<network> in the HOSTS column then
|
|
|
|
|
|
startup errors occur on "shorewall [re]start".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, if "shorewall status" was run on a system
|
|
|
|
|
|
whose kernel lacked advanced routing support
|
|
|
|
|
|
(CONFIG_IP_ADVANCED_ROUTER), then no routing
|
|
|
|
|
|
information was displayed.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A new extension script "continue" has been added. This
|
|
|
|
|
|
script is invoked after Shorewall has set the built-in filter
|
|
|
|
|
|
chains policy to DROP, deleted any existing Netfilter rules
|
|
|
|
|
|
and user chains and has enabled existing connections. It is
|
|
|
|
|
|
useful for enabling certain communication while Shorewall is
|
|
|
|
|
|
being [re]started. Be sure to delete any rules that you add
|
|
|
|
|
|
here in your /etc/shorewall/start file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>There has been ongoing confusion about how the
|
|
|
|
|
|
/etc/shorewall/routestopped file works. People understand how
|
|
|
|
|
|
it works with the 'shorewall stop' command but when they read
|
|
|
|
|
|
that 'shorewall restart' is logically equivalent to
|
|
|
|
|
|
'shorewall stop' followed by 'shorewall start' then they
|
|
|
|
|
|
erroneously conclude that /etc/shorewall/routestopped can be
|
|
|
|
|
|
used to enable new connections during 'shorewall restart'. Up
|
|
|
|
|
|
to now, it cannot -- that file is not processed during either
|
|
|
|
|
|
'shorewall start' or 'shorewall restart'.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Beginning with Shorewall version 2.2.3,
|
|
|
|
|
|
/etc/shorewall/routestopped will be processed TWICE during
|
|
|
|
|
|
'shorewall start' and during 'shorewall restart'. It will be
|
|
|
|
|
|
processed early in the command execution to add rules
|
|
|
|
|
|
allowing new connections while the command is running and it
|
|
|
|
|
|
will be processed again when the command is complete to
|
|
|
|
|
|
remove the rules added earlier.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The result of this change will be that during most of
|
|
|
|
|
|
[re]start, new connections will be allowed in accordance with
|
|
|
|
|
|
the contents of /etc/shorewall/routestopped.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The performance of configurations with a large numbers of
|
|
|
|
|
|
entries in /etc/shorewall/maclist can be improved by setting
|
|
|
|
|
|
the new MACLIST_TTL variable in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If your iptables and kernel support the "Recent Match" (see
|
|
|
|
|
|
the output of "shorewall check" near the top), you can cache
|
|
|
|
|
|
the results of a 'maclist' file lookup and thus reduce the
|
|
|
|
|
|
overhead associated with MAC Verification.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When a new connection arrives from a 'maclist' interface, the
|
|
|
|
|
|
packet passes through then list of entries for that interface
|
|
|
|
|
|
in /etc/shorewall/maclist. If there is a match then the
|
|
|
|
|
|
source IP address is added to the 'Recent' set for that
|
|
|
|
|
|
interface. Subsequent connection attempts from that IP
|
|
|
|
|
|
address occuring within $MACLIST_TTL seconds will be accepted
|
|
|
|
|
|
without having to scan all of the entries. After $MACLIST_TTL
|
|
|
|
|
|
from the first accepted connection request from an IP
|
|
|
|
|
|
address, the next connection request from that IP address
|
|
|
|
|
|
will be checked against the entire list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If MACLIST_TTL is not specified or is specified as empty
|
|
|
|
|
|
(e.g, MACLIST_TTL="" or is specified as zero then 'maclist'
|
|
|
|
|
|
lookups will not be cached.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You can now specify QUEUE as a policy and you can
|
|
|
|
|
|
designate a common action for QUEUE policies in
|
|
|
|
|
|
/etc/shorewall/actions. This is useful for sending packets to
|
|
|
|
|
|
something like Snort Inline.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">03/31/2005 Shorewall
|
|
|
|
|
|
2.0.17<br>
|
2004-04-05 23:13:45 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Invoking the 'rejNotSyn' action results in an error at
|
|
|
|
|
|
startup.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The UDP and TCP port numbers in
|
|
|
|
|
|
/usr/share/shorewall/action.AllowPCA were reversed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If a zone is defined in /etc/shorewall/hosts using
|
|
|
|
|
|
<<span style=
|
|
|
|
|
|
"font-style: italic;">interface</span>>:!<<span style=
|
|
|
|
|
|
"font-style: italic;">network</span>> in the HOSTS column
|
|
|
|
|
|
then startup errors occur on "shorewall [re]start".<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">03/12/2005 Shorewall 2.2.2<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The SOURCE column in the /etc/shorewall/tcrules file now
|
|
|
|
|
|
correctly allows IP ranges (assuming that your iptables and
|
|
|
|
|
|
kernel support ranges).<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If A is a user-defined action and you have file
|
|
|
|
|
|
/etc/shorewall/A then when that file is invoked by Shorewall
|
|
|
|
|
|
during [re]start, the $TAG value may be incorrect.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, if an iptables command generating a logging
|
|
|
|
|
|
rule failed, the Shorewall [re]start was still successful.
|
|
|
|
|
|
This error is now considered fatal and Shorewall will be
|
|
|
|
|
|
either restored from the last save (if any) or it will be
|
|
|
|
|
|
stopped.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The port numbers for UDP and TCP were previously reversed
|
|
|
|
|
|
in the /usr/share/shorewall/action.AllowPCA file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, the 'install.sh' script did not update the
|
|
|
|
|
|
/usr/share/shorewall/action.* files.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, when an interface name appeared in the DEST
|
|
|
|
|
|
column of /etc/shorewall/tcrules, the name was not validated
|
|
|
|
|
|
against the set of defined interfaces and bridge ports.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The SOURCE column in the /etc/shorewall/tcrules file now
|
|
|
|
|
|
allows $FW to be optionally followed by ":" and a
|
|
|
|
|
|
host/network address or address range.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now clears the output device only if it is a
|
|
|
|
|
|
terminal. This avoids ugly control sequences being placed in
|
|
|
|
|
|
files when /sbin/shorewall output is redirected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The output from 'arp -na' has been added to the
|
|
|
|
|
|
'shorewall status' display.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 2.6.11 Linux kernel and iptables 1.3.0 now allow port
|
|
|
|
|
|
ranges to appear in port lists handled by "multiport match".
|
|
|
|
|
|
If Shorewall detects this capability, it will use "multiport
|
|
|
|
|
|
match" for port lists containing port ranges. Be cautioned
|
|
|
|
|
|
that each port range counts for TWO ports and a port list
|
|
|
|
|
|
handled with "multiport match" can still specify a maximum of
|
|
|
|
|
|
15 ports.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
As always, if a port list in /etc/shorewall/rules is
|
|
|
|
|
|
incompatible with "multiport match", a separate iptables rule
|
|
|
|
|
|
will be generated for each element in the list.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Traditionally, the RETURN target in the 'rfc1918' file
|
|
|
|
|
|
has caused 'norfc1918' processing to cease for a packet if
|
|
|
|
|
|
the packet's source IP address matches the rule. Thus, if you
|
|
|
|
|
|
have:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
SUBNETS
|
|
|
|
|
|
TARGET</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
192.168.1.0/24 RETURN</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
then traffic from 192.168.1.4 to 10.0.3.9 will be accepted
|
|
|
|
|
|
even though you also have:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
SUBNETS
|
|
|
|
|
|
TARGET</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
10.0.0.0/8
|
|
|
|
|
|
logdrop</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Setting RFC1918_STRICT=Yes in shorewall.conf will cause such
|
|
|
|
|
|
traffic to be logged and dropped since while the packet's
|
|
|
|
|
|
source matches the RETURN rule, the packet's destination
|
|
|
|
|
|
matches the 'logdrop' rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If not specified or specified as empty (e.g.,
|
|
|
|
|
|
RFC1918_STRICT="") then RFC1918_STRICT=No is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
WARNING: RFC1918_STRICT=Yes requires that your kernel and
|
|
|
|
|
|
iptables support 'Connection Tracking' match.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;">02/15/2005 Shorewall
|
|
|
|
|
|
2.2.1<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span>This release rolls up the fixes for bugs found in the
|
|
|
|
|
|
first 2-3 weeks of deployment of Shorewall 2.2.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The /etc/shorewall/policy file contained a misleading
|
|
|
|
|
|
comment and both that file and the /etc/shorewall/zones file
|
|
|
|
|
|
lacked examples.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall previously used root's default umask which
|
|
|
|
|
|
could cause files in /var/lib/shorewall to be world-readable.
|
|
|
|
|
|
Shorewall now uses umask 0177.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In log messages produced by logging a built-in action,
|
|
|
|
|
|
the packet disposition was displayed incorrectly.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
rejNotSyn:ULOG
|
|
|
|
|
|
all
|
|
|
|
|
|
all
|
|
|
|
|
|
tcp<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
produces the log message:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Feb 12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
rather than<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Feb 12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The comments regarding built-in actions in
|
|
|
|
|
|
/usr/share/shorewall/actions.std have been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /etc/shorewall/policy file in the LRP package was
|
|
|
|
|
|
missing the 'all->all' policy.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;">02/05/2005 End of Support for
|
|
|
|
|
|
Shorewall 1.4<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span>Effective today, support for Shorewall 1.4 has been
|
|
|
|
|
|
discontinued. See the link at the top of this article for
|
|
|
|
|
|
upgrade information.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;">02/01/2005 Shorewall
|
|
|
|
|
|
2.0.16<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
This release back-ports the DROPINVALID shorewall.conf option
|
|
|
|
|
|
from 2.2.0.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Recent 2.6 kernels include code that evaluates TCP
|
|
|
|
|
|
packets based on TCP Window analysis. This can cause packets
|
|
|
|
|
|
that were previously classified as NEW or ESTABLISHED to be
|
|
|
|
|
|
classified as INVALID.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The new kernel code can be disabled by including this command
|
|
|
|
|
|
in your /etc/shorewall/init file:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
echo 1 >
|
|
|
|
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Additional kernel logging about INVALID TCP packets may be
|
|
|
|
|
|
obtained by adding this command to /etc/shorewall/init:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
echo 1 >
|
|
|
|
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Traditionally, Shorewall has dropped INVALID TCP packets
|
|
|
|
|
|
early. The new DROPINVALID option allows INVALID packets to
|
|
|
|
|
|
be passed through the normal rules chains by setting
|
|
|
|
|
|
DROPINVALID=No.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If not specified or if specified as empty (e.g.,
|
|
|
|
|
|
DROPINVALID="") then DROPINVALID=Yes is assumed.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;">02/01/2005 Shorewall
|
|
|
|
|
|
2.2.0<br>
|
2004-04-05 23:13:45 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>New Features:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>ICMP packets that are in the INVALID state are now
|
|
|
|
|
|
dropped by the Reject and Drop default actions. They do so
|
|
|
|
|
|
using the new 'dropInvalid' builtin action. An 'allowInvalid'
|
|
|
|
|
|
builtin action is also provided which accepts packets in that
|
|
|
|
|
|
state.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /etc/shorewall/masq file INTERFACE column now allows
|
|
|
|
|
|
additional options.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Normally MASQUERADE/SNAT rules are evaluated after one-to-one
|
|
|
|
|
|
NAT rules defined in the /etc/shorewall/nat file. If you
|
|
|
|
|
|
preceed the interface name with a plus sign ("+") then the
|
|
|
|
|
|
rule will be evaluated before one-to-one NAT.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
+eth0<br>
|
|
|
|
|
|
+eth1:192.0.2.32/27<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for
|
|
|
|
|
|
an entry by following the interface name by ":" but no
|
|
|
|
|
|
digit.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
eth0:<br>
|
|
|
|
|
|
eth1::192.0.2.32/27<br>
|
|
|
|
|
|
+eth3:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Similar to 2), the /etc/shorewall/nat file INTERFACE
|
|
|
|
|
|
column now allows you to override the setting of
|
|
|
|
|
|
ADD_IP_ALIASES=Yes by following the interface name with ":"
|
|
|
|
|
|
but no digit.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>All configuration files in the Shorewall distribution
|
|
|
|
|
|
with the exception of shorewall.conf are now empty. In
|
|
|
|
|
|
particular, the /etc/shorewall/zones, /etc/shorewall/policy
|
|
|
|
|
|
and /etc/shorewall/tos files now have no active entries.
|
|
|
|
|
|
Hopefully this will stop the questions on the support and
|
|
|
|
|
|
development lists regarding why the default entries are the
|
|
|
|
|
|
way they are.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, including a log level (and optionally a log
|
|
|
|
|
|
tag) on a rule that specified a user-defined (or
|
|
|
|
|
|
Shorewall-defined) action would log all traffic passed to the
|
|
|
|
|
|
action. Beginning with this release, specifying a log level
|
|
|
|
|
|
in a rule that specifies a user- or Shorewall-defined action
|
|
|
|
|
|
will cause each rule in the action to be logged with the
|
|
|
|
|
|
specified level (and tag).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The extent to which logging of action rules occurs is
|
|
|
|
|
|
goverend by the following:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style="list-style: none">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>When you invoke an action and specify a log level,
|
|
|
|
|
|
only those rules in the action that have no log level
|
|
|
|
|
|
will be changed to log at the level specified at the
|
|
|
|
|
|
action invocation.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/action.foo:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT -
|
|
|
|
|
|
- tcp 22<br>
|
|
|
|
|
|
bar:info<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
foo:debug fw net<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Logging in the invoked 'foo' action will be:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT:debug -
|
|
|
|
|
|
- tcp 22<br>
|
|
|
|
|
|
bar:info<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If you follow the log level with "!" then logging
|
|
|
|
|
|
will be at that level for all rules recursively invoked
|
|
|
|
|
|
by the action<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example: /etc/shorewall/action.foo:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<b>Update:</b> I've been informed by Mandrake
|
|
|
|
|
|
Development that this problem has been corrected in
|
|
|
|
|
|
Mandrake 10.0 Final (the problem still exists in the 10.0
|
|
|
|
|
|
Community release).<br>
|
|
|
|
|
|
ACCEPT -
|
|
|
|
|
|
- tcp 22<br>
|
|
|
|
|
|
bar:info<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
foo:debug! fw net<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Logging in the invoke 'foo' action will be:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT:debug -
|
|
|
|
|
|
- tcp 22<br>
|
|
|
|
|
|
bar:debug!<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
This change has an effect on extension scripts used with
|
|
|
|
|
|
user-defined actions. If you define an action 'acton' and you
|
|
|
|
|
|
have an /etc/shorewall/acton script then when that script is
|
|
|
|
|
|
invoked, the following three variables will be set for use by
|
|
|
|
|
|
the script:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
$CHAIN = the name of the chain where your rules are to be
|
|
|
|
|
|
placed. When logging is used on an action invocation,
|
|
|
|
|
|
Shorewall creates a chain with a slightly different name
|
|
|
|
|
|
from the action itself.<br>
|
|
|
|
|
|
$LEVEL = Log level. If empty, no logging was specified.<br>
|
|
|
|
|
|
$TAG = Log Tag.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
acton:info:test<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Your /etc/shorewall/acton file will be run with:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
$CHAIN="%acton1<br>
|
|
|
|
|
|
$LEVEL="info"<br>
|
|
|
|
|
|
$TAG="test"<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol start="6">
|
|
|
|
|
|
<li>The /etc/shorewall/startup_disabled file is no longer
|
|
|
|
|
|
created when Shorewall is first installed. Rather, the
|
|
|
|
|
|
variable STARTUP_ENABLED is set to 'No' in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. In order to get Shorewall to
|
|
|
|
|
|
start, that variable's value must be set to 'Yes'. This
|
|
|
|
|
|
change accomplishes two things:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style="list-style: none">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>It prevents Shorewall from being started prematurely
|
|
|
|
|
|
by the user's initialization scripts.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It causes /etc/shorewall/shorewall.conf to be
|
|
|
|
|
|
modified so that it won't be replaced by upgrades using
|
|
|
|
|
|
RPM.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support has been added for the 2.6 Kernel IPSEC
|
|
|
|
|
|
implementation. To use this support, you must have installed
|
|
|
|
|
|
the IPSEC policy match patch and the four IPSEC/Netfilter
|
|
|
|
|
|
patches from Patch-0-Matic-ng. The policy match patch affects
|
|
|
|
|
|
both your kernel and iptables. There are two ways to specify
|
|
|
|
|
|
that IPSEC is to be used when communicating with a set of
|
|
|
|
|
|
hosts; both methods involve the new /etc/shorewall/ipsec
|
|
|
|
|
|
file:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style="list-style: none">
|
|
|
|
|
|
<ol style="list-style-type: lower-alpha;">
|
|
|
|
|
|
<li>If encrypted communication is used with all hosts in
|
|
|
|
|
|
a zone, then you can designate the zone as an "ipsec"
|
|
|
|
|
|
zone by placing 'Yes" in the IPSEC ONLY column in
|
|
|
|
|
|
/etc/shorewall/ipsec:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">#ZONE
|
|
|
|
|
|
IPSEC OPTIONS
|
|
|
|
|
|
...</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">#
|
|
|
|
|
|
ONLY</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
Yes</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The hosts in the zone (if any) must be specified in
|
|
|
|
|
|
/etc/shorewall/hosts but you do not need to specify the
|
|
|
|
|
|
'ipsec' option on the entries in that file (see below).
|
|
|
|
|
|
Dynamic zones involving IPSEC must use that
|
|
|
|
|
|
technique.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:Under 2.4 Kernel FreeS/Wan:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/zones:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">net
|
|
|
|
|
|
Net The big bad Internet</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
VPN Remote Network</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/interfaces:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">net
|
|
|
|
|
|
eth0 ...</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
ipsec0 ...</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Under 2.6 Kernel with this new support:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/zones:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">net
|
|
|
|
|
|
Net The big bad Internet</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
VPN Remote Network</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/interfaces:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">net
|
|
|
|
|
|
eth0 ...</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/hosts:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
eth0:0.0.0.0/0</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/ipsec<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn Yes<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
If only part of the hosts in a zone require encrypted
|
|
|
|
|
|
communication, you may use of the new 'ipsec' option in
|
|
|
|
|
|
/etc/shorewall/hosts to designate those hosts.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Under 2.4 Kernel FreeS/Wan:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/zones:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
net Net The big bad Internet<br>
|
|
|
|
|
|
loc Local Extended local zone
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
/etc/shorewall/interfaces:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">net
|
|
|
|
|
|
eth0 ...</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">loc
|
|
|
|
|
|
eth1 ...</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">loc
|
|
|
|
|
|
ipsec0 ...</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Under 2.6 Kernel with this new support:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/zones:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">net
|
|
|
|
|
|
Net The big bad
|
|
|
|
|
|
Internet</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
VPN Remote Network</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/interfaces:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">net
|
|
|
|
|
|
eth0 ...</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">loc
|
|
|
|
|
|
eth1 ...</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/hosts:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
eth0:0.0.0.0/0 ipsec,...</span>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
Regardless of which technique you choose, you can specify
|
|
|
|
|
|
additional SA options for the zone in the
|
|
|
|
|
|
/etc/shorewall/ipsec entry.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
|
|
|
|
|
|
input-output, input and output characteristics of the
|
|
|
|
|
|
security associations to be used to decrypt (input) or
|
|
|
|
|
|
encrypt (output) traffic to/from the zone.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The available options are:<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 2em">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>reqid[!]=<number> where <number> is
|
|
|
|
|
|
specified using setkey(8) using the 'unique:<number>'
|
|
|
|
|
|
option for the SPD level.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>spi[!]=<number> where <number> is the SPI
|
|
|
|
|
|
of the SA. Since different SAs are used to encrypt and
|
|
|
|
|
|
decrypt traffic, this option should only be listed in the
|
|
|
|
|
|
IN OPTIONS and OUT OPTIONS columns.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>proto[!]=ah|esp|ipcomp</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>mss=<number> (sets the MSS value in TCP SYN
|
|
|
|
|
|
packets and is not related to policy matching)</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>mode[!]=transport|tunnel</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>tunnel-src[!]=<address>[/<mask>] (only
|
|
|
|
|
|
available with mode=tunnel)</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>tunnel-dst[!]=<address>[/<mask>] (only
|
|
|
|
|
|
available with mode=tunnel). Because tunnel source and
|
|
|
|
|
|
destination are dependent on the direction of the traffic,
|
|
|
|
|
|
these options should only appear in the IN OPTIONS and OUT
|
|
|
|
|
|
OPTIONS columns.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>strict (if specified, packets must match all
|
|
|
|
|
|
policies; policies are delimited by 'next').</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>next (only available with
|
|
|
|
|
|
strict)</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-family: monospace;">#ZONE
|
|
|
|
|
|
IPSEC OPTIONS
|
|
|
|
|
|
|
|
|
|
|
|
IN
|
|
|
|
|
|
OUT</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">#
|
|
|
|
|
|
ONLY
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
|
|
OPTIONS</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">vpn
|
|
|
|
|
|
Yes mode=tunnel,proto=esp
|
|
|
|
|
|
spi=1000 spi=1001</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">loc
|
|
|
|
|
|
No reqid=44,mode=transport</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The /etc/shorewall/masq file has a new IPSEC column added. If
|
|
|
|
|
|
you specify Yes or yes in that column then the unencrypted
|
|
|
|
|
|
packets will have their source address changed. Otherwise,
|
|
|
|
|
|
the unencrypted packets will not have their source addresses
|
|
|
|
|
|
changed. This column may also contain a comma-separated list
|
|
|
|
|
|
of the options specified above in which case only those
|
|
|
|
|
|
packets that will be encrypted by an SA matching the given
|
|
|
|
|
|
options will have their source address changed.<br>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<ol start="8">
|
|
|
|
|
|
<li>To improve interoperability, tunnels of type 'ipsec' no
|
|
|
|
|
|
longer enforce the use of source port 500 for ISAKMP and
|
|
|
|
|
|
OpenVPN tunnels no longer enforce use of the specified port
|
|
|
|
|
|
as both the source and destination ports.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new 'allowBcast' builtin action has been added -- it
|
|
|
|
|
|
silently allows broadcasts and multicasts.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The -c option in /sbin/shorewall commands is now
|
|
|
|
|
|
deprecated. The commands where -c was previously allowed now
|
|
|
|
|
|
permit you to specify a configuration directory after the
|
|
|
|
|
|
command:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall check [
|
|
|
|
|
|
<configuration-directory> ]<br>
|
|
|
|
|
|
shorewall restart [
|
|
|
|
|
|
<configuration-directory> ]<br>
|
|
|
|
|
|
shorewall start [
|
|
|
|
|
|
<configuration-directory> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Normally, when SNAT or MASQUERADE is applied to a tcp or
|
|
|
|
|
|
udp connection, Netfilter attempts to retain the source port
|
|
|
|
|
|
number. If it has to change to port number to avoid
|
|
|
|
|
|
<source address>,<source port> conflicts, it
|
|
|
|
|
|
tries to do so within port ranges ( < 512, 512-1023, and
|
|
|
|
|
|
> 1023). You may now specify an explicit range of source
|
|
|
|
|
|
ports to be used by following the address or address range
|
|
|
|
|
|
(if any) in the ADDRESS column with ":" and a port range in
|
|
|
|
|
|
the format <low-port>-<high-port>. You must
|
|
|
|
|
|
specify either "tcp" or "udp" in the PROTO column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
#INTERFACE SUBNET
|
|
|
|
|
|
ADDRESS PROTO</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
eth0 192.168.1.0/24
|
|
|
|
|
|
:4000-5000 tcp</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">#INTERFACE SUBNET
|
|
|
|
|
|
ADDRESS
|
|
|
|
|
|
|
|
|
|
|
|
PROTO</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
eth0
|
|
|
|
|
|
10.0.0.0/8
|
|
|
|
|
|
192.0.2.44:7000-8000 udp<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You may now account by user/group ID for outbound traffic
|
|
|
|
|
|
from the firewall itself with entries in
|
|
|
|
|
|
/etc/shorewall/accounting. Such accounting rules must be
|
|
|
|
|
|
placed in the OUTPUT chain. See the comments at the top of
|
|
|
|
|
|
/etc/shorewall/accounting for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now verifies that your kernel and iptables have
|
|
|
|
|
|
physdev match support if BRIDGING=Yes in shorewall.conf.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Beginning with this release, if your kernel and iptables
|
|
|
|
|
|
have iprange match support (see the output from "shorewall
|
|
|
|
|
|
check"), then with the exception of the /etc/shorewall/netmap
|
|
|
|
|
|
file, anywhere that a network address may appear an IP
|
|
|
|
|
|
address range of the form <low address>-<high
|
|
|
|
|
|
address> may also appear.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support has been added for the iptables CLASSIFY target.
|
|
|
|
|
|
That target allows you to classify packets for traffic
|
|
|
|
|
|
shaping directly rather than indirectly through fwmark.
|
|
|
|
|
|
Simply enter the <major>:<minor> classification
|
|
|
|
|
|
in the first column of /etc/shorewall/tcrules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">#MARK/
|
|
|
|
|
|
SOURCE
|
|
|
|
|
|
DEST
|
|
|
|
|
|
PROTO PORT(S)</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">#CLASSIFY</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">1:30
|
|
|
|
|
|
-
|
|
|
|
|
|
eth0
|
|
|
|
|
|
tcp 25</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note that when using this form of rule, it is acceptable to
|
|
|
|
|
|
include the name of an interface in the DEST column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Marking using the CLASSIFY target always occurs in the
|
|
|
|
|
|
POSTROUTING chain of the mangle table and is not affected by
|
|
|
|
|
|
the setting of MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>During "shorewall start", IP addresses to be added as a
|
|
|
|
|
|
consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes
|
|
|
|
|
|
are quietly deleted when /etc/shorewall/nat and
|
|
|
|
|
|
/etc/shorewall/masq are processed then they are re-added
|
|
|
|
|
|
later. This is done to help ensure that the addresses can be
|
|
|
|
|
|
added with the specified labels but can have the undesirable
|
|
|
|
|
|
side effect of causing routes to be quietly deleted. A new
|
|
|
|
|
|
RETAIN_ALIASES option has been added to shorewall.conf; when
|
|
|
|
|
|
this option is set to Yes, existing addresses will not be
|
|
|
|
|
|
deleted. Regardless of the setting of RETAIN_ALIASES,
|
|
|
|
|
|
addresses added during "shorewall start" are still deleted at
|
|
|
|
|
|
a subsequent "shorewall stop" or "shorewall restart".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Users with a large black list (from
|
|
|
|
|
|
/etc/shorewall/blacklist) may want to set the new
|
|
|
|
|
|
DELAYBLACKLISTLOAD option in shorewall.conf. When
|
|
|
|
|
|
DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections
|
|
|
|
|
|
before loading the blacklist rules. While this may allow
|
|
|
|
|
|
connections from blacklisted hosts to slip by during
|
|
|
|
|
|
construction of the blacklist, it can substantially reduce
|
|
|
|
|
|
the time that all new connections are disabled during
|
|
|
|
|
|
"shorewall [re]start".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Using the default LOGFORMAT, chain names longer than 11
|
|
|
|
|
|
characters (such as in user-defined actions) may result in
|
|
|
|
|
|
log prefix truncation. A new shorewall.conf action
|
|
|
|
|
|
LOGTAGONLY has been added to deal with this problem. When
|
|
|
|
|
|
LOGTAGONLY=Yes, logging rules that specify a log tag will
|
|
|
|
|
|
substitute the tag for the chain name in the log prefix.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example -- file
|
|
|
|
|
|
/etc/shorewall/action.thisisaverylogactionname:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Rule:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">DROP:info:ftp
|
|
|
|
|
|
0.0.0.0/0 0.0.0.0/0
|
|
|
|
|
|
tcp 21</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Log prefix with LOGTAGONLY=No:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Log prefix with LOGTAGONLY=Yes:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">Shorewall:ftp:DROP</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now resets the 'accept_source_route' flag for
|
|
|
|
|
|
all interfaces. If you wish to accept source routing on an
|
|
|
|
|
|
interface, you must specify the new 'sourceroute' interface
|
|
|
|
|
|
option in /etc/shorewall/interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The default Drop and Reject actions now invoke the new
|
|
|
|
|
|
standard action 'AllowICMPs'. This new action accepts
|
|
|
|
|
|
critical ICMP types:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Type 3 code 4 (fragmentation needed)<br>
|
|
|
|
|
|
Type
|
|
|
|
|
|
11 (TTL exceeded)<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Explicit control over the kernel's Martian logging is now
|
|
|
|
|
|
provided using the new 'logmartians' interface option. If you
|
|
|
|
|
|
include 'logmartians' in the interface option list then
|
|
|
|
|
|
logging of Martian packets on will be enabled on the
|
|
|
|
|
|
specified interface. If you wish to globally enable martian
|
|
|
|
|
|
logging, you can set LOG_MARTIANS=Yes in shorewall.conf.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You may now cause Shorewall to use the '--set-mss' option
|
|
|
|
|
|
of the TCPMSS target. In other words, you can cause Shorewall
|
|
|
|
|
|
to set the MSS field of SYN packets passing through the
|
|
|
|
|
|
firewall to the value you specify. This feature extends the
|
|
|
|
|
|
existing CLAMPMSS option in /etc/shorewall/shorewall.conf by
|
|
|
|
|
|
allowing that option to have a numeric value as well as the
|
|
|
|
|
|
values "Yes" and "No".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
CLAMPMSS=1400<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now includes support for the ipp2p match
|
|
|
|
|
|
facility. This is a departure from my usual policy in that
|
|
|
|
|
|
the ipp2p match facility is included in Patch-O-Matic-NG and
|
|
|
|
|
|
is unlikely to ever be included in the kernel.org source
|
|
|
|
|
|
tree. Questions about how to install the patch or how to
|
|
|
|
|
|
build your kernel and/or iptables should not be posted on the
|
|
|
|
|
|
Shorewall mailing lists.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the following files, the "PROTO" or "PROTOCOL" column may
|
|
|
|
|
|
contain "ipp2p":<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/tcrules<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/accounting<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When the PROTO or PROTOCOL column contains "ipp2p" then the
|
|
|
|
|
|
DEST PORT(S) or PORT(S) column may contain a recognized ipp2p
|
|
|
|
|
|
option; for a list of the options and their meaning, at a
|
|
|
|
|
|
root prompt:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
iptables -m ipp2p --help<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You must not include the leading "--" on the option;
|
|
|
|
|
|
Shorewall will supply those characters for you. If you do not
|
|
|
|
|
|
include an option then "ipp2p" is assumed (Shorewall will
|
|
|
|
|
|
generate "-m ipp2p --ipp2p").</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now has support for the CONNMARK target from
|
|
|
|
|
|
iptables. See the /etc/shorewall/tcrules file for
|
|
|
|
|
|
details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new debugging option LOGALLNEW has been added to
|
|
|
|
|
|
shorewall.conf. When set to a log level, this option causes
|
|
|
|
|
|
Shorewall to generaate a logging rule as the first rule in
|
|
|
|
|
|
each builtin chain.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
- The table name is used as the chain name
|
|
|
|
|
|
in the log prefix.<br>
|
|
|
|
|
|
- The chain name is used as the target in
|
|
|
|
|
|
the log prefix.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example: Using the default LOGFORMAT, the log prefix for
|
|
|
|
|
|
logging from the nat table's PREROUTING chain is:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
IMPORTANT: There is no rate limiting on these logging rules
|
|
|
|
|
|
so use LOGALLNEW at your own risk; it may cause high CPU and
|
|
|
|
|
|
disk utilization and you may not be able to control your
|
|
|
|
|
|
firewall after you enable this option.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES
|
|
|
|
|
|
WILL BE SENT TO ANOTHER SYSTEM.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The SUBNET column in /etc/shorewall/rfc1918 has been
|
|
|
|
|
|
renamed SUBNETS and it is now possible to specify a list of
|
|
|
|
|
|
addresses in that column.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The AllowNNTP action now also allows NNTP over SSL/TLS
|
|
|
|
|
|
(NNTPS).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>For consistency, the CLIENT PORT(S) column in the tcrules
|
|
|
|
|
|
file has been renamed SOURCE PORT(S).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
|
|
|
|
|
|
now shown in the output of "shorewall status".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new IPTABLES option has been added to shorewall.conf.
|
|
|
|
|
|
IPTABLES can be used to designate the iptables executable to
|
|
|
|
|
|
be used by Shorewall. If not specified, the iptables
|
|
|
|
|
|
executable determined by the PATH setting is used.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You can now use the "shorewall show zones" command to
|
|
|
|
|
|
display the current contents of the zones. This is
|
|
|
|
|
|
particularly useful if you use dynamic zones
|
|
|
|
|
|
(DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">ursa:/etc/shorewall # shorewall
|
|
|
|
|
|
show zones</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
|
|
|
|
|
|
2004</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;"> </span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
loc</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
eth0:192.168.1.0/24</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
eth1:1.2.3.4</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
net </span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
eth0:0.0.0.0/0</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
WiFi</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
eth1:0.0.0.0/0</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
sec</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
eth1:0.0.0.0/0</span><br style=
|
|
|
|
|
|
"font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;"> </span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
ursa:/etc/shorewall #</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Variable expansion may now be used with the INCLUDE
|
|
|
|
|
|
directive.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/params<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">FILE=/etc/foo/bar</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Any other config
|
|
|
|
|
|
file:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">INCLUDE $FILE</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The output of "shorewall status" now includes the results
|
|
|
|
|
|
of "ip -stat link ls". This helps diagnose performance
|
|
|
|
|
|
problems caused by link errors.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, when rate-limiting was specified in
|
|
|
|
|
|
/etc/shorewall/policy (LIMIT:BURST column), any traffic which
|
|
|
|
|
|
exceeded the specified rate was silently dropped. Now, if a
|
|
|
|
|
|
log level is given in the entry (LEVEL column) then drops are
|
|
|
|
|
|
logged at that level at a rate of 5/min with a burst of
|
|
|
|
|
|
5.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Recent 2.6 kernels include code that evaluates TCP
|
|
|
|
|
|
packets based on TCP Window analysis. This can cause packets
|
|
|
|
|
|
that were previously classified as NEW or ESTABLISHED to be
|
|
|
|
|
|
classified as INVALID.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The new kernel code can be disabled by including this command
|
|
|
|
|
|
in your /etc/shorewall/init file:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-family: monospace;">echo
|
|
|
|
|
|
1 >
|
|
|
|
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Additional kernel logging about INVALID TCP packets may be
|
|
|
|
|
|
obtained by adding this command to /etc/shorewall/init:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-family: monospace;">echo
|
|
|
|
|
|
1 >
|
|
|
|
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Traditionally, Shorewall has dropped INVALID TCP packets
|
|
|
|
|
|
early. The new DROPINVALID option allows INVALID packets to
|
|
|
|
|
|
be passed through the normal rules chains by setting
|
|
|
|
|
|
DROPINVALID=No.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If not specified or if specified as empty (e.g.,
|
|
|
|
|
|
DROPINVALID="") then DROPINVALID=Yes is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall add" and "shorewall delete" commands now
|
|
|
|
|
|
accept a list of hosts to add or delete.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">shorewall add eth1:1.2.3.4
|
|
|
|
|
|
eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;"> shorewall
|
|
|
|
|
|
delete eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The above commands may also be
|
|
|
|
|
|
written:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">shorewall add eth1:1.2.3.4,2.3.4.5
|
|
|
|
|
|
z12</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;"> shorewall
|
|
|
|
|
|
delete eth1:1.2.3.4,2.3.4.5 z12</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>TCP OpenVPN tunnels are now supported using the 'openvpn'
|
|
|
|
|
|
tunnel type. OpenVPN entries in /etc/shorewall/tunnels have
|
|
|
|
|
|
this format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">openvpn[:{tcp|udp}][:<port>]
|
|
|
|
|
|
<zone>
|
|
|
|
|
|
<gateway></span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style=
|
|
|
|
|
|
"font-family: monospace;">openvpn:tcp
|
|
|
|
|
|
net
|
|
|
|
|
|
1.2.3.4 # TCP tunnel on port 1194</span><br
|
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
openvpn:3344
|
|
|
|
|
|
net 1.2.3.4 # UDP on port
|
|
|
|
|
|
3344</span><br style="font-family: monospace;">
|
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
|
openvpn:tcp:4455 net
|
|
|
|
|
|
1.2.3.4 # TCP on port 4455</span><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new 'ipsecvpn' script is included in the tarball and in
|
|
|
|
|
|
the RPM. The RPM installs the file in the Documentation
|
|
|
|
|
|
directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This script is intended for use on Roadwarrior laptops for
|
|
|
|
|
|
establishing an IPSEC SA to/from remote networks. The script
|
|
|
|
|
|
has some limitations:</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 2em">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Only one instance of the script may be used at a
|
|
|
|
|
|
time.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Only the first SPD accessed will be instantiated at the
|
|
|
|
|
|
remote gateway. So while the script creates SPDs to/from
|
|
|
|
|
|
the remote gateway and each network listed in the NETWORKS
|
|
|
|
|
|
setting at the front of the script, only one of these may
|
|
|
|
|
|
be used at a time.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<ol start="39">
|
|
|
|
|
|
<li>The output of "shorewall status" now lists the loaded
|
|
|
|
|
|
netfilter kernel modules.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The range of UDP ports opened by the AllowTrcrt action
|
|
|
|
|
|
has been increased to 33434:33524.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The IANA has recently registered port 1194 for use by
|
|
|
|
|
|
OpenVPN. In previous versions of Shorewall (and OpenVPN), the
|
|
|
|
|
|
default port was 5000 but has been changed to 1194 to conform
|
|
|
|
|
|
to the new OpenVPN default.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;">01/17/2005 - Shorewall
|
|
|
|
|
|
2.2.0 RC5<br>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The AllowTrcrt action has been changed to allow up to 30
|
|
|
|
|
|
hops (same as default for 'traceroute'). Previously, the
|
|
|
|
|
|
action was documented as allowing 20 hops but actually only
|
|
|
|
|
|
allowed for 6 hops.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Using some lightweight shells, valid entries in
|
|
|
|
|
|
/etc/shorewall/ecn produce startup errors.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A new AllowInvalid standard built-in action has been
|
|
|
|
|
|
added. This action accepts packets that are in the INVALID
|
|
|
|
|
|
connection-tracking state.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"Mirrors"></a>01/16/2005 - New Shorewall Mirrors<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span>Thanks to Lorenzo Martignoni and Nick Slikey, there are
|
|
|
|
|
|
now Shorewall <a href="shorewall_mirrors.htm">mirrors</a> in
|
|
|
|
|
|
Milan Italy and in Austin Texas. Thanks Lorenzo and Nick!<br>
|
|
|
|
|
|
<span style="font-weight: bold;"><br>
|
|
|
|
|
|
<a name="2_0_15"></a>01/12/2005 - Shorewall 2.0.15<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The range of ports opened by the AllowTrcrt action has
|
|
|
|
|
|
been expanded to 33434:33524 to allow for a maximum of 30
|
|
|
|
|
|
hops.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Code mis-ported from 2.2.0 in release 2.0.14 caused the
|
|
|
|
|
|
following error during "shorewall start" where SYN
|
|
|
|
|
|
rate-limiting is present in /etc/shorewall/policy:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Bad argument `DROP'<br>
|
|
|
|
|
|
Try `iptables -h' or 'iptables
|
|
|
|
|
|
--help' for more information.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_RC4"></a>01/06/2005 - Shorewall 2.2.0 RC4<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A listing of loaded iptables kernel modules is now
|
|
|
|
|
|
included in the output of "shorewall status".<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Problems Corrected.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Several problems associated with processing the IPSEC
|
|
|
|
|
|
colummn in /etc/shorewall/masq have been corrected.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_0_14"></a>01/03/2005 - Shorewall 2.0.14<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Previously, when rate-limiting was specified in
|
|
|
|
|
|
/etc/shorewall/policy (LIMIT:BURST column), any traffic which
|
|
|
|
|
|
exceeded the specified rate was silently dropped. Now, if a
|
|
|
|
|
|
log level is given in the entry (LEVEL column) then drops are
|
|
|
|
|
|
logged at that level at a rate of 5/min with a burst of
|
|
|
|
|
|
5.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A typo in the /etc/shorewall/interfaces file has been
|
|
|
|
|
|
fixed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>"bad variable" error messages occurring during "shorewall
|
|
|
|
|
|
stop" and "shorewall clear" have been eliminated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A misleading typo in /etc/shorewall/tunnels has been
|
|
|
|
|
|
corrected. The TYPE column for an IPIP tunnel should contain
|
|
|
|
|
|
"ipip" rather than "ip".<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"MandrakeRPMS"></a>12/31/2004 - Mandrake-specific RPMs
|
|
|
|
|
|
available<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span>Jack Coates has generously volunteered to provide
|
|
|
|
|
|
Shorewall RPMs for use under Mandrake. You can download Jack's
|
|
|
|
|
|
RPMs from <a target="_top" href=
|
|
|
|
|
|
"http://www.monkeynoodle.org/tmp/">http://www.monkeynoodle.org/tmp/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"Redhat_Fedora"></a>12/31/2004 - Redhat/Fedora-specific RPMs
|
|
|
|
|
|
available<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Simon Matter has graciously volunteered to provide RPMs
|
|
|
|
|
|
taylored for Redhat and Fedora. You can download Simon's RPMs
|
|
|
|
|
|
from <a target="_top" href=
|
|
|
|
|
|
"http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Thanks, Simon!<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_RC3"></a>12/30/2004 - Shorewall 2.2.0 RC3<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The following error message could appear during
|
|
|
|
|
|
"shorewall stop" or "shorewall clear":<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
local: lo:: bad variable name<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The rate limiting example in /etc/shorewall/rules has
|
|
|
|
|
|
been changed to use the RATE LIMIT column.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Entries in /etc/shorewall/masq with the INTERFACE column
|
|
|
|
|
|
containing <ifname>:: (e.g., "eth0::") would generate a
|
|
|
|
|
|
progress message but would not generate an iptables
|
|
|
|
|
|
rule.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A misleading typo in /etc/shorewall/tunnels has been
|
|
|
|
|
|
corrected.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;">12/24/2004 - Shorewall
|
|
|
|
|
|
2.2.0 RC2<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span>New Features:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>By popular demand, the default port for Open VPN tunnels
|
|
|
|
|
|
is now 1194 (the IANA-reserved port number for Open
|
|
|
|
|
|
VPN).</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_RC1"></a>12/19/2004 - Shorewall 2.2.0 RC1<br>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The syntax of the add and delete command has been
|
|
|
|
|
|
clarified in the help summary produced by
|
|
|
|
|
|
/sbin/shorewall.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
TCP OpenVPN tunnels are now supported using the 'openvpn'
|
|
|
|
|
|
tunnel type. OpenVPN entries in /etc/shorewall/tunnels have
|
|
|
|
|
|
this format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
openvpn[:{tcp|udp}][:<port>]
|
|
|
|
|
|
<zone>
|
|
|
|
|
|
<gateway><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
openvpn:tcp net 1.2.3.4 # TCP tunnel on port 5000<br>
|
|
|
|
|
|
openvpn:3344 net 1.2.3.4 # UDP on port 3344<br>
|
|
|
|
|
|
openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new 'ipsecvpn' script is included in the tarball and in
|
|
|
|
|
|
the RPM. The RPM installs the file in the Documentation
|
|
|
|
|
|
directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This script is intended for use on Roadwarrior laptops for
|
|
|
|
|
|
establishing an IPSEC SA to/from remote networks. The script
|
|
|
|
|
|
has some limitations:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
- Only one instance of the script may be
|
|
|
|
|
|
used at a time.<br>
|
|
|
|
|
|
- Only the first SPD accessed will be
|
|
|
|
|
|
instantiated at the remote gateway. So while the script
|
|
|
|
|
|
creates SPDs to/from the remote gateway and each network
|
|
|
|
|
|
listed in the NETWORKS setting at the front of the script,
|
|
|
|
|
|
only one of these may be used at a time.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta8"></a>12/11/2004 - Shorewall 2.2.0 Beta 8<br>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A typo in the /etc/shorewall/interfaces file has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, the "add" and "delete" commands were
|
|
|
|
|
|
generating incorrect policy matches when policy match support
|
|
|
|
|
|
was available.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Recent 2.6 kernels include code that evaluates TCP
|
|
|
|
|
|
packets based on TCP Window analysis. This can cause packets
|
|
|
|
|
|
that were previously classified as NEW or ESTABLISHED to be
|
|
|
|
|
|
classified as INVALID.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The new kernel code can be disabled by including this command
|
|
|
|
|
|
in your /etc/shorewall/init file:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
echo 1 >
|
|
|
|
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Additional kernel logging about INVALID TCP packets may be
|
|
|
|
|
|
obtained by adding this command to /etc/shorewall/init:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
echo 1 >
|
|
|
|
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Traditionally, Shorewall has dropped INVALID TCP packets
|
|
|
|
|
|
early. The new DROPINVALID option allows INVALID packets to
|
|
|
|
|
|
be passed through the normal rules chains by setting
|
|
|
|
|
|
DROPINVALID=No.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If not specified or if specified as empty (e.g.,
|
|
|
|
|
|
DROPINVALID="") then DROPINVALID=Yes is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall add" and "shorewall delete" commands now
|
|
|
|
|
|
accept a list of hosts to add or delete.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall add eth1:1.2.3.4 eth1:2.3.4.5
|
|
|
|
|
|
z12<br>
|
|
|
|
|
|
shorewall delete eth1:1.2.3.4 eth1:2.3.4.5
|
|
|
|
|
|
z12<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The above commands may also be written:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall add eth1:1.2.3.4,2.3.4.5 z12<br>
|
|
|
|
|
|
shorewall delete eth1:1.2.3.4,2.3.4.5
|
|
|
|
|
|
z12<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta7"></a>12/04/2004 - Shorewall 2.2.0 Beta 7<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The "shorewall add" and "shorewall delete" commands now
|
|
|
|
|
|
work in a bridged environment. The syntax is:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall add
|
|
|
|
|
|
<interface>[:<port>]:<address>
|
|
|
|
|
|
<zone><br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall delete
|
|
|
|
|
|
<interface>[:<port>]:<address>
|
|
|
|
|
|
<zone><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall add br0:eth2:192.168.1.3 OK<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall delete br0:eth2:192.168.1.3 OK<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, "shorewall save" created an out-of-sequence
|
|
|
|
|
|
restore script. The commands saved in the user's
|
|
|
|
|
|
/etc/shorewall/start script were executed prior to the
|
|
|
|
|
|
Netfilter configuration being restored. This has been
|
|
|
|
|
|
corrected so that "shorewall save" now places those commands
|
|
|
|
|
|
at the end of the script.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To accomplish this change, the "restore base" file
|
|
|
|
|
|
(/var/lib/shorewall/restore-base) has been split into two
|
|
|
|
|
|
files:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/var/lib/shorewall/restore-base -- commands to be executed
|
|
|
|
|
|
before Netfilter the configuration is restored.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/var/lib/shorewall/restore-tail -- commands to be executed
|
|
|
|
|
|
after the Netfilter configuration is restored.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, traffic from the firewall to a dynamic zone
|
|
|
|
|
|
member host did not need to match the interface specified
|
|
|
|
|
|
when the host was added to the zone. For example, if
|
|
|
|
|
|
eth0:1.2.3.4 is added to dynamic zone Z then traffic out of
|
|
|
|
|
|
any firewall interface to 1.2.3.4 will obey the fw->Z
|
|
|
|
|
|
policies and rules. This has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall uses the temporary chain 'fooX1234' to probe
|
|
|
|
|
|
iptables for detrmining which features are supported.
|
|
|
|
|
|
Previously, if that chain happened to exist when Shorewall
|
|
|
|
|
|
was run, capabilities were mis-detected.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>You can now use the "shorewall show zones" command to
|
|
|
|
|
|
display the current contents of the zones. This is
|
|
|
|
|
|
particularly useful if you use dynamic zones
|
|
|
|
|
|
(DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
ursa:/etc/shorewall # shorewall show zones<br>
|
|
|
|
|
|
|
|
|
|
|
|
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
|
|
|
|
|
|
2004<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
loc<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0:192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth1:1.2.3.4<br>
|
|
|
|
|
|
net<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0:0.0.0.0/0<br>
|
|
|
|
|
|
WiFi<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth1:0.0.0.0/0<br>
|
|
|
|
|
|
sec<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth1:0.0.0.0/0<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
ursa:/etc/shorewall #<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Variable expansion may now be used with the INCLUDE
|
|
|
|
|
|
directive.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/params<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
FILE=/etc/foo/bar<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Any other config
|
|
|
|
|
|
file:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
INCLUDE $FILE<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The output of "shorewall status" now includes the results
|
|
|
|
|
|
of "ip -stat link ls". This helps diagnose performance
|
|
|
|
|
|
problems caused by link errors.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, when rate-limiting was specified in
|
|
|
|
|
|
/etc/shorewall/policy (LIMIT:BURST column), any traffic which
|
|
|
|
|
|
exceeded the specified rate was silently dropped. Now, if a
|
|
|
|
|
|
log<br>
|
|
|
|
|
|
level is given in the entry (LEVEL column) then drops are
|
|
|
|
|
|
logged at that level at a rate of 5/min with a burst of
|
|
|
|
|
|
5.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_0_13"></a>12/02/2004 - Shorewall 2.0.13<br>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
A typo in /usr/share/shorewall/firewall caused the
|
|
|
|
|
|
"shorewall add" to issue an error message:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre class="programlisting">
|
|
|
|
|
|
/usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_0_12"></a>12/01/2004 - Shorewall 2.0.12<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A typo in shorewall.conf (NETNOTSYN) has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall add" and "shorewall delete" commands now
|
|
|
|
|
|
work in a bridged environment. The syntax is:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall add
|
|
|
|
|
|
<interface>[:<bridge port>][:<address>]
|
|
|
|
|
|
<zone><br>
|
|
|
|
|
|
shorewall delete
|
|
|
|
|
|
<interface>[:<bridge port>][:<address>]
|
|
|
|
|
|
<zone><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall add
|
|
|
|
|
|
br0:eth2:192.168.1.3 OK<br>
|
|
|
|
|
|
shorewall delete
|
|
|
|
|
|
br0:eth2:192.168.1.3 OK<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, "shorewall save" created an out-of-sequence
|
|
|
|
|
|
restore script. The commands saved in the user's
|
|
|
|
|
|
/etc/shorewall/start script were executed prior to the
|
|
|
|
|
|
Netfilter configuration being restored. This has been
|
|
|
|
|
|
corrected so that "shorewall save" now places those commands
|
|
|
|
|
|
at the end of the script.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To accomplish this change, the "restore base" file
|
|
|
|
|
|
(/var/lib/shorewall/restore-base) has been split into two
|
|
|
|
|
|
files:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/var/lib/shorewall/restore-base -- commands to
|
|
|
|
|
|
be executed before the Netfilter configuration is
|
|
|
|
|
|
restored.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/var/lib/shorewall/restore-tail -- commands to
|
|
|
|
|
|
be executed after the Netfilter configuration is
|
|
|
|
|
|
restored.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, traffic from the firewall to a dynamic zone
|
|
|
|
|
|
member host did not need to match the interface specified
|
|
|
|
|
|
when the host was added to the zone. For example, if
|
|
|
|
|
|
eth0:1.2.3.4 is added to dynamic zone Z then traffic out of
|
|
|
|
|
|
any firewall interface to 1.2.3.4 will obey the fw->Z
|
|
|
|
|
|
policies and rules. This has been corrected.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Variable expansion may now be used with the INCLUDE
|
|
|
|
|
|
directive.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/params<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
FILE=/etc/foo/bar<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Any other config
|
|
|
|
|
|
file:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
INCLUDE $FILE<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta6"></a>11/26/2004 - Shorewall 2.2.0 Beta 6<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Beta 5 was more or less DOA. Here's Beta 6.<br>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Fixed a number of problems associated with not having an
|
|
|
|
|
|
IPTABLES value assigned in shorewall.conf</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected a 'duplicate chain' error on "shorewall add"
|
|
|
|
|
|
when the 'mss' option is present in /etc/shorewall/ipsec.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta5"></a>11/26/2004 - Shorewall 2.2.0 Beta 5<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A typo in shorewall.conf (NETNOTSYN) has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>For consistency, the CLIENT PORT(S) column in the tcrules
|
|
|
|
|
|
file has been renamed SOURCE PORT(S).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
|
|
|
|
|
|
now shown in the output of "shorewall status".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new IPTABLES option has been added to shorewall.conf.
|
|
|
|
|
|
IPTABLES can be used to designate the iptables executable to
|
|
|
|
|
|
be used by Shorewall. If not specified, the iptables
|
|
|
|
|
|
executable determined by the PATH setting is used.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_0_11"></a>11/23/2004 - Shorewall 2.0.11<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The INSTALL file now include special instructions for
|
|
|
|
|
|
Slackware users.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The bogons file has been updated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Service names are replaced by port numbers in
|
|
|
|
|
|
/etc/shorewall/tos.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A typo in the install.sh file that caused an error during
|
|
|
|
|
|
a new install has been corrected.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The AllowNNTP action now allows NNTP over SSL/TLS
|
|
|
|
|
|
(NTTPS).<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta4"></a>11/19/2004 - Shorewall 2.2.0 Beta 4<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A cut and paste error resulted in some nonsense in the
|
|
|
|
|
|
description of the IPSEC column in /etc/shorewall/masq.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A typo in /etc/shorewall/rules has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The bogons file has been updated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall add" command previously reported success
|
|
|
|
|
|
but did nothing -- now it works.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The AllowNNTP action now allows NNTP over SSL/TLS
|
|
|
|
|
|
(NNTPS).<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta3"></a>11/09/2004 - Shorewall 2.2.0 Beta 3<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Missing '#' in the rfc1918 file has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The INSTALL file now includes special instructions for
|
|
|
|
|
|
Slackware users.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
In CLASSIFY rules (/etc/shorewall/tcrules), an interface
|
|
|
|
|
|
name may now appear in the DEST column as in:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
#MARK/ SOURCE DEST PROTO PORT(S)<br>
|
|
|
|
|
|
#CLASSIFY<br>
|
|
|
|
|
|
1:30 - eth0 tcp 25
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta2"></a>11/02/2004 - Shorewall 2.2.0 Beta 2<br>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The "shorewall check" command results in the (harmless)
|
|
|
|
|
|
error message:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
/usr/share/shorewall/firewall: line 2753:<br>
|
|
|
|
|
|
|
|
|
|
|
|
check_dupliate_zones: command not found<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The AllowNTP standard action now allows outgoing
|
|
|
|
|
|
responses to broadcasts.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A clarification has been added to the hosts file's
|
|
|
|
|
|
description of the 'ipsec' option pointing out that the
|
|
|
|
|
|
option is redundent if the zone named in the ZONE column has
|
|
|
|
|
|
been designated an IPSEC zone in the /etc/shorewall/ipsec
|
|
|
|
|
|
file.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The SUBNET column in /etc/shorewall/rfc1918 has been
|
|
|
|
|
|
renamed SUBNETS and it is now possible to specify a list of
|
|
|
|
|
|
addresses in that column.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_0_10"></a>10/25/2004 - Shorewall 2.0.10<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The GATEWAY column was previously ignored in 'pptpserver'
|
|
|
|
|
|
entries in /etc/shorewall/tunnels.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When log rule numbers are included in the LOGFORMAT,
|
|
|
|
|
|
duplicate rule numbers could previously be generated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /etc/shorewall/tcrules file now includes a note to
|
|
|
|
|
|
the effect that rule evaluation continues after a match.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The error message produced if Shorewall couldn't obtain
|
|
|
|
|
|
the routes through an interface named in the SUBNET column of
|
|
|
|
|
|
/etc/shorewall/masq was less than helpful since it didn't
|
|
|
|
|
|
include the interface name.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The "shorewall status" command has been enhanced to
|
|
|
|
|
|
include the values of key /proc settings:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example from a two-interface firewall:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/proc<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/ip_forward = 1<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/all/proxy_arp = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/all/arp_filter = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/all/rp_filter = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/default/proxy_arp =
|
|
|
|
|
|
0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/default/arp_filter =
|
|
|
|
|
|
0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/default/rp_filter =
|
|
|
|
|
|
0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/eth0/proxy_arp = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/eth0/arp_filter = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/eth0/rp_filter = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/eth1/proxy_arp = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/eth1/arp_filter = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/eth1/rp_filter = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/lo/proxy_arp = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/lo/arp_filter = 0<br>
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/lo/rp_filter = 0<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_2_0_Beta1"></a>10/24/2004 - Shorewall 2.2.0 Beta1<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span>The first beta in the 2.2 series is now available.
|
|
|
|
|
|
Download location is:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">
|
|
|
|
|
|
http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a target="_top" href=
|
|
|
|
|
|
"ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">
|
|
|
|
|
|
ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The features available in this release and the migration
|
|
|
|
|
|
considerations are covered in the <a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1/releasenotes.txt">
|
|
|
|
|
|
release notes</a>. Highlights include:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The behavior produced by specifying a log level in an
|
|
|
|
|
|
action invocation is now much more rational. Previously, all
|
|
|
|
|
|
packets sent to the action were logged; now each rule within
|
|
|
|
|
|
the invoked action behaves as if logging had been specified
|
|
|
|
|
|
on it.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the 2.6 Kernel's native IPSEC implementation
|
|
|
|
|
|
is now available.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for ipp2p is included.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the iptables CONNMARK facility is now
|
|
|
|
|
|
included in Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new LOGALLNEW option facilitates problem analysis.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Users with a large static blacklist can now defer loading
|
|
|
|
|
|
the blacklist until after the rest of the ruleset has been
|
|
|
|
|
|
enabled. Doing so can decrease substantially the amount of
|
|
|
|
|
|
time that connections are disabled during <span style=
|
|
|
|
|
|
"font-weight: bold;">shorewall [re]start</span>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the iptables 'iprange match' feature has been
|
|
|
|
|
|
enabled. Users whose kernel and iptables contain this feature
|
|
|
|
|
|
can use ip address ranges in most places in their Shorewall
|
|
|
|
|
|
configuration where a CIDR netowrk can be used.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Accepting of source routing and martian logging may now
|
|
|
|
|
|
be enabled/disabled on each interface.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now supports the CLASSIFY iptable target.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><span style="font-weight: bold;"><a name=
|
|
|
|
|
|
"2_0_9"></a>9/23/2004 - Shorewall 2.0.9<br>
|
|
|
|
|
|
</span><br>
|
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Previously, an empty PROTO column or a value of "all" in
|
|
|
|
|
|
that column would cause errors when processing the
|
|
|
|
|
|
/etc/shorewall/tcrules file.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The "shorewall status" command now includes the output of
|
|
|
|
|
|
"brctl show" if the bridge tools are installed.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="SupportChange"><b>9/20/2004 – Change in Shorewall
|
|
|
|
|
|
Support</b></a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p style="">Friends,</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p style="">The demands that my job and my personal life are
|
|
|
|
|
|
currently placing on me are such that supporing Shorewall to
|
|
|
|
|
|
the extent that I have been doing is just not possible any
|
|
|
|
|
|
more.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p style="">I will continue to be active on the development
|
|
|
|
|
|
list and will continue to develop Shorewall if at all
|
|
|
|
|
|
possible.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p style="">I will also continue to read the user's list and
|
|
|
|
|
|
will help with problems that interest me. But I am no longer
|
|
|
|
|
|
going to hop on every problem as soon as I see it.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p style="">This change means that I'm going to have to depend
|
|
|
|
|
|
on you folks to help each other; I'm confident that we can make
|
|
|
|
|
|
this work.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_8"></a><b>8/22/2004 - Shorewall 2.0.8<br>
|
|
|
|
|
|
</b><br>
|
|
|
|
|
|
Problems Corrected:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>Entries in the USER/GROUP column of an action file (made
|
|
|
|
|
|
from action.template) may be ignored or cause odd
|
|
|
|
|
|
errors.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_7"></a><b>7/29/2004 - Shorewall 2.0.7<br>
|
2004-01-31 04:35:08 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</b>Problems Corrected:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The PKTTYPE option
|
|
|
|
|
|
introduced in version 2.0.6 is now used when generating
|
|
|
|
|
|
rules to REJECT packets. Broadcast packets are silently
|
|
|
|
|
|
dropped rather than being rejected with an ICMP (which is a
|
|
|
|
|
|
protocol violation) and users whose kernels have broken
|
|
|
|
|
|
packet type match support are likely to see messages
|
|
|
|
|
|
reporting this violation. Setting PKTTYPE=No should cause
|
|
|
|
|
|
these messages to cease.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Multiple interfaces with the
|
|
|
|
|
|
'blacklist' option no longer result in an error message at
|
|
|
|
|
|
startup.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>The following has been added to
|
|
|
|
|
|
/etc/shorewall/bogons:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
0.0.0.0
|
|
|
|
|
|
RETURN<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This prevents the 'nobogons' option from logging DHCP
|
|
|
|
|
|
'DISCOVER' broadcasts.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>New Features:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>To improve supportability, the "shorewall status"
|
|
|
|
|
|
command now includes IP and Route configuration
|
|
|
|
|
|
information.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">IP
|
|
|
|
|
|
Configuration</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">1: lo:
|
|
|
|
|
|
<LOOPBACK,UP> mtu 16436 qdisc noqueue</font><br>
|
|
|
|
|
|
<font face=
|
|
|
|
|
|
"monospace">link/loopback 00:00:00:00:00:00 brd
|
|
|
|
|
|
00:00:00:00:00:00</font><br>
|
|
|
|
|
|
<font face="monospace">inet
|
|
|
|
|
|
127.0.0.1/8 brd 127.255.255.255 scope host lo</font><br>
|
|
|
|
|
|
<font face="monospace">inet6
|
|
|
|
|
|
::1/128 scope host</font><br>
|
|
|
|
|
|
<font face="monospace">2: eth0:
|
|
|
|
|
|
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
|
|
|
|
|
|
pfifo_fast qlen 1000</font><br>
|
|
|
|
|
|
<font face=
|
|
|
|
|
|
"monospace">link/ether 00:a0:c9:15:39:78 brd
|
|
|
|
|
|
ff:ff:ff:ff:ff:ff</font><br>
|
|
|
|
|
|
<font face="monospace">inet6
|
|
|
|
|
|
fe80::2a0:c9ff:fe15:3978/64 scope link</font><br>
|
|
|
|
|
|
<font face="monospace">3: eth1:
|
|
|
|
|
|
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
|
|
|
|
|
|
pfifo_fast qlen 1000</font><br>
|
|
|
|
|
|
<font face=
|
|
|
|
|
|
"monospace">link/ether 00:a0:c9:a7:d7:bf brd
|
|
|
|
|
|
ff:ff:ff:ff:ff:ff</font><br>
|
|
|
|
|
|
<font face="monospace">inet6
|
|
|
|
|
|
fe80::2a0:c9ff:fea7:d7bf/64 scope link</font><br>
|
|
|
|
|
|
<font face="monospace">5: sit0@NONE:
|
|
|
|
|
|
<NOARP> mtu 1480 qdisc noop</font><br>
|
|
|
|
|
|
<font face=
|
|
|
|
|
|
"monospace">link/sit 0.0.0.0 brd 0.0.0.0</font><br>
|
|
|
|
|
|
<font face="monospace">6: eth2:
|
|
|
|
|
|
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
|
|
|
|
|
|
pfifo_fast qlen 1000</font><br>
|
|
|
|
|
|
<font face=
|
|
|
|
|
|
"monospace">link/ether 00:40:d0:07:3a:1b brd
|
|
|
|
|
|
ff:ff:ff:ff:ff:ff</font><br>
|
|
|
|
|
|
<font face="monospace">inet6
|
|
|
|
|
|
fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
|
|
|
|
|
|
<font face="monospace">7: br0:
|
|
|
|
|
|
<BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc
|
|
|
|
|
|
noqueue</font><br>
|
|
|
|
|
|
<font face=
|
|
|
|
|
|
"monospace">link/ether 00:40:d0:07:3a:1b brd
|
|
|
|
|
|
ff:ff:ff:ff:ff:ff</font><br>
|
|
|
|
|
|
<font face="monospace">inet
|
|
|
|
|
|
192.168.1.3/24 brd 192.168.1.255 scope global
|
|
|
|
|
|
br0</font><br>
|
|
|
|
|
|
<font face="monospace">inet6
|
|
|
|
|
|
fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">Routing
|
|
|
|
|
|
Rules</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face=
|
|
|
|
|
|
"monospace">0: from all
|
|
|
|
|
|
lookup local</font><br>
|
|
|
|
|
|
<font face="monospace">32765: from all
|
|
|
|
|
|
fwmark ca lookup
|
|
|
|
|
|
www.out</font><br>
|
|
|
|
|
|
<font face="monospace">32766: from all
|
|
|
|
|
|
lookup main</font><br>
|
|
|
|
|
|
<font face="monospace">32767: from all
|
|
|
|
|
|
lookup default</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">Table local:</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">broadcast 192.168.1.0
|
|
|
|
|
|
dev br0 proto kernel scope link src
|
|
|
|
|
|
192.168.1.3</font><br>
|
|
|
|
|
|
<font face="monospace">broadcast
|
|
|
|
|
|
127.255.255.255 dev lo proto kernel scope
|
|
|
|
|
|
link src 127.0.0.1</font><br>
|
|
|
|
|
|
<font face="monospace">local 192.168.1.3 dev
|
|
|
|
|
|
br0 proto kernel scope host src
|
|
|
|
|
|
192.168.1.3</font><br>
|
|
|
|
|
|
<font face="monospace">broadcast 192.168.1.255
|
|
|
|
|
|
dev br0 proto kernel scope link src
|
|
|
|
|
|
192.168.1.3</font><br>
|
|
|
|
|
|
<font face="monospace">broadcast 127.0.0.0 dev
|
|
|
|
|
|
lo proto kernel scope link src
|
|
|
|
|
|
127.0.0.1</font><br>
|
|
|
|
|
|
<font face="monospace">local 127.0.0.1 dev
|
|
|
|
|
|
lo proto kernel scope host src
|
|
|
|
|
|
127.0.0.1</font><br>
|
|
|
|
|
|
<font face="monospace">local 127.0.0.0/8 dev
|
|
|
|
|
|
lo proto kernel scope host src
|
|
|
|
|
|
127.0.0.1</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">Table
|
|
|
|
|
|
www.out:</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">default via 192.168.1.3
|
|
|
|
|
|
dev br0</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">Table main:</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">192.168.1.0/24 dev
|
|
|
|
|
|
br0 proto kernel scope link src
|
|
|
|
|
|
192.168.1.3</font><br>
|
|
|
|
|
|
<font face="monospace">default via
|
|
|
|
|
|
192.168.1.254 dev br0</font><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<font face="monospace">Table
|
|
|
|
|
|
default:</font></p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_6"></a><b>7/16/2004 - Shorewall 2.0.6<br>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</b>Problems Corrected:</p>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Some users have reported the
|
|
|
|
|
|
packet type match option in iptables/Netfilter failing to
|
|
|
|
|
|
match certain broadcast packets. The result is that the
|
|
|
|
|
|
firewall log shows a lot of broadcast packets.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Other users have complained of the following message when
|
|
|
|
|
|
starting Shorewall:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
modprobe: cant locate module ipt_pkttype<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
Users experiencing either of these problems can use
|
|
|
|
|
|
PKTTYPE=No in shorewall.conf to cause Shorewall to use IP
|
|
|
|
|
|
address filtering of broadcasts rather than packet
|
|
|
|
|
|
type.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The shorewall.conf and zones
|
|
|
|
|
|
file are no longer given execute permission by the
|
|
|
|
|
|
installer script.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>ICMP packets that are in the INVALID state are now
|
|
|
|
|
|
dropped by the Reject and Drop default actions. They do so
|
|
|
|
|
|
using the new 'dropInvalid' builtin action.</p>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_5"></a><b>7/10/2004 - Shorewall 2.0.5<br>
|
|
|
|
|
|
</b><br>
|
|
|
|
|
|
Problems Corrected:</p>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">If DISABLE_IPV6=Yes in
|
|
|
|
|
|
shorewall.conf then harmless error messages referring to
|
|
|
|
|
|
$RESTOREBASE are generated during <b>shorewall
|
|
|
|
|
|
stop</b>.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>An anachronistic comment concerning a mangle option has
|
|
|
|
|
|
been removed from shorewall.conf.</p>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_4"></a><b>7/06/2004 - Shorewall 2.0.4<br>
|
|
|
|
|
|
</b><br>
|
|
|
|
|
|
Problems Corrected:</p>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>
|
|
|
|
|
|
<p>Rules with $FW as the source zone and that specify
|
|
|
|
|
|
logging can cause "shorewall start" to fail.</p>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<p><a name="Release_Model"></a><b>7/03/2004 - New Shorewall
|
|
|
|
|
|
Release Model<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</b>Effective today, Shorewall is adopting a new release model
|
|
|
|
|
|
which takes ideas from the one used in the Linux Kernel and
|
|
|
|
|
|
from the release model for Postfix.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Releases continue to have a
|
|
|
|
|
|
three-level identification <i>x.y.z</i> (e.g., 2.0.3).</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The first two levels
|
|
|
|
|
|
(<i>x.y)</i> designate the <i>Major Release Number</i>
|
|
|
|
|
|
(e.g., 2.0)</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The third level (<i>z</i>)
|
|
|
|
|
|
designates the <i>Minor Release Number</i>.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Even numbered major releases
|
|
|
|
|
|
(e.g., <i>1.4, 2.0, 2.2, ...)</i> are <i>Stable
|
|
|
|
|
|
Releases</i>. No new features are added to stable releases
|
|
|
|
|
|
and new minor releases of a stable release will only
|
|
|
|
|
|
contain bug fixes. Installing a new minor release for the
|
|
|
|
|
|
major release that you are currently running involves no
|
|
|
|
|
|
migration issues (for example, if you are running 1.4.10
|
|
|
|
|
|
and I release 1.4.11, your current configuration is 100%
|
|
|
|
|
|
compatible with the new release).</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Support is available through
|
|
|
|
|
|
the <a href="http://lists.shorewall.net/">Mailing List</a>
|
|
|
|
|
|
for the two most recent Stable Releases.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Odd numbered major releases
|
|
|
|
|
|
(e.g., 2.1, 2.3, ...) are <i>Development Releases</i>.
|
|
|
|
|
|
Development releases are where new functionality is
|
|
|
|
|
|
introduced. Documentation for new features will be
|
|
|
|
|
|
available but it may not be up to the standards of the
|
|
|
|
|
|
stable release documentation. Sites running Development
|
|
|
|
|
|
Releases should be prepared to play an active role in
|
|
|
|
|
|
testing new features. Bug fixes and problem resolution for
|
|
|
|
|
|
the development release take a back seat to support of the
|
|
|
|
|
|
stable releases. Problem reports for the current
|
|
|
|
|
|
development release should be sent to the <a href=
|
|
|
|
|
|
"mailto:shorewall-devel@lists.shorewall.net">Shorewall
|
|
|
|
|
|
Development Mailing List</a>.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">When the level of
|
|
|
|
|
|
functionality of the current development release is judged
|
|
|
|
|
|
adaquate, the Beta period for a new Stable release will
|
|
|
|
|
|
begin. Beta releases have identifications of the form
|
|
|
|
|
|
<i>x.y.0-BetaN</i> where <i>x.y</i> is the number of the
|
|
|
|
|
|
next Stable Release and <i>N</i>=1,2,3... . Betas are
|
|
|
|
|
|
expected to occur rougly once per year. Beta releases may
|
|
|
|
|
|
contain new functionality not present in the previous beta
|
|
|
|
|
|
release (e.g., 2.2.0-Beta4 may contain functionality not
|
|
|
|
|
|
present in 2.2.0-Beta3). When I'm confident that the
|
|
|
|
|
|
current Beta release is stable, I will release the first
|
|
|
|
|
|
<i>Release Candidate.</i> Release candidates have
|
|
|
|
|
|
identifications of the form <i>x.y.0-RCn</i> where
|
|
|
|
|
|
<i>x.y</i> is the number of the next Stable Release and
|
|
|
|
|
|
<i>n</i>=1,2,3... . Release candidates contain no new
|
|
|
|
|
|
functionailty -- they only contain bug fixes. When the
|
|
|
|
|
|
stability of the current release candidate is judged to be
|
|
|
|
|
|
sufficient then that release candidate will be released as
|
|
|
|
|
|
the new stable release (e.g., 2.2.0). At that time, the new
|
|
|
|
|
|
stable release and the prior stable release are those that
|
|
|
|
|
|
are supported.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">What does it mean for a
|
|
|
|
|
|
major release to be <i>supported?</i> It means that I will
|
|
|
|
|
|
answer questions about the release and that if a bug is
|
|
|
|
|
|
found, I will fix the bug and include the fix in the next
|
|
|
|
|
|
minor release.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>Between minor releases, bug fixes will continue to be
|
|
|
|
|
|
made available through the Errata page for each major
|
|
|
|
|
|
release.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The immediate implications of this change are as
|
|
|
|
|
|
follows:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The functionality of the 2.0
|
|
|
|
|
|
major release is frozen at the level of minor release
|
|
|
|
|
|
2.0.3.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The two major releases
|
|
|
|
|
|
currently supported are 1.4 and 2.0.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">I will be opening the 2.1
|
|
|
|
|
|
development release shortly with the release of 2.1.0.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>Bug-fix releases with identifications of the form
|
|
|
|
|
|
<i>x.y.zX</i> where X=a,b,c,... (e.g., 2.0.3c) will not be
|
|
|
|
|
|
seen in the future.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_3c"></a><b>7/02/2004 - Shorewall 2.0.3c<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</b>Problems Corrected<b>:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Error messages regarding
|
|
|
|
|
|
$RESTOREBASE occur during <b>shorewall stop</b></p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>If CLEAR_TC=Yes in <tt>shorewall.conf</tt>, <b>shorewall
|
|
|
|
|
|
stop</b> fails without removing the lock file.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_3b"></a><b><br>
|
|
|
|
|
|
6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</b>Problems Corrected:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The security vulnerability
|
|
|
|
|
|
fix released in Shorewall 2.0.3a failed under Slackware
|
|
|
|
|
|
9.1.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>The security vulnerability fix released in Shorewall
|
|
|
|
|
|
2.0.3a failed if mktemp was not installed.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_3a"></a><b>6/28/2004 - Shorewall 2.0.3a and
|
|
|
|
|
|
Shorewall 1.4.10f<br>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
</b>Problems Corrected:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Javier Fernández-Sanguino
|
|
|
|
|
|
Peña has discovered an exploitable vulnerability in the way
|
|
|
|
|
|
that Shorewall handles temporary files and directories. The
|
|
|
|
|
|
vulnerability can allow a non-root user to cause arbitrary
|
|
|
|
|
|
files on the system to be overwritten. LEAF Bering and
|
|
|
|
|
|
Bering uClibc users are generally not at risk due to the
|
|
|
|
|
|
fact that LEAF boxes do not typically allow logins by
|
|
|
|
|
|
non-root users.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>(2.0.3a only) A non-empty DEST entry in
|
|
|
|
|
|
/etc/shorewall/tcrules will generate an error and Shorewall
|
|
|
|
|
|
fails to start.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p style="margin-left: 0.42in;">Note:: Slackware users may need
|
|
|
|
|
|
the 'functions' file from CVS (STABLE/ project for 1.4.10f and
|
|
|
|
|
|
STABLE2/ project for 2.0.3a) to prevent startup errors with
|
|
|
|
|
|
these versions installed. These updatged files are also
|
|
|
|
|
|
available from the Errata (<a href="errata.htm">2.0,</a> <a
|
|
|
|
|
|
href="1.4/errata.htm">1.4</a>).</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a name="2_0_3"></a><b>6/23/2004 - Shorewall 2.0.3<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</b>Problems Corrected:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The 'firewall' script is not
|
|
|
|
|
|
purging temporary restore files in /var/lib/shorewall.
|
|
|
|
|
|
These files have names of the form "restore-nnnnn".</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The
|
|
|
|
|
|
/var/lib/shorewall/restore script did not load the kernel
|
|
|
|
|
|
modules specified in /etc/shorewall/modules.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Specifying a null common
|
|
|
|
|
|
action in /etc/shorewall/actions (e.g., :REJECT) results in
|
|
|
|
|
|
a startup error.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">If /var/lib/shorewall does
|
|
|
|
|
|
not exist, shorewall start fails.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">DNAT rules with a dynamic
|
|
|
|
|
|
source zone don't work properly. When used, these rules
|
|
|
|
|
|
cause the rule to be checked against ALL input, not just
|
|
|
|
|
|
input from the designated zone.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The install.sh script
|
|
|
|
|
|
reported installing some files in /etc/shorewall when the
|
|
|
|
|
|
files were actually installed in /usr/share/shorewall.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Shorewall checks netfilter
|
|
|
|
|
|
capabilities before loading kernel modules. Hence if kernel
|
|
|
|
|
|
module autoloading isn't enabled, the capabilities will be
|
|
|
|
|
|
misdetected.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The 'newnotsyn' option in
|
|
|
|
|
|
/etc/shorewall/hosts has no effect.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The file
|
|
|
|
|
|
/etc/init.d/shorewall now gets proper ownership when the
|
|
|
|
|
|
RPM is built by a non-root user.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Rules that specify bridge
|
|
|
|
|
|
ports in both the SOURCE and DEST columns no longer cause
|
|
|
|
|
|
"shorewall start" to fail.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Comments in the rules file
|
|
|
|
|
|
have been added to advise users that "all" in the SOURCE or
|
|
|
|
|
|
DEST column does not affect intra-zone traffic.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>With BLACKLISTNEWONLY=Yes, ICMP packets with state
|
|
|
|
|
|
INVALID are now passed through the blacklisting chains.
|
|
|
|
|
|
Without this change, it is not possible to blacklist hosts
|
|
|
|
|
|
that are mounting certain types of ICMP-based DOS
|
|
|
|
|
|
attacks.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Issues when migrating from Shorewall 2.0.2 to Shorewall
|
|
|
|
|
|
2.0.3:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>The 'dropNonSyn' standard builtin action has been
|
|
|
|
|
|
replaced with the 'dropNotSyn' standard builtin action. The
|
|
|
|
|
|
old name can still be used but will generate a warning.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>New Features:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Shorewall now supports
|
|
|
|
|
|
multiple saved configurations.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The default saved
|
|
|
|
|
|
configuration (restore script) in /var/lib/shorewall is
|
|
|
|
|
|
now specified using the RESTOREFILE option in
|
|
|
|
|
|
shorewall.conf. If this variable isn't set then to
|
|
|
|
|
|
maintain backward compatibility, 'restore' is
|
|
|
|
|
|
assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The value of RESTOREFILE must be a simple file name; no
|
|
|
|
|
|
slashes ("/") may be included.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The "save" command has
|
|
|
|
|
|
been extended to be able to specify the name of a saved
|
|
|
|
|
|
configuration.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall save [ <file name> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The current state is saved to
|
|
|
|
|
|
/var/lib/shorewall/<file name>. If no <file
|
|
|
|
|
|
name> is given, the configuration is saved to the
|
|
|
|
|
|
file determined by the RESTOREFILE setting.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The "restore" command
|
|
|
|
|
|
has been extended to be able to specify the name of a
|
|
|
|
|
|
saved configuration:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall restore [ <file name> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall state is restored from
|
|
|
|
|
|
/var/lib/shorewall/<file name>. If no <file
|
|
|
|
|
|
name> is given, the firewall state is restored from
|
|
|
|
|
|
the file determined by the RESTOREFILE setting.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The "forget" command has
|
|
|
|
|
|
changed. Previously, the command unconditionally
|
|
|
|
|
|
removed the /var/lib/shorewall/save file which records
|
|
|
|
|
|
the current dynamic blacklist. The "forget" command now
|
|
|
|
|
|
leaves that file alone.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Also, the "forget" command has been extended to be able
|
|
|
|
|
|
to specify the name of a saved configuration:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall forget [ <file name> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The file /var/lib/shorewall/<file name> is
|
|
|
|
|
|
removed. If no <file name> is given, the file
|
|
|
|
|
|
determined by the RESTOREFILE setting is removed.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">The "shorewall -f start"
|
|
|
|
|
|
command restores the state from the file determined by
|
|
|
|
|
|
the RESTOREFILE setting.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">"!" is now allowed in
|
|
|
|
|
|
accounting rules.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Interface names appearing
|
|
|
|
|
|
within the configuration are now verified. Interface names
|
|
|
|
|
|
must match the name of an entry in
|
|
|
|
|
|
/etc/shorewall/interfaces (or if bridging is enabled, they
|
|
|
|
|
|
must match the name of an entry in
|
|
|
|
|
|
/etc/shorewall/interfaces or the name of a bridge port
|
|
|
|
|
|
appearing in /etc/shorewall/hosts).</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">A new 'rejNotSyn' built-in
|
|
|
|
|
|
standard action has been added. This action responds to
|
|
|
|
|
|
"New not SYN" packets with an RST.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The 'dropNonSyn' action has been superceded by the new
|
|
|
|
|
|
'dropNotSyn' action. The old name will be accepted until
|
|
|
|
|
|
the next major release of Shorewall but will generate a
|
|
|
|
|
|
warning.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Several new logging actions involving "New not SYN" packets
|
|
|
|
|
|
have been added:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
logNewNotSyn -- logs the packet with disposition =
|
|
|
|
|
|
LOG<br>
|
|
|
|
|
|
dLogNewNotSyn --
|
|
|
|
|
|
logs the packet with disposition = DROP<br>
|
|
|
|
|
|
rLogNewNotSyn --
|
|
|
|
|
|
logs the packet with disposition = REJECT<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The packets are logged at the log level specified in the
|
|
|
|
|
|
LOGNEWNOTSYN option in shorewall.conf. If than option is
|
|
|
|
|
|
empty or not specified, then 'info' is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples (In all cases, set NEWNOTSYN=Yes in
|
|
|
|
|
|
shorewall.conf):</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">To simulate the behavior
|
|
|
|
|
|
of NEWNOTSYN=No:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Add 'NoNewNotSyn' to
|
|
|
|
|
|
/etc/shorewall/actions.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>Create /etc/shorewall/action.NoNewNotSyn
|
|
|
|
|
|
containing:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
dLogNotSyn<br>
|
|
|
|
|
|
|
|
|
|
|
|
dropNotSyn</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>Early in your rules file, place:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
NoNewNotSyn all
|
|
|
|
|
|
all tcp</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p style="margin-bottom: 0in;">Drop 'New not SYN'
|
|
|
|
|
|
packets from the net only. Don't log them:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>Early in your rules file, place:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
dropNotSyn
|
|
|
|
|
|
net
|
|
|
|
|
|
all tcp</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
<p>Slackware users no longer have to modify the install.sh
|
|
|
|
|
|
script before installation. Tuomo Soini has provided a
|
|
|
|
|
|
change that allows the INIT and FIREWALL variables to be
|
|
|
|
|
|
specified outside the script as in:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DEST=/etc/rc.d
|
|
|
|
|
|
INIT=rc.firewall ./install.sh</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/3/2004 - Shorewall 2.0.2f<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Fixes one problem:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Versions 2.0.2d and 2.0.2e fail to load kernel modules
|
|
|
|
|
|
unless MODULE_SUFFIX is set in shorewall.conf<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/2/2004 - Shorewall 2.0.2e<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>One problem corrected:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>LOG rules within an action generate two Netfilter logging
|
|
|
|
|
|
rules.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/28/2004 - Shorewall 2.0.2d<br>
|
|
|
|
|
|
</b><br>
|
|
|
|
|
|
One problem corrected:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall was checking capabilities before loading kernel
|
|
|
|
|
|
modules. Consequently, if kernel module autoloading was
|
|
|
|
|
|
disabled, the capabilities were mis-detected.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/21/2004 - Shorewall 2.0.2c</b></p>
|
|
|
|
|
|
One problem corrected:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li> DNAT rules with a dynamic source zone don't work
|
|
|
|
|
|
properly. When used, these rules cause the rule to be checked
|
|
|
|
|
|
against ALL input, not just input from the designated
|
|
|
|
|
|
zone.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/18/2004 - Shorewall 2.0.2b</b><b> </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Corrects two problems:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Specifying a null common action in /etc/shorewall/actions
|
|
|
|
|
|
(e.g., :REJECT) results in a startup error.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If /var/lib/shorewall does not exist, shorewall start
|
|
|
|
|
|
fails.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/15/2004 - Shorewall 2.0.2a</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Corrects two problems:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Temporary restore files were not being removed from
|
|
|
|
|
|
/var/lib/shorewall. These files have names of the form
|
|
|
|
|
|
'restore-nnnnn'. You can remove files that have
|
|
|
|
|
|
accumulated with the command:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
rm -f
|
|
|
|
|
|
/var/lib/shorewall/restore-[0-9]*<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The restore script did not load kernel modules. The
|
|
|
|
|
|
result was that after a cold load, applications like FTP and
|
|
|
|
|
|
IRC DCC didn't work.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To correct:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
1) Install 2.0.2a<br>
|
|
|
|
|
|
2) "shorewall restart"<br>
|
|
|
|
|
|
3) "shorewall save"</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/13/2004 - Shorewall 2.0.2</b><b> </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since 2.0.1<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The /etc/init.d/shorewall script installed on Debian by
|
|
|
|
|
|
install.sh failed silently due to a missing file
|
|
|
|
|
|
(/usr/share/shorewall/wait4ifup). That file is not part of
|
|
|
|
|
|
the normal Shorewall distribution and is provided by the
|
|
|
|
|
|
Debian maintainer.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A meaningless warning message out of the proxyarp file
|
|
|
|
|
|
processing has been eliminated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall delete" command now correctly removes all
|
|
|
|
|
|
dynamic rules pertaining to the host(s) being deleted. Thanks
|
|
|
|
|
|
to Stefan Engel for this correction.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Issues when migrating from Shorewall 2.0.1 to Shorewall
|
|
|
|
|
|
2.0.2:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Extension Scripts -- In order for extension scripts to
|
|
|
|
|
|
work properly with the new iptables-save/restore integration
|
|
|
|
|
|
(see New Feature 1 below), some change may be required to
|
|
|
|
|
|
your extension scripts. If your extension scripts are
|
|
|
|
|
|
executing commands other than iptables then those commands
|
|
|
|
|
|
must also be written to the restore file (a temporary file in
|
|
|
|
|
|
/var/lib/shorewall that is renamed
|
|
|
|
|
|
/var/lib/shorewall/restore-base at the end of the
|
|
|
|
|
|
operation).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The following functions should be of help:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
A. save_command() -- saves the passed command to the restore
|
|
|
|
|
|
file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
save_command echo
|
|
|
|
|
|
Operation Complete<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
That command would simply write "echo Operation
|
|
|
|
|
|
Complete" to the restore file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
B. run_and_save_command() -- saves the passed command to the
|
|
|
|
|
|
restore file then executes it. The return value is the exit
|
|
|
|
|
|
status of the command.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
run_and_save_command
|
|
|
|
|
|
"echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note that as in this example, when the
|
|
|
|
|
|
command involves file redirection then the entire command
|
|
|
|
|
|
must be enclosed in quotes. This applies to all of the
|
|
|
|
|
|
functions described here.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
C. ensure_and_save_command() -- runs the passed command. If
|
|
|
|
|
|
the command fails, the firewall is restored to it's prior
|
|
|
|
|
|
saved state and the operation is terminated. If the command
|
|
|
|
|
|
succeeds, the command is written to the restore file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Dynamic Zone support -- If you don't need to use the
|
|
|
|
|
|
"shorewall add" and "shorewall delete commands, you should
|
|
|
|
|
|
set DYNAMIC_ZONES=No in /etc/shorewall/shorewall.conf.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall has now been integrated with
|
|
|
|
|
|
iptables-save/iptables-restore to provide very fast start and
|
|
|
|
|
|
restart. The elements of this integration are as follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) The 'shorewall save' command now saves the current
|
|
|
|
|
|
configuration in addition to the current dynamic blacklist.
|
|
|
|
|
|
If you have dynamic zones, you will want to issue 'shorewall
|
|
|
|
|
|
save' when the zones are empty or the current contents of the
|
|
|
|
|
|
zones will be restored by the 'shorewall restore' and
|
|
|
|
|
|
'shorewall -f start' commands.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) The 'shorewall restore' command has been added. This
|
|
|
|
|
|
command restores the configuration at the time of the last
|
|
|
|
|
|
'save'.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
c) The -f (fast) option has been added to 'shorewall start'.
|
|
|
|
|
|
When specified (e.g. 'shorewall -f start'), shorewall will
|
|
|
|
|
|
perform a 'shorewall restore' if there is a saved
|
|
|
|
|
|
configuration. If there is no saved configuration, a normal
|
|
|
|
|
|
'shorewall start' is performed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
d) The /etc/init.d/shorewall script now translates the
|
|
|
|
|
|
'start' command into 'shorewall -f start' so that fast
|
|
|
|
|
|
restart is possible.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
e) When a state-changing command encounters an error and
|
|
|
|
|
|
there is current saved configuration, that configuration will
|
|
|
|
|
|
be restored (currently, the firewall is placed in the
|
|
|
|
|
|
'stopped' state).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
f) If you have previously saved the running configuration and
|
|
|
|
|
|
want Shorewall to discard it, use the 'shorewall forget'
|
|
|
|
|
|
command. WARNING: iptables 1.2.9 is broken with respect to
|
|
|
|
|
|
iptables-save; if your kernel has connection tracking match
|
|
|
|
|
|
support, you must patch iptables 1.2.9 with the iptables
|
|
|
|
|
|
patch availale from the Shorewall errata page.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The previous implementation of dynamic zones was
|
|
|
|
|
|
difficult to maintain. I have changed the code to make
|
|
|
|
|
|
dynamic zones optional under the control of the DYNAMIC_ZONES
|
|
|
|
|
|
option in /etc/shorewall/shorewall.conf.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In earlier Shorewall 2.0 releases, Shorewall searches in
|
|
|
|
|
|
order the following directories for configuration files.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) The directory specified in a 'try' command or specified
|
|
|
|
|
|
using the -c option.<br>
|
|
|
|
|
|
b) /etc/shorewall<br>
|
|
|
|
|
|
c) /usr/share/shorewall<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In this release, the CONFIG_PATH option is added to
|
|
|
|
|
|
shorewall.conf. CONFIG_PATH contains a list of directory
|
|
|
|
|
|
names separated by colons (":"). If not set or set to a null
|
|
|
|
|
|
value (e.g., CONFIG_PATH="") then
|
|
|
|
|
|
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
|
|
|
|
|
|
Now Shorewall searches for shorewall.conf according to the
|
|
|
|
|
|
old rules and for other configuration files as follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) The directory specified in a 'try' command or specified
|
|
|
|
|
|
using the -c option.<br>
|
|
|
|
|
|
b) Each directory in $CONFIG_PATH is searched in
|
|
|
|
|
|
sequence.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In case it is not obvious, your CONFIG_PATH should include
|
|
|
|
|
|
/usr/share/shorewall and your shorewall.conf file must be in
|
|
|
|
|
|
the directory specified via -c or in a try command, in
|
|
|
|
|
|
/etc/shorewall or in /usr/share/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
For distribution packagers, the default CONFIG_PATH is set in
|
|
|
|
|
|
/usr/share/shorewall/configpath. You can customize this file
|
|
|
|
|
|
to have a default that differs from mine.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, in /etc/shorewall/nat a Yes (or yes) in the
|
|
|
|
|
|
LOCAL column would only take effect if the ALL INTERFACES
|
|
|
|
|
|
column also contained Yes or yes. Now, the LOCAL columns
|
|
|
|
|
|
contents are treated independently of the contents of the ALL
|
|
|
|
|
|
INTERFACES column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The folks at Mandrake have created yet another kernel
|
|
|
|
|
|
module naming convention (module names end in "ko.gz"). As a
|
|
|
|
|
|
consequence, beginning with this release, if MODULE_SUFFIX
|
|
|
|
|
|
isn't specified in shorewall.conf, then the default value is
|
|
|
|
|
|
"o gz ko o.gz ko.gz".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An updated bogons file is included in this release.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In /etc/shorewall/rules and in action files generated
|
|
|
|
|
|
from /usr/share/shorewall/action.template, rules that perform
|
|
|
|
|
|
logging can specify an optional "log tag". A log tag is a
|
|
|
|
|
|
string of alphanumeric characters and is specified by
|
|
|
|
|
|
following the log level with ":" and the log tag.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT:info:ftp
|
|
|
|
|
|
net dmz
|
|
|
|
|
|
tcp 21<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The log tag is appended to the log prefix generated by the
|
|
|
|
|
|
LOGPREFIX variable in /etc/shorewall/conf. If "ACCEPT:info"
|
|
|
|
|
|
generates the log prefix "Shorewall:net2dmz:ACCEPT:" then
|
|
|
|
|
|
"ACCEPT:info:ftp" will generate "Shorewall:net2dmz:ACCEPT:ftp
|
|
|
|
|
|
" (note the trailing blank). The maximum length of a log
|
|
|
|
|
|
prefix supported by iptables is 29 characters; if a larger
|
|
|
|
|
|
prefix is generated, Shorewall will issue a warning message
|
|
|
|
|
|
and will truncate the prefix to 29 characters.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new "-q" option has been added to /sbin/shorewall
|
|
|
|
|
|
commands. It causes the start, restart, check and refresh
|
|
|
|
|
|
commands to produce much less output so that warning messages
|
|
|
|
|
|
are more visible (when testing this change, I discovered a
|
|
|
|
|
|
bug where a bogus warning message was being generated).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now uses 'modprobe' to load kernel modules if
|
|
|
|
|
|
that utility is available in the PATH; otherwise, 'insmod' is
|
|
|
|
|
|
used.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is now possible to restrict entries in the
|
|
|
|
|
|
/etc/shorewall/masq file to particular protocols and
|
|
|
|
|
|
destination port(s). Two new columns (PROTO and PORT(S)) have
|
|
|
|
|
|
been added to the file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You want all outgoing SMTP traffic entering the firewall on
|
|
|
|
|
|
eth1 to be sent from eth0 with source IP address
|
|
|
|
|
|
206.124.146.177. You want all other outgoing traffic from
|
|
|
|
|
|
eth1 to be sent from eth0 with source IP address
|
|
|
|
|
|
206.124.146.176.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0 eth1 206.124.146.177
|
|
|
|
|
|
tcp 25<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0 eth1
|
|
|
|
|
|
206.124.146.176<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Assuming that 10.0.0.0/8 is the only host/network connected
|
|
|
|
|
|
to eth1, the progress message at "shorewall start" would
|
|
|
|
|
|
be:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Masqueraded Networks and Hosts:<br>
|
|
|
|
|
|
To 0.0.0.0/0 (tcp 25)
|
|
|
|
|
|
from 10.0.0.0/8 through eth0 using 206.124.146.177<br>
|
|
|
|
|
|
To 0.0.0.0/0 (all) from
|
|
|
|
|
|
10.0.0.0/8 through eth0 using 206.124.146.176<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Two new actions are available in the /etc/shorewall/rules
|
|
|
|
|
|
file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT+ -- Behaves like
|
|
|
|
|
|
ACCEPT with the exception that it exempts matching
|
|
|
|
|
|
connections from subsequent DNAT[-] and REDIRECT[-]
|
|
|
|
|
|
rules.<br>
|
|
|
|
|
|
NONAT --
|
|
|
|
|
|
Exempts matching connections from subsequent DNAT[-] and
|
|
|
|
|
|
REDIRECT[-] rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new extension script 'initdone' has been added. This
|
|
|
|
|
|
script is invoked at the same point as the 'common' script
|
|
|
|
|
|
was previously and is useful for users who mis-used that
|
|
|
|
|
|
script under Shorewall 1.x (the script was intended for
|
|
|
|
|
|
adding rules to the 'common' chain but many users treated it
|
|
|
|
|
|
as a script for adding rules before Shorewall's).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Installing/Upgrading Shorewall on Slackware has been
|
|
|
|
|
|
improved. Slackware users must use the tarball and must
|
|
|
|
|
|
modify settings in the install.sh script before running it as
|
|
|
|
|
|
follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DEST="/etc/rc.d"<br>
|
|
|
|
|
|
INIT="rc.firewall"<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Thanks to Alex Wilms for helping with this change.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/17/2004 - Presentation at LinuxFest NW</b><b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
Today I gave a presentation at LinuxFest NW in Bellingham. The
|
|
|
|
|
|
presentation was entitled "<a href=
|
|
|
|
|
|
"http://lists.shorewall.net/Shorewall_and_the_Enterprise.htm"
|
|
|
|
|
|
target="_blank">Shorewall and the Enterprise</a>" and described
|
|
|
|
|
|
the history of Shorewall and gave an overview of its features.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/5/2004 - Shorewall 2.0.1</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
Problems Corrected since 2.0.0<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Using actions in the manner recommended in the
|
|
|
|
|
|
documentation results in a Warning that the rule is a
|
|
|
|
|
|
policy.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When a zone on a single interface is defined using
|
|
|
|
|
|
/etc/shorewall/hosts, superfluous rules are generated in the
|
|
|
|
|
|
<zone>_frwd chain.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Sean Mathews, a long-standing problem with
|
|
|
|
|
|
Proxy ARP and IPSEC has been corrected. Thanks Sean!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall show log" and "shorewall logwatch"
|
|
|
|
|
|
commands incorrectly displayed type 3 ICMP packets.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Issues when migrating from Shorewall 2.0.0 to Shorewall
|
|
|
|
|
|
2.0.1:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The function of 'norfc1918' is now split between that
|
|
|
|
|
|
option and a new 'nobogons' option.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The rfc1918 file released with Shorewall now contains entries
|
|
|
|
|
|
for only those three address ranges reserved by RFC 1918. A
|
|
|
|
|
|
'nobogons' interface option has been added which handles
|
|
|
|
|
|
bogon source addresses (those which are reserved by the IANA,
|
|
|
|
|
|
those reserved for DHCP auto-configuration and the class C
|
|
|
|
|
|
test-net reserved for testing and documentation examples).
|
|
|
|
|
|
This will allow users to perform RFC 1918 filtering without
|
|
|
|
|
|
having to deal with out of date data from IANA. Those who are
|
|
|
|
|
|
willing to update their /usr/share/shorewall/bogons file
|
|
|
|
|
|
regularly can specify the 'nobogons' option in addition to
|
|
|
|
|
|
'norfc1918'.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The level at which bogon packets are logged is specified in
|
|
|
|
|
|
the new BOGON_LOG_LEVEL variable in shorewall.conf. If that
|
|
|
|
|
|
option is not specified or is specified as empty (e.g,
|
|
|
|
|
|
BOGON_LOG_LEVEL="") then bogon packets whose TARGET is
|
|
|
|
|
|
'logdrop' in /usr/share/shorewall/bogons are logged at the
|
|
|
|
|
|
'info' level.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Support for Bridging Firewalls has been added. For
|
|
|
|
|
|
details, see<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://shorewall.net/bridge.html">http://shorewall.net/bridge.html</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for NETMAP has been added. NETMAP allows NAT to
|
|
|
|
|
|
be defined between two network:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
a.b.c.1 -> x.y.z.1<br>
|
|
|
|
|
|
|
|
|
|
|
|
a.b.c.2 -> x.y.z.2<br>
|
|
|
|
|
|
|
|
|
|
|
|
a.b.c.3 -> x.y.z.3<br>
|
|
|
|
|
|
|
|
|
|
|
|
...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://shorewall.net/netmap.htm">http://shorewall.net/netmap.htm</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /sbin/shorewall program now accepts a "-x" option to
|
|
|
|
|
|
cause iptables to print out the actual packet and byte counts
|
|
|
|
|
|
rather than abbreviated counts such as "13MB".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Commands affected by this are:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall -x show [ <chain>[ <chain> ...] ]<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall -x show tos|mangle<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall -x show nat<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall -x status<br>
|
|
|
|
|
|
|
|
|
|
|
|
shorewall -x monitor [ <interval> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
Shorewall now traps two common zone definition errors:<br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Including the firewall zone in a /etc/shorewall/hosts
|
|
|
|
|
|
record.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Defining an interface for a zone in both
|
|
|
|
|
|
/etc/shorewall/interfaces and /etc/shorewall/hosts.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In the second case, the following will appear during
|
|
|
|
|
|
"shorewall [re]start" or "shorewall check":<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Determining Hosts in Zones...<br>
|
|
|
|
|
|
...<br>
|
|
|
|
|
|
Error: Invalid zone definition
|
|
|
|
|
|
for zone <name of zone><br>
|
|
|
|
|
|
Terminated<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To support bridging, the following options have been
|
|
|
|
|
|
added to entries in /etc/shorewall/hosts:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
norfc1918<br>
|
|
|
|
|
|
|
|
|
|
|
|
nobogons<br>
|
|
|
|
|
|
|
|
|
|
|
|
blacklist<br>
|
|
|
|
|
|
|
|
|
|
|
|
tcpflags<br>
|
|
|
|
|
|
|
|
|
|
|
|
nosmurfs<br>
|
|
|
|
|
|
|
|
|
|
|
|
newnotsyn<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With the exception of 'newnotsyn', these options are only
|
|
|
|
|
|
useful when the entry refers to a bridge port.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
#ZONE
|
|
|
|
|
|
HOST(S) OPTIONS<br>
|
|
|
|
|
|
net
|
|
|
|
|
|
br0:eth0
|
|
|
|
|
|
norfc1918,nobogons,blacklist,tcpflags,nosmurfs</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/14/2004 - Shorewall 2.0.0b </b></p>
|
|
|
|
|
|
Corrects two problems:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Thanks to Sean Mathews, the long-standing problem with
|
|
|
|
|
|
Proxy ARP and IPSEC has been eliminated!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The default value of the ALL INTERFACES column in
|
|
|
|
|
|
/etc/shorewall/nat is documented as 'No' but the default
|
|
|
|
|
|
continued to be 'Yes' as it was in Shorewall 1.4.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/14/2004 - Shorewall 2.0.0a </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Corrects one problem:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Rules of the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<action>
|
|
|
|
|
|
zone1 zone2<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generated a warning stating that the rule was a policy.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/14/2004 - Shorewall 2.0.0</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Dedicated to Agnes Van Slyke Eastep: March 14, 1910 -
|
|
|
|
|
|
February 23, 2004<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since 1.4.10<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A blank USER/GROUP column in /etc/shorewall/tcrules no
|
|
|
|
|
|
longer causes a [re]start error.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'fgrep' utility is no longer required (caused startup
|
|
|
|
|
|
problems on LEAF/Bering).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall add" command no longer inserts rules
|
|
|
|
|
|
before checking of the blacklist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'detectnets' and 'routeback' options may now be used
|
|
|
|
|
|
together with the intended effect.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The following syntax previously produced an error:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DNAT z1!z2,z3
|
|
|
|
|
|
z4...<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since RC2<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>CONTINUE rules now work again.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A comment in the rules file has been corrected.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Issues when migrating from Shorewall 1.4.x to Shorewall
|
|
|
|
|
|
2.0.0:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The 'dropunclean' and 'logunclean' interface options are
|
|
|
|
|
|
no longer supported. If either option is specified in
|
|
|
|
|
|
/etc/shorewall/interfaces, an threatening message will be
|
|
|
|
|
|
generated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_BEFORE_RULES option has been removed from
|
|
|
|
|
|
shorewall.conf. The behavior of Shorewall is as if
|
|
|
|
|
|
NAT_BEFORE_RULES=No had been specified. In other words, DNAT
|
|
|
|
|
|
rules now always take precidence over one-to-one NAT
|
|
|
|
|
|
specifications.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The default value for the ALL INTERFACES column in
|
|
|
|
|
|
/etc/shorewall/nat has changed. In Shorewall 1.*, if the
|
|
|
|
|
|
column was left empty, a value of "Yes" was assumed. This has
|
|
|
|
|
|
been changed so that a value of "No" is now assumed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The following files don't exist in Shorewall 2.0:<br>
|
|
|
|
|
|
/etc/shorewall/common.def<br>
|
|
|
|
|
|
/etc/shorewall/common<br>
|
|
|
|
|
|
/etc/shorewall/icmpdef<br>
|
|
|
|
|
|
/etc/shorewall/action.template (Moved to
|
|
|
|
|
|
/usr/share/shorewall)<br>
|
|
|
|
|
|
/etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The /etc/shorewall/action file now allows an action to be
|
|
|
|
|
|
designated as the "common" action for a particular policy
|
|
|
|
|
|
type by following the action name with ":" and the policy
|
|
|
|
|
|
(DROP, REJECT or ACCEPT).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The file /usr/share/shorewall/actions.std has been added to
|
|
|
|
|
|
define those actions that are released as part of Shorewall.
|
|
|
|
|
|
In that file are two actions as follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Drop:DROP<br>
|
|
|
|
|
|
Reject:REJECT<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The "Drop" action is the common action for DROP policies
|
|
|
|
|
|
while the "Reject" action is the default action for "REJECT"
|
|
|
|
|
|
policies. These actions will be performed on packets prior to
|
|
|
|
|
|
applying the DROP or REJECT policy respectively. In the first
|
|
|
|
|
|
release, the difference between "Reject" and "Drop" is that
|
|
|
|
|
|
"Reject" REJECTs SMB traffic while "Drop" silently drops such
|
|
|
|
|
|
traffic.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
As described above, Shorewall allows a common action for
|
|
|
|
|
|
ACCEPT policies but does not specify such an action in the
|
|
|
|
|
|
default configuration.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If for some reason, you don't wish to have a common DROP or
|
|
|
|
|
|
REJECT action, just include :DROP or :REJECT respectively in
|
|
|
|
|
|
your /etc/shorewall/actions file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The file /usr/share/shorewall/actions.std catalogs the
|
|
|
|
|
|
standard actions and is processed prior to
|
|
|
|
|
|
/etc/shorewall/actions. This causes a large number of actions
|
|
|
|
|
|
to be defined. The files which define these aactions are also
|
|
|
|
|
|
located in /usr/share/shorewall as is the he action template
|
|
|
|
|
|
file (action.template).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
These actions may be used in the ACTION column of the rules
|
|
|
|
|
|
column. So for example, to allow FTP from your loc zone to
|
|
|
|
|
|
your firewall, you would place this rule in
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
#ACTION
|
|
|
|
|
|
SOURCE DEST<br>
|
|
|
|
|
|
AllowFTP
|
|
|
|
|
|
loc
|
|
|
|
|
|
fw<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If you want to redefine any of the Shorewall-defined actions,
|
|
|
|
|
|
simply copy the appropriate action file from
|
|
|
|
|
|
/usr/share/shorewall to /etc/shorewall and modify the copy as
|
|
|
|
|
|
desired. Your modified copy will be used rather than the
|
|
|
|
|
|
original one in /usr/share/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note: The 'dropBcast' and 'dropNonSyn' actions are built into
|
|
|
|
|
|
Shorewall and may not be changed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Beginning with version 2.0.0-Beta2, Shorewall will only
|
|
|
|
|
|
create a chain for those actions that are actually used.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /etc/shorewall directory no longer contains a 'users'
|
|
|
|
|
|
file or a 'usersets' file. Similar functionality is now
|
|
|
|
|
|
available using user-defined actions.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Now, action files created by copying
|
|
|
|
|
|
/usr/share/shorewall/action.template may specify a USER and
|
|
|
|
|
|
or GROUP name/id in the final column just like in the rules
|
|
|
|
|
|
file (see below). It is thus possible to create actions that
|
|
|
|
|
|
control traffic from a list of users and/or groups.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The last column in /etc/shorewall/rules is now labeled
|
|
|
|
|
|
USER/GROUP and may contain:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[!]<user number>[:]<br>
|
|
|
|
|
|
[!]<user name>[:]<br>
|
|
|
|
|
|
[!]:<group number><br>
|
|
|
|
|
|
[!]:<group name><br>
|
|
|
|
|
|
[!]<user number>:<group
|
|
|
|
|
|
number><br>
|
|
|
|
|
|
[!]<user number>:<group
|
|
|
|
|
|
name><br>
|
|
|
|
|
|
[!]<user name>:<group
|
|
|
|
|
|
number><br>
|
|
|
|
|
|
[!]<user name>:<group
|
|
|
|
|
|
name><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is no longer possible to specify rate limiting in the
|
|
|
|
|
|
ACTION column of /etc/shorewall/rules -- you must use the
|
|
|
|
|
|
RATE LIMIT column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Depending on which method you use to upgrade, if you have
|
|
|
|
|
|
your own version of /etc/shorewall/rfc1918, you may have to
|
|
|
|
|
|
take special action to restore it after the upgrade. Look for
|
|
|
|
|
|
/etc/shorewall/rfc1918*, locate the proper file and rename it
|
|
|
|
|
|
back to /etc/shorewall/rfc1918. The contents of that file
|
|
|
|
|
|
will supercede the contents of
|
|
|
|
|
|
/usr/share/shorewall/rfc1918.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>New Features:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The INCLUDE directive now allows absolute file
|
|
|
|
|
|
names.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A 'nosmurfs' interface option has been added to
|
|
|
|
|
|
/etc/shorewall/interfaces. When specified for an interface,
|
|
|
|
|
|
this option causes smurfs (packets with a broadcast address
|
|
|
|
|
|
as their source) to be dropped and optionally logged (based
|
|
|
|
|
|
on the setting of a new SMURF_LOG_LEVEL option in
|
|
|
|
|
|
shorewall.conf).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>fw->fw traffic may now be controlled by Shorewall.
|
|
|
|
|
|
There is no need to define the loopback interface in
|
|
|
|
|
|
/etc/shorewall/interfaces; you simply add a fw->fw policy
|
|
|
|
|
|
and fw->fw rules. If you have neither a fw->fw policy
|
|
|
|
|
|
nor fw->fw rules, all fw->fw traffic is allowed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>There is a new PERSISTENT column in the proxyarp file. A
|
|
|
|
|
|
value of "Yes" in this column means that the route added by
|
|
|
|
|
|
Shorewall for this host will remain after a "shorewall stop"
|
|
|
|
|
|
or "shorewall clear".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>"trace" is now a synonym for "debug" in /sbin/shorewall
|
|
|
|
|
|
commands. So to trace the "start" command, you could
|
|
|
|
|
|
enter:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall trace start 2> /tmp/trace<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The trace information would be written to the file
|
|
|
|
|
|
/tmp/trace.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When defining an ipsec tunnel in /etc/shorewall/tunnels,
|
|
|
|
|
|
if you follow the tunnel type ("ipsec" or "ipsecnet") with
|
|
|
|
|
|
":noah" (e.g., "ipsec:noah"), then Shorewall will only create
|
|
|
|
|
|
rules for ESP (protocol 50) and will not create rules for AH
|
|
|
|
|
|
(protocol 51).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new DISABLE_IPV6 option has been added to
|
|
|
|
|
|
shorewall.conf. When this option is set to "Yes", Shorewall
|
|
|
|
|
|
will set the policy for the IPv6 INPUT, OUTPUT and FORWARD
|
|
|
|
|
|
chains to DROP during "shorewall [re]start" and "shorewall
|
|
|
|
|
|
stop". Regardless of the setting of this variable, "shorewall
|
|
|
|
|
|
clear" will silently attempt to set these policies to
|
|
|
|
|
|
ACCEPT.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If this option is not set in your existing shorewall.conf
|
|
|
|
|
|
then a setting of DISABLE_IPV6=No is assumed in which case,
|
|
|
|
|
|
Shorewall will not touch any IPv6 settings except during
|
|
|
|
|
|
"shorewall clear".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The CONTINUE target is now available in action
|
|
|
|
|
|
definitions. CONTINUE terminates processing of the current
|
|
|
|
|
|
action and returns to the point where that action was
|
|
|
|
|
|
invoked.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/15/2004 - Shorewall 1.4.10c </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Corrects one problem:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
Entries in /etc/shorewall/tcrules with an empty USER/GROUP
|
|
|
|
|
|
column would cause a startup error.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/12/2004 - Shorewall 1.4.10b </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Corrects one problem:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>In the /etc/shorewall/masq entry “<span class=
|
|
|
|
|
|
"quote">eth0:!10.1.1.150 0.0.0.0/0!10.1.0.0/16
|
|
|
|
|
|
10.1.2.16</span>”, the “<span class=
|
|
|
|
|
|
"quote">!10.1.0.0/16</span>” is ignored.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/8/2004 - Shorewall 1.4.10a </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Corrects two problems:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A problem which can cause [re]start to fail inexplicably
|
|
|
|
|
|
while processing /etc/shorewall/masq.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interfaces using the Atheros WiFi card to use the
|
|
|
|
|
|
'maclist' option.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/30/2004 - Shorewall 1.4.10</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The column descriptions in the action.template file did
|
|
|
|
|
|
not match the column headings. That has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The presence of IPV6 addresses on devices generated error
|
|
|
|
|
|
messages during [re]start if ADD_IP_ALIASES=Yes or
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes are specified in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. These messages have been
|
|
|
|
|
|
eliminated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="3">The CONTINUE action in /etc/shorewall/rules now
|
|
|
|
|
|
works correctly. A couple of problems involving rate limiting
|
|
|
|
|
|
have been corrected. These bug fixes courtesy of Steven Jan
|
|
|
|
|
|
Springl.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now tried to avoid sending an ICMP response to
|
|
|
|
|
|
broadcasts and smurfs.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Specifying "-" or "all" in the PROTO column of an action
|
|
|
|
|
|
no longer causes a startup error.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Migragion Issues:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
None.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may
|
|
|
|
|
|
now specify a destination list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
#INTERFACE
|
|
|
|
|
|
|
|
|
|
|
|
SUBNET ADDRESS<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If the list begins with "!" then SNAT will occur only if the
|
|
|
|
|
|
destination IP address is NOT included in the list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output traffic control rules (those with the firewall as
|
|
|
|
|
|
the source) may now be qualified by the effective userid
|
|
|
|
|
|
and/or effective group id of the program generating the
|
|
|
|
|
|
output. This feature is courtesy of Frédéric
|
|
|
|
|
|
LESPEZ.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
A new USER column has been added to /etc/shorewall/tcrules.
|
|
|
|
|
|
It may contain :<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[<user name or
|
|
|
|
|
|
number>]:[<group name or number>]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The colon is optionnal when specifying only a user.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples : john: / john
|
|
|
|
|
|
/ :users / john:users<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "detectnets" interface option has been added for
|
|
|
|
|
|
entries in /etc/shorewall/interfaces. This option
|
|
|
|
|
|
automatically taylors the definition of the zone named in the
|
|
|
|
|
|
ZONE column to include just those hosts that have
|
|
|
|
|
|
routes through the interface named in the INTERFACE column.
|
|
|
|
|
|
The named interface must be UP when Shorewall is
|
|
|
|
|
|
[re]started.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
|
|
|
|
|
|
INTERFACE! </li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/27/2004 - Shorewall 1.4.10 RC3</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The column descriptions in the action.template file did
|
|
|
|
|
|
not match the column headings. That has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The presence of IPV6 addresses on devices generated error
|
|
|
|
|
|
messages during [re]start if ADD_IP_ALIASES=Yes or
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes are specified in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. These messages have been
|
|
|
|
|
|
eliminated.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="3">The CONTINUE action in /etc/shorewall/rules now
|
|
|
|
|
|
works correctly. A couple of problems involving rate limiting
|
|
|
|
|
|
have been corrected. These bug fixes courtesy of Steven Jan
|
|
|
|
|
|
Springl.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now tried to avoid sending an ICMP response to
|
|
|
|
|
|
broadcasts and smurfs.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Migragion Issues:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
None.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may
|
|
|
|
|
|
now specify a destination list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
#INTERFACE
|
|
|
|
|
|
|
|
|
|
|
|
SUBNET ADDRESS<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If the list begins with "!" then SNAT will occur only if the
|
|
|
|
|
|
destination IP address is NOT included in the list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output traffic control rules (those with the firewall as
|
|
|
|
|
|
the source) may now be qualified by the effective userid
|
|
|
|
|
|
and/or effective group id of the program generating the
|
|
|
|
|
|
output. This feature is courtesy of Frédéric
|
|
|
|
|
|
LESPEZ.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
A new USER column has been added to /etc/shorewall/tcrules.
|
|
|
|
|
|
It may contain :<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[<user name or
|
|
|
|
|
|
number>]:[<group name or number>]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The colon is optionnal when specifying only a user.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples : john: / john
|
|
|
|
|
|
/ :users / john:users<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "detectnets" interface option has been added for
|
|
|
|
|
|
entries in /etc/shorewall/interfaces. This option
|
|
|
|
|
|
automatically taylors the definition of the zone named in the
|
|
|
|
|
|
ZONE column to include just those hosts that have
|
|
|
|
|
|
routes through the interface named in the INTERFACE column.
|
|
|
|
|
|
The named interface must be UP when Shorewall is
|
|
|
|
|
|
[re]started.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
|
|
|
|
|
|
INTERFACE! </li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/24/2004 - Shorewall 1.4.10 RC2</b><b> </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The column descriptions in the action.template file did
|
|
|
|
|
|
not match the column headings. That has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The presence of IPV6 addresses on devices generated error
|
|
|
|
|
|
messages during [re]start if ADD_IP_ALIASES=Yes or
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes are specified in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. These messages have been
|
|
|
|
|
|
eliminated.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Migragion Issues:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
None.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may
|
|
|
|
|
|
now specify a destination list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
#INTERFACE
|
|
|
|
|
|
|
|
|
|
|
|
SUBNET ADDRESS<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If the list begins with "!" then SNAT will occur only if the
|
|
|
|
|
|
destination IP address is NOT included in the list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output traffic control rules (those with the firewall as
|
|
|
|
|
|
the source) may now be qualified by the effective userid
|
|
|
|
|
|
and/or effective group id of the program generating the
|
|
|
|
|
|
output. This feature is courtesy of Frédéric
|
|
|
|
|
|
LESPEZ.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
A new USER column has been added to /etc/shorewall/tcrules.
|
|
|
|
|
|
It may contain :<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[<user name or
|
|
|
|
|
|
number>]:[<group name or number>]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The colon is optionnal when specifying only a user.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples : john: / john
|
|
|
|
|
|
/ :users / john:users<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "detectnets" interface option has been added for
|
|
|
|
|
|
entries in /etc/shorewall/interfaces. This option
|
|
|
|
|
|
automatically taylors the definition of the zone named in the
|
|
|
|
|
|
ZONE column to include just those hosts that have
|
|
|
|
|
|
routes through the interface named in the INTERFACE column.
|
|
|
|
|
|
The named interface must be UP when Shorewall is
|
|
|
|
|
|
[re]started.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
|
|
|
|
|
|
INTERFACE!</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/22/2004 - Shorewall 1.4.10 RC1</b><b> </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The column descriptions in the action.template file did
|
|
|
|
|
|
not match the column headings. That has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The presence of IPV6 addresses on devices generated error
|
|
|
|
|
|
messages during [re]start if ADD_IP_ALIASES=Yes or
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes are specified in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. These messages have been
|
|
|
|
|
|
eliminated.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Migragion Issues:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
None.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may
|
|
|
|
|
|
now specify a destination list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
#INTERFACE
|
|
|
|
|
|
|
|
|
|
|
|
SUBNET ADDRESS<br>
|
|
|
|
|
|
|
|
|
|
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If the list begins with "!" then SNAT will occur only if the
|
|
|
|
|
|
destination IP address is NOT included in the list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output traffic control rules (those with the firewall as
|
|
|
|
|
|
the source) may now be qualified by the effective userid
|
|
|
|
|
|
and/or effective group id of the program generating the
|
|
|
|
|
|
output. This feature is courtesy of Frédéric
|
|
|
|
|
|
LESPEZ.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
A new USER column has been added to /etc/shorewall/tcrules.
|
|
|
|
|
|
It may contain :<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[<user name or
|
|
|
|
|
|
number>]:[<group name or number>]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The colon is optionnal when specifying only a user.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples : john: / john
|
|
|
|
|
|
/ :users / john:users <br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/13/2004 - Shorewall 1.4.9</b><b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since version 1.4.8:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>There has been a low continuing level of confusion over
|
|
|
|
|
|
the terms "Source NAT" (SNAT) and "Static NAT". To avoid
|
|
|
|
|
|
future confusion, all instances of "Static NAT" have been
|
|
|
|
|
|
replaced with "One-to-one NAT" in the documentation and
|
|
|
|
|
|
configuration files.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
|
|
|
|
|
reworded for clarity.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
|
|
|
|
|
will no longer produce an error if they attempt to add a rule
|
|
|
|
|
|
that would override a NONE policy. The logic for expanding
|
|
|
|
|
|
these wild-card rules now simply skips those (SOURCE,DEST)
|
|
|
|
|
|
pairs that have a NONE policy.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DNAT rules that also specified SNAT now work reliably.
|
|
|
|
|
|
Previously, there were cases where the SNAT specification was
|
|
|
|
|
|
effectively ignored.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Migration Issues:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
None.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The documentation has been completely rebased to Docbook
|
|
|
|
|
|
XML. The documentation is now released as separate HTML and
|
|
|
|
|
|
XML packages.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To cut down on the number of "Why are these ports closed
|
|
|
|
|
|
rather than stealthed?" questions, the SMB-related rules in
|
|
|
|
|
|
/etc/shorewall/common.def have been changed from 'reject' to
|
|
|
|
|
|
'DROP'.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>For easier identification, packets logged under the
|
|
|
|
|
|
'norfc1918' interface option are now logged out of chains
|
|
|
|
|
|
named 'rfc1918'. Previously, such packets were logged under
|
|
|
|
|
|
chains named 'logdrop'.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Distributors and developers seem to be regularly
|
|
|
|
|
|
inventing new naming conventions for kernel modules. To avoid
|
|
|
|
|
|
the need to change Shorewall code for each new convention,
|
|
|
|
|
|
the MODULE_SUFFIX option has been added to shorewall.conf.
|
|
|
|
|
|
MODULE_SUFFIX may be set to the suffix for module names in
|
|
|
|
|
|
your particular distribution. If MODULE_SUFFIX is not set in
|
|
|
|
|
|
shorewall.conf, Shorewall will use the list "o gz ko
|
|
|
|
|
|
o.gz".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To see what suffix is used by your distribution:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
All of the files listed should have the same suffix
|
|
|
|
|
|
(extension). Set MODULE_SUFFIX to that suffix.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If all files end in ".kzo" then set
|
|
|
|
|
|
MODULE_SUFFIX="kzo"<br>
|
|
|
|
|
|
If all files end in ".kz.o" then set
|
|
|
|
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for user defined rule ACTIONS has been
|
|
|
|
|
|
implemented through two new files:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/actions - used to list the user-defined
|
|
|
|
|
|
ACTIONS.<br>
|
|
|
|
|
|
/etc/shorewall/action.template - For each user defined
|
|
|
|
|
|
<action>, copy this file to
|
|
|
|
|
|
/etc/shorewall/action.<action> and add the appropriate
|
|
|
|
|
|
rules for that <action>. Once an <action> has
|
|
|
|
|
|
been defined, it may be used like any of the builtin ACTIONS
|
|
|
|
|
|
(ACCEPT, DROP, etc.) in /etc/shorewall/rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example: You want an action that logs a packet at the 'info'
|
|
|
|
|
|
level and accepts the connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
LogAndAccept<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You would then copy /etc/shorewall/action.template to
|
|
|
|
|
|
/etc/shorewall/action.LogAndAccept and in that file, you
|
|
|
|
|
|
would add the two rules:<br>
|
|
|
|
|
|
LOG:info<br>
|
|
|
|
|
|
ACCEPT</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
|
|
|
|
|
"Yes" (non-syn TCP packets that are not part of an existing
|
|
|
|
|
|
connection are filtered according to the rules and policies
|
|
|
|
|
|
rather than being dropped). I have made this change for two
|
|
|
|
|
|
reasons:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck"
|
|
|
|
|
|
connections since any timeout during TCP session tear down
|
|
|
|
|
|
results in the firewall dropping all of the retries.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
|
|
|
|
|
|
resulted in lots of confusing messages when a connection got
|
|
|
|
|
|
"stuck". While I could have changed the default value of
|
|
|
|
|
|
LOGNEWNOTSYN to suppress logging, I dislike defaults that
|
|
|
|
|
|
silently throw away packets.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The common.def file now contains an entry that silently
|
|
|
|
|
|
drops ICMP packets with a null source address. Ad Koster
|
|
|
|
|
|
reported a case where these were occuring frequently as a
|
|
|
|
|
|
result of a broken system on his external network.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since version 1.4.8:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>There has been a low continuing level of confusion over
|
|
|
|
|
|
the terms "Source NAT" (SNAT) and "Static NAT". To avoid
|
|
|
|
|
|
future confusion, all instances of "Static NAT" have been
|
|
|
|
|
|
replaced with "One-to-one NAT" in the documentation and
|
|
|
|
|
|
configuration files.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
|
|
|
|
|
reworded for clarity.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
|
|
|
|
|
will no longer produce an error if they attempt to add a rule
|
|
|
|
|
|
that would override a NONE policy. The logic for expanding
|
|
|
|
|
|
these wild-card rules now simply skips those (SOURCE,DEST)
|
|
|
|
|
|
pairs that have a NONE policy.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DNAT rules that also specified SNAT now work reliably.
|
|
|
|
|
|
Previously, there were cases where the SNAT specification was
|
|
|
|
|
|
effectively ignored.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Migration Issues:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p> None.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
New Features:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The documentation has been completely rebased to Docbook
|
|
|
|
|
|
XML. The documentation is now released as separate HTML and
|
|
|
|
|
|
XML packages.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To cut down on the number of "Why are these ports closed
|
|
|
|
|
|
rather than stealthed?" questions, the SMB-related rules in
|
|
|
|
|
|
/etc/shorewall/common.def have been changed from 'reject' to
|
|
|
|
|
|
'DROP'.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>For easier identification, packets logged under the
|
|
|
|
|
|
'norfc1918' interface option are now logged out of chains
|
|
|
|
|
|
named 'rfc1918'. Previously, such packets were logged under
|
|
|
|
|
|
chains named 'logdrop'.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Distributors and developers seem to be regularly
|
|
|
|
|
|
inventing new naming conventions for kernel modules. To avoid
|
|
|
|
|
|
the need to change Shorewall code for each new convention,
|
|
|
|
|
|
the MODULE_SUFFIX option has been added to shorewall.conf.
|
|
|
|
|
|
MODULE_SUFFIX may be set to the suffix for module names in
|
|
|
|
|
|
your particular distribution. If MODULE_SUFFIX is not set in
|
|
|
|
|
|
shorewall.conf, Shorewall will use the list "o gz ko
|
|
|
|
|
|
o.gz".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To see what suffix is used by your distribution:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
All of the files listed should have the same suffix
|
|
|
|
|
|
(extension). Set MODULE_SUFFIX to that suffix.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If all files end in ".kzo" then set
|
|
|
|
|
|
MODULE_SUFFIX="kzo"<br>
|
|
|
|
|
|
If all files end in ".kz.o" then set
|
|
|
|
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for user defined rule ACTIONS has been
|
|
|
|
|
|
implemented through two new files:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/actions - used to list the user-defined
|
|
|
|
|
|
ACTIONS.<br>
|
|
|
|
|
|
/etc/shorewall/action.template - For each user defined
|
|
|
|
|
|
<action>, copy this file to
|
|
|
|
|
|
/etc/shorewall/action.<action> and add the appropriate
|
|
|
|
|
|
rules for that <action>. Once an <action> has
|
|
|
|
|
|
been defined, it may be used like any of the builtin ACTIONS
|
|
|
|
|
|
(ACCEPT, DROP, etc.) in /etc/shorewall/rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example: You want an action that logs a packet at the 'info'
|
|
|
|
|
|
level and accepts the connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
LogAndAccept<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You would then copy /etc/shorewall/action.template to
|
|
|
|
|
|
/etc/shorewall/action.LogAndAccept and in that file, you
|
|
|
|
|
|
would add the two rules:<br>
|
|
|
|
|
|
LOG:info<br>
|
|
|
|
|
|
ACCEPT<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
|
|
|
|
|
"Yes" (non-syn TCP packets that are not part of an existing
|
|
|
|
|
|
connection are filtered according to the rules and policies
|
|
|
|
|
|
rather than being dropped). I have made this change for two
|
|
|
|
|
|
reasons:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck"
|
|
|
|
|
|
connections since any timeout during TCP session tear down
|
|
|
|
|
|
results in the firewall dropping all of the retries.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
|
|
|
|
|
|
resulted in lots of confusing messages when a connection got
|
|
|
|
|
|
"stuck". While I could have changed the default value of
|
|
|
|
|
|
LOGNEWNOTSYN to suppress logging, I dislike defaults that
|
|
|
|
|
|
silently throw away packets.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back
|
|
|
|
|
|
On-line</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Our high-capacity server has been restored to service --
|
|
|
|
|
|
please let <a href="mailto:webmaster@shorewall.net">us</a> know
|
|
|
|
|
|
if you find any problems.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 1</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected since version 1.4.8:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>There has been a low continuing level of confusion over
|
|
|
|
|
|
the terms "Source NAT" (SNAT) and "Static NAT". To avoid
|
|
|
|
|
|
future confusion, all instances of "Static NAT" have been
|
|
|
|
|
|
replaced with "One-to-one NAT" in the documentation and
|
|
|
|
|
|
configuration files.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
|
|
|
|
|
reworded for clarity.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
|
|
|
|
|
will no longer produce an error if they attempt to add a rule
|
|
|
|
|
|
that would override a NONE policy. The logic for expanding
|
|
|
|
|
|
these wild-card rules now simply skips those (SOURCE,DEST)
|
|
|
|
|
|
pairs that have a NONE policy.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Migration Issues:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p> None.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
New Features:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>To cut down on the number of "Why are these ports closed
|
|
|
|
|
|
rather than stealthed?" questions, the SMB-related rules in
|
|
|
|
|
|
/etc/shorewall/common.def have been changed from 'reject' to
|
|
|
|
|
|
'DROP'.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>For easier identification, packets logged under the
|
|
|
|
|
|
'norfc1918' interface option are now logged out of chains
|
|
|
|
|
|
named 'rfc1918'. Previously, such packets were logged under
|
|
|
|
|
|
chains named 'logdrop'.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Distributors and developers seem to be regularly
|
|
|
|
|
|
inventing new naming conventions for kernel modules. To avoid
|
|
|
|
|
|
the need to change Shorewall code for each new convention,
|
|
|
|
|
|
the MODULE_SUFFIX option has been added to shorewall.conf.
|
|
|
|
|
|
MODULE_SUFFIX may be set to the suffix for module names in
|
|
|
|
|
|
your particular distribution. If MODULE_SUFFIX is not set in
|
|
|
|
|
|
shorewall.conf, Shorewall will use the list "o gz ko
|
|
|
|
|
|
o.gz".<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To see what suffix is used by your distribution:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
All of the files listed should have the same suffix
|
|
|
|
|
|
(extension). Set MODULE_SUFFIX to that suffix.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If all files end in ".kzo" then set
|
|
|
|
|
|
MODULE_SUFFIX="kzo"<br>
|
|
|
|
|
|
If all files end in ".kz.o" then set
|
|
|
|
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for user defined rule ACTIONS has been
|
|
|
|
|
|
implemented through two new files:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/actions - used to list the user-defined
|
|
|
|
|
|
ACTIONS.<br>
|
|
|
|
|
|
/etc/shorewall/action.template - For each user defined
|
|
|
|
|
|
<action>, copy this file to
|
|
|
|
|
|
/etc/shorewall/action.<action> and add the appropriate
|
|
|
|
|
|
rules for that <action>. Once an <action> has
|
|
|
|
|
|
been defined, it may be used like any of the builtin ACTIONS
|
|
|
|
|
|
(ACCEPT, DROP, etc.) in /etc/shorewall/rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example: You want an action that logs a packet at the 'info'
|
|
|
|
|
|
level and accepts the connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
LogAndAccept<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You would then copy /etc/shorewall/action.template to
|
|
|
|
|
|
/etc/shorewall/action.LogAndAccept and in that file, you
|
|
|
|
|
|
would add the two rules:<br>
|
|
|
|
|
|
LOG:info<br>
|
|
|
|
|
|
ACCEPT<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
|
|
|
|
|
"Yes" (non-syn TCP packets that are not part of an existing
|
|
|
|
|
|
connection are filtered according to the rules and policies
|
|
|
|
|
|
rather than being dropped). I have made this change for two
|
|
|
|
|
|
reasons:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck"
|
|
|
|
|
|
connections since any timeout during TCP session tear down
|
|
|
|
|
|
results in the firewall dropping all of the retries.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
|
|
|
|
|
|
resulted in lots of confusing messages when a connection got
|
|
|
|
|
|
"stuck". While I could have changed the default value of
|
|
|
|
|
|
LOGNEWNOTSYN to suppress logging, I dislike defaults that
|
|
|
|
|
|
silently throw away packets.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/03/2003 - Support Torch Passed</b></p>
|
|
|
|
|
|
Effective today, I am reducing my participation in the
|
|
|
|
|
|
day-to-day support of Shorewall. As part of this shift to
|
|
|
|
|
|
community-based Shorewall support a new <a href=
|
|
|
|
|
|
"https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">
|
|
|
|
|
|
Shorewall Newbies mailing list</a> has been established to
|
|
|
|
|
|
field questions and problems from new users. I will not monitor
|
|
|
|
|
|
that list personally. I will continue my active development of
|
|
|
|
|
|
Shorewall and will be available via the development list to
|
|
|
|
|
|
handle development issues -- Tom.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/07/2003 - Shorewall 1.4.8<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</b>Problems Corrected since version 1.4.7:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Tuomo Soini has supplied a correction to a problem that
|
|
|
|
|
|
occurs using some versions of 'ash'. The symptom is that
|
|
|
|
|
|
"shorewall start" fails with:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
local: --limit: bad variable name<br>
|
|
|
|
|
|
iptables v1.2.8: Couldn't load match
|
|
|
|
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
|
|
|
|
cannot open shared object file: No such file or
|
|
|
|
|
|
directory<br>
|
|
|
|
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
|
|
|
|
information.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Andres Zhoglo has supplied a correction that avoids
|
|
|
|
|
|
trying to use the multiport match iptables facility on ICMP
|
|
|
|
|
|
rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example of rule that previously caused
|
|
|
|
|
|
"shorewall start" to fail:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
ACCEPT loc $FW
|
|
|
|
|
|
icmp 0,8,11,12<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, if the following error message was issued,
|
|
|
|
|
|
Shorewall was left in an inconsistent state.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Error: Unable to determine the routes through
|
|
|
|
|
|
interface xxx<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has
|
|
|
|
|
|
been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In Shorewall 1.4.2, an optimization was added. This
|
|
|
|
|
|
optimization involved creating a chain named
|
|
|
|
|
|
"<zone>_frwd" for most zones defined using the
|
|
|
|
|
|
/etc/shorewall/hosts file. It has since been discovered that
|
|
|
|
|
|
in many cases these new chains contain redundant rules and
|
|
|
|
|
|
that the "optimization" turns out to be less than optimal.
|
|
|
|
|
|
The implementation has now been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When the MARK value in a tcrules entry is followed by
|
|
|
|
|
|
":F" or ":P", the ":F" or ":P" was previously only applied to
|
|
|
|
|
|
the first Netfilter rule generated by the entry. It is now
|
|
|
|
|
|
applied to all entries.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An incorrect comment concerning Debian's use of the
|
|
|
|
|
|
SUBSYSLOCK option has been removed from shorewall.conf.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, neither the 'routefilter' interface option
|
|
|
|
|
|
nor the ROUTE_FILTER parameter were working properly. This
|
|
|
|
|
|
has been corrected (thanks to Eric Bowles for his analysis
|
|
|
|
|
|
and patch). The definition of the ROUTE_FILTER option has
|
|
|
|
|
|
changed however. Previously, ROUTE_FILTER=Yes was documented
|
|
|
|
|
|
as enabling route filtering on all interfaces (which didn't
|
|
|
|
|
|
work). Beginning with this release, setting ROUTE_FILTER=Yes
|
|
|
|
|
|
will enable route filtering of all interfaces brought up
|
|
|
|
|
|
while Shorewall is started. As a consequence,
|
|
|
|
|
|
ROUTE_FILTER=Yes can coexist with the use of the
|
|
|
|
|
|
'routefilter' option in the interfaces file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If MAC verification was enabled on an interface with a
|
|
|
|
|
|
/32 address and a broadcast address then an error would occur
|
|
|
|
|
|
during startup.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NONE policy's intended use is to suppress the
|
|
|
|
|
|
generating of rules that can't possibly be traversed. This
|
|
|
|
|
|
means that a policy of NONE is inappropriate where the source
|
|
|
|
|
|
or destination zone is $FW or "all". Shorewall now generates
|
|
|
|
|
|
an error message if such a policy is given in
|
|
|
|
|
|
/etc/shorewall/policy. Previously such a policy caused
|
|
|
|
|
|
"shorewall start" to fail.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'routeback' option was broken for wildcard interfaces
|
|
|
|
|
|
(e.g., "tun+"). This has been corrected so that 'routeback'
|
|
|
|
|
|
now works as expected in this case.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Migration Issues:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The definition of the ROUTE_FILTER option in
|
|
|
|
|
|
shorewall.conf has changed as described in item 8) above.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A new QUEUE action has been introduced for rules. QUEUE
|
|
|
|
|
|
allows you to pass connection requests to a user-space filter
|
|
|
|
|
|
such as ftwall (http://p2pwall.sourceforge.net). The ftwall
|
|
|
|
|
|
program allows for effective filtering of p2p applications
|
|
|
|
|
|
such as Kazaa. For example, to use ftwall to filter P2P
|
|
|
|
|
|
clients in the 'loc' zone, you would add the following
|
|
|
|
|
|
rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
QUEUE loc
|
|
|
|
|
|
net tcp<br>
|
|
|
|
|
|
QUEUE loc
|
|
|
|
|
|
net udp<br>
|
|
|
|
|
|
QUEUE loc
|
|
|
|
|
|
fw udp<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You would normally want to place those three rules BEFORE any
|
|
|
|
|
|
ACCEPT rules for loc->net udp or tcp.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note: When the protocol specified is TCP ("tcp", "TCP" or
|
|
|
|
|
|
"6"), Shorewall will only pass connection requests (SYN
|
|
|
|
|
|
packets) to user space. This is for compatibility with
|
|
|
|
|
|
ftwall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A BLACKLISTNEWNONLY option has been added to
|
|
|
|
|
|
shorewall.conf. When this option is set to "Yes", the
|
|
|
|
|
|
blacklists (dynamic and static) are only consulted for new
|
|
|
|
|
|
connection requests. When set to "No" (the default if the
|
|
|
|
|
|
variable is not set), the blacklists are consulted on every
|
|
|
|
|
|
packet.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Setting this option to "No" allows blacklisting to stop
|
|
|
|
|
|
existing connections from a newly blacklisted host but is
|
|
|
|
|
|
more expensive in terms of packet processing time. This is
|
|
|
|
|
|
especially true if the blacklists contain a large number of
|
|
|
|
|
|
entries.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Chain names used in the /etc/shorewall/accounting file
|
|
|
|
|
|
may now begin with a digit ([0-9]) and may contain embedded
|
|
|
|
|
|
dashes ("-").</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/30/2003 - Shorewall 1.4.8 RC1<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
Given the small number of new features and the relatively few
|
|
|
|
|
|
lines of code that were changed, there will be no Beta for
|
|
|
|
|
|
1.4.8.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</b>Problems Corrected since version 1.4.7:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Tuomo Soini has supplied a correction to a problem that
|
|
|
|
|
|
occurs using some versions of 'ash'. The symptom is that
|
|
|
|
|
|
"shorewall start" fails with:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
local: --limit: bad variable name<br>
|
|
|
|
|
|
iptables v1.2.8: Couldn't load match
|
|
|
|
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
|
|
|
|
cannot open shared object file: No such file or
|
|
|
|
|
|
directory<br>
|
|
|
|
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
|
|
|
|
information.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Andres Zhoglo has supplied a correction that avoids
|
|
|
|
|
|
trying to use the multiport match iptables facility on ICMP
|
|
|
|
|
|
rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example of rule that previously caused
|
|
|
|
|
|
"shorewall start" to fail:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
ACCEPT loc $FW
|
|
|
|
|
|
icmp 0,8,11,12<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, if the following error message was issued,
|
|
|
|
|
|
Shorewall was left in an inconsistent state.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Error: Unable to determine the routes through
|
|
|
|
|
|
interface xxx<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has
|
|
|
|
|
|
been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In Shorewall 1.4.2, an optimization was added. This
|
|
|
|
|
|
optimization involved creating a chain named
|
|
|
|
|
|
"<zone>_frwd" for most zones defined using the
|
|
|
|
|
|
/etc/shorewall/hosts file. It has since been discovered that
|
|
|
|
|
|
in many cases these new chains contain redundant rules and
|
|
|
|
|
|
that the "optimization" turns out to be less than optimal.
|
|
|
|
|
|
The implementation has now been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When the MARK value in a tcrules entry is followed by
|
|
|
|
|
|
":F" or ":P", the ":F" or ":P" was previously only applied to
|
|
|
|
|
|
the first Netfilter rule generated by the entry. It is now
|
|
|
|
|
|
applied to all entries.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An incorrect comment concerning Debian's use of the
|
|
|
|
|
|
SYBSYSLOCK option has been removed from shorewall.conf.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, neither the 'routefilter' interface option
|
|
|
|
|
|
nor the ROUTE_FILTER parameter were working properly. This
|
|
|
|
|
|
has been corrected (thanks to Eric Bowles for his analysis
|
|
|
|
|
|
and patch). The definition of the ROUTE_FILTER option has
|
|
|
|
|
|
changed however. Previously, ROUTE_FILTER=Yes was documented
|
|
|
|
|
|
as enabling route filtering on all interfaces (which didn't
|
|
|
|
|
|
work). Beginning with this release, setting ROUTE_FILTER=Yes
|
|
|
|
|
|
will enable route filtering of all interfaces brought up
|
|
|
|
|
|
while Shorewall is started. As a consequence,
|
|
|
|
|
|
ROUTE_FILTER=Yes can coexist with the use of the
|
|
|
|
|
|
'routefilter' option in the interfaces file.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Migration Issues:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The definition of the ROUTE_FILTER option in
|
|
|
|
|
|
shorewall.conf has changed as described in item 8) above.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
New Features:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A new QUEUE action has been introduced for rules. QUEUE
|
|
|
|
|
|
allows you to pass connection requests to a user-space filter
|
|
|
|
|
|
such as ftwall (http://p2pwall.sourceforge.net). The ftwall
|
|
|
|
|
|
program allows for effective filtering of p2p applications
|
|
|
|
|
|
such as Kazaa. For example, to use ftwall to filter P2P
|
|
|
|
|
|
clients in the 'loc' zone, you would add the following
|
|
|
|
|
|
rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
QUEUE loc
|
|
|
|
|
|
net tcp<br>
|
|
|
|
|
|
QUEUE loc
|
|
|
|
|
|
net udp<br>
|
|
|
|
|
|
QUEUE loc
|
|
|
|
|
|
fw udp<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
You would normally want to place those three rules BEFORE any
|
|
|
|
|
|
ACCEPT rules for loc->net udp or tcp.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note: When the protocol specified is TCP ("tcp", "TCP" or
|
|
|
|
|
|
"6"), Shorewall will only pass connection requests (SYN
|
|
|
|
|
|
packets) to user space. This is for compatibility with
|
|
|
|
|
|
ftwall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A BLACKLISTNEWNONLY option has been added to
|
|
|
|
|
|
shorewall.conf. When this option is set to "Yes", the
|
|
|
|
|
|
blacklists (dynamic and static) are only consulted for new
|
|
|
|
|
|
connection requests. When set to "No" (the default if the
|
|
|
|
|
|
variable is not set), the blacklists are consulted on every
|
|
|
|
|
|
packet.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Setting this option to "No" allows blacklisting to stop
|
|
|
|
|
|
existing connections from a newly blacklisted host but is
|
|
|
|
|
|
more expensive in terms of packet processing time. This is
|
|
|
|
|
|
especially true if the blacklists contain a large number of
|
|
|
|
|
|
entries.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Chain names used in the /etc/shorewall/accounting file
|
|
|
|
|
|
may now begin with a digit ([0-9]) and may contain embedded
|
|
|
|
|
|
dashes ("-").<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper
|
|
|
|
|
|
bag awards</b> <b><img style=
|
|
|
|
|
|
"border: 0px solid ; width: 50px; height: 80px;" src=
|
|
|
|
|
|
"images/j0233056.gif" title="" alt="" align="middle">Shorewall
|
|
|
|
|
|
1.4.7c released.</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The saga with "<zone>_frwd" chains continues. The
|
|
|
|
|
|
1.4.7c script produces a ruleset that should work for
|
|
|
|
|
|
everyone even if it is not quite optimal. My apologies for
|
|
|
|
|
|
this ongoing mess.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/24/2003 - Shorewall 1.4.7b</b></p>
|
|
|
|
|
|
This is a bugfx rollup of the 1.4.7a fixes plus:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The fix for problem 5 in 1.4.7a was wrong with the result
|
|
|
|
|
|
that "<zone>_frwd" chains might contain too few rules.
|
|
|
|
|
|
That wrong code is corrected in this release.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/21/2003 - Shorewall 1.4.7a<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This is a bugfix rollup of the following problem
|
|
|
|
|
|
corrections:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Tuomo Soini has supplied a correction to a problem that
|
|
|
|
|
|
occurs using some versions of 'ash'. The symptom is that
|
|
|
|
|
|
"shorewall start" fails with:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
local: --limit: bad variable name<br>
|
|
|
|
|
|
iptables v1.2.8: Couldn't load match
|
|
|
|
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
|
|
|
|
cannot open shared object file: No such file or
|
|
|
|
|
|
directory<br>
|
|
|
|
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
|
|
|
|
information.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Andres Zhoglo has supplied a correction that avoids
|
|
|
|
|
|
trying to use the multiport match iptables facility on ICMP
|
|
|
|
|
|
rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example of rule that previously caused
|
|
|
|
|
|
"shorewall start" to fail:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
ACCEPT loc $FW
|
|
|
|
|
|
icmp 0,8,11,12<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, if the following error message was issued,
|
|
|
|
|
|
Shorewall was left in an inconsistent state.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Error: Unable to determine the routes through
|
|
|
|
|
|
interface xxx<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has
|
|
|
|
|
|
been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In Shorewall 1.4.2, an optimization was added. This
|
|
|
|
|
|
optimization involved creating a chain named
|
|
|
|
|
|
"<zone>_frwd" for most zones defined using the
|
|
|
|
|
|
/etc/shorewall/hosts file. It has since been discovered that
|
|
|
|
|
|
in many cases these new chains contain redundant rules and
|
|
|
|
|
|
that the "optimization" turns out to be less than optimal.
|
|
|
|
|
|
The implementation has now been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When the MARK value in a tcrules entry is followed by
|
|
|
|
|
|
":F" or ":P", the ":F" or ":P" was previously only applied to
|
|
|
|
|
|
the first Netfilter rule generated by the entry. It is now
|
|
|
|
|
|
applied to all entries.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/06/2003 - Shorewall 1.4.7</b><b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font
|
|
|
|
|
|
were corrected since 1.4.7 RC2).</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
|
|
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
|
|
|
|
(previously named "Dynamic Chain").</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
|
|
|
|
|
|
again.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop'
|
|
|
|
|
|
commands now delete any existing rules for the subject IP
|
|
|
|
|
|
address before adding a new DROP or REJECT rule. Previously,
|
|
|
|
|
|
there could be many rules for the same IP address in the
|
|
|
|
|
|
dynamic chain so that multiple 'allow' commands were required
|
|
|
|
|
|
to re-enable traffic to/from the address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
|
|
|
|
|
|
following entry in /etc/shorewall/masq resulted in a startup
|
|
|
|
|
|
error:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
eth0 eth1
|
|
|
|
|
|
206.124.146.20-206.124.146.24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall previously choked over IPV6 addresses
|
|
|
|
|
|
configured on interfaces in contexts where Shorewall needed
|
|
|
|
|
|
to detect something about the interface (such as when
|
|
|
|
|
|
"detect" appears in the BROADCAST column of the
|
|
|
|
|
|
/etc/shorewall/interfaces file).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall will now load module files that are formed from
|
|
|
|
|
|
the module name by appending ".o.gz".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When Shorewall adds a route to a proxy ARP host and such
|
|
|
|
|
|
a route already exists, two routes resulted previously. This
|
|
|
|
|
|
has been corrected so that the existing route is replaced if
|
|
|
|
|
|
it already exists.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The rfc1918 file has been updated to reflect recent
|
|
|
|
|
|
allocations.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The documentation of the USER SET column in the rules
|
|
|
|
|
|
file has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If there is no policy defined for the zones specified in
|
|
|
|
|
|
a rule, the firewall script previously encountered a shell
|
|
|
|
|
|
syntax error:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
[: NONE:
|
|
|
|
|
|
unexpected operator<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Now, the absence of a policy generates an error message and
|
|
|
|
|
|
the firewall is stopped:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
No policy defined
|
|
|
|
|
|
from zone <source> to zone <dest><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, if neither /etc/shorewall/common nor
|
|
|
|
|
|
/etc/shorewall/common.def existed, Shorewall would fail to
|
|
|
|
|
|
start and would not remove the lock file. Failure to remove
|
|
|
|
|
|
the lock file resulted in the following during subsequent
|
|
|
|
|
|
attempts to start:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Loading
|
|
|
|
|
|
/usr/share/shorewall/functions...<br>
|
|
|
|
|
|
Processing /etc/shorewall/params ...<br>
|
|
|
|
|
|
Processing
|
|
|
|
|
|
/etc/shorewall/shorewall.conf...<br>
|
|
|
|
|
|
Giving up on lock file
|
|
|
|
|
|
/var/lib/shorewall/lock<br>
|
|
|
|
|
|
Shorewall Not Started<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall now reports a fatal error if neither of these two
|
|
|
|
|
|
files exist and correctly removes the lock fille.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The order of processing the various options has been
|
|
|
|
|
|
changed such that blacklist entries now take precedence over
|
|
|
|
|
|
the 'dhcp' <span style="font-weight: bold;">i</span>nterface
|
|
|
|
|
|
setting.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The log message generated from the 'logunclean' interface
|
|
|
|
|
|
option has been changed to reflect a disposition of LOG
|
|
|
|
|
|
rather than DROP.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">When a user name and/or
|
|
|
|
|
|
a group name was specified in the USER SET column and the
|
|
|
|
|
|
destination zone was qualified with a IP address, the user
|
|
|
|
|
|
and/or group name was not being used to qualify the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT fw net:192.0.2.12 tcp 23 - -
|
|
|
|
|
|
- vladimir:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">The /etc/shorewall/masq
|
|
|
|
|
|
file has had the spurious "/" character at the front
|
|
|
|
|
|
removed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span></li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall IP Traffic Accounting has changed since
|
|
|
|
|
|
snapshot 20030813 -- see the <a href=
|
|
|
|
|
|
"Accounting.html">Accounting Page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Uset Set capability introduced in SnapShot 20030821
|
|
|
|
|
|
has changed -- see the <a href="UserSets.html">User Set
|
|
|
|
|
|
page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The per-interface Dynamic Blacklisting facility
|
|
|
|
|
|
introduced in the first post-1.4.6 Snapshot has been removed.
|
|
|
|
|
|
The facility had too many idiosyncrasies for dial-up users to
|
|
|
|
|
|
be a viable part of Shorewall.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include
|
|
|
|
|
|
a comma-separated list of addresses and/or address ranges.
|
|
|
|
|
|
Netfilter will use all listed addresses/ranges in round-robin
|
|
|
|
|
|
fashion. \</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/accounting file has been added to allow
|
|
|
|
|
|
for traffic accounting. See the <a href=
|
|
|
|
|
|
"Accounting.html">accounting documentation</a> for a
|
|
|
|
|
|
description of this facility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
|
|
|
|
/etc/shorewall/maclist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
|
|
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and
|
|
|
|
|
|
REDIRECT rules, rate limiting occurs in the nat table DNAT
|
|
|
|
|
|
rule; the corresponding ACCEPT rule in the filter table is
|
|
|
|
|
|
not rate limited. If you want to limit the filter table rule,
|
|
|
|
|
|
you will need o create two rules; a DNAT- rule and an ACCEPT
|
|
|
|
|
|
rule which can be rate-limited separately.<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, the limit will apply to each pair of zones
|
|
|
|
|
|
individually rather than as a single limit for all pairs of
|
|
|
|
|
|
covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a rate limit,<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<
|
|
|
|
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<rate> is the sustained
|
|
|
|
|
|
rate per <interval><br>
|
|
|
|
|
|
<interval> is "sec" or
|
|
|
|
|
|
"min"<br>
|
|
|
|
|
|
<burst> is the largest
|
|
|
|
|
|
burst accepted within an <interval>. If not given, the
|
|
|
|
|
|
default of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no white space between the ACTION and "<" nor
|
|
|
|
|
|
there may be any white space within the burst specification.
|
|
|
|
|
|
If you want to specify logging of a rate-limited rule, the
|
|
|
|
|
|
":" and log level comes after the ">" (e.g.,
|
|
|
|
|
|
ACCEPT<2/sec:4>:info ).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) A new RATE LIMIT column has been added to the
|
|
|
|
|
|
/etc/shorewall/rules file. You may specify the rate limit
|
|
|
|
|
|
there in the format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate>/<interval>[:<burst>]<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<br>
|
|
|
|
|
|
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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Multiple chains may now be displayed in one "shorewall
|
|
|
|
|
|
show" command (e.g., shorewall show INPUT FORWARD
|
|
|
|
|
|
OUTPUT).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output rules (those with $FW as the SOURCE) may now be
|
|
|
|
|
|
limited to a set of local users and/or groups. See <a href=
|
|
|
|
|
|
"UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
|
|
|
|
details.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/02/2003 - Shorewall 1.4.7 RC2</b><b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font
|
|
|
|
|
|
were corrected since 1.4.7 RC 1).</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
|
|
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
|
|
|
|
(previously named "Dynamic Chain").</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
|
|
|
|
|
|
again.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop'
|
|
|
|
|
|
commands now delete any existing rules for the subject IP
|
|
|
|
|
|
address before adding a new DROP or REJECT rule. Previously,
|
|
|
|
|
|
there could be many rules for the same IP address in the
|
|
|
|
|
|
dynamic chain so that multiple 'allow' commands were required
|
|
|
|
|
|
to re-enable traffic to/from the address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
|
|
|
|
|
|
following entry in /etc/shorewall/masq resulted in a startup
|
|
|
|
|
|
error:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
eth0 eth1
|
|
|
|
|
|
206.124.146.20-206.124.146.24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall previously choked over IPV6 addresses
|
|
|
|
|
|
configured on interfaces in contexts where Shorewall needed
|
|
|
|
|
|
to detect something about the interface (such as when
|
|
|
|
|
|
"detect" appears in the BROADCAST column of the
|
|
|
|
|
|
/etc/shorewall/interfaces file).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall will now load module files that are formed from
|
|
|
|
|
|
the module name by appending ".o.gz".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When Shorewall adds a route to a proxy ARP host and such
|
|
|
|
|
|
a route already exists, two routes resulted previously. This
|
|
|
|
|
|
has been corrected so that the existing route is replaced if
|
|
|
|
|
|
it already exists.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The rfc1918 file has been updated to reflect recent
|
|
|
|
|
|
allocations.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">The documentation of the
|
|
|
|
|
|
USER SET column in the rules file has been
|
|
|
|
|
|
corrected.</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">If there is no policy
|
|
|
|
|
|
defined for the zones specified in a rule, the firewall
|
|
|
|
|
|
script previously encountered a shell syntax error:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
[: NONE:
|
|
|
|
|
|
unexpected operator<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Now, the absence of a policy generates an error message and
|
|
|
|
|
|
the firewall is stopped:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
No policy defined
|
|
|
|
|
|
from zone <source> to zone <dest><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">Previously, if neither
|
|
|
|
|
|
/etc/shorewall/common nor /etc/shorewall/common.def existed,
|
|
|
|
|
|
Shorewall would fail to start and would not remove the lock
|
|
|
|
|
|
file. Failure to remove the lock file resulted in the
|
|
|
|
|
|
following during subsequent attempts to start:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
Loading
|
|
|
|
|
|
/usr/share/shorewall/functions...<br>
|
|
|
|
|
|
Processing /etc/shorewall/params ...<br>
|
|
|
|
|
|
Processing
|
|
|
|
|
|
/etc/shorewall/shorewall.conf...<br>
|
|
|
|
|
|
Giving up on lock file
|
|
|
|
|
|
/var/lib/shorewall/lock<br>
|
|
|
|
|
|
Shorewall Not Started<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall now reports a fatal error if neither of these two
|
|
|
|
|
|
files exist and correctly removes the lock fille.</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">The order of processing
|
|
|
|
|
|
the various options has been changed such that blacklist
|
|
|
|
|
|
entries now take precedence over the 'dhcp' interface
|
|
|
|
|
|
setting.</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">The log message
|
|
|
|
|
|
generated from the 'logunclean' interface option has been
|
|
|
|
|
|
changed to reflect a disposition of LOG rather than
|
|
|
|
|
|
DROP.</span></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">The RFC1918 file has
|
|
|
|
|
|
been updated to reflect recent IANA allocations.<br>
|
|
|
|
|
|
</span></li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall IP Traffic Accounting has changed since
|
|
|
|
|
|
snapshot 20030813 -- see the <a href=
|
|
|
|
|
|
"Accounting.html">Accounting Page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Uset Set capability introduced in SnapShot 20030821
|
|
|
|
|
|
has changed -- see the <a href="UserSets.html">User Set
|
|
|
|
|
|
page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The per-interface Dynamic Blacklisting facility
|
|
|
|
|
|
introduced in the first post-1.4.6 Snapshot has been removed.
|
|
|
|
|
|
The facility had too many idiosyncrasies for dial-up users to
|
|
|
|
|
|
be a viable part of Shorewall.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include
|
|
|
|
|
|
a comma-separated list of addresses and/or address ranges.
|
|
|
|
|
|
Netfilter will use all listed addresses/ranges in round-robin
|
|
|
|
|
|
fashion. \</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/accounting file has been added to allow
|
|
|
|
|
|
for traffic accounting. See the <a href=
|
|
|
|
|
|
"Accounting.html">accounting documentation</a> for a
|
|
|
|
|
|
description of this facility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
|
|
|
|
/etc/shorewall/maclist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
|
|
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and
|
|
|
|
|
|
REDIRECT rules, rate limiting occurs in the nat table DNAT
|
|
|
|
|
|
rule; the corresponding ACCEPT rule in the filter table is
|
|
|
|
|
|
not rate limited. If you want to limit the filter table rule,
|
|
|
|
|
|
you will need o create two rules; a DNAT- rule and an ACCEPT
|
|
|
|
|
|
rule which can be rate-limited separately.<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, the limit will apply to each pair of zones
|
|
|
|
|
|
individually rather than as a single limit for all pairs of
|
|
|
|
|
|
covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a rate limit,<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<
|
|
|
|
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<rate> is the sustained
|
|
|
|
|
|
rate per <interval><br>
|
|
|
|
|
|
<interval> is "sec" or
|
|
|
|
|
|
"min"<br>
|
|
|
|
|
|
<burst> is the largest
|
|
|
|
|
|
burst accepted within an <interval>. If not given, the
|
|
|
|
|
|
default of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no white space between the ACTION and "<" nor
|
|
|
|
|
|
there may be any white space within the burst specification.
|
|
|
|
|
|
If you want to specify logging of a rate-limited rule, the
|
|
|
|
|
|
":" and log level comes after the ">" (e.g.,
|
|
|
|
|
|
ACCEPT<2/sec:4>:info ).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) A new RATE LIMIT column has been added to the
|
|
|
|
|
|
/etc/shorewall/rules file. You may specify the rate limit
|
|
|
|
|
|
there in the format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate>/<interval>[:<burst>]<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<br>
|
|
|
|
|
|
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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Multiple chains may now be displayed in one "shorewall
|
|
|
|
|
|
show" command (e.g., shorewall show INPUT FORWARD
|
|
|
|
|
|
OUTPUT).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output rules (those with $FW as the SOURCE) may now be
|
|
|
|
|
|
limited to a set of local users and/or groups. See <a href=
|
|
|
|
|
|
"UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
|
|
|
|
details.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/18/2003 - Shorewall 1.4.7 RC 1</b><b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font
|
|
|
|
|
|
were corrected since 1.4.7 Beta 1).</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
|
|
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
|
|
|
|
(previously named "Dynamic Chain").</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
|
|
|
|
|
|
again.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop'
|
|
|
|
|
|
commands now delete any existing rules for the subject IP
|
|
|
|
|
|
address before adding a new DROP or REJECT rule. Previously,
|
|
|
|
|
|
there could be many rules for the same IP address in the
|
|
|
|
|
|
dynamic chain so that multiple 'allow' commands were required
|
|
|
|
|
|
to re-enable traffic to/from the address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
|
|
|
|
|
|
following entry in /etc/shorewall/masq resulted in a startup
|
|
|
|
|
|
error:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
eth0 eth1
|
|
|
|
|
|
206.124.146.20-206.124.146.24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall previously choked over IPV6 addresses
|
|
|
|
|
|
configured on interfaces in contexts where Shorewall needed
|
|
|
|
|
|
to detect something about the interface (such as when
|
|
|
|
|
|
"detect" appears in the BROADCAST column of the
|
|
|
|
|
|
/etc/shorewall/interfaces file).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall will now load module files that are formed from
|
|
|
|
|
|
the module name by appending ".o.gz".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style="font-weight: bold;">When Shorewall adds a route to
|
|
|
|
|
|
a proxy ARP host and such a route already exists, two routes
|
|
|
|
|
|
resulted previously. This has been corrected so that the
|
|
|
|
|
|
existing route is replaced if it already exists.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">The rfc1918 file has
|
|
|
|
|
|
been updated to reflect recent allocations.</span><br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall IP Traffic Accounting has changed since
|
|
|
|
|
|
snapshot 20030813 -- see the <a href=
|
|
|
|
|
|
"Accounting.html">Accounting Page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Uset Set capability introduced in SnapShot 20030821
|
|
|
|
|
|
has changed -- see the <a href="UserSets.html">User Set
|
|
|
|
|
|
page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The per-interface Dynamic Blacklisting facility
|
|
|
|
|
|
introduced in the first post-1.4.6 Snapshot has been removed.
|
|
|
|
|
|
The facility had too many idiosyncrasies for dial-up users to
|
|
|
|
|
|
be a viable part of Shorewall.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include
|
|
|
|
|
|
a comma-separated list of addresses and/or address ranges.
|
|
|
|
|
|
Netfilter will use all listed addresses/ranges in round-robin
|
|
|
|
|
|
fashion. \</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/accounting file has been added to allow
|
|
|
|
|
|
for traffic accounting. See the <a href=
|
|
|
|
|
|
"Accounting.html">accounting documentation</a> for a
|
|
|
|
|
|
description of this facility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
|
|
|
|
/etc/shorewall/maclist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
|
|
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and
|
|
|
|
|
|
REDIRECT rules, rate limiting occurs in the nat table DNAT
|
|
|
|
|
|
rule; the corresponding ACCEPT rule in the filter table is
|
|
|
|
|
|
not rate limited. If you want to limit the filter table rule,
|
|
|
|
|
|
you will need o create two rules; a DNAT- rule and an ACCEPT
|
|
|
|
|
|
rule which can be rate-limited separately.<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, the limit will apply to each pair of zones
|
|
|
|
|
|
individually rather than as a single limit for all pairs of
|
|
|
|
|
|
covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a rate limit,<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<
|
|
|
|
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<rate> is the sustained
|
|
|
|
|
|
rate per <interval><br>
|
|
|
|
|
|
<interval> is "sec" or
|
|
|
|
|
|
"min"<br>
|
|
|
|
|
|
<burst> is the largest
|
|
|
|
|
|
burst accepted within an <interval>. If not given, the
|
|
|
|
|
|
default of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no white space between the ACTION and "<" nor
|
|
|
|
|
|
there may be any white space within the burst specification.
|
|
|
|
|
|
If you want to specify logging of a rate-limited rule, the
|
|
|
|
|
|
":" and log level comes after the ">" (e.g.,
|
|
|
|
|
|
ACCEPT<2/sec:4>:info ).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) A new RATE LIMIT column has been added to the
|
|
|
|
|
|
/etc/shorewall/rules file. You may specify the rate limit
|
|
|
|
|
|
there in the format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate>/<interval>[:<burst>]<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<br>
|
|
|
|
|
|
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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Multiple chains may now be displayed in one "shorewall
|
|
|
|
|
|
show" command (e.g., shorewall show INPUT FORWARD
|
|
|
|
|
|
OUTPUT).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output rules (those with $FW as the SOURCE) may now be
|
|
|
|
|
|
limited to a set of local users and/or groups. See <a href=
|
|
|
|
|
|
"UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
|
|
|
|
details.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/15/2003 - Shorewall 1.4.7 Beta 2</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font
|
|
|
|
|
|
were corrected since 1.4.7 Beta 1).</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
|
|
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
|
|
|
|
(previously named "Dynamic Chain").</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
|
|
|
|
|
|
again.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="7" style="font-weight: bold;">The 'shorewall
|
|
|
|
|
|
reject' and 'shorewall drop' commands now delete any existing
|
|
|
|
|
|
rules for the subject IP address before adding a new DROP or
|
|
|
|
|
|
REJECT rule. Previously, there could be many rules for the
|
|
|
|
|
|
same IP address in the dynamic chain so that multiple 'allow'
|
|
|
|
|
|
commands were required to re-enable traffic to/from the
|
|
|
|
|
|
address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style="font-weight: bold;">When ADD_SNAT_ALIASES=Yes in
|
|
|
|
|
|
shorewall.conf, the following entry in /etc/shorewall/masq
|
|
|
|
|
|
resulted in a startup error:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
eth0 eth1
|
|
|
|
|
|
206.124.146.20-206.124.146.24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style="font-weight: bold;">Shorewall previously choked
|
|
|
|
|
|
over IPV6 addresses configured on interfaces in contexts
|
|
|
|
|
|
where Shorewall needed to detect something about the
|
|
|
|
|
|
interface (such as when "detect" appears in the BROADCAST
|
|
|
|
|
|
column of the /etc/shorewall/interfaces file).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><span style="font-weight: bold;">Shorewall will now load
|
|
|
|
|
|
module files that are formed from the module name by
|
|
|
|
|
|
appending ".o.gz".</span><br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall IP Traffic Accounting has changed since
|
|
|
|
|
|
snapshot 20030813 -- see the <a href=
|
|
|
|
|
|
"Accounting.html">Accounting Page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Uset Set capability introduced in SnapShot 20030821
|
|
|
|
|
|
has changed -- see the <a href="UserSets.html">User Set
|
|
|
|
|
|
page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The per-interface Dynamic Blacklisting facility
|
|
|
|
|
|
introduced in the first post-1.4.6 Snapshot has been removed.
|
|
|
|
|
|
The facility had too many idiosyncrasies for dial-up users to
|
|
|
|
|
|
be a viable part of Shorewall.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include
|
|
|
|
|
|
a comma-separated list of addresses and/or address ranges.
|
|
|
|
|
|
Netfilter will use all listed addresses/ranges in round-robin
|
|
|
|
|
|
fashion. \</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/accounting file has been added to allow
|
|
|
|
|
|
for traffic accounting. See the <a href=
|
|
|
|
|
|
"Accounting.html">accounting documentation</a> for a
|
|
|
|
|
|
description of this facility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
|
|
|
|
/etc/shorewall/maclist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
|
|
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and
|
|
|
|
|
|
REDIRECT rules, rate limiting occurs in the nat table DNAT
|
|
|
|
|
|
rule; the corresponding ACCEPT rule in the filter table is
|
|
|
|
|
|
not rate limited. If you want to limit the filter table rule,
|
|
|
|
|
|
you will need o create two rules; a DNAT- rule and an ACCEPT
|
|
|
|
|
|
rule which can be rate-limited separately.<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, the limit will apply to each pair of zones
|
|
|
|
|
|
individually rather than as a single limit for all pairs of
|
|
|
|
|
|
covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a rate limit,<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<
|
|
|
|
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<rate> is the sustained
|
|
|
|
|
|
rate per <interval><br>
|
|
|
|
|
|
<interval> is "sec" or
|
|
|
|
|
|
"min"<br>
|
|
|
|
|
|
<burst> is the largest
|
|
|
|
|
|
burst accepted within an <interval>. If not given, the
|
|
|
|
|
|
default of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no white space between the ACTION and "<" nor
|
|
|
|
|
|
there may be any white space within the burst specification.
|
|
|
|
|
|
If you want to specify logging of a rate-limited rule, the
|
|
|
|
|
|
":" and log level comes after the ">" (e.g.,
|
|
|
|
|
|
ACCEPT<2/sec:4>:info ).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) A new RATE LIMIT column has been added to the
|
|
|
|
|
|
/etc/shorewall/rules file. You may specify the rate limit
|
|
|
|
|
|
there in the format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate>/<interval>[:<burst>]<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<br>
|
|
|
|
|
|
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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Multiple chains may now be displayed in one "shorewall
|
|
|
|
|
|
show" command (e.g., shorewall show INPUT FORWARD
|
|
|
|
|
|
OUTPUT).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output rules (those with $FW as the SOURCE) may now be
|
|
|
|
|
|
limited to a set of local users and/or groups. See <a href=
|
|
|
|
|
|
"UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
|
|
|
|
details.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/27/2003 - Shorewall Mirror in Australia</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to Dave Kempe and Solutions First (<a href=
|
|
|
|
|
|
"http://www.solutionsfirst.com.au"><font size=
|
|
|
|
|
|
"3">http://www.solutionsfirst.com.au</font></a>), there is now
|
|
|
|
|
|
a Shorewall Mirror in Australia:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
|
|
|
|
<a href="http://www.shorewall.com.au" target="_top"><font
|
|
|
|
|
|
size="3">http://www.shorewall.com.au</font></a><br>
|
|
|
|
|
|
<a href="ftp://ftp.shorewall.com.au"><font size=
|
|
|
|
|
|
"3">ftp://ftp.shorewall.com.au</font></a>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/26/2003 - French Version of the Shorewall Setup
|
|
|
|
|
|
Guide </b></p>
|
|
|
|
|
|
Thanks to Fabien <font size="3">Demassieux, there is now a <a
|
|
|
|
|
|
href="shorewall_setup_guide_fr.htm">French translation of the
|
|
|
|
|
|
Shorewall Setup Guide</a>. Merci Beacoup, Fabien!</font>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/25/2003 - Shorewall 1.4.7 Beta 1</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
|
|
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
|
|
|
|
(previously named "Dynamic Chain").</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
|
|
|
|
|
|
again.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall IP Traffic Accounting has changed since
|
|
|
|
|
|
snapshot 20030813 -- see the <a href=
|
|
|
|
|
|
"Accounting.html">Accounting Page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Uset Set capability introduced in SnapShot 20030821
|
|
|
|
|
|
has changed -- see the <a href="UserSets.html">User Set
|
|
|
|
|
|
page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The per-interface Dynamic Blacklisting facility
|
|
|
|
|
|
introduced in the first post-1.4.6 Snapshot has been removed.
|
|
|
|
|
|
The facility had too many idiosyncrasies for dial-up users to
|
|
|
|
|
|
be a viable part of Shorewall.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include
|
|
|
|
|
|
a comma-separated list of addresses and/or address ranges.
|
|
|
|
|
|
Netfilter will use all listed addresses/ranges in round-robin
|
|
|
|
|
|
fashion. \</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/accounting file has been added to allow
|
|
|
|
|
|
for traffic accounting. See the <a href=
|
|
|
|
|
|
"Accounting.html">accounting documentation</a> for a
|
|
|
|
|
|
description of this facility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
|
|
|
|
/etc/shorewall/maclist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
|
|
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and
|
|
|
|
|
|
REDIRECT rules, rate limiting occurs in the nat table DNAT
|
|
|
|
|
|
rule; the corresponding ACCEPT rule in the filter table is
|
|
|
|
|
|
not rate limited. If you want to limit the filter table rule,
|
|
|
|
|
|
you will need o create two rules; a DNAT- rule and an ACCEPT
|
|
|
|
|
|
rule which can be rate-limited separately.<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, the limit will apply to each pair of zones
|
|
|
|
|
|
individually rather than as a single limit for all pairs of
|
|
|
|
|
|
covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a rate limit,<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<
|
|
|
|
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<rate> is the sustained
|
|
|
|
|
|
rate per <interval><br>
|
|
|
|
|
|
<interval> is "sec" or
|
|
|
|
|
|
"min"<br>
|
|
|
|
|
|
<burst> is the largest
|
|
|
|
|
|
burst accepted within an <interval>. If not given, the
|
|
|
|
|
|
default of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no white space between the ACTION and "<" nor
|
|
|
|
|
|
there may be any white space within the burst specification.
|
|
|
|
|
|
If you want to specify logging of a rate-limited rule, the
|
|
|
|
|
|
":" and log level comes after the ">" (e.g.,
|
|
|
|
|
|
ACCEPT<2/sec:4>:info ).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) A new RATE LIMIT column has been added to the
|
|
|
|
|
|
/etc/shorewall/rules file. You may specify the rate limit
|
|
|
|
|
|
there in the format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate>/<interval>[:<burst>]<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<br>
|
|
|
|
|
|
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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Multiple chains may now be displayed in one "shorewall
|
|
|
|
|
|
show" command (e.g., shorewall show INPUT FORWARD
|
|
|
|
|
|
OUTPUT).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output rules (those with $FW as the SOURCE) may now be
|
|
|
|
|
|
limited to a set of local users and/or groups. See <a href=
|
|
|
|
|
|
"UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
|
|
|
|
details.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/23/2003 - Snapshot 1.4.6_2003082</b><span style=
|
|
|
|
|
|
"font-weight: bold;">3</span></p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
|
|
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
|
|
|
|
(previously named "Dynamic Chain").</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
|
|
|
|
|
|
again.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Once you have installed this version of Shorewall, you
|
|
|
|
|
|
must restart Shorewall before you may use the 'drop',
|
|
|
|
|
|
'reject', 'allow' or 'save' commands.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To maintain strict compatibility with previous versions,
|
|
|
|
|
|
current uses of "shorewall drop" and "shorewall reject"
|
|
|
|
|
|
should be replaced with "shorewall dropall" and "shorewall
|
|
|
|
|
|
rejectall"</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall IP Traffic Accounting has changed since
|
|
|
|
|
|
snapshot 20030813 -- see the <a href=
|
|
|
|
|
|
"Accounting.html">Accounting Page</a> for details.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Uset Set capability introduced in SnapShot 20030821
|
|
|
|
|
|
has changed -- see the <a href="UserSets.html">User Set
|
|
|
|
|
|
page</a> for details.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall now creates a dynamic blacklisting chain for
|
|
|
|
|
|
each interface defined in /etc/shorewall/interfaces. The
|
|
|
|
|
|
'drop' and 'reject' commands use the routing table to
|
|
|
|
|
|
determine which of these chains is to be used for
|
|
|
|
|
|
blacklisting the specified IP address(es).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Two new commands ('dropall' and 'rejectall') have been
|
|
|
|
|
|
introduced that do what 'drop' and 'reject' used to do;
|
|
|
|
|
|
namely, when an address is blacklisted using these new
|
|
|
|
|
|
commands, it will be blacklisted on all of your firewall's
|
|
|
|
|
|
interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include
|
|
|
|
|
|
a comma-separated list of addresses and/or address ranges.
|
|
|
|
|
|
Netfilter will use all listed addresses/ranges in round-robin
|
|
|
|
|
|
fashion. \</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/accounting file has been added to allow
|
|
|
|
|
|
for traffic accounting. See the <a href=
|
|
|
|
|
|
"Accounting.html">accounting documentation</a> for a
|
|
|
|
|
|
description of this facility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
|
|
|
|
/etc/shorewall/maclist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
|
|
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and
|
|
|
|
|
|
REDIRECT rules, rate limiting occurs in the nat table DNAT
|
|
|
|
|
|
rule; the corresponding ACCEPT rule in the filter table is
|
|
|
|
|
|
not rate limited. If you want to limit the filter table rule,
|
|
|
|
|
|
you will need o create two rules; a DNAT- rule and an ACCEPT
|
|
|
|
|
|
rule which can be rate-limited separately.<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, the limit will apply to each pair of zones
|
|
|
|
|
|
individually rather than as a single limit for all pairs of
|
|
|
|
|
|
covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a rate limit,<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<
|
|
|
|
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<rate> is the sustained
|
|
|
|
|
|
rate per <interval><br>
|
|
|
|
|
|
<interval> is "sec" or
|
|
|
|
|
|
"min"<br>
|
|
|
|
|
|
<burst> is the largest
|
|
|
|
|
|
burst accepted within an <interval>. If not given, the
|
|
|
|
|
|
default of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no white space between the ACTION and "<" nor
|
|
|
|
|
|
there may be any white space within the burst specification.
|
|
|
|
|
|
If you want to specify logging of a rate-limited rule, the
|
|
|
|
|
|
":" and log level comes after the ">" (e.g.,
|
|
|
|
|
|
ACCEPT<2/sec:4>:info ).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) A new RATE LIMIT column has been added to the
|
|
|
|
|
|
/etc/shorewall/rules file. You may specify the rate limit
|
|
|
|
|
|
there in the format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<rate>/<interval>[:<burst>]<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<br>
|
|
|
|
|
|
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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Multiple chains may now be displayed in one "shorewall
|
|
|
|
|
|
show" command (e.g., shorewall show INPUT FORWARD
|
|
|
|
|
|
OUTPUT).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Output rules (those with $FW as the SOURCE) may now be
|
|
|
|
|
|
limited to a set of local users and/or groups. See <a href=
|
|
|
|
|
|
"UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
|
|
|
|
details.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/13/2003 - Snapshot 1.4.6_20030813</b><b> </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li> Interface-specific dynamic blacklisting chains are
|
|
|
|
|
|
now displayed by "shorewall monitor" on the "Dynamic Chains"
|
|
|
|
|
|
page (previously named "Dynamic Chain").<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Once you have installed this version of Shorewall, you
|
|
|
|
|
|
must restart Shorewall before you may use the 'drop',
|
|
|
|
|
|
'reject', 'allow' or 'save' commands.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To maintain strict compatibility with previous versions,
|
|
|
|
|
|
current uses of "shorewall drop" and "shorewall reject"
|
|
|
|
|
|
should be replaced with "shorewall dropall" and "shorewall
|
|
|
|
|
|
rejectall"</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall now creates a dynamic blacklisting chain for
|
|
|
|
|
|
each interface defined in /etc/shorewall/interfaces. The
|
|
|
|
|
|
'drop' and 'reject' commands use the routing table to
|
|
|
|
|
|
determine which of these chains is to be used for
|
|
|
|
|
|
blacklisting the specified IP address(es).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Two new commands ('dropall' and 'rejectall') have been
|
|
|
|
|
|
introduced that do what 'drop' and 'reject' used to do;
|
|
|
|
|
|
namely, when an address is blacklisted using these new
|
|
|
|
|
|
commands, it will be blacklisted on all of your firewall's
|
|
|
|
|
|
interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include
|
|
|
|
|
|
a comma-separated list of addresses and/or address ranges.
|
|
|
|
|
|
Netfilter will use all listed addresses/ranges in round-robin
|
|
|
|
|
|
fashion. \</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/accounting file has been added to allow
|
|
|
|
|
|
for traffic accounting. See the <a href=
|
|
|
|
|
|
"Accounting.html">accounting documentation</a> for a
|
|
|
|
|
|
description of this facility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
|
|
|
|
/etc/shorewall/maclist.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
|
|
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and
|
|
|
|
|
|
REDIRECT rules, rate limiting occurs in the nat table DNAT
|
|
|
|
|
|
rule; the corresponding ACCEPT rule in the filter table is
|
|
|
|
|
|
not rate limited. If you want to limit the filter table rule,
|
|
|
|
|
|
you will need o create two rules; a DNAT- rule and an ACCEPT
|
|
|
|
|
|
rule which can be rate-limited separately.<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, the limit will apply to each pair of zones
|
|
|
|
|
|
individually rather than as a single limit for all pairs of
|
|
|
|
|
|
covered by the rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-]
|
|
|
|
|
|
or LOG with<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<
|
|
|
|
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<rate> is the sustained
|
|
|
|
|
|
rate per <interval><br>
|
|
|
|
|
|
<interval> is "sec" or
|
|
|
|
|
|
"min"<br>
|
|
|
|
|
|
<burst> is the largest
|
|
|
|
|
|
burst accepted within an <interval>. If not given, the
|
|
|
|
|
|
default of 5 is assumed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
There may be no white space between the ACTION and "<" nor
|
|
|
|
|
|
there may be any white space within the burst specification.
|
|
|
|
|
|
If you want to specify logging of a rate-limited rule, the
|
|
|
|
|
|
":" and log level comes after the ">" (e.g.,
|
|
|
|
|
|
ACCEPT<2/sec:4>:info ).<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<br>
|
|
|
|
|
|
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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/9/2003 - Snapshot 1.4.6_20030809</b><b> </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Once you have installed this version of Shorewall, you
|
|
|
|
|
|
must restart Shorewall before you may use the 'drop',
|
|
|
|
|
|
'reject', 'allow' or 'save' commands.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To maintain strict compatibility with previous versions,
|
|
|
|
|
|
current uses of "shorewall drop" and "shorewall reject"
|
|
|
|
|
|
should be replaced with "shorewall dropall" and "shorewall
|
|
|
|
|
|
rejectall"</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall now creates a dynamic blacklisting chain for
|
|
|
|
|
|
each interface defined in /etc/shorewall/interfaces. The
|
|
|
|
|
|
'drop' and 'reject' commands use the routing table to
|
|
|
|
|
|
determine which of these chains is to be used for
|
|
|
|
|
|
blacklisting the specified IP address(es).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Two new commands ('dropall' and 'rejectall') have been
|
|
|
|
|
|
introduced that do what 'drop' and 'reject' used to do;
|
|
|
|
|
|
namely, when an address is blacklisted using these new
|
|
|
|
|
|
commands, it will be blacklisted on all of your firewall's
|
|
|
|
|
|
interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Given the wide range of VPN software, I can never hope to
|
|
|
|
|
|
add specific support for all of it. I have therefore decided
|
|
|
|
|
|
to add "generic" tunnel support.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
|
|
|
|
types. You usually add a zone to represent the systems at the
|
|
|
|
|
|
other end of the tunnel and you add the appropriate
|
|
|
|
|
|
rules/policies to<br>
|
|
|
|
|
|
implement your security policy regarding traffic to/from
|
|
|
|
|
|
those systems.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In the /etc/shorewall/tunnels file, you can have entries of
|
|
|
|
|
|
the form:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
generic:<protocol>[:<port>]
|
|
|
|
|
|
<zone> <ip address>
|
|
|
|
|
|
<gateway zones><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
where:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<protocol> is the
|
|
|
|
|
|
protocol used by the tunnel<br>
|
|
|
|
|
|
<port> if
|
|
|
|
|
|
the protocol is 'udp' or 'tcp' then this is the destination
|
|
|
|
|
|
port number used by the tunnel.<br>
|
|
|
|
|
|
<zone> is
|
|
|
|
|
|
the zone of the remote tunnel gateway<br>
|
|
|
|
|
|
<ip address> is
|
|
|
|
|
|
the IP address of the remote tunnel gateway.<br>
|
|
|
|
|
|
<gateway
|
|
|
|
|
|
zone> Optional. A comma-separated list of zone
|
|
|
|
|
|
names. If specified, the remote gateway is to be considered
|
|
|
|
|
|
part of these zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'arp_filter' option has been added to the
|
|
|
|
|
|
/etc/shorewall/interfaces file. 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 through
|
|
|
|
|
|
that interface. Setting this option facilitates testing of
|
|
|
|
|
|
your firewall where multiple firewall interfaces are
|
|
|
|
|
|
connected to the same HUB/Switch (all interfaces 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>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/5/2003 - Shorewall-1.4.6b</b><b> <br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf
|
|
|
|
|
|
then Shorewall would fail to start with the error "ERROR:
|
|
|
|
|
|
Traffic Control requires Mangle"; that problem has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/5/2003 - Shorewall-1.4.6b</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf
|
|
|
|
|
|
then Shorewall would fail to start with the error "ERROR:
|
|
|
|
|
|
Traffic Control requires Mangle"; that problem has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall stop" command is now disabled when
|
|
|
|
|
|
/etc/shorewall/startup_disabled exists. This prevents people
|
|
|
|
|
|
from shooting themselves in the foot prior to having
|
|
|
|
|
|
configured Shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A change introduced in version 1.4.6 caused error
|
|
|
|
|
|
messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
|
|
|
|
|
|
and ip addresses were being added to a PPP interface; the
|
|
|
|
|
|
addresses were successfully added in spite of the
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The firewall script has been modified to eliminate the error
|
|
|
|
|
|
messages.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/31/2003 - Snapshot 1.4.6_20030731</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Problems Corrected since version 1.4.6:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Once you have installed this version of Shorewall, you
|
|
|
|
|
|
must restart Shorewall before you may use the 'drop',
|
|
|
|
|
|
'reject', 'allow' or 'save' commands.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To maintain strict compatibility with previous versions,
|
|
|
|
|
|
current uses of "shorewall drop" and "shorewall reject"
|
|
|
|
|
|
should be replaced with "shorewall dropall" and "shorewall
|
|
|
|
|
|
rejectall"</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>New Features:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall now creates a dynamic blacklisting chain for
|
|
|
|
|
|
each interface defined in /etc/shorewall/interfaces. The
|
|
|
|
|
|
'drop' and 'reject' commands use the routing table to
|
|
|
|
|
|
determine which of these chains is to be used for
|
|
|
|
|
|
blacklisting the specified IP address(es).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Two new commands ('dropall' and 'rejectall') have been
|
|
|
|
|
|
introduced that do what 'drop' and 'reject' used to do;
|
|
|
|
|
|
namely, when an address is blacklisted using these new
|
|
|
|
|
|
commands, it will be blacklisted on all of your firewall's
|
|
|
|
|
|
interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. This option has a default
|
|
|
|
|
|
value of "No" for existing users which causes Shorewall's
|
|
|
|
|
|
'stopped' state to continue as it has been; namely, in
|
|
|
|
|
|
the stopped state only traffic to/from hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped is accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs),
|
|
|
|
|
|
in addition to traffic to/from the hosts listed in
|
|
|
|
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) All traffic originating from the firewall
|
|
|
|
|
|
itself; and<br>
|
|
|
|
|
|
b) All traffic that is part of or related to an
|
|
|
|
|
|
already-existing connection.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In particular, with ADMINISABSENTMINDED=Yes, a
|
|
|
|
|
|
"shorewall stop" entered through an ssh session will not kill
|
|
|
|
|
|
the session.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it
|
|
|
|
|
|
is still possible for people to shoot themselves in the
|
|
|
|
|
|
foot.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/nat:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
206.124.146.178
|
|
|
|
|
|
eth0:0 192.168.1.5 <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
/etc/shorewall/rules:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
loc:192.168.1.5 tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
ACCEPT loc
|
|
|
|
|
|
fw tcp
|
|
|
|
|
|
22<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
From a remote system, I ssh to 206.124.146.178 which
|
|
|
|
|
|
establishes an SSH connection with local system 192.168.1.5.
|
|
|
|
|
|
I then create a second SSH connection from that computer to
|
|
|
|
|
|
the firewall and confidently type "shorewall stop". As part
|
|
|
|
|
|
of its stop processing, Shorewall removes eth0:0 which kills
|
|
|
|
|
|
my SSH connection to 192.168.1.5!!!</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/27/2003 - Snapshot 1.4.6_20030727</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>Migration Issues:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Once you have installed this version of Shorewall, you
|
|
|
|
|
|
must restart Shorewall before you may use the 'drop',
|
|
|
|
|
|
'reject', 'allow' or 'save' commands.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To maintain strict compatibility with previous versions,
|
|
|
|
|
|
current uses of "shorewall drop" and "shorewall reject"
|
|
|
|
|
|
should be replaced with "shorewall dropall" and "shorewall
|
|
|
|
|
|
rejectall"</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Shorewall now creates a dynamic blacklisting chain for
|
|
|
|
|
|
each interface defined in /etc/shorewall/interfaces. The
|
|
|
|
|
|
'drop' and 'reject' commands use the routing table to
|
|
|
|
|
|
determine which of these chains is to be used for
|
|
|
|
|
|
blacklisting the specified IP address(es).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Two new commands ('dropall' and 'rejectall') have been
|
|
|
|
|
|
introduced that do what 'drop' and 'reject' used to do;
|
|
|
|
|
|
namely, when an address is blacklisted using these new
|
|
|
|
|
|
commands, it will be blacklisted on all of your firewall's
|
|
|
|
|
|
interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
|
|
|
|
command-specific help (e.g., shorewall help
|
|
|
|
|
|
<command>).<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/26/2003 - Snapshot 1.4.6_20030726</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<p><a href=
|
|
|
|
|
|
"http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Problems Corrected since version 1.4.6:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
|
|
|
|
|
|
variable was being tested before it was set.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected handling of MAC addresses in the SOURCE column
|
|
|
|
|
|
of the tcrules file. Previously, these addresses resulted in
|
|
|
|
|
|
an invalid iptables command.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Once you have installed this version of Shorewall, you
|
|
|
|
|
|
must restart Shorewall before you may use the 'drop',
|
|
|
|
|
|
'reject', 'allow' or 'save' commands.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>To maintain strict compatibility with previous versions,
|
|
|
|
|
|
current uses of "shorewall drop" and "shorewall reject"
|
|
|
|
|
|
should be replaced with "shorewall dropall" and "shorewall
|
|
|
|
|
|
rejectall"</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>New Features:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
Shorewall now creates a dynamic blacklisting chain for each
|
|
|
|
|
|
interface defined in /etc/shorewall/interfaces. The 'drop' and
|
|
|
|
|
|
'reject' commands use the routing table to determine which of
|
|
|
|
|
|
these chains is to be used for blacklisting the specified IP
|
|
|
|
|
|
address(es).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Two new commands ('dropall' and 'rejectall') have been
|
|
|
|
|
|
introduced that do what 'drop' and 'reject' used to do; namely,
|
|
|
|
|
|
when an address is blacklisted using these new commands, it
|
|
|
|
|
|
will be blacklisted on all of your firewall's interfaces.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/22/2003 - Shorewall-1.4.6a</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
<b>Problems Corrected:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf
|
|
|
|
|
|
then Shorewall would fail to start with the error "ERROR:
|
|
|
|
|
|
Traffic Control requires Mangle"; that problem has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/20/2003 - Shorewall-1.4.6</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A problem seen on RH7.3 systems where Shorewall
|
|
|
|
|
|
encountered start errors when started using the "service"
|
|
|
|
|
|
mechanism has been worked around.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Where a list of IP addresses appears in the DEST column
|
|
|
|
|
|
of a DNAT[-] rule, Shorewall incorrectly created multiple
|
|
|
|
|
|
DNAT rules in the nat table (one for each element in the
|
|
|
|
|
|
list). Shorewall now correctly creates a single DNAT rule
|
|
|
|
|
|
with multiple "--to-destination" clauses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected a problem in Beta 1 where DNS names containing
|
|
|
|
|
|
a "-" were mis-handled when they appeared in the DEST column
|
|
|
|
|
|
of a rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A number of problems with rule parsing have been
|
|
|
|
|
|
corrected. Corrections involve the handling of "z1!z2" in the
|
|
|
|
|
|
SOURCE column as well as lists in the ORIGINAL DESTINATION
|
|
|
|
|
|
column.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The message "Adding rules for DHCP" is now suppressed if
|
|
|
|
|
|
there are no DHCP rules to add.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>In earlier versions, an undocumented feature allowed
|
|
|
|
|
|
entries in the host file as follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
z
|
|
|
|
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This capability was never documented and has been removed in
|
|
|
|
|
|
1.4.6 to allow entries of the following format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
z
|
|
|
|
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
|
|
|
|
|
|
have been removed from /etc/shorewall/shorewall.conf. These
|
|
|
|
|
|
capabilities are now automatically detected by Shorewall (see
|
|
|
|
|
|
below).<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>New Features:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A 'newnotsyn' interface option has been added. This
|
|
|
|
|
|
option may be specified in /etc/shorewall/interfaces and
|
|
|
|
|
|
overrides the setting NEWNOTSYN=No for packets arriving on
|
|
|
|
|
|
the associated interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The means for specifying a range of IP addresses in
|
|
|
|
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall can now add IP addresses to subnets other than
|
|
|
|
|
|
the first one on an interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DNAT[-] rules may now be used to load balance
|
|
|
|
|
|
(round-robin) over a set of servers. Servers may be specified
|
|
|
|
|
|
in a range of addresses given as <first
|
|
|
|
|
|
address>-<last address>.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp
|
|
|
|
|
|
80<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
|
|
|
|
|
|
configuration options have been removed and have been
|
|
|
|
|
|
replaced by code that detects whether these capabilities are
|
|
|
|
|
|
present in the current kernel. The output of the start,
|
|
|
|
|
|
restart and check commands have been enhanced to report the
|
|
|
|
|
|
outcome:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the Connection Tracking Match Extension has
|
|
|
|
|
|
been added. This extension is available in recent
|
|
|
|
|
|
kernel/iptables releases and allows for rules which match
|
|
|
|
|
|
against elements in netfilter's connection tracking table.
|
|
|
|
|
|
Shorewall automatically detects the availability of this
|
|
|
|
|
|
extension and reports its availability in the output of the
|
|
|
|
|
|
start, restart and check commands.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Connection Tracking Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If this extension is available, the ruleset generated by
|
|
|
|
|
|
Shorewall is changed in the following ways:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style=
|
|
|
|
|
|
"list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not
|
|
|
|
|
|
create chains in the mangle table but will rather do all
|
|
|
|
|
|
'norfc1918' filtering in the filter table (rfc1918
|
|
|
|
|
|
chain).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Recall that Shorewall DNAT rules generate two
|
|
|
|
|
|
netfilter rules; one in the nat table and one in the
|
|
|
|
|
|
filter table. If the Connection Tracking Match Extension
|
|
|
|
|
|
is available, the rule in the filter table is extended to
|
|
|
|
|
|
check that the original destination address was the same
|
|
|
|
|
|
as specified (or defaulted to) in the DNAT rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The shell used to interpret the firewall script
|
|
|
|
|
|
(/usr/share/shorewall/firewall) may now be specified using
|
|
|
|
|
|
the SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'ipcalc' command has been added to
|
|
|
|
|
|
/sbin/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipcalc [ <address>
|
|
|
|
|
|
<netmask> | <address>/<vlsm> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@wookie root]# shorewall
|
|
|
|
|
|
ipcalc 192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
|
|
|
|
[root@wookie root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@wookie root]# shorewall
|
|
|
|
|
|
ipcalc 192.168.1.0 255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
|
|
|
|
[root@wookie root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Warning:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If your shell only supports 32-bit signed arithmatic (ash or
|
|
|
|
|
|
dash), then the ipcalc command produces incorrect information
|
|
|
|
|
|
for IP addresses 128.0.0.0-1 and for /1 networks. Bash should
|
|
|
|
|
|
produce correct information for all valid IP addresses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'iprange' command has been added to
|
|
|
|
|
|
/sbin/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
iprange
|
|
|
|
|
|
<address>-<address><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This command decomposes a range of IP addressses into a list
|
|
|
|
|
|
of network and host addresses. The command can be useful if
|
|
|
|
|
|
you need to construct an efficient set of rules that accept
|
|
|
|
|
|
connections from a range of network addresses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note: If your shell only supports 32-bit signed arithmetic
|
|
|
|
|
|
(ash or dash) then the range may not span 128.0.0.0.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@gateway root]# shorewall
|
|
|
|
|
|
iprange 192.168.1.4-192.168.12.9<br>
|
|
|
|
|
|
192.168.1.4/30<br>
|
|
|
|
|
|
192.168.1.8/29<br>
|
|
|
|
|
|
192.168.1.16/28<br>
|
|
|
|
|
|
192.168.1.32/27<br>
|
|
|
|
|
|
192.168.1.64/26<br>
|
|
|
|
|
|
192.168.1.128/25<br>
|
|
|
|
|
|
192.168.2.0/23<br>
|
|
|
|
|
|
192.168.4.0/22<br>
|
|
|
|
|
|
192.168.8.0/22<br>
|
|
|
|
|
|
192.168.12.0/29<br>
|
|
|
|
|
|
192.168.12.8/31<br>
|
|
|
|
|
|
[root@gateway root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A list of host/net addresses is now allowed in an entry
|
|
|
|
|
|
in /etc/shorewall/hosts.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
foo
|
|
|
|
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall check" command now includes the chain name
|
|
|
|
|
|
when printing the applicable policy for each pair of
|
|
|
|
|
|
zones.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Policy for dmz to
|
|
|
|
|
|
net is REJECT using chain all2all<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This means that the policy for connections from the dmz to
|
|
|
|
|
|
the internet is REJECT and the applicable entry in the
|
|
|
|
|
|
/etc/shorewall/policy was the all->all policy.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the 2.6 Kernel series has been added.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/15/2003 - New Mirror in Brazil</b><b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
Thanks to the folks at securityopensource.org.br, there is now
|
|
|
|
|
|
a <a href="http://shorewall.securityopensource.org.br" target=
|
|
|
|
|
|
"_top">Shorewall mirror in Brazil</a>.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/15/2003 - Shorewall-1.4.6 RC 1</b> <b><br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A problem seen on RH7.3 systems where Shorewall
|
|
|
|
|
|
encountered start errors when started using the "service"
|
|
|
|
|
|
mechanism has been worked around.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Where a list of IP addresses appears in the DEST column
|
|
|
|
|
|
of a DNAT[-] rule, Shorewall incorrectly created multiple
|
|
|
|
|
|
DNAT rules in the nat table (one for each element in the
|
|
|
|
|
|
list). Shorewall now correctly creates a single DNAT rule
|
|
|
|
|
|
with multiple "--to-destination" clauses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected a problem in Beta 1 where DNS names containing
|
|
|
|
|
|
a "-" were mis-handled when they appeared in the DEST column
|
|
|
|
|
|
of a rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A number of problems with rule parsing have been
|
|
|
|
|
|
corrected. Corrections involve the handling of "z1!z2" in the
|
|
|
|
|
|
SOURCE column as well as lists in the ORIGINAL DESTINATION
|
|
|
|
|
|
column.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>In earlier versions, an undocumented feature allowed
|
|
|
|
|
|
entries in the host file as follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
z
|
|
|
|
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This capability was never documented and has been removed in
|
|
|
|
|
|
1.4.6 to allow entries of the following format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
z
|
|
|
|
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
|
|
|
|
|
|
have been removed from /etc/shorewall/shorewall.conf. These
|
|
|
|
|
|
capabilities are now automatically detected by Shorewall (see
|
|
|
|
|
|
below).<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>New Features:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A 'newnotsyn' interface option has been added. This
|
|
|
|
|
|
option may be specified in /etc/shorewall/interfaces and
|
|
|
|
|
|
overrides the setting NEWNOTSYN=No for packets arriving on
|
|
|
|
|
|
the associated interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The means for specifying a range of IP addresses in
|
|
|
|
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall can now add IP addresses to subnets other than
|
|
|
|
|
|
the first one on an interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DNAT[-] rules may now be used to load balance
|
|
|
|
|
|
(round-robin) over a set of servers. Servers may be specified
|
|
|
|
|
|
in a range of addresses given as <first
|
|
|
|
|
|
address>-<last address>.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp
|
|
|
|
|
|
80<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
|
|
|
|
|
|
configuration options have been removed and have been
|
|
|
|
|
|
replaced by code that detects whether these capabilities are
|
|
|
|
|
|
present in the current kernel. The output of the start,
|
|
|
|
|
|
restart and check commands have been enhanced to report the
|
|
|
|
|
|
outcome:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the Connection Tracking Match Extension has
|
|
|
|
|
|
been added. This extension is available in recent
|
|
|
|
|
|
kernel/iptables releases and allows for rules which match
|
|
|
|
|
|
against elements in netfilter's connection tracking table.
|
|
|
|
|
|
Shorewall automatically detects the availability of this
|
|
|
|
|
|
extension and reports its availability in the output of the
|
|
|
|
|
|
start, restart and check commands.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Connection Tracking Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If this extension is available, the ruleset generated by
|
|
|
|
|
|
Shorewall is changed in the following ways:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style=
|
|
|
|
|
|
"list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not
|
|
|
|
|
|
create chains in the mangle table but will rather do all
|
|
|
|
|
|
'norfc1918' filtering in the filter table (rfc1918
|
|
|
|
|
|
chain).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Recall that Shorewall DNAT rules generate two
|
|
|
|
|
|
netfilter rules; one in the nat table and one in the
|
|
|
|
|
|
filter table. If the Connection Tracking Match Extension
|
|
|
|
|
|
is available, the rule in the filter table is extended to
|
|
|
|
|
|
check that the original destination address was the same
|
|
|
|
|
|
as specified (or defaulted to) in the DNAT rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The shell used to interpret the firewall script
|
|
|
|
|
|
(/usr/share/shorewall/firewall) may now be specified using
|
|
|
|
|
|
the SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'ipcalc' command has been added to
|
|
|
|
|
|
/sbin/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipcalc [ <address>
|
|
|
|
|
|
<netmask> | <address>/<vlsm> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@wookie root]# shorewall
|
|
|
|
|
|
ipcalc 192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
|
|
|
|
[root@wookie root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@wookie root]# shorewall
|
|
|
|
|
|
ipcalc 192.168.1.0 255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
|
|
|
|
[root@wookie root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Warning:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If your shell only supports 32-bit signed arithmatic (ash or
|
|
|
|
|
|
dash), then the ipcalc command produces incorrect information
|
|
|
|
|
|
for IP addresses 128.0.0.0-1 and for /1 networks. Bash should
|
|
|
|
|
|
produce correct information for all valid IP addresses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'iprange' command has been added to
|
|
|
|
|
|
/sbin/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
iprange
|
|
|
|
|
|
<address>-<address><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This command decomposes a range of IP addressses into a list
|
|
|
|
|
|
of network and host addresses. The command can be useful if
|
|
|
|
|
|
you need to construct an efficient set of rules that accept
|
|
|
|
|
|
connections from a range of network addresses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note: If your shell only supports 32-bit signed arithmetic
|
|
|
|
|
|
(ash or dash) then the range may not span 128.0.0.0.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@gateway root]# shorewall
|
|
|
|
|
|
iprange 192.168.1.4-192.168.12.9<br>
|
|
|
|
|
|
192.168.1.4/30<br>
|
|
|
|
|
|
192.168.1.8/29<br>
|
|
|
|
|
|
192.168.1.16/28<br>
|
|
|
|
|
|
192.168.1.32/27<br>
|
|
|
|
|
|
192.168.1.64/26<br>
|
|
|
|
|
|
192.168.1.128/25<br>
|
|
|
|
|
|
192.168.2.0/23<br>
|
|
|
|
|
|
192.168.4.0/22<br>
|
|
|
|
|
|
192.168.8.0/22<br>
|
|
|
|
|
|
192.168.12.0/29<br>
|
|
|
|
|
|
192.168.12.8/31<br>
|
|
|
|
|
|
[root@gateway root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A list of host/net addresses is now allowed in an entry
|
|
|
|
|
|
in /etc/shorewall/hosts.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
foo
|
|
|
|
|
|
eth1:192.168.1.0/24,192.168.2.0/24</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A problem seen on RH7.3 systems where Shorewall
|
|
|
|
|
|
encountered start errors when started using the "service"
|
|
|
|
|
|
mechanism has been worked around.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Where a list of IP addresses appears in the DEST column
|
|
|
|
|
|
of a DNAT[-] rule, Shorewall incorrectly created multiple
|
|
|
|
|
|
DNAT rules in the nat table (one for each element in the
|
|
|
|
|
|
list). Shorewall now correctly creates a single DNAT rule
|
|
|
|
|
|
with multiple "--to-destination" clauses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected a problem in Beta 1 where DNS names containing
|
|
|
|
|
|
a "-" were mis-handled when they appeared in the DEST column
|
|
|
|
|
|
of a rule.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>In earlier versions, an undocumented feature allowed
|
|
|
|
|
|
entries in the host file as follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
z
|
|
|
|
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This capability was never documented and has been removed in
|
|
|
|
|
|
1.4.6 to allow entries of the following format:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
z
|
|
|
|
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
|
|
|
|
|
|
have been removed from /etc/shorewall/shorewall.conf. These
|
|
|
|
|
|
capabilities are now automatically detected by Shorewall (see
|
|
|
|
|
|
below).<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>New Features:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A 'newnotsyn' interface option has been added. This
|
|
|
|
|
|
option may be specified in /etc/shorewall/interfaces and
|
|
|
|
|
|
overrides the setting NEWNOTSYN=No for packets arriving on
|
|
|
|
|
|
the associated interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The means for specifying a range of IP addresses in
|
|
|
|
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall can now add IP addresses to subnets other than
|
|
|
|
|
|
the first one on an interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DNAT[-] rules may now be used to load balance
|
|
|
|
|
|
(round-robin) over a set of servers. Servers may be specified
|
|
|
|
|
|
in a range of addresses given as <first
|
|
|
|
|
|
address>-<last address>.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp
|
|
|
|
|
|
80<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
|
|
|
|
|
|
configuration options have been removed and have been
|
|
|
|
|
|
replaced by code that detects whether these capabilities are
|
|
|
|
|
|
present in the current kernel. The output of the start,
|
|
|
|
|
|
restart and check commands have been enhanced to report the
|
|
|
|
|
|
outcome:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the Connection Tracking Match Extension has
|
|
|
|
|
|
been added. This extension is available in recent
|
|
|
|
|
|
kernel/iptables releases and allows for rules which match
|
|
|
|
|
|
against elements in netfilter's connection tracking table.
|
|
|
|
|
|
Shorewall automatically detects the availability of this
|
|
|
|
|
|
extension and reports its availability in the output of the
|
|
|
|
|
|
start, restart and check commands.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Connection Tracking Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If this extension is available, the ruleset generated by
|
|
|
|
|
|
Shorewall is changed in the following ways:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style=
|
|
|
|
|
|
"list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not
|
|
|
|
|
|
create chains in the mangle table but will rather do all
|
|
|
|
|
|
'norfc1918' filtering in the filter table (rfc1918
|
|
|
|
|
|
chain).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Recall that Shorewall DNAT rules generate two
|
|
|
|
|
|
netfilter rules; one in the nat table and one in the
|
|
|
|
|
|
filter table. If the Connection Tracking Match Extension
|
|
|
|
|
|
is available, the rule in the filter table is extended to
|
|
|
|
|
|
check that the original destination address was the same
|
|
|
|
|
|
as specified (or defaulted to) in the DNAT rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The shell used to interpret the firewall script
|
|
|
|
|
|
(/usr/share/shorewall/firewall) may now be specified using
|
|
|
|
|
|
the SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'ipcalc' command has been added to
|
|
|
|
|
|
/sbin/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ipcalc [ <address>
|
|
|
|
|
|
<netmask> | <address>/<vlsm> ]<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@wookie root]# shorewall
|
|
|
|
|
|
ipcalc 192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
|
|
|
|
[root@wookie root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@wookie root]# shorewall
|
|
|
|
|
|
ipcalc 192.168.1.0 255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
|
|
|
|
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
|
|
|
|
[root@wookie root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Warning:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If your shell only supports 32-bit signed arithmatic (ash or
|
|
|
|
|
|
dash), then the ipcalc command produces incorrect information
|
|
|
|
|
|
for IP addresses 128.0.0.0-1 and for /1 networks. Bash should
|
|
|
|
|
|
produce correct information for all valid IP addresses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An 'iprange' command has been added to
|
|
|
|
|
|
/sbin/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
iprange
|
|
|
|
|
|
<address>-<address><br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
This command decomposes a range of IP addressses into a list
|
|
|
|
|
|
of network and host addresses. The command can be useful if
|
|
|
|
|
|
you need to construct an efficient set of rules that accept
|
|
|
|
|
|
connections from a range of network addresses.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note: If your shell only supports 32-bit signed arithmetic
|
|
|
|
|
|
(ash or dash) then the range may not span 128.0.0.0.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
[root@gateway root]# shorewall
|
|
|
|
|
|
iprange 192.168.1.4-192.168.12.9<br>
|
|
|
|
|
|
192.168.1.4/30<br>
|
|
|
|
|
|
192.168.1.8/29<br>
|
|
|
|
|
|
192.168.1.16/28<br>
|
|
|
|
|
|
192.168.1.32/27<br>
|
|
|
|
|
|
192.168.1.64/26<br>
|
|
|
|
|
|
192.168.1.128/25<br>
|
|
|
|
|
|
192.168.2.0/23<br>
|
|
|
|
|
|
192.168.4.0/22<br>
|
|
|
|
|
|
192.168.8.0/22<br>
|
|
|
|
|
|
192.168.12.0/29<br>
|
|
|
|
|
|
192.168.12.8/31<br>
|
|
|
|
|
|
[root@gateway root]#<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A list of host/net addresses is now allowed in an entry
|
|
|
|
|
|
in /etc/shorewall/hosts.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
foo
|
|
|
|
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A problem seen on RH7.3 systems where Shorewall
|
|
|
|
|
|
encountered start errors when started using the "service"
|
|
|
|
|
|
mechanism has been worked around.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Where a list of IP addresses appears in the DEST column
|
|
|
|
|
|
of a DNAT[-] rule, Shorewall incorrectly created multiple
|
|
|
|
|
|
DNAT rules in the nat table (one for each element in the
|
|
|
|
|
|
list). Shorewall now correctly creates a single DNAT rule
|
|
|
|
|
|
with multiple "--to-destination" clauses.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>New Features:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A 'newnotsyn' interface option has been added. This
|
|
|
|
|
|
option may be specified in /etc/shorewall/interfaces and
|
|
|
|
|
|
overrides the setting NEWNOTSYN=No for packets arriving on
|
|
|
|
|
|
the associated interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The means for specifying a range of IP addresses in
|
|
|
|
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
|
|
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall can now add IP addresses to subnets other than
|
|
|
|
|
|
the first one on an interface.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DNAT[-] rules may now be used to load balance
|
|
|
|
|
|
(round-robin) over a set of servers. Up to 256 servers may be
|
|
|
|
|
|
specified in a range of addresses given as <first
|
|
|
|
|
|
address>-<last address>.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp
|
|
|
|
|
|
80<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Note that this capability has previously been available using
|
|
|
|
|
|
a combination of a DNAT- rule and one or more ACCEPT rules.
|
|
|
|
|
|
That technique is still preferable for load-balancing over a
|
|
|
|
|
|
large number of servers (> 16) since specifying a range in
|
|
|
|
|
|
the DNAT rule causes one filter table ACCEPT rule to be
|
|
|
|
|
|
generated for each IP address in the range.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
|
|
|
|
|
|
configuration options have been removed and have been
|
|
|
|
|
|
replaced by code that detects whether these capabilities are
|
|
|
|
|
|
present in the current kernel. The output of the start,
|
|
|
|
|
|
restart and check commands have been enhanced to report the
|
|
|
|
|
|
outcome:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the Connection Tracking Match Extension has
|
|
|
|
|
|
been added. This extension is available in recent
|
|
|
|
|
|
kernel/iptables releases and allows for rules which match
|
|
|
|
|
|
against elements in netfilter's connection tracking table.
|
|
|
|
|
|
Shorewall automatically detects the availability of this
|
|
|
|
|
|
extension and reports its availability in the output of the
|
|
|
|
|
|
start, restart and check commands.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Shorewall has detected the following iptables/netfilter
|
|
|
|
|
|
capabilities:<br>
|
|
|
|
|
|
NAT: Available<br>
|
|
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
|
|
Connection Tracking Match: Available<br>
|
|
|
|
|
|
Verifying Configuration...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
If this extension is available, the ruleset generated by
|
|
|
|
|
|
Shorewall is changed in the following ways:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style=
|
|
|
|
|
|
"list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not
|
|
|
|
|
|
create chains in the mangle table but will rather do all
|
|
|
|
|
|
'norfc1918' filtering in the filter table (rfc1918
|
|
|
|
|
|
chain).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Recall that Shorewall DNAT rules generate two
|
|
|
|
|
|
netfilter rules; one in the nat table and one in the
|
|
|
|
|
|
filter table. If the Connection Tracking Match Extension
|
|
|
|
|
|
is available, the rule in the filter table is extended to
|
|
|
|
|
|
check that the original destination address was the same
|
|
|
|
|
|
as specified (or defaulted to) in the DNAT rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The shell used to interpret the firewall script
|
|
|
|
|
|
(/usr/share/shorewall/firewall) may now be specified using
|
|
|
|
|
|
the SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/17/2003 - Shorewall-1.4.5</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Problems Corrected:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The command "shorewall debug try <directory>" now
|
|
|
|
|
|
correctly traces the attempt.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The INCLUDE directive now works properly in the zones
|
|
|
|
|
|
file; previously, INCLUDE in that file was ignored.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>/etc/shorewall/routestopped records with an empty second
|
|
|
|
|
|
column are no longer ignored.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p>New Features:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
|
|
|
|
|
|
may now contain a list of addresses. If the list begins with
|
|
|
|
|
|
"!' then the rule will take effect only if the original
|
|
|
|
|
|
destination address in the connection request does not match
|
|
|
|
|
|
any of the addresses listed.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables
|
|
|
|
|
|
1.2.8</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The firewall at shorewall.net has been upgraded to the
|
|
|
|
|
|
2.4.21 kernel and iptables 1.2.8 (using the "official" RPM from
|
|
|
|
|
|
netfilter.org). No problems have been encountered with this set
|
|
|
|
|
|
of software. The Shorewall version is 1.4.4b plus the
|
|
|
|
|
|
accumulated changes for 1.4.5.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/8/2003 - Updated Samples</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to Francesca Smith, the samples have been updated to
|
|
|
|
|
|
Shorewall version 1.4.4.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/29/2003 - Shorewall-1.4.4b</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Groan -- This version corrects a problem whereby the
|
|
|
|
|
|
--log-level was not being set when logging via syslog. The most
|
|
|
|
|
|
commonly reported symptom was that Shorewall messages were
|
|
|
|
|
|
being written to the console even though console logging was
|
|
|
|
|
|
correctly configured per FAQ 16.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/27/2003 - Shorewall-1.4.4a</b></p>
|
|
|
|
|
|
The Fireparse --log-prefix fiasco continues. Tuomo Soini has
|
|
|
|
|
|
pointed out that the code in 1.4.4 restricts the length of
|
|
|
|
|
|
short zone names to 4 characters. I've produced version 1.4.4a
|
|
|
|
|
|
that restores the previous 5-character limit by conditionally
|
|
|
|
|
|
omitting the log rule number when the LOGFORMAT doesn't contain
|
|
|
|
|
|
'%d'. <br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/23/2003 - Shorewall-1.4.4</b></p>
|
|
|
|
|
|
I apologize for the rapid-fire releases but since there is a
|
|
|
|
|
|
potential configuration change required to go from 1.4.3a to
|
|
|
|
|
|
1.4.4, I decided to make it a full release rather than just a
|
|
|
|
|
|
bug-fix release. <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<b> Problems corrected:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
None.<br>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
<b> New Features:<br>
|
|
|
|
|
|
</b>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A REDIRECT- rule target has been added. This target
|
|
|
|
|
|
behaves for REDIRECT in the same way as DNAT- does for DNAT
|
|
|
|
|
|
in that the Netfilter nat table REDIRECT rule is added but
|
|
|
|
|
|
not the companion filter table ACCEPT rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The LOGMARKER variable has been renamed LOGFORMAT and has
|
|
|
|
|
|
been changed to a 'printf' formatting template which accepts
|
|
|
|
|
|
three arguments (the chain name, logging rule number 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>
|
|
|
|
|
|
<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>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When logging is specified on a DNAT[-] or REDIRECT[-]
|
|
|
|
|
|
rule, the logging now takes place in the nat table rather
|
|
|
|
|
|
than in the filter table. This way, only those connections
|
|
|
|
|
|
that actually undergo DNAT or redirection will be logged.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/20/2003 - Shorewall-1.4.3a</b> <br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
This version primarily corrects the documentation included in
|
|
|
|
|
|
the .tgz and in the .rpm. In addition: <br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>(This change is in 1.4.3 but is not documented) If you
|
|
|
|
|
|
are running iptables 1.2.7a and kernel 2.4.20, then Shorewall
|
|
|
|
|
|
will return reject replies as follows:<br>
|
|
|
|
|
|
a) tcp - RST<br>
|
|
|
|
|
|
b) udp - ICMP port unreachable<br>
|
|
|
|
|
|
c) icmp - ICMP host unreachable<br>
|
|
|
|
|
|
d) Otherwise - ICMP host prohibited<br>
|
|
|
|
|
|
If you are running earlier software, Shorewall will follow
|
|
|
|
|
|
it's traditional convention:<br>
|
|
|
|
|
|
a) tcp - RST<br>
|
|
|
|
|
|
b) Otherwise - ICMP port unreachable</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>UDP port 135 is now silently dropped in the common.def
|
|
|
|
|
|
chain. Remember that this chain is traversed just before a
|
|
|
|
|
|
DROP or REJECT policy is enforced.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
<b>Problems Corrected:<br>
|
|
|
|
|
|
</b>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>There were several cases where Shorewall would fail to
|
|
|
|
|
|
remove a temporary directory from /tmp. These cases have been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The rules for allowing all traffic via the loopback
|
|
|
|
|
|
interface have been moved to before the rule that drops
|
|
|
|
|
|
status=INVALID packets. This insures that all loopback
|
|
|
|
|
|
traffic is allowed even if Netfilter connection tracking is
|
|
|
|
|
|
confused.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:<br>
|
|
|
|
|
|
</b>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li> IPV6-IPV4 (6to4) tunnels are now supported in the
|
|
|
|
|
|
/etc/shorewall/tunnels file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="2">You may now change the leading portion of the
|
|
|
|
|
|
--log-prefix used by Shorewall using the LOGMARKER variable
|
|
|
|
|
|
in shorewall.conf. By default, "Shorewall:" is used.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/10/2003 - Shorewall Mirror in Asia<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Ed Greshko has established a mirror in Taiwan -- Thanks
|
|
|
|
|
|
Ed!<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/8/2003 - Shorewall Mirror in Chile</b></p>
|
|
|
|
|
|
Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago
|
|
|
|
|
|
Chile.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/21/2003 - Samples updated for Shorewall version
|
|
|
|
|
|
1.4.2</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to Francesca Smith, the sample configurations are now
|
|
|
|
|
|
upgraded to Shorewall version 1.4.2.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/9/2003 - Shorewall 1.4.2</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b> Problems Corrected:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>TCP connection requests rejected out of the
|
|
|
|
|
|
<b>common</b> chain are now properly rejected with TCP RST;
|
|
|
|
|
|
previously, some of these requests were rejected with an
|
|
|
|
|
|
ICMP port-unreachable response.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>'traceroute -I' from behind the firewall previously
|
|
|
|
|
|
timed out on the first hop (e.g., to the firewall). This
|
|
|
|
|
|
has been worked around.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b> New Features:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Where an entry in the/etc/shorewall/hosts file specifies
|
|
|
|
|
|
a particular host or network, Shorewall now creates an
|
|
|
|
|
|
intermediate chain for handling input from the related zone.
|
|
|
|
|
|
This can substantially reduce the number of rules traversed
|
|
|
|
|
|
by connections requests from such zones.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Any file may include an INCLUDE directive. An INCLUDE
|
|
|
|
|
|
directive consists of the word INCLUDE followed by a file
|
|
|
|
|
|
name and causes the contents of the named file to be
|
|
|
|
|
|
logically included into the file containing the INCLUDE. File
|
|
|
|
|
|
names given in an INCLUDE directive are assumed to reside in
|
|
|
|
|
|
/etc/shorewall or in an alternate configuration directory if
|
|
|
|
|
|
one has been specified for the command.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Examples:<br>
|
|
|
|
|
|
shorewall/params.mgmt:<br>
|
|
|
|
|
|
MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3<br>
|
|
|
|
|
|
TIME_SERVERS=4.4.4.4<br>
|
|
|
|
|
|
BACKUP_SERVERS=5.5.5.5<br>
|
|
|
|
|
|
----- end params.mgmt -----<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall/params:<br>
|
|
|
|
|
|
# Shorewall 1.3 /etc/shorewall/params<br>
|
|
|
|
|
|
[..]<br>
|
|
|
|
|
|
#######################################<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
INCLUDE params.mgmt <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
# params unique to this host here<br>
|
|
|
|
|
|
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE -
|
|
|
|
|
|
DO NOT REMOVE<br>
|
|
|
|
|
|
----- end params -----<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall/rules.mgmt:<br>
|
|
|
|
|
|
ACCEPT
|
|
|
|
|
|
net:$MGMT_SERVERS
|
|
|
|
|
|
$FW tcp 22<br>
|
|
|
|
|
|
ACCEPT
|
|
|
|
|
|
$FW
|
|
|
|
|
|
net:$TIME_SERVERS udp
|
|
|
|
|
|
123<br>
|
|
|
|
|
|
ACCEPT
|
|
|
|
|
|
$FW
|
|
|
|
|
|
net:$BACKUP_SERVERS tcp 22<br>
|
|
|
|
|
|
----- end rules.mgmt -----<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
shorewall/rules:<br>
|
|
|
|
|
|
# Shorewall version 1.3 - Rules File<br>
|
|
|
|
|
|
[..]<br>
|
|
|
|
|
|
#######################################<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
INCLUDE rules.mgmt <br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
# rules unique to this host here<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE
|
|
|
|
|
|
-- DO NOT REMOVE<br>
|
|
|
|
|
|
----- end rules -----<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
INCLUDE's may be nested to a level of 3 -- further nested
|
|
|
|
|
|
INCLUDE directives are ignored with a warning message.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Routing traffic from an interface back out that interface
|
|
|
|
|
|
continues to be a problem. While I firmly believe that this
|
|
|
|
|
|
should never happen, people continue to want to do it. To
|
|
|
|
|
|
limit the damage that such nonsense produces, I have added a
|
|
|
|
|
|
new 'routeback' option in /etc/shorewall/interfaces and
|
|
|
|
|
|
/etc/shorewall/hosts. When used in /etc/shorewall/interfaces,
|
|
|
|
|
|
the 'ZONE' column may not contain '-'; in other words,
|
|
|
|
|
|
'routeback' can't be used as an option for a multi-zone
|
|
|
|
|
|
interface. The 'routeback' option CAN be specified however on
|
|
|
|
|
|
individual group entries in /etc/shorewall/hosts.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
The 'routeback' option is similar to the old 'multi' option
|
|
|
|
|
|
with two exceptions:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) The option pertains to a particular
|
|
|
|
|
|
zone,interface,address tuple.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
b) The option only created infrastructure to
|
|
|
|
|
|
pass traffic from (zone,interface,address) tuples back to
|
|
|
|
|
|
themselves (the 'multi' option affected all
|
|
|
|
|
|
(zone,interface,address) tuples associated with the given
|
|
|
|
|
|
'interface').<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
See the '<a href="upgrade_issues.htm">Upgrade Issues</a>' for
|
|
|
|
|
|
information about how this new option may affect your
|
|
|
|
|
|
configuration.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/24/2003 - Shorewall 1.4.1</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p>This release follows up on 1.4.0. It corrects a problem
|
|
|
|
|
|
introduced in 1.4.0 and removes additional warts.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
<b>Problems Corrected:</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>When Shorewall 1.4.0 is run under the ash shell (such as
|
|
|
|
|
|
on Bering/LEAF), it can attempt to add ECN disabling rules
|
|
|
|
|
|
even if the /etc/shorewall/ecn file is empty. That problem
|
|
|
|
|
|
has been corrected so that ECN disabling rules are only added
|
|
|
|
|
|
if there are entries in /etc/shorewall/ecn.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
Note: In the list that follows, the term <i>group</i> refers
|
|
|
|
|
|
to a particular network or subnetwork (which may be 0.0.0.0/0
|
|
|
|
|
|
or it may be a host address) accessed through a particular
|
|
|
|
|
|
interface. Examples:<br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
eth0:0.0.0.0/0<br>
|
|
|
|
|
|
eth2:192.168.1.0/24<br>
|
|
|
|
|
|
eth3:192.0.2.123<br>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
You can use the "shorewall check" command to see the groups
|
|
|
|
|
|
associated with each of your zones.<br>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Beginning with Shorewall 1.4.1, if a zone Z comprises
|
|
|
|
|
|
more than one group then if there is no explicit Z to Z
|
|
|
|
|
|
policy and there are no rules governing traffic from Z to Z
|
|
|
|
|
|
then Shorewall will permit all traffic between the groups in
|
|
|
|
|
|
the zone.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Beginning with Shorewall 1.4.1, Shorewall will never
|
|
|
|
|
|
create rules to handle traffic from a group to itself.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A NONE policy is introduced in 1.4.1. When a policy of
|
|
|
|
|
|
NONE is specified from Z1 to Z2:</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>There may be no rules created that govern connections
|
|
|
|
|
|
from Z1 to Z2.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall will not create any infrastructure to handle
|
|
|
|
|
|
traffic from Z1 to Z2.</li>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
See the <a href="upgrade_issues.htm">upgrade issues</a> for a
|
|
|
|
|
|
discussion of how these changes may affect your configuration.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/17/2003 - Shorewall 1.4.0</b></p>
|
|
|
|
|
|
Shorewall 1.4 represents the next step in the evolution of
|
|
|
|
|
|
Shorewall. The main thrust of the initial release is simply to
|
|
|
|
|
|
remove the cruft that has accumulated in Shorewall over time.
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
|
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<b>IMPORTANT: Shorewall 1.4.0 requires</b> <b>the iproute
|
|
|
|
|
|
package ('ip' utility).</b><br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
Function from 1.3 that has been omitted from this version
|
|
|
|
|
|
include:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The MERGE_HOSTS variable in shorewall.conf is no longer
|
|
|
|
|
|
supported. Shorewall 1.4 behavior is the same as 1.3 with
|
|
|
|
|
|
MERGE_HOSTS=Yes.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface names of the form
|
|
|
|
|
|
<device>:<integer> in /etc/shorewall/interfaces
|
|
|
|
|
|
now generate an error.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall 1.4 implements behavior consistent with
|
|
|
|
|
|
OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an
|
|
|
|
|
|
error at startup as will specification of the 'noping' or
|
|
|
|
|
|
'filterping' interface options.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'routestopped' option in the
|
|
|
|
|
|
/etc/shorewall/interfaces and /etc/shorewall/hosts files is
|
|
|
|
|
|
no longer supported and will generate an error at startup if
|
|
|
|
|
|
specified.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is
|
|
|
|
|
|
no longer accepted.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ALLOWRELATED variable in shorewall.conf is no longer
|
|
|
|
|
|
supported. Shorewall 1.4 behavior is the same as 1.3 with
|
|
|
|
|
|
ALLOWRELATED=Yes.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The icmp.def file has been removed.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Changes for 1.4 include:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>The /etc/shorewall/shorewall.conf file has been
|
|
|
|
|
|
completely reorganized into logical sections.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>LOG is now a valid action for a rule
|
|
|
|
|
|
(/etc/shorewall/rules).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The firewall script and version file are now installed in
|
|
|
|
|
|
/usr/share/shorewall.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Late arriving DNS replies are now silently dropped in the
|
|
|
|
|
|
common chain by default.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In addition to behaving like OLD_PING_HANDLING=No,
|
|
|
|
|
|
Shorewall 1.4 no longer unconditionally accepts outbound ICMP
|
|
|
|
|
|
packets. So if you want to 'ping' from the firewall, you will
|
|
|
|
|
|
need the appropriate rule or policy.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>CONTINUE is now a valid action for a rule
|
|
|
|
|
|
(/etc/shorewall/rules).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>802.11b devices with names of the form wlan<n> now
|
|
|
|
|
|
support the 'maclist' option.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Explicit Congestion Notification (ECN - RFC 3168) may now
|
|
|
|
|
|
be turned off on a host or network basis using the new
|
|
|
|
|
|
/etc/shorewall/ecn file. To use this facility:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) You must be running kernel 2.4.20<br>
|
|
|
|
|
|
b) You must have applied the patch in<br>
|
|
|
|
|
|
|
|
|
|
|
|
http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
|
|
|
|
|
|
c) You must have iptables 1.2.7a installed.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /etc/shorewall/params file is now processed first so
|
|
|
|
|
|
that variables may be used in the
|
|
|
|
|
|
/etc/shorewall/shorewall.conf file.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li value="10">Shorewall now gives a more helpful diagnostic
|
|
|
|
|
|
when the 'ipchains' compatibility kernel module is loaded and
|
|
|
|
|
|
a 'shorewall start' command is issued.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The SHARED_DIR variable has been removed from
|
|
|
|
|
|
shorewall.conf. This variable was for use by package
|
|
|
|
|
|
maintainers and was not documented for general use.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now ignores 'default' routes when detecting
|
|
|
|
|
|
masq'd networks.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/10/2003 - Shoreall 1.3.14a</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>A roleup of the following bug fixes and other updates:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>There is an updated rfc1918 file that reflects the resent
|
|
|
|
|
|
allocation of 222.0.0.0/8 and 223.0.0.0/8.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The documentation for the routestopped file claimed that
|
|
|
|
|
|
a comma-separated list could appear in the second column
|
|
|
|
|
|
while the code only supported a single host or network
|
|
|
|
|
|
address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Log messages produced by 'logunclean' and 'dropunclean'
|
|
|
|
|
|
were not rate-limited.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>802.11b devices with names of the form
|
|
|
|
|
|
<i>wlan</i><n> don't support the 'maclist' interface
|
|
|
|
|
|
option.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Log messages generated by RFC 1918 filtering are not rate
|
|
|
|
|
|
limited.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The firewall fails to start in the case where you have
|
|
|
|
|
|
"eth0 eth1" in /etc/shorewall/masq and the default route is
|
|
|
|
|
|
through eth1</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/8/2003 - Shoreawall 1.3.14</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>New features include</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>An OLD_PING_HANDLING option has been added to
|
|
|
|
|
|
shorewall.conf. When set to Yes, Shorewall ping handling is
|
|
|
|
|
|
as it has always been (see
|
|
|
|
|
|
http://www.shorewall.net/ping.html).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via
|
|
|
|
|
|
rules and policies just like any other connection request.
|
|
|
|
|
|
The FORWARDPING=Yes option in shorewall.conf and the 'noping'
|
|
|
|
|
|
and 'filterping' options in /etc/shorewall/interfaces will
|
|
|
|
|
|
all generate an error.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is now possible to direct Shorewall to create a
|
|
|
|
|
|
"label" such as "eth0:0" for IP addresses that it
|
|
|
|
|
|
creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
|
|
|
|
|
|
This is done by specifying the label instead of just the
|
|
|
|
|
|
interface name:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) In the INTERFACE column of
|
|
|
|
|
|
/etc/shorewall/masq<br>
|
|
|
|
|
|
b) In the INTERFACE column of
|
|
|
|
|
|
/etc/shorewall/nat<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for OpenVPN Tunnels.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for VLAN devices with names of the form $DEV.$VID
|
|
|
|
|
|
(e.g., eth0.0)<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In /etc/shorewall/tcrules, the MARK value may be
|
|
|
|
|
|
optionally followed by ":" and either 'F' or 'P' to designate
|
|
|
|
|
|
that the marking will occur in the FORWARD or PREROUTING
|
|
|
|
|
|
chains respectively. If this additional specification is
|
|
|
|
|
|
omitted, the chain used to mark packets will be determined by
|
|
|
|
|
|
the setting of the MARK_IN_FORWARD_CHAIN option in <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">shorewall.conf</a>.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
When an interface name is entered in the SUBNET column of
|
|
|
|
|
|
the /etc/shorewall/masq file, Shorewall previously
|
|
|
|
|
|
masqueraded traffic from only the first subnet defined on
|
|
|
|
|
|
that interface. It did not masquerade traffic from:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) The subnets associated with other addresses
|
|
|
|
|
|
on the interface.<br>
|
|
|
|
|
|
b) Subnets accessed through local routers.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Beginning with Shorewall 1.3.14, if you enter an interface
|
|
|
|
|
|
name in the SUBNET column, shorewall will use the
|
|
|
|
|
|
firewall's routing table to construct the masquerading/SNAT
|
|
|
|
|
|
rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 1 -- This is how it works in 1.3.14.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# cat /etc/shorewall/masq<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
|
|
|
|
eth0 eth2 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# ip route show dev eth2<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
192.168.1.0/24 scope link<br>
|
|
|
|
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# shorewall start<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
...<br>
|
|
|
|
|
|
Masqueraded Subnets and Hosts:<br>
|
|
|
|
|
|
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
|
|
|
|
|
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
|
|
|
|
|
Processing /etc/shorewall/tos...
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When upgrading to Shorewall 1.3.14, if you have multiple
|
|
|
|
|
|
local subnets connected to an interface that is specified
|
|
|
|
|
|
in the SUBNET column of an /etc/shorewall/masq entry, your
|
|
|
|
|
|
/etc/shorewall/masq file will need changing. In most cases,
|
|
|
|
|
|
you will simply be able to remove redundant entries. In
|
|
|
|
|
|
some cases though, you might want to change from using the
|
|
|
|
|
|
interface name to listing specific subnetworks if the
|
|
|
|
|
|
change described above will cause masquerading to occur on
|
|
|
|
|
|
subnetworks that you don't wish to masquerade.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 2 -- Suppose that your current config is as
|
|
|
|
|
|
follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# cat /etc/shorewall/masq<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
|
|
|
|
eth0 eth2 206.124.146.176<br>
|
|
|
|
|
|
eth0 192.168.10.0/24 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# ip route show dev eth2<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
192.168.1.0/24 scope link<br>
|
|
|
|
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
|
|
|
|
[root@gateway test]#
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In this case, the second entry in
|
|
|
|
|
|
/etc/shorewall/masq is no longer required.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 3 -- What if your current configuration is like
|
|
|
|
|
|
this?<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# cat /etc/shorewall/masq<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
|
|
|
|
eth0 eth2 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# ip route show dev eth2<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
192.168.1.0/24 scope link<br>
|
|
|
|
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
|
|
|
|
[root@gateway test]#
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In this case, you would want to change the
|
|
|
|
|
|
entry in /etc/shorewall/masq to:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
eth0 192.168.1.0/24 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><br>
|
|
|
|
|
|
<b>2/5/2003 - Shorewall Support included in Webmin
|
|
|
|
|
|
1.060</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Webmin version 1.060 now has Shorewall support included as
|
|
|
|
|
|
standard. See <a href=
|
|
|
|
|
|
"http://www.webmin.com">http://www.webmin.com</a>.<br>
|
|
|
|
|
|
<b><br>
|
|
|
|
|
|
2/4/2003 - Shorewall 1.3.14-RC1</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Includes the Beta 2 content plus support for OpenVPN
|
|
|
|
|
|
tunnels.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Includes the Beta 1 content plus restores VLAN device names
|
|
|
|
|
|
of the form $dev.$vid (e.g., eth0.1)</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The Beta includes the following changes:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>An OLD_PING_HANDLING option has been added to
|
|
|
|
|
|
shorewall.conf. When set to Yes, Shorewall ping handling is
|
|
|
|
|
|
as it has always been (see
|
|
|
|
|
|
http://www.shorewall.net/ping.html).<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via
|
|
|
|
|
|
rules and policies just like any other connection request.
|
|
|
|
|
|
The FORWARDPING=Yes option in shorewall.conf and the 'noping'
|
|
|
|
|
|
and 'filterping' options in /etc/shorewall/interfaces will
|
|
|
|
|
|
all generate an error.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is now possible to direct Shorewall to create a
|
|
|
|
|
|
"label" such as "eth0:0" for IP addresses that it
|
|
|
|
|
|
creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
|
|
|
|
|
|
This is done by specifying the label instead of just the
|
|
|
|
|
|
interface name:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) In the INTERFACE column of
|
|
|
|
|
|
/etc/shorewall/masq<br>
|
|
|
|
|
|
b) In the INTERFACE column of
|
|
|
|
|
|
/etc/shorewall/nat<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
When an interface name is entered in the SUBNET column of
|
|
|
|
|
|
the /etc/shorewall/masq file, Shorewall previously
|
|
|
|
|
|
masqueraded traffic from only the first subnet defined on
|
|
|
|
|
|
that interface. It did not masquerade traffic from:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
a) The subnets associated with other addresses
|
|
|
|
|
|
on the interface.<br>
|
|
|
|
|
|
b) Subnets accessed through local routers.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Beginning with Shorewall 1.3.14, if you enter an interface
|
|
|
|
|
|
name in the SUBNET column, shorewall will use the
|
|
|
|
|
|
firewall's routing table to construct the masquerading/SNAT
|
|
|
|
|
|
rules.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 1 -- This is how it works in 1.3.14.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# cat /etc/shorewall/masq<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
|
|
|
|
eth0 eth2 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# ip route show dev eth2<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
192.168.1.0/24 scope link<br>
|
|
|
|
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# shorewall start<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
...<br>
|
|
|
|
|
|
Masqueraded Subnets and Hosts:<br>
|
|
|
|
|
|
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
|
|
|
|
|
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
|
|
|
|
|
Processing /etc/shorewall/tos...
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
When upgrading to Shorewall 1.3.14, if you have multiple
|
|
|
|
|
|
local subnets connected to an interface that is specified
|
|
|
|
|
|
in the SUBNET column of an /etc/shorewall/masq entry, your
|
|
|
|
|
|
/etc/shorewall/masq file will need changing. In most cases,
|
|
|
|
|
|
you will simply be able to remove redundant entries. In
|
|
|
|
|
|
some cases though, you might want to change from using the
|
|
|
|
|
|
interface name to listing specific subnetworks if the
|
|
|
|
|
|
change described above will cause masquerading to occur on
|
|
|
|
|
|
subnetworks that you don't wish to masquerade.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 2 -- Suppose that your current config is as
|
|
|
|
|
|
follows:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# cat /etc/shorewall/masq<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
|
|
|
|
eth0 eth2 206.124.146.176<br>
|
|
|
|
|
|
eth0 192.168.10.0/24 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# ip route show dev eth2<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
192.168.1.0/24 scope link<br>
|
|
|
|
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
|
|
|
|
[root@gateway test]#
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In this case, the second entry in
|
|
|
|
|
|
/etc/shorewall/masq is no longer required.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example 3 -- What if your current configuration is like
|
|
|
|
|
|
this?<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# cat /etc/shorewall/masq<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
|
|
|
|
eth0 eth2 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
[root@gateway test]# ip route show dev eth2<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
192.168.1.0/24 scope link<br>
|
|
|
|
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
|
|
|
|
[root@gateway test]#
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
In this case, you would want to change the
|
|
|
|
|
|
entry in /etc/shorewall/masq to:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
|
#INTERFACE SUBNET ADDRESS<br>
|
2005-05-20 00:17:37 +02:00
|
|
|
|
eth0 192.168.1.0/24 206.124.146.176<br>
|
|
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF
|
|
|
|
|
|
Format</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Juraj Ontkanin has produced a PDF containing the Shorewall
|
|
|
|
|
|
1.3.13 documenation. the PDF may be downloaded from</p>
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target=
|
|
|
|
|
|
"_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/17/2003 - shorewall.net has MOVED</b><b> </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to the generosity of Alex Martin and <a href=
|
|
|
|
|
|
"http://www.rettc.com">Rett Consulting</a>, www.shorewall.net
|
|
|
|
|
|
and ftp.shorewall.net are now hosted on a system in Bellevue,
|
|
|
|
|
|
Washington. A big thanks to Alex for making this happen.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/13/2003 - Shorewall 1.3.13<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Just includes a few things that I had on the burner:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>A new 'DNAT-' action has been added for entries in the
|
|
|
|
|
|
/etc/shorewall/rules file. DNAT- is intended for advanced
|
|
|
|
|
|
users who wish to minimize the number of rules that
|
|
|
|
|
|
connection requests must traverse.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
A Shorewall DNAT rule actually generates two iptables rules:
|
|
|
|
|
|
a header rewriting rule in the 'nat' table and an ACCEPT rule
|
|
|
|
|
|
in the 'filter' table. A DNAT- rule only generates the first
|
|
|
|
|
|
of these rules. This is handy when you have several DNAT
|
|
|
|
|
|
rules that would generate the same ACCEPT rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Here are three rules from my previous rules
|
|
|
|
|
|
file:<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DNAT
|
|
|
|
|
|
net dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
|
|
|
|
|
|
DNAT
|
|
|
|
|
|
net dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
These three rules ended up generating _three_
|
|
|
|
|
|
copies of<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT
|
|
|
|
|
|
net dmz:206.124.146.177 tcp smtp<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
By writing the rules this way, I end up with
|
|
|
|
|
|
only one copy of the ACCEPT rule.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
DNAT-
|
|
|
|
|
|
net dmz:206.124.146.177 tcp smtp -
|
|
|
|
|
|
206.124.146.178<br>
|
|
|
|
|
|
DNAT-
|
|
|
|
|
|
net dmz:206.124.146.177 tcp smtp -
|
|
|
|
|
|
206.124.146.179<br>
|
|
|
|
|
|
ACCEPT net
|
|
|
|
|
|
dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'shorewall check' command now prints out the
|
|
|
|
|
|
applicable policy between each pair of zones.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new CLEAR_TC option has been added to shorewall.conf.
|
|
|
|
|
|
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.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new SHARED_DIR variable has been added that allows
|
|
|
|
|
|
distribution packagers to easily move the shared directory
|
|
|
|
|
|
(default /usr/lib/shorewall). Users should never have a need
|
|
|
|
|
|
to change the value of this shorewall.conf setting.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/6/2003 -
|
|
|
|
|
|
<big><big><big>BURNOUT</big></big></big></b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>Until further notice, I will not be involved in either
|
|
|
|
|
|
Shorewall Development or Shorewall Support</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>-Tom Eastep</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/30/2002 - Shorewall Documentation in PDF
|
|
|
|
|
|
Format</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Juraj Ontkanin has produced a PDF containing the Shorewall
|
|
|
|
|
|
1.3.12 documenation. the PDF may be downloaded from</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p> <a href=
|
|
|
|
|
|
"ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target=
|
|
|
|
|
|
"_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Features include:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>"shorewall refresh" now reloads the traffic shaping rules
|
|
|
|
|
|
(tcrules and tcstart).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>"shorewall debug [re]start" now turns off debugging after
|
|
|
|
|
|
an error occurs. This places the point of the failure near
|
|
|
|
|
|
the end of the trace rather than up in the middle of it.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>"shorewall [re]start" has been speeded up by more than
|
|
|
|
|
|
40% with my configuration. Your milage may vary.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "shorewall show classifiers" command has been added
|
|
|
|
|
|
which shows the current packet classification filters. The
|
|
|
|
|
|
output from this command is also added as a separate page in
|
|
|
|
|
|
"shorewall monitor"</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ULOG (must be all caps) is now accepted as a valid syslog
|
|
|
|
|
|
level and causes the subject packets to be logged using the
|
|
|
|
|
|
ULOG target rather than the LOG target. This allows you to
|
|
|
|
|
|
run ulogd (available from <a href=
|
|
|
|
|
|
"http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
|
|
|
|
|
|
and log all Shorewall messages <a href=
|
|
|
|
|
|
"shorewall_logging.html">to a separate log file</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If you are running a kernel that has a FORWARD chain in
|
|
|
|
|
|
the mangle table ("shorewall show mangle" will show you the
|
|
|
|
|
|
chains in the mangle table), you can set
|
|
|
|
|
|
MARK_IN_FORWARD_CHAIN=Yes in <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">shorewall.conf</a>. This allows for
|
|
|
|
|
|
marking input packets based on their destination even when
|
|
|
|
|
|
you are using Masquerading or SNAT.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>I have cluttered up the /etc/shorewall directory with
|
|
|
|
|
|
empty 'init', 'start', 'stop' and 'stopped' files. If you
|
|
|
|
|
|
already have a file with one of these names, don't worry --
|
|
|
|
|
|
the upgrade process won't overwrite your file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>I have added a new RFC1918_LOG_LEVEL variable to <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">shorewall.conf</a>. This variable
|
|
|
|
|
|
specifies the syslog level at which packets are logged as a
|
|
|
|
|
|
result of entries in the /etc/shorewall/rfc1918 file.
|
|
|
|
|
|
Previously, these packets were always logged at the 'info'
|
|
|
|
|
|
level.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
This version corrects a problem with Blacklist logging. In Beta
|
|
|
|
|
|
2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the
|
|
|
|
|
|
firewall would fail to start and "shorewall refresh" would also
|
|
|
|
|
|
fail.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The first public Beta version of Shorewall 1.3.12 is now
|
|
|
|
|
|
available (Beta 1 was made available only to a limited
|
|
|
|
|
|
audience).<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
Features include:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>"shorewall refresh" now reloads the traffic shaping rules
|
|
|
|
|
|
(tcrules and tcstart).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>"shorewall debug [re]start" now turns off debugging after
|
|
|
|
|
|
an error occurs. This places the point of the failure near
|
|
|
|
|
|
the end of the trace rather than up in the middle of it.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>"shorewall [re]start" has been speeded up by more than
|
|
|
|
|
|
40% with my configuration. Your milage may vary.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "shorewall show classifiers" command has been added
|
|
|
|
|
|
which shows the current packet classification filters. The
|
|
|
|
|
|
output from this command is also added as a separate page in
|
|
|
|
|
|
"shorewall monitor"</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>ULOG (must be all caps) is now accepted as a valid syslog
|
|
|
|
|
|
level and causes the subject packets to be logged using the
|
|
|
|
|
|
ULOG target rather than the LOG target. This allows you to
|
|
|
|
|
|
run ulogd (available from <a href=
|
|
|
|
|
|
"http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
|
|
|
|
|
|
and log all Shorewall messages <a href=
|
|
|
|
|
|
"shorewall_logging.html">to a separate log file</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If you are running a kernel that has a FORWARD chain in
|
|
|
|
|
|
the mangle table ("shorewall show mangle" will show you the
|
|
|
|
|
|
chains in the mangle table), you can set
|
|
|
|
|
|
MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for
|
|
|
|
|
|
marking input packets based on their destination even when
|
|
|
|
|
|
you are using Masquerading or SNAT.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>I have cluttered up the /etc/shorewall directory with
|
|
|
|
|
|
empty 'init', 'start', 'stop' and 'stopped' files. If you
|
|
|
|
|
|
already have a file with one of these names, don't worry --
|
|
|
|
|
|
the upgrade process won't overwrite your file.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
You may download the Beta from:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target=
|
|
|
|
|
|
"_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a href=
|
|
|
|
|
|
"http://www.mandrakesoft.com"><img src="images/logo2.png" alt=
|
|
|
|
|
|
"Powered by Mandrake Linux" border="0" height="21" width="140">
|
|
|
|
|
|
</a></b></p>
|
|
|
|
|
|
Shorewall is at the center of MandrakeSoft's recently-announced
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&id_art=250&LANG_=en#GOTO_250">
|
|
|
|
|
|
Multi Network Firewall (MNF)</a> product. Here is the <a href=
|
|
|
|
|
|
"http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">
|
|
|
|
|
|
press release</a>.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Two months and 3 days after I ordered Mandrake 9.0, it was
|
|
|
|
|
|
finally delivered. I have installed 9.0 on one of my systems
|
|
|
|
|
|
and I am now in a position to support Shorewall users who run
|
|
|
|
|
|
Mandrake 9.0.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/6/2002 - Debian 1.3.11a Packages Available<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Apt-get sources listed at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/3/2002 - Shorewall 1.3.11a</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This is a bug-fix roll up which includes Roger Aich's fix
|
|
|
|
|
|
for DNAT with excluded subnets (e.g., "DNAT foo!bar ...").
|
|
|
|
|
|
Current 1.3.11 users who don't need rules of this type need not
|
|
|
|
|
|
upgrade to 1.3.11.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/24/2002 - Shorewall 1.3.11</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>A 'tcpflags' option has been added to entries in <a href=
|
|
|
|
|
|
"Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
|
|
|
|
|
|
This option causes Shorewall to make a set of sanity check on
|
|
|
|
|
|
TCP packet header flags.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is now allowed to use 'all' in the SOURCE or DEST
|
|
|
|
|
|
column in a <a href="Documentation.htm#Rules">rule</a>. When
|
|
|
|
|
|
used, 'all' must appear by itself (in may not be qualified)
|
|
|
|
|
|
and it does not enable intra-zone traffic. For example, the
|
|
|
|
|
|
rule<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
ACCEPT loc all tcp 80<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
does not enable http traffic from 'loc' to 'loc'.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall's use of the 'echo' command is now compatible
|
|
|
|
|
|
with bash clones such as ash and dash.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>fw->fw policies now generate a startup error.
|
|
|
|
|
|
fw->fw rules generate a warning and are ignored</li>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<p><b>11/14/2002 - Shorewall Documentation in PDF
|
|
|
|
|
|
Format</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Juraj Ontkanin has produced a PDF containing the Shorewall
|
|
|
|
|
|
1.3.10 documenation. the PDF may be downloaded from</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p> <a href=
|
|
|
|
|
|
"ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target=
|
|
|
|
|
|
"_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
|
|
|
|
|
|
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/09/2002 - Shorewall is Back at SourceForge</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The main Shorewall 1.3 web site is now back at SourceForge
|
|
|
|
|
|
at <a href="http://shorewall.sf.net" target=
|
|
|
|
|
|
"_top">http://shorewall.sf.net</a>.<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/09/2002 - Shorewall 1.3.10</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>You may now <a href="IPSEC.htm#Dynamic">define the
|
|
|
|
|
|
contents of a zone dynamically</a> with the <a href=
|
|
|
|
|
|
"starting_and_stopping_shorewall.htm">"shorewall add" and
|
|
|
|
|
|
"shorewall delete" commands</a>. These commands are expected
|
|
|
|
|
|
to be used primarily within <a href=
|
|
|
|
|
|
"http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
|
|
|
|
|
|
scripts.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall can now do <a href="MAC_Validation.html">MAC
|
|
|
|
|
|
verification</a> on ethernet segments. You can specify the
|
|
|
|
|
|
set of allowed MAC addresses on the segment and you can
|
|
|
|
|
|
optionally tie each MAC address to one or more IP
|
|
|
|
|
|
addresses.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>PPTP Servers and Clients running on the firewall system
|
|
|
|
|
|
may now be defined in the <a href=
|
|
|
|
|
|
"PPTP.htm">/etc/shorewall/tunnels</a> file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new 'ipsecnat' tunnel type is supported for use when
|
|
|
|
|
|
the <a href="IPSEC.htm">remote IPSEC endpoint is behind a NAT
|
|
|
|
|
|
gateway</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The PATH used by Shorewall may now be specified in <a
|
|
|
|
|
|
href=
|
|
|
|
|
|
"Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The main firewall script is now
|
|
|
|
|
|
/usr/lib/shorewall/firewall. The script in
|
|
|
|
|
|
/etc/init.d/shorewall is very small and uses /sbin/shorewall
|
|
|
|
|
|
to do the real work. This change makes custom distributions
|
|
|
|
|
|
such as for Debian and for Gentoo easier to manage since it
|
|
|
|
|
|
is /etc/init.d/shorewall that tends to have
|
|
|
|
|
|
distribution-dependent code</li>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<p><b>10/24/2002 - Shorewall is now in Gentoo Linux</b> <a
|
|
|
|
|
|
href="http://www.gentoo.org"><br>
|
|
|
|
|
|
</a></p>
|
|
|
|
|
|
Alexandru Hartmann reports that his Shorewall package is now a
|
|
|
|
|
|
part of <a href="http://www.gentoo.org">the Gentoo Linux
|
|
|
|
|
|
distribution</a>. Thanks Alex!<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/23/2002 - Shorewall 1.3.10 Beta 1</b></p>
|
|
|
|
|
|
In this version:<br>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li>You may now <a href="IPSEC.htm#Dynamic">define the
|
|
|
|
|
|
contents of a zone dynamically</a> with the <a href=
|
|
|
|
|
|
"starting_and_stopping_shorewall.htm">"shorewall add" and
|
|
|
|
|
|
"shorewall delete" commands</a>. These commands are expected
|
|
|
|
|
|
to be used primarily within <a href=
|
|
|
|
|
|
"http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
|
|
|
|
|
|
scripts.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall can now do <a href="MAC_Validation.html">MAC
|
|
|
|
|
|
verification</a> on ethernet segments. You can specify the
|
|
|
|
|
|
set of allowed MAC addresses on the segment and you can
|
|
|
|
|
|
optionally tie each MAC address to one or more IP
|
|
|
|
|
|
addresses.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>PPTP Servers and Clients running on the firewall system
|
|
|
|
|
|
may now be defined in the <a href=
|
|
|
|
|
|
"PPTP.htm">/etc/shorewall/tunnels</a> file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new 'ipsecnat' tunnel type is supported for use when
|
|
|
|
|
|
the <a href="IPSEC.htm">remote IPSEC endpoint is behind a NAT
|
|
|
|
|
|
gateway</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The PATH used by Shorewall may now be specified in <a
|
|
|
|
|
|
href=
|
|
|
|
|
|
"Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The main firewall script is now
|
|
|
|
|
|
/usr/lib/shorewall/firewall. The script in
|
|
|
|
|
|
/etc/init.d/shorewall is very small and uses /sbin/shorewall
|
|
|
|
|
|
to do the real work. This change makes custom distributions
|
|
|
|
|
|
such as for Debian and for Gentoo easier to manage since it
|
|
|
|
|
|
is /etc/init.d/shorewall that tends to have
|
|
|
|
|
|
distribution-dependent code.</li>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
You may download the Beta from:<br>
|
|
|
|
|
|
|
2003-12-31 03:54:31 +01:00
|
|
|
|
<ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
<li><a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a></li>
|
2003-12-31 03:54:31 +01:00
|
|
|
|
</ul>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
|
|
|
|
|
<p><b>10/10/2002 - Debian 1.3.9b Packages Available<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Apt-get sources listed at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/9/2002 - Shorewall 1.3.9b</b></p>
|
|
|
|
|
|
This release rolls up fixes to the installer and to the
|
|
|
|
|
|
firewall script.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/6/2002 - Shorewall.net now running on RH8.0<br>
|
|
|
|
|
|
</b><br>
|
|
|
|
|
|
The firewall and server here at shorewall.net are now running
|
|
|
|
|
|
RedHat release 8.0.<br>
|
|
|
|
|
|
<b><br>
|
|
|
|
|
|
9/30/2002 - Shorewall 1.3.9a</b></p>
|
|
|
|
|
|
Roles up the fix for broken tunnels.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/30/2002 - TUNNELS Broken in 1.3.9!!!</b></p>
|
|
|
|
|
|
There is an updated firewall script at <a href=
|
|
|
|
|
|
"ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
|
|
|
|
|
|
target=
|
|
|
|
|
|
"_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
|
|
|
|
|
|
-- copy that file to /usr/lib/shorewall/firewall.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/28/2002 - Shorewall 1.3.9</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="configuration_file_basics.htm#dnsnames">DNS
|
|
|
|
|
|
Names</a> are now allowed in Shorewall config files (although
|
|
|
|
|
|
I recommend against using them).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The connection SOURCE may now be qualified by both
|
|
|
|
|
|
interface and IP address in a <a href=
|
|
|
|
|
|
"Documentation.htm#Rules">Shorewall rule</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall startup is now disabled after initial
|
|
|
|
|
|
installation until the file /etc/shorewall/startup_disabled
|
|
|
|
|
|
is removed. This avoids nasty surprises during reboot for
|
|
|
|
|
|
users who install Shorewall but don't configure it.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'functions' and 'version' files and the 'firewall'
|
|
|
|
|
|
symbolic link have been moved from /var/lib/shorewall to
|
|
|
|
|
|
/usr/lib/shorewall to appease the LFS police at Debian.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive
|
|
|
|
|
|
Search Capability Restored</b><br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
<img src="images/j0233056.gif" alt="Brown Paper Bag" align=
|
|
|
|
|
|
"left" height="86" width="50"> A couple of recent configuration
|
|
|
|
|
|
changes at www.shorewall.net broke the Search facility:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Mailing List Archive Search was not available.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Site Search index was incomplete</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Only one page of matches was presented.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
Hopefully these problems are now corrected.
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive
|
|
|
|
|
|
Search Capability Restored<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
A couple of recent configuration changes at www.shorewall.net
|
|
|
|
|
|
had the negative effect of breaking the Search facility:<br>
|
|
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
|
<li>Mailing List Archive Search was not available.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Site Search index was incomplete</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Only one page of matches was presented.</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
Hopefully these problems are now corrected.<br>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/18/2002 - Debian 1.3.8 Packages Available<br>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Apt-get sources listed at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/16/2002 - Shorewall 1.3.8</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:<br>
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A <a href="Documentation.htm#Conf">NEWNOTSYN</a> option
|
|
|
|
|
|
has been added to shorewall.conf. This option determines
|
|
|
|
|
|
whether Shorewall accepts TCP packets which are not part of
|
|
|
|
|
|
an established connection and that are not 'SYN' packets (SYN
|
|
|
|
|
|
flag on and ACK flag off).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The need for the 'multi' option to communicate between
|
|
|
|
|
|
zones za and zb on the same interface is removed in the case
|
|
|
|
|
|
where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will
|
|
|
|
|
|
exist if:</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li style=
|
|
|
|
|
|
"list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>There is a policy for za to zb; or</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>There is at least one rule for za to zb.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The /etc/shorewall/blacklist file now contains three
|
|
|
|
|
|
columns. In addition to the SUBNET/ADDRESS column, there are
|
|
|
|
|
|
optional PROTOCOL and PORT columns to block only certain
|
|
|
|
|
|
applications from the blacklisted addresses.<br>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/11/2002 - Debian 1.3.7c Packages Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Apt-get sources listed at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/2/2002 - Shorewall 1.3.7c</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This is a role up of a fix for "DNAT" rules where the source
|
|
|
|
|
|
zone is $FW (fw).</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/31/2002 - I'm not available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>I'm currently on vacation -- please respect my need
|
|
|
|
|
|
for a couple of weeks free of Shorewall problem reports.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>-Tom</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/26/2002 - Shorewall 1.3.7b</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This is a role up of the "shorewall refresh" bug fix and the
|
|
|
|
|
|
change which reverses the order of "dhcp" and "norfc1918"
|
|
|
|
|
|
checking.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/26/2002 - French FTP Mirror is Operational</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a target="_blank" href=
|
|
|
|
|
|
"ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
|
|
|
|
|
|
is now available.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/25/2002 - Shorewall Mirror in France</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to a Shorewall user in Paris, the Shorewall web site
|
|
|
|
|
|
is now mirrored at <a target="_top" href=
|
|
|
|
|
|
"http://france.shorewall.net">http://france.shorewall.net</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/25/2002 - Shorewall 1.3.7a Debian Packages
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lorenzo Martignoni reports that the packages for version
|
|
|
|
|
|
1.3.7a are available at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award
|
|
|
|
|
|
for its Author -- Shorewall 1.3.7a released<img src=
|
|
|
|
|
|
"images/j0233056.gif" alt="Brown Paper Bag Graphic" align=
|
|
|
|
|
|
"middle" border="0" height="80" width="50"></b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>1.3.7a corrects problems occurring in rules file processing
|
|
|
|
|
|
when starting Shorewall 1.3.7.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/22/2002 - Shorewall 1.3.7 Released 8/13/2002</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Features in this release include:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The 'icmp.def' file is now empty! The rules in that file
|
|
|
|
|
|
were required in ipchains firewalls but are not required in
|
|
|
|
|
|
Shorewall. Users who have ALLOWRELATED=No in <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">shorewall.conf</a> should see the <a
|
|
|
|
|
|
href="errata.htm#Upgrade">Upgrade Issues</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A 'FORWARDPING' option has been added to <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">shorewall.conf</a>. The effect of
|
|
|
|
|
|
setting this variable to Yes is the same as the effect of
|
|
|
|
|
|
adding an ACCEPT rule for ICMP echo-request in <a href=
|
|
|
|
|
|
"shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>.
|
|
|
|
|
|
Users who have such a rule in icmpdef are encouraged to
|
|
|
|
|
|
switch to FORWARDPING=Yes.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The loopback CLASS A Network (127.0.0.0/8) has been added
|
|
|
|
|
|
to the rfc1918 file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now works with iptables 1.2.7</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The documentation and web site no longer uses FrontPage
|
|
|
|
|
|
themes.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p>I would like to thank John Distler for his valuable input
|
|
|
|
|
|
regarding TCP SYN and ICMP treatment in Shorewall. That input
|
|
|
|
|
|
has led to marked improvement in Shorewall in the last two
|
|
|
|
|
|
releases.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/13/2002 - Documentation in the <a target="_top" href=
|
|
|
|
|
|
"http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
|
|
|
|
|
|
Repository</a></b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The Shorewall-docs project now contains just the HTML and
|
|
|
|
|
|
image files - the Frontpage files have been removed.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/7/2002 - <i>STABLE</i></b> <b>branch added to <a
|
|
|
|
|
|
target="_top" href=
|
|
|
|
|
|
"http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
|
|
|
|
|
|
Repository</a></b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This branch will only be updated after I release a new
|
|
|
|
|
|
version of Shorewall so you can always update from this branch
|
|
|
|
|
|
to get the latest stable tree.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/7/2002 - <a href="errata.htm#Upgrade">Upgrade
|
|
|
|
|
|
Issues</a> section added to the <a href="errata.htm">Errata
|
|
|
|
|
|
Page</a></b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Now there is one place to go to look for issues involved
|
|
|
|
|
|
with upgrading to recent versions of Shorewall.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/7/2002 - Shorewall 1.3.6</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This is primarily a bug-fix rollup with a couple of new
|
|
|
|
|
|
features:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The latest <a href=
|
|
|
|
|
|
"shorewall_quickstart_guide.htm">QuickStart Guides</a>
|
|
|
|
|
|
including the <a href="shorewall_setup_guide.htm">Shorewall
|
|
|
|
|
|
Setup Guide.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall will now DROP TCP packets that are not part of
|
|
|
|
|
|
or related to an existing connection and that are not SYN
|
|
|
|
|
|
packets. These "New not SYN" packets may be optionally logged
|
|
|
|
|
|
by setting the LOGNEWNOTSYN option in <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The processing of "New not SYN" packets may be extended
|
|
|
|
|
|
by commands in the new <a href=
|
|
|
|
|
|
"shorewall_extension_scripts.htm">newnotsyn extension
|
|
|
|
|
|
script</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This interim release:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Causes the firewall script to remove the lock file if it
|
|
|
|
|
|
is killed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Once again allows lists in the second column of the <a
|
|
|
|
|
|
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
|
|
|
|
|
|
file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Includes the latest <a href=
|
|
|
|
|
|
"shorewall_quickstart_guide.htm">QuickStart Guides</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/29/2002 - New Shorewall Setup Guide Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The first draft of this guide is available at <a href=
|
|
|
|
|
|
"http://www.shorewall.net/shorewall_setup_guide.htm">http://www.shorewall.net/shorewall_setup_guide.htm</a>.
|
|
|
|
|
|
The guide is intended for use by people who are setting up
|
|
|
|
|
|
Shorewall to manage multiple public IP addresses and by people
|
|
|
|
|
|
who want to learn more about Shorewall than is described in the
|
|
|
|
|
|
single-address guides. Feedback on the new guide is
|
|
|
|
|
|
welcome.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/28/2002 - Shorewall 1.3.5 Debian Package
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lorenzo Martignoni reports that the packages are version
|
|
|
|
|
|
1.3.5a and are available at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/27/2002 - Shorewall 1.3.5a Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This interim release restores correct handling of REDIRECT
|
|
|
|
|
|
rules.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/26/2002 - Shorewall 1.3.5 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This will be the last Shorewall release for a while. I'm
|
|
|
|
|
|
going to be focusing on rewriting a lot of the
|
|
|
|
|
|
documentation.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b> </b> In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Empty and invalid source and destination qualifiers are
|
|
|
|
|
|
now detected in the rules file. It is a good idea to use the
|
|
|
|
|
|
'shorewall check' command before you issue a 'shorewall
|
|
|
|
|
|
restart' command be be sure that you don't have any
|
|
|
|
|
|
configuration problems that will prevent a successful
|
|
|
|
|
|
restart.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Added <b>MERGE_HOSTS</b> variable in <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">shorewall.conf</a> to provide saner
|
|
|
|
|
|
behavior of the /etc/shorewall/hosts file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The time that the counters were last reset is now
|
|
|
|
|
|
displayed in the heading of the 'status' and 'show'
|
|
|
|
|
|
commands.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A <b>proxyarp</b> option has been added for entries in <a
|
|
|
|
|
|
href=
|
|
|
|
|
|
"Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
|
|
|
|
|
|
This option facilitates Proxy ARP sub-netting as described in
|
|
|
|
|
|
the Proxy ARP subnetting mini-HOWTO (<a href=
|
|
|
|
|
|
"http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>).
|
|
|
|
|
|
Specifying the proxyarp option for an interface causes
|
|
|
|
|
|
Shorewall to set
|
|
|
|
|
|
/proc/sys/net/ipv4/conf/<interface>/proxy_arp.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Samples have been updated to reflect the new
|
|
|
|
|
|
capabilities in this release.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/16/2002 - New Mirror in Argentina</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to Arturo "Buanzo" Busleiman, there is now a
|
|
|
|
|
|
Shorewall mirror in Argentina. Thanks Buanzo!!!</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/16/2002 - Shorewall 1.3.4 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A new <a href=
|
|
|
|
|
|
"Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>
|
|
|
|
|
|
file has been added. This file is intended to eventually
|
|
|
|
|
|
replace the <b>routestopped</b> option in the
|
|
|
|
|
|
/etc/shorewall/interface and /etc/shorewall/hosts files. This
|
|
|
|
|
|
new file makes remote firewall administration easier by
|
|
|
|
|
|
allowing any IP or subnet to be enabled while Shorewall is
|
|
|
|
|
|
stopped.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>An /etc/shorewall/stopped <a href=
|
|
|
|
|
|
"Documentation.htm#Scripts">extension script</a> has been
|
|
|
|
|
|
added. This script is invoked after Shorewall has
|
|
|
|
|
|
stopped.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A <b>DETECT_DNAT_ADDRS</b> option has been added to <a
|
|
|
|
|
|
href=
|
|
|
|
|
|
"Documentation.htm#Conf">/etc/shoreall/shorewall.conf</a>.
|
|
|
|
|
|
When this option is selected, DNAT rules only apply when the
|
|
|
|
|
|
destination address is the external interface's primary IP
|
|
|
|
|
|
address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The <a href="shorewall_quickstart_guide.htm">QuickStart
|
|
|
|
|
|
Guide</a> has been broken into three guides and has been
|
|
|
|
|
|
almost entirely rewritten.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Samples have been updated to reflect the new
|
|
|
|
|
|
capabilities in this release.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/8/2002 - Shorewall 1.3.3 Debian Package
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lorenzo Marignoni reports that the packages are available at
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/6/2002 - Shorewall 1.3.3 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Entries in /etc/shorewall/interface that use the wildcard
|
|
|
|
|
|
character ("+") now have the "multi" option assumed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 'rfc1918' chain in the mangle table has been renamed
|
|
|
|
|
|
'man1918' to make log messages generated from that chain
|
|
|
|
|
|
distinguishable from those generated by the 'rfc1918' chain
|
|
|
|
|
|
in the filter table.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Interface names appearing in the hosts file are now
|
|
|
|
|
|
validated against the interfaces file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The TARGET column in the rfc1918 file is now checked for
|
|
|
|
|
|
correctness.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The chain structure in the nat table has been changed to
|
|
|
|
|
|
reduce the number of rules that a packet must traverse and to
|
|
|
|
|
|
correct problems with NAT_BEFORE_RULES=No</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "hits" command has been enhanced.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/25/2002 - Samples Updated for 1.3.2</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The comments in the sample configuration files have been
|
|
|
|
|
|
updated to reflect new features introduced in Shorewall
|
|
|
|
|
|
1.3.2.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/25/2002 - Shorewall 1.3.1 Debian Package
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lorenzo Marignoni reports that the package is available at
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/19/2002 - Documentation Available in PDF Format</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to Mike Martinez, the Shorewall Documentation is now
|
|
|
|
|
|
available for <a href="download.htm">download</a> in <a href=
|
|
|
|
|
|
"http://www.adobe.com">Adobe</a> PDF format.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/16/2002 - Shorewall 1.3.2 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A <a href="Documentation.htm#Starting">logwatch
|
|
|
|
|
|
command</a> has been added to /sbin/shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A <a href="blacklisting_support.htm">dynamic blacklist
|
|
|
|
|
|
facility</a> has been added.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for the <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">Netfilter multiport match
|
|
|
|
|
|
function</a> has been added.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The files <b>firewall, functions</b> and <b>version</b>
|
|
|
|
|
|
have been moved from /etc/shorewall to
|
|
|
|
|
|
/var/lib/shorewall.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/6/2002 - Why CVS Web access is Password
|
|
|
|
|
|
Protected</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Last weekend, I installed the CVS Web package to provide
|
|
|
|
|
|
brower-based access to the Shorewall CVS repository. Since
|
|
|
|
|
|
then, I have had several instances where my server was almost
|
|
|
|
|
|
unusable due to the high load generated by website copying
|
|
|
|
|
|
tools like HTTrack and WebStripper. These mindless tools:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Ignore robot.txt files.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Recursively copy everything that they find.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Should be classified as weapons rather than tools.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p>These tools/weapons are particularly damaging when combined
|
|
|
|
|
|
with CVS Web because they doggedly follow every link in the
|
|
|
|
|
|
cgi-generated HTML resulting in 1000s of executions of the
|
|
|
|
|
|
cvsweb.cgi script. Yesterday, I spend several hours
|
|
|
|
|
|
implementing measures to block these tools but unfortunately,
|
|
|
|
|
|
these measures resulted in my server OOM-ing under even
|
|
|
|
|
|
moderate load.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Until I have the time to understand the cause of the OOM (or
|
|
|
|
|
|
until I buy more RAM if that is what is required), CVS Web
|
|
|
|
|
|
access will remain Password Protected.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/5/2002 - Shorewall 1.3.1 Debian Package
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lorenzo Marignoni reports that the package is available at
|
|
|
|
|
|
<a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/2/2002 - Samples Corrected</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The 1.3.0 samples configurations had several serious
|
|
|
|
|
|
problems that prevented DNS and SSH from working properly.
|
|
|
|
|
|
These problems have been corrected in the <a href=
|
|
|
|
|
|
"/pub/shorewall/samples-1.3.1">1.3.1 samples.</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/1/2002 - Shorewall 1.3.1 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Hot on the heels of 1.3.0, this release:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Corrects a serious problem with "all <i><zone></i>
|
|
|
|
|
|
CONTINUE" policies. This problem is present in all versions
|
|
|
|
|
|
of Shorewall that support the CONTINUE policy. These previous
|
|
|
|
|
|
versions optimized away the "all2<i><zone></i>" chain
|
|
|
|
|
|
and replaced it with the "all2all" chain with the usual
|
|
|
|
|
|
result that a policy of REJECT was enforced rather than the
|
|
|
|
|
|
intended CONTINUE policy.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Adds an <a href=
|
|
|
|
|
|
"Documentation.htm#rfc1918">/etc/shorewall/rfc1918</a> file
|
|
|
|
|
|
for defining the exact behavior of the <a href=
|
|
|
|
|
|
"Documentation.htm#Interfaces">'norfc1918' interface
|
|
|
|
|
|
option</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/29/2002 - Shorewall 1.3.0 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In addition to the changes in Beta 1, Beta 2 and RC1,
|
|
|
|
|
|
Shorewall 1.3.0 includes:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A 'filterping' interface option that allows ICMP
|
|
|
|
|
|
echo-request (ping) requests addressed to the firewall to be
|
|
|
|
|
|
handled by entries in /etc/shorewall/rules and
|
|
|
|
|
|
/etc/shorewall/policy.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/23/2002 - Shorewall 1.3 RC1 Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In addition to the changes in Beta 1 and Beta 2, RC1
|
|
|
|
|
|
(Version 1.2.92) incorporates the following:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Support for the /etc/shorewall/whitelist file has been
|
|
|
|
|
|
withdrawn. If you need whitelisting, see <a href=
|
|
|
|
|
|
"/1.3/whitelisting_under_shorewall.htm">these
|
|
|
|
|
|
instructions</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/19/2002 - Shorewall 1.3 Beta 2 Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In addition to the changes in Beta 1, this release which
|
|
|
|
|
|
carries the designation 1.2.91 adds:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The structure of the firewall is changed markedly. There
|
|
|
|
|
|
is now an INPUT and a FORWARD chain for each interface; this
|
|
|
|
|
|
reduces the number of rules that a packet must traverse,
|
|
|
|
|
|
especially in complicated setups.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><a href="Documentation.htm#Exclude">Sub-zones may now be
|
|
|
|
|
|
excluded from DNAT and REDIRECT rules.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The names of the columns in a number of the configuration
|
|
|
|
|
|
files have been changed to be more consistent and
|
|
|
|
|
|
self-explanatory and the documentation has been updated
|
|
|
|
|
|
accordingly.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The sample configurations have been updated for 1.3.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/17/2002 - Shorewall 1.3 Beta 1 Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Beta 1 carries the version designation 1.2.90 and implements
|
|
|
|
|
|
the following features:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Simplified rule syntax which makes the intent of each
|
|
|
|
|
|
rule clearer and hopefully makes Shorewall easier to
|
|
|
|
|
|
learn.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Upward compatibility with 1.2 configuration files has
|
|
|
|
|
|
been maintained so that current users can migrate to the new
|
|
|
|
|
|
syntax at their convenience.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><b><font color="#CC6666">WARNING: Compatibility
|
|
|
|
|
|
with the old parameterized sample configurations has NOT been
|
|
|
|
|
|
maintained. Users still running those configurations should
|
|
|
|
|
|
migrate to the new sample configurations before upgrading to
|
|
|
|
|
|
1.3 Beta 1.</font></b></li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/4/2002 - Shorewall 1.2.13 is Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="Documentation.htm#Whitelist">White-listing</a>
|
|
|
|
|
|
is supported.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><a href="Documentation.htm#Policy">SYN-flood
|
|
|
|
|
|
protection</a> is added.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>IP addresses added under <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">ADD_IP_ALIASES and
|
|
|
|
|
|
ADD_SNAT_ALIASES</a> now inherit the VLSM and Broadcast
|
|
|
|
|
|
Address of the interface's primary IP address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The order in which port forwarding DNAT and Static DNAT
|
|
|
|
|
|
<a href="Documentation.htm#Conf">can now be reversed</a> so
|
|
|
|
|
|
that port forwarding rules can override the contents of <a
|
|
|
|
|
|
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/30/2002 - Shorewall Debian News</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lorenzo Marignoni reports that Shorewall 1.2.12 is now in
|
|
|
|
|
|
both the <a href=
|
|
|
|
|
|
"http://packages.debian.org/testing/net/shorewall.html">Debian
|
|
|
|
|
|
Testing Branch</a> and the <a href=
|
|
|
|
|
|
"http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
|
|
|
|
Unstable Branch</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/20/2002 - Shorewall 1.2.12 is Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The 'try' command works again</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>There is now a single RPM that also works with SuSE.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/17/2002 - Shorewall Debian News</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Lorenzo Marignoni reports that:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Shorewall 1.2.10 is in the <a href=
|
|
|
|
|
|
"http://packages.debian.org/testing/net/shorewall.html">Debian
|
|
|
|
|
|
Testing Branch</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall 1.2.11 is in the <a href=
|
|
|
|
|
|
"http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
|
|
|
|
Unstable Branch</a></li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks, Lorenzo!</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/16/2002 - Shorewall 1.2.11 RPM Available for
|
|
|
|
|
|
SuSE</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan
|
|
|
|
|
|
Mohr</a>, there is now a Shorewall 1.2.11 <a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm">
|
|
|
|
|
|
SuSE RPM</a> available.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/13/2002 - Shorewall 1.2.11 Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The 'try' command now accepts an optional timeout. If the
|
|
|
|
|
|
timeout is given in the command, the standard configuration
|
|
|
|
|
|
will automatically be restarted after the new configuration
|
|
|
|
|
|
has been running for that length of time. This prevents a
|
|
|
|
|
|
remote admin from being locked out of the firewall in the
|
|
|
|
|
|
case where the new configuration starts but prevents
|
|
|
|
|
|
access.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Kernel route filtering may now be enabled globally using
|
|
|
|
|
|
the new ROUTE_FILTER parameter in <a href=
|
|
|
|
|
|
"Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Individual IP source addresses and/or subnets may now be
|
|
|
|
|
|
excluded from masquerading/SNAT.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Simple "Yes/No" and "On/Off" values are now
|
|
|
|
|
|
case-insensitive in /etc/shorewall/shorewall.conf.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/13/2002 - Hamburg Mirror now has FTP</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Stefan now has an FTP mirror at <a target="_blank" href=
|
|
|
|
|
|
"ftp://germany.shorewall.net/pub/shorewall">ftp://germany.shorewall.net/pub/shorewall</a>.
|
|
|
|
|
|
Thanks Stefan!</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/12/2002 - New Mirror in Hamburg</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan
|
|
|
|
|
|
Mohr</a>, there is now a mirror of the Shorewall website at <a
|
|
|
|
|
|
target="_top" href=
|
|
|
|
|
|
"http://germany.shorewall.net">http://germany.shorewall.net</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/10/2002 - Shorewall QuickStart Guide Version 1.1
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a href="shorewall_quickstart_guide.htm">Version 1.1 of the
|
|
|
|
|
|
QuickStart Guide</a> is now available. Thanks to those who have
|
|
|
|
|
|
read version 1.0 and offered their suggestions. Corrections
|
|
|
|
|
|
have also been made to the sample scripts.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/9/2002 - Shorewall QuickStart Guide Version 1.0
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a href="shorewall_quickstart_guide.htm">Version 1.0 of the
|
|
|
|
|
|
QuickStart Guide</a> is now available. This Guide and its
|
|
|
|
|
|
accompanying sample configurations are expected to provide a
|
|
|
|
|
|
replacement for the recently withdrawn parameterized
|
|
|
|
|
|
samples.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/8/2002 - Parameterized Samples Withdrawn</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Although the <a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized
|
|
|
|
|
|
samples</a> have allowed people to get a firewall up and
|
|
|
|
|
|
running quickly, they have unfortunately set the wrong level of
|
|
|
|
|
|
expectation among those who have used them. I am therefore
|
|
|
|
|
|
withdrawing support for the samples and I am recommending that
|
|
|
|
|
|
they not be used in new Shorewall installations.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/2/2002 - Updated Log Parser</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has
|
|
|
|
|
|
provided an updated version of his <a href=
|
|
|
|
|
|
"pub/shorewall/parsefw/">CGI-based log parser</a> with
|
|
|
|
|
|
corrected date handling.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/30/2002 - Shorewall Website Search Improvements</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The quick search on the home page now excludes the mailing
|
|
|
|
|
|
list archives. The <a href="htdig/search.html">Extended
|
|
|
|
|
|
Search</a> allows excluding the archives or restricting the
|
|
|
|
|
|
search to just the archives. An archive search form is also
|
|
|
|
|
|
available on the <a href=
|
|
|
|
|
|
"http://lists.shorewall.net/mailing_list.htm">mailing list
|
|
|
|
|
|
information page</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/28/2002 - Debian Shorewall News (From Lorenzo
|
|
|
|
|
|
Martignoni)</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The 1.2.10 Debian Package is available at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall 1.2.9 is now in the <a href=
|
|
|
|
|
|
"http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
|
|
|
|
Unstable Distribution</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/25/2002 - Log Parser Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has
|
|
|
|
|
|
provided a <a href="pub/shorewall/parsefw/">CGI-based log
|
|
|
|
|
|
parser</a> for Shorewall. Thanks John.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/20/2002 - Shorewall 1.2.10 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A "shorewall try" command has been added (syntax:
|
|
|
|
|
|
shorewall try <i><configuration directory></i>). This
|
|
|
|
|
|
command attempts "shorewall -c <i><configuration
|
|
|
|
|
|
directory></i> start" and if that results in the firewall
|
|
|
|
|
|
being stopped due to an error, a "shorewall start" command is
|
|
|
|
|
|
executed. The 'try' command allows you to create a new <a
|
|
|
|
|
|
href="Documentation.htm#Configs">configuration</a> and
|
|
|
|
|
|
attempt to start it; if there is an error that leaves your
|
|
|
|
|
|
firewall in the stopped state, it will automatically be
|
|
|
|
|
|
restarted using the default configuration (in
|
|
|
|
|
|
/etc/shorewall).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A new variable ADD_SNAT_ALIASES has been added to <a
|
|
|
|
|
|
href=
|
|
|
|
|
|
"Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.
|
|
|
|
|
|
If this variable is set to "Yes", Shorewall will
|
|
|
|
|
|
automatically add IP addresses listed in the third column of
|
|
|
|
|
|
the <a href="Documentation.htm#Masq">/etc/shorewall/masq</a>
|
|
|
|
|
|
file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Copyright notices have been added to the
|
|
|
|
|
|
documenation.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/11/2002 - Shorewall 1.2.9 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
Filtering by <a href="Documentation.htm#MAC">MAC
|
|
|
|
|
|
address</a> has been added. MAC addresses may be used as
|
|
|
|
|
|
the source address in:
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Filtering rules (<a href=
|
|
|
|
|
|
"Documentation.htm#Rules">/etc/shorewall/rules</a>)</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Traffic Control Classification Rules (<a href=
|
|
|
|
|
|
"traffic_shaping.htm#tcrules">/etc/shorewall/tcrules</a>)</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>TOS Rules (<a href=
|
|
|
|
|
|
"Documentation.htm#TOS">/etc/shorewall/tos</a>)</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Blacklist (<a href=
|
|
|
|
|
|
"Documentation.htm#Blacklist">/etc/shorewall/blacklist</a>)</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Several bugs have been fixed</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The 1.2.9 Debian Package is also available at <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/1/2002 - 1.2.8 Debian Package is Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>See <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/25/2002 - New Two-interface Sample</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>I've enhanced the two interface sample to allow access from
|
|
|
|
|
|
the firewall to servers in the local zone - <a href=
|
|
|
|
|
|
"http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz">
|
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/23/2002 - Shorewall 1.2.8 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Do to a serious problem with 1.2.7, I am releasing 1.2.8. It
|
|
|
|
|
|
corrects problems associated with the lock file used to prevent
|
|
|
|
|
|
multiple state-changing operations from occuring
|
|
|
|
|
|
simultaneously. My apologies for any inconvenience my
|
|
|
|
|
|
carelessness may have caused.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/22/2002 - Shorewall 1.2.7 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>UPnP probes (UDP destination port 1900) are now silently
|
|
|
|
|
|
dropped in the <i>common</i> chain</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>RFC 1918 checking in the mangle table has been
|
|
|
|
|
|
streamlined to no longer require packet marking. RFC 1918
|
|
|
|
|
|
checking in the filter table has been changed to require half
|
|
|
|
|
|
as many rules as previously.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A 'shorewall check' command has been added that does a
|
|
|
|
|
|
cursory validation of the zones, interfaces, hosts, rules and
|
|
|
|
|
|
policy files.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/18/2002 - 1.2.6 Debian Package is Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>See <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/8/2002 - Shorewall 1.2.6 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>$-variables may now be used anywhere in the configuration
|
|
|
|
|
|
files except /etc/shorewall/zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The interfaces and hosts files now have their contents
|
|
|
|
|
|
validated before any changes are made to the existing
|
|
|
|
|
|
Netfilter configuration. The appearance of a zone name that
|
|
|
|
|
|
isn't defined in /etc/shorewall/zones causes "shorewall
|
|
|
|
|
|
start" and "shorewall restart" to abort without changing the
|
|
|
|
|
|
Shorewall state. Unknown options in either file cause a
|
|
|
|
|
|
warning to be issued.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A problem occurring when BLACKLIST_LOGLEVEL was not set
|
|
|
|
|
|
has been corrected.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/4/2002 - Shorewall 1.2.5 Debian Package
|
|
|
|
|
|
Available</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>see <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>2/1/2002 - Shorewall 1.2.5 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Due to installation problems with Shorewall 1.2.4, I have
|
|
|
|
|
|
released Shorewall 1.2.5. Sorry for the rapid-fire
|
|
|
|
|
|
development.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In version 1.2.5:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The installation problems have been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><a href="Documentation.htm#Masq">SNAT</a> is now
|
|
|
|
|
|
supported.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A "shorewall version" command has been added</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The default value of the STATEDIR variable in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf has been changed to
|
|
|
|
|
|
/var/lib/shorewall in order to conform to the GNU/Linux File
|
|
|
|
|
|
Hierarchy Standard, Version 2.2.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/28/2002 - Shorewall 1.2.4 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The "fw" zone <a href="Documentation.htm#FW">may now be
|
|
|
|
|
|
given a different name</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You may now place end-of-line comments (preceded by '#')
|
|
|
|
|
|
in any of the configuration files</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>There is now protection against against two state
|
|
|
|
|
|
changing operations occuring concurrently. This is
|
|
|
|
|
|
implemented using the 'lockfile' utility if it is available
|
|
|
|
|
|
(lockfile is part of procmail); otherwise, a less robust
|
|
|
|
|
|
technique is used. The lockfile is created in the STATEDIR
|
|
|
|
|
|
defined in /etc/shorewall/shorewall.conf and has the name
|
|
|
|
|
|
"lock".</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>"shorewall start" no longer fails if "detect" is
|
|
|
|
|
|
specified in <a href=
|
|
|
|
|
|
"Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
|
|
|
|
|
|
for an interface with subnet mask 255.255.255.255.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/27/2002 - Shorewall 1.2.3 Debian Package Available</b>
|
|
|
|
|
|
-- see <a href=
|
|
|
|
|
|
"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/20/2002 - Corrected firewall script
|
|
|
|
|
|
available </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Corrects a problem with BLACKLIST_LOGLEVEL. See <a href=
|
|
|
|
|
|
"errata.htm">the errata</a> for details.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/19/2002 - Shorewall 1.2.3 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>This is a minor feature and bugfix release. The single new
|
|
|
|
|
|
feature is:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Support for TCP MSS Clamp to PMTU -- This support is
|
|
|
|
|
|
usually required when the internet connection is via PPPoE or
|
|
|
|
|
|
PPTP and may be enabled using the <a href=
|
|
|
|
|
|
"Documentation.htm#ClampMSS">CLAMPMSS</a> option in
|
|
|
|
|
|
/etc/shorewall/shorewall.conf.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The following problems were corrected:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The "shorewall status" command no longer hangs.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall monitor" command now displays the icmpdef
|
|
|
|
|
|
chain</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The CLIENT PORT(S) column in tcrules is no longer
|
|
|
|
|
|
ignored</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/18/2002 - Shorewall 1.2.2 packaged with new</b> <a
|
|
|
|
|
|
href="http://leaf.sourceforge.net">LEAF</a> <b>release</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Jacques Nilo and Eric Wolzak have released a kernel 2.4.16
|
|
|
|
|
|
LEAF distribution that includes Shorewall 1.2.2. See <a href=
|
|
|
|
|
|
"http://leaf.sourceforge.net/devel/jnilo">http://leaf.sourceforge.net/devel/jnilo</a>
|
|
|
|
|
|
for details.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/11/2002 - Debian Package (.deb) Now Available -</b>
|
|
|
|
|
|
Thanks to <a href="mailto:lorenzo.martignoni@milug.org">Lorenzo
|
|
|
|
|
|
Martignoni</a>, a 1.2.2 Shorewall Debian package is now
|
|
|
|
|
|
available. There is a link to Lorenzo's site from the <a href=
|
|
|
|
|
|
"download.htm">Shorewall download page</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/9/2002 - Updated 1.2.2 /sbin/shorewall available -</b>
|
|
|
|
|
|
<a href="/pub/shorewall/errata/1.2.2/shorewall">This corrected
|
|
|
|
|
|
version</a> restores the "shorewall status" command to
|
|
|
|
|
|
health.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/8/2002 - Shorewall 1.2.2 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In version 1.2.2</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>
|
|
|
|
|
|
Support for IP blacklisting has been added
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>You specify whether you want packets from blacklisted
|
|
|
|
|
|
hosts dropped or rejected using the <a href=
|
|
|
|
|
|
"Documentation.htm#BLDisposition">BLACKLIST_DISPOSITION</a>
|
|
|
|
|
|
setting in /etc/shorewall/shorewall.conf</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You specify whether you want packets from blacklisted
|
|
|
|
|
|
hosts logged and at what syslog level using the <a href=
|
|
|
|
|
|
"Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL</a>
|
|
|
|
|
|
setting in /etc/shorewall/shorewall.conf</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You list the IP addresses/subnets that you wish to
|
|
|
|
|
|
blacklist in <a href=
|
|
|
|
|
|
"Documentation.htm#Blacklist">/etc/shorewall/blacklist</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You specify the interfaces you want checked against
|
|
|
|
|
|
the blacklist using the new "<a href=
|
|
|
|
|
|
"Documentation.htm#BLInterface">blacklist</a>" option in
|
|
|
|
|
|
/etc/shorewall/interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The black list is refreshed from
|
|
|
|
|
|
/etc/shorewall/blacklist by the "shorewall refresh"
|
|
|
|
|
|
command.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
|
Use of TCP RST replies has been expanded
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>TCP connection requests rejected because of a REJECT
|
|
|
|
|
|
policy are now replied with a TCP RST packet.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>TCP connection requests rejected because of a
|
|
|
|
|
|
protocol=all rule in /etc/shorewall/rules are now replied
|
|
|
|
|
|
with a TCP RST packet.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A <a href="Documentation.htm#Logfile">LOGFILE</a>
|
|
|
|
|
|
specification has been added to
|
|
|
|
|
|
/etc/shorewall/shorewall.conf. LOGFILE is used to tell the
|
|
|
|
|
|
/sbin/shorewall program where to look for Shorewall
|
|
|
|
|
|
messages.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/5/2002 - New Parameterized Samples (<a href=
|
|
|
|
|
|
"ftp://ftp.shorewall.net/pub/shorewall/samples-1.2.0/" target=
|
|
|
|
|
|
"_blank">version 1.2.0</a>) released.</b> These are minor
|
|
|
|
|
|
updates to the previously-released samples. There are two new
|
|
|
|
|
|
rules added:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Unless you have explicitly enabled Auth connections (tcp
|
|
|
|
|
|
port 113) to your firewall, these connections will be
|
|
|
|
|
|
REJECTED rather than DROPPED. This speeds up connection
|
|
|
|
|
|
establishment to some servers.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Orphan DNS replies are now silently dropped.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p>See the README file for upgrade instructions.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>1/1/2002 - <u><font color="#FF6633">Shorewall Mailing
|
|
|
|
|
|
List Moving</font></u></b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>The Shorewall mailing list hosted at <a href=
|
|
|
|
|
|
"http://sourceforge.net">Sourceforge</a> is moving to
|
|
|
|
|
|
Shorewall.net. If you are a current subscriber to the list at
|
|
|
|
|
|
Sourceforge, please <a href=
|
|
|
|
|
|
"shorewall_mailing_list_migration.htm">see these
|
|
|
|
|
|
instructions</a>. If you would like to subscribe to the new
|
|
|
|
|
|
list, visit <a href=
|
|
|
|
|
|
"http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/31/2001 - Shorewall 1.2.1 Released</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In version 1.2.1:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="Documentation.htm#LogUncleanOption">Logging of
|
|
|
|
|
|
Mangled/Invalid Packets</a> is added. </li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The <a href="IPIP.htm">tunnel script</a> has been
|
|
|
|
|
|
corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>'shorewall show tc' now correctly handles tunnels.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/21/2001 - Shorewall 1.2.0 Released!</b> - <b>I
|
|
|
|
|
|
couldn't resist releasing 1.2 on 12/21/2001</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Version 1.2 contains the following new features:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Support for <a href="traffic_shaping.htm">Traffic
|
|
|
|
|
|
Control/Shaping</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for <a href="Documentation.htm#Unclean">Filtering
|
|
|
|
|
|
of Mangled/Invalid Packets</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for <a href="IPIP.htm">GRE Tunnels</a></li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p>For the next month or so, I will continue to provide
|
|
|
|
|
|
corrections to version 1.1.18 as necessary so that current
|
|
|
|
|
|
version 1.1.x users will not be forced into a quick upgrade to
|
|
|
|
|
|
1.2.0 just to have access to bug fixes.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>For those of you who have installed one of the Beta RPMS,
|
|
|
|
|
|
you will need to use the "--oldpackage" option when upgrading
|
|
|
|
|
|
to 1.2.0:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
|
<p>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</p>
|
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>12/19/2001 - Thanks to <a href=
|
|
|
|
|
|
"mailto:scowles@infohiiway.com">Steve Cowles</a>, there is now
|
|
|
|
|
|
a Shorewall mirror in Texas.</b> This web site is mirrored at
|
|
|
|
|
|
<a href="http://www.infohiiway.com/shorewall" target=
|
|
|
|
|
|
"_top">http://www.infohiiway.com/shorewall</a> and the ftp site
|
|
|
|
|
|
is at <a href=
|
|
|
|
|
|
"ftp://ftp.infohiiway.com/pub/mirrors/shorewall">ftp://ftp.infohiiway.com/pub/mirrors/shorewall</a>.<b>
|
|
|
|
|
|
</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/30/2001 - A new set of the parameterized <a href=
|
|
|
|
|
|
"ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample
|
|
|
|
|
|
Configurations</a> has been released</b>. In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Ping is now allowed between the zones.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In the three-interface configuration, it is now possible
|
|
|
|
|
|
to configure the internet services that are to be available
|
|
|
|
|
|
to servers in the DMZ. </li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/20/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.18. </b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The spelling of ADD_IP_ALIASES has been corrected in the
|
|
|
|
|
|
shorewall.conf file</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The logic for deleting user-defined chains has been
|
|
|
|
|
|
simplified so that it avoids a bug in the LRP version of the
|
|
|
|
|
|
'cut' utility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /var/lib/lrpkg/shorwall.conf file has been corrected
|
|
|
|
|
|
to properly display the NAT entry in that file.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/19/2001 - Thanks to <a href=
|
|
|
|
|
|
"mailto:shorewall@timelord.sk">Juraj Ontkanin</a>, there is now
|
|
|
|
|
|
a Shorewall mirror in the Slovak Republic</b>. The website is
|
|
|
|
|
|
now mirrored at <a href="http://www.nrg.sk/mirror/shorewall"
|
|
|
|
|
|
target="_top">http://www.nrg.sk/mirror/shorewall</a> and the
|
|
|
|
|
|
FTP site is mirrored at <a href=
|
|
|
|
|
|
"ftp://ftp.nrg.sk/mirror/shorewall">ftp://ftp.nrg.sk/mirror/shorewall</a>.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/2/2001 - Announcing Shorewall Parameter-driven Sample
|
|
|
|
|
|
Configurations.</b> There are three sample configurations:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>One Interface -- for a standalone system.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Two Interfaces -- A masquerading firewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Three Interfaces -- A masquerading firewall with
|
|
|
|
|
|
DMZ.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p>Samples may be downloaded from <a href=
|
|
|
|
|
|
"ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17">ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17</a>
|
|
|
|
|
|
. See the README file for instructions.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>11/1/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.17</b>. I intend this to be the last of the 1.1
|
|
|
|
|
|
Shorewall releases.</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The handling of <a href=
|
|
|
|
|
|
"Documentation.htm#Aliases">ADD_IP_ALIASES</a> has been
|
|
|
|
|
|
corrected. </li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/22/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.16</b>. In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A new "shorewall show connections" command has been
|
|
|
|
|
|
added.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In the "shorewall monitor" output, the currently tracked
|
|
|
|
|
|
connections are now shown on a separate page.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Prior to this release, Shorewall unconditionally added
|
|
|
|
|
|
the external IP adddress(es) specified in /etc/shorewall/nat.
|
|
|
|
|
|
Beginning with version 1.1.16, a new parameter (<a href=
|
|
|
|
|
|
"Documentation.htm#Aliases">ADD_IP_ALIASES</a>) may be set to
|
|
|
|
|
|
"no" (or "No") to inhibit this behavior. This allows IP
|
|
|
|
|
|
aliases created using your distribution's network
|
|
|
|
|
|
configuration tools to be used in static NAT. </li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/15/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.15.</b> In this version:</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Support for nested zones has been improved. See <a href=
|
|
|
|
|
|
"Documentation.htm#Nested">the documentation</a> for
|
|
|
|
|
|
details</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall now correctly checks the alternate
|
|
|
|
|
|
configuration directory for the 'zones' file.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>10/4/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.14.</b> In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Shorewall now supports alternate configuration
|
|
|
|
|
|
directories. When an alternate directory is specified when
|
|
|
|
|
|
starting or restarting Shorewall (e.g., "shorewall -c
|
|
|
|
|
|
/etc/testconf restart"), Shorewall will first look for
|
|
|
|
|
|
configuration files in the alternate directory then in
|
|
|
|
|
|
/etc/shorewall. To create an alternate configuration
|
|
|
|
|
|
simply:<br>
|
|
|
|
|
|
1. Create a New Directory<br>
|
|
|
|
|
|
2. Copy to that directory any of your configuration files
|
|
|
|
|
|
that you want to change.<br>
|
|
|
|
|
|
3. Modify the copied files as needed.<br>
|
|
|
|
|
|
4. Restart Shorewall specifying the new directory.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The rules for allowing/disallowing icmp echo-requests
|
|
|
|
|
|
(pings) are now moved after rules created when processing the
|
|
|
|
|
|
rules file. This allows you to add rules that selectively
|
|
|
|
|
|
allow/deny ping based on source or destination address.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Rules that specify multiple client ip addresses or
|
|
|
|
|
|
subnets no longer cause startup failures.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Zone names in the policy file are now validated against
|
|
|
|
|
|
the zones file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>If you have <a href=
|
|
|
|
|
|
"Documentation.htm#MangleEnabled">packet mangling</a> support
|
|
|
|
|
|
enabled, the "<a href=
|
|
|
|
|
|
"Documentation.htm#Interfaces">norfc1918</a>" interface
|
|
|
|
|
|
option now logs and drops any incoming packets on the
|
|
|
|
|
|
interface that have an RFC 1918 destination address.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>9/12/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.13</b>. In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Shell variables can now be used to parameterize Shorewall
|
|
|
|
|
|
rules.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The second column in the hosts file may now contain a
|
|
|
|
|
|
comma-separated list.<br>
|
|
|
|
|
|
<br>
|
|
|
|
|
|
Example:<br>
|
|
|
|
|
|
sea
|
|
|
|
|
|
eth0:130.252.100.0/24,206.191.149.0/24</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Handling of multi-zone interfaces has been improved. See
|
|
|
|
|
|
the <a href="Documentation.htm#Interfaces">documentation for
|
|
|
|
|
|
the /etc/shorewall/interfaces file</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>8/28/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.12</b>. In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Several columns in the rules file may now contain
|
|
|
|
|
|
comma-separated lists.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Shorewall is now more rigorous in parsing the options in
|
|
|
|
|
|
/etc/shorewall/interfaces.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Complementation using "!" is now supported in rules.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/28/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.11</b>. In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A "shorewall refresh" command has been added to allow for
|
|
|
|
|
|
refreshing the rules associated with the broadcast address on
|
|
|
|
|
|
a dynamic interface. This command should be used in place of
|
|
|
|
|
|
"shorewall restart" when the internet interface's IP address
|
|
|
|
|
|
changes.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The /etc/shorewall/start file (if any) is now processed
|
|
|
|
|
|
after all temporary rules have been deleted. This change
|
|
|
|
|
|
prevents the accidental removal of rules added during the
|
|
|
|
|
|
processing of that file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "dhcp" interface option is now applicable to firewall
|
|
|
|
|
|
interfaces used by a DHCP server running on the
|
|
|
|
|
|
firewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The RPM can now be built from the .tgz file using "rpm
|
|
|
|
|
|
-tb" </li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>7/6/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.10.</b> In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Shorewall now enables Ipv4 Packet Forwarding by default.
|
|
|
|
|
|
Packet forwarding may be disabled by specifying
|
|
|
|
|
|
IP_FORWARD=Off in /etc/shorewall/shorewall.conf. If you don't
|
|
|
|
|
|
want Shorewall to enable or disable packet forwarding, add
|
|
|
|
|
|
IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf
|
|
|
|
|
|
file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The "shorewall hits" command no longer lists extraneous
|
|
|
|
|
|
service names in its last report.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Erroneous instructions in the comments at the head of the
|
|
|
|
|
|
firewall script have been corrected.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/23/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.9.</b> In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The "tunnels" file <u>really</u> is in the RPM now.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>SNAT can now be applied to port-forwarded
|
|
|
|
|
|
connections.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A bug which would cause firewall start failures in some
|
|
|
|
|
|
dhcp configurations has been fixed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The firewall script now issues a message if you have the
|
|
|
|
|
|
name of an interface in the second column in an entry in
|
|
|
|
|
|
/etc/shorewall/masq and that interface is not up.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>You can now configure Shorewall so that it <a href=
|
|
|
|
|
|
"Documentation.htm#NatEnabled">doesn't require the NAT and/or
|
|
|
|
|
|
mangle netfilter modules</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Thanks to Alex Polishchuk, the "hits" command from
|
|
|
|
|
|
seawall is now in shorewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Support for <a href="IPIP.htm">IPIP tunnels</a> has been
|
|
|
|
|
|
added.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/18/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.8</b>. In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>A typo in the sample rules file has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is now possible to restrict masquerading by <a href=
|
|
|
|
|
|
"Documentation.htm#Masq">destination host or subnet.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>It is now possible to have static <a href=
|
|
|
|
|
|
"NAT.htm#LocalPackets">NAT rules applied to packets
|
|
|
|
|
|
originating on the firewall itself</a>.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>6/2/2001 - The current version of Shorewall is 1.1.7.</b>
|
|
|
|
|
|
In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The TOS rules are now deleted when the firewall is
|
|
|
|
|
|
stopped.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The .rpm will now install regardless of which version of
|
|
|
|
|
|
iptables is installed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The .rpm will now install without iproute2 being
|
|
|
|
|
|
installed.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The documentation has been cleaned up.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The sample configuration files included in Shorewall have
|
|
|
|
|
|
been formatted to 80 columns for ease of editing on a VGA
|
|
|
|
|
|
console.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/25/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.6</b>. In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="Documentation.htm#lograte">You may now
|
|
|
|
|
|
rate-limit the packet log.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previous versions of Shorewall have an implementation of
|
|
|
|
|
|
Static NAT which violates the principle of least
|
|
|
|
|
|
surprise. NAT only occurs for packets arriving at
|
|
|
|
|
|
(DNAT) or send from (SNAT) the interface named in the
|
|
|
|
|
|
INTERFACE column of /etc/shorewall/nat. Beginning with
|
|
|
|
|
|
version 1.1.6, NAT effective regardless of which interface
|
|
|
|
|
|
packets come from or are destined to. To get compatibility
|
|
|
|
|
|
with prior versions, I have added a new "ALL <a href=
|
|
|
|
|
|
"NAT.htm#AllInterFaces">"ALL INTERFACES" column to
|
|
|
|
|
|
/etc/shorewall/nat</a>. By placing "no" or "No" in the new
|
|
|
|
|
|
column, the NAT behavior of prior versions may be
|
|
|
|
|
|
retained. </li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The treatment of <a href="IPSEC.htm#RoadWarrior">IPSEC
|
|
|
|
|
|
Tunnels where the remote gateway is a standalone system has
|
|
|
|
|
|
been improved</a>. Previously, it was necessary to include an
|
|
|
|
|
|
additional rule allowing UDP port 500 traffic to pass through
|
|
|
|
|
|
the tunnel. Shorewall will now create this rule automatically
|
|
|
|
|
|
when you place the name of the remote peer's zone in a new
|
|
|
|
|
|
GATEWAY ZONE column in /etc/shorewall/tunnels. </li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/20/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.5.</b> In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="Documentation.htm#modules">You may now pass
|
|
|
|
|
|
parameters when loading netfilter modules and you can specify
|
|
|
|
|
|
the modules to load.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Compressed modules are now loaded. This requires that you
|
|
|
|
|
|
modutils support loading compressed modules.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li><a href="Documentation.htm#TOS">You may now set the Type
|
|
|
|
|
|
of Service (TOS) field in packets.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected rules generated for port redirection
|
|
|
|
|
|
(again).</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>5/10/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.4.</b> In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="Documentation.htm#Conf">Accepting RELATED
|
|
|
|
|
|
connections is now optional.</a></li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected problem where if "shorewall start" aborted
|
|
|
|
|
|
early (due to kernel configuration errors for example),
|
|
|
|
|
|
superfluous 'sed' error messages were reported.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Corrected rules generated for port redirection.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The order in which iptables kernel modules are loaded has
|
|
|
|
|
|
been corrected (Thanks to Mark Pavlidis). </li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/28/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.3.</b> In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Correct message issued when Proxy ARP address added
|
|
|
|
|
|
(Thanks to Jason Kirtland).</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>/tmp/shorewallpolicy-$$ is now removed if there is an
|
|
|
|
|
|
error while starting the firewall.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>/etc/shorewall/icmp.def and /etc/shorewall/common.def are
|
|
|
|
|
|
now used to define the icmpdef and common chains unless
|
|
|
|
|
|
overridden by the presence of /etc/shorewall/icmpdef or
|
|
|
|
|
|
/etc/shorewall/common.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>In the .lrp, the file /var/lib/lrpkg/shorwall.conf has
|
|
|
|
|
|
been corrected. An extra space after "/etc/shorwall/policy"
|
|
|
|
|
|
has been removed and "/etc/shorwall/rules" has been
|
|
|
|
|
|
added.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>When a sub-shell encounters a fatal error and has stopped
|
|
|
|
|
|
the firewall, it now kills the main shell so that the main
|
|
|
|
|
|
shell will not continue.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A problem has been corrected where a sub-shell stopped
|
|
|
|
|
|
the firewall and main shell continued resulting in a
|
|
|
|
|
|
perplexing error message referring to "common.so"
|
|
|
|
|
|
resulted.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Previously, placing "-" in the PORT(S) column in
|
|
|
|
|
|
/etc/shorewall/rules resulted in an error message during
|
|
|
|
|
|
start. This has been corrected.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The first line of "install.sh" has been corrected -- I
|
|
|
|
|
|
had inadvertently deleted the initial "#".</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/12/2001 - The current version of Shorewall is
|
|
|
|
|
|
1.1.2.</b> In this version</p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Port redirection now works again.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The icmpdef and common chains <a href=
|
|
|
|
|
|
"Documentation.htm#Icmpdef">may now be user-defined</a>.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The firewall no longer fails to start if "routefilter" is
|
|
|
|
|
|
specified for an interface that isn't started. A warning
|
|
|
|
|
|
message is now issued in this case.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The LRP Version is renamed "shorwall" for 8,3 MSDOS file
|
|
|
|
|
|
system compatibility.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>A couple of LRP-specific problems were corrected.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/8/2001 - Shorewall is now affiliated with the <a href=
|
|
|
|
|
|
"http://leaf.sourceforge.net">Leaf Project</a></b> <a href=
|
|
|
|
|
|
"http://leaf.sourceforge.net"><img src="images/leaflogo.gif"
|
|
|
|
|
|
alt="Leaf Logo" border="0" height="36" width="49"></a></p>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>4/5/2001 - The current version of Shorewall is 1.1.1. In
|
|
|
|
|
|
this version:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The common chain is traversed from INPUT, OUTPUT and
|
|
|
|
|
|
FORWARD before logging occurs</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The source has been cleaned up dramatically</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DHCP DISCOVER packets with RFC1918 source addresses no
|
|
|
|
|
|
longer generate log messages. Linux DHCP clients generate
|
|
|
|
|
|
such packets and it's annoying to see them logged. </li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/25/2001 - The current version of Shorewall is 1.1.0. In
|
|
|
|
|
|
this version:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Log messages now indicate the packet disposition.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Error messages have been improved.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The ability to define zones consisting of an enumerated
|
|
|
|
|
|
set of hosts and/or subnetworks has been added.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The zone-to-zone chain matrix is now sparse so that only
|
|
|
|
|
|
those chains that contain meaningful rules are defined.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>240.0.0.0/4 and 169.254.0.0/16 have been added to the
|
|
|
|
|
|
source subnetworks whose packets are dropped under the
|
|
|
|
|
|
<i>norfc1918</i> interface option.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Exits are now provided for executing an user-defined
|
|
|
|
|
|
script when a chain is defined, when the firewall is
|
|
|
|
|
|
initialized, when the firewall is started, when the firewall
|
|
|
|
|
|
is stopped and when the firewall is cleared.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The Linux kernel's route filtering facility can now be
|
|
|
|
|
|
specified selectively on network interfaces.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/19/2001 - The current version of Shorewall is 1.0.4.
|
|
|
|
|
|
This version:</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>Allows user-defined zones. Shorewall now has only one
|
|
|
|
|
|
pre-defined zone (fw) with the remaining zones being defined
|
|
|
|
|
|
in the new configuration file /etc/shorewall/zones. The
|
|
|
|
|
|
/etc/shorewall/zones file released in this version provides
|
|
|
|
|
|
behavior that is compatible with Shorewall 1.0.3. </li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Adds the ability to specify logging in entries in the
|
|
|
|
|
|
/etc/shorewall/rules file.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Correct handling of the icmp-def chain so that only ICMP
|
|
|
|
|
|
packets are sent through the chain.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>Compresses the output of "shorewall monitor" if awk is
|
|
|
|
|
|
installed. Allows the command to work if awk isn't installed
|
|
|
|
|
|
(although it's not pretty).</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/13/2001 - The current version of Shorewall is 1.0.3.
|
|
|
|
|
|
This is a bug-fix release with no new features.</b></p>
|
|
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li>The PATH variable in the firewall script now includes
|
|
|
|
|
|
/usr/local/bin and /usr/local/sbin.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>DMZ-related chains are now correctly deleted if the DMZ
|
|
|
|
|
|
is deleted.</li>
|
|
|
|
|
|
|
|
|
|
|
|
<li>The interface OPTIONS for "gw" interfaces are no longer
|
|
|
|
|
|
ignored.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<p><b>3/8/2001 - The current version of Shorewall is 1.0.2. It
|
|
|
|
|
|
supports an additional "gw" (gateway) zone for tunnels and it
|
|
|
|
|
|
supports IPSEC tunnels with end-points on the firewall. There
|
|
|
|
|
|
is also a .lrp available now.</b></p>
|
|
|
|
|
|
</body>
|
2003-12-30 02:19:52 +01:00
|
|
|
|
</html>
|
2005-09-23 02:12:12 +02:00
|
|
|
|
|
