mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-30 19:43:45 +01:00
aa36c47640
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5940 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
11731 lines
462 KiB
HTML
11731 lines
462 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
||
<html>
|
||
<head>
|
||
<meta name="generator" content=
|
||
"HTML Tidy for Linux (vers 1st April 2002), see www.w3.org">
|
||
|
||
<title> Old News </title>
|
||
</head>
|
||
|
||
<body>
|
||
<span style="font-weight: bold;">10/05/2005
|
||
Shorewall 2.4.5<br>
|
||
</span>
|
||
<br>
|
||
Problems Corrected in 2.4.5<br>
|
||
<ol>
|
||
<li>In previous versions, when the command is 'start', 'restart' or
|
||
'stop' then OUTPUT traffic to hosts listed in
|
||
/etc/shorewall/routestopped is not enabled if ADMINISABSENTMINDED=Yes.
|
||
That traffic is now enabled independent of the setting of
|
||
ADMINISABSENTMINDED.</li>
|
||
<li>Although it was documented that icmp types could be used in the
|
||
tcrules file, the code did not support it. Thanks to Jorge Molina, that
|
||
problem is now corrected.</li>
|
||
<li>In a multi-ISP configuration, fwmark routing rules now have a
|
||
higher priority than source IP rules. This allows entries in tcrules to
|
||
be more effective in controlling routing.</li>
|
||
<li>Previously, not all of the mangle chains were flushed during
|
||
"shorewall restart".</li>
|
||
</ol>
|
||
<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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</span>Problems Corrected:<br>
|
||
<ol>
|
||
<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>
|
||
</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li> 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>
|
||
<br>
|
||
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>
|
||
</li>
|
||
<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>
|
||
</li>
|
||
</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>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;">06/05/2005 Shorewall 2.4.0<br>
|
||
<br>
|
||
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>
|
||
<br>
|
||
New Features:<br>
|
||
<ol>
|
||
<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>
|
||
</li>
|
||
<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>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;">05/20/2005 Shorewall CVS
|
||
Repository has Moved to Sourceforge<br>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</span> This will be my last 2.2 release. It contains a couple
|
||
of small bug fixes that I hadn't yet released.<br>
|
||
<br>
|
||
-Tom<br>
|
||
<br>
|
||
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>
|
||
<br>
|
||
</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>
|
||
</li>
|
||
|
||
<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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</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
|
||
tailored 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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</span> Beta 5 was more or less DOA. Here's Beta 6.<br>
|
||
<br>
|
||
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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
<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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</b> Problems Corrected:</p>
|
||
|
||
<ul>
|
||
<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>
|
||
<br>
|
||
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>
|
||
</li>
|
||
</ul>
|
||
|
||
<p><a name="2_0_5"></a><b>7/10/2004 - Shorewall 2.0.5<br>
|
||
</b><br>
|
||
Problems Corrected:</p>
|
||
|
||
<ul>
|
||
<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>
|
||
</li>
|
||
</ul>
|
||
|
||
<p><a name="2_0_4"></a><b>7/06/2004 - Shorewall 2.0.4<br>
|
||
</b><br>
|
||
Problems Corrected:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
<p>Rules with $FW as the source zone and that specify
|
||
logging can cause "shorewall start" to fail.</p>
|
||
</li>
|
||
</ul>
|
||
|
||
<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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</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>
|
||
<br>
|
||
</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 tailors 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 tailors 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 tailors 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>
|
||
|
||
<ul>
|
||
<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>
|
||
</ul>
|
||
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.
|
||
<br>
|
||
<br>
|
||
<b>IMPORTANT: Shorewall 1.4.0 requires</b> <b>the iproute
|
||
package ('ip' utility).</b><br>
|
||
<br>
|
||
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>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# shorewall start<br>
|
||
...<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...
|
||
|
||
</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>
|
||
#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
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# ip route show dev eth2<br>
|
||
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]#
|
||
|
||
</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>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# ip route show dev eth2<br>
|
||
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]#
|
||
|
||
</pre>
|
||
<br>
|
||
In this case, you would want to change the
|
||
entry in /etc/shorewall/masq to:<br>
|
||
|
||
<pre>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 192.168.1.0/24 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
||
</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>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# shorewall start<br>
|
||
...<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...
|
||
|
||
</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>
|
||
#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
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# ip route show dev eth2<br>
|
||
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]#
|
||
|
||
</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>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
||
</pre>
|
||
<pre>
|
||
[root@gateway test]# ip route show dev eth2<br>
|
||
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]#
|
||
|
||
</pre>
|
||
<br>
|
||
In this case, you would want to change the
|
||
entry in /etc/shorewall/masq to:<br>
|
||
|
||
<pre>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 192.168.1.0/24 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
||
</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.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</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.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</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>
|
||
|
||
<ul>
|
||
<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>
|
||
</ul>
|
||
|
||
<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>
|
||
|
||
<ul>
|
||
<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>
|
||
</ul>
|
||
|
||
<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>
|
||
|
||
|
||
<ul>
|
||
<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>
|
||
</ul>
|
||
You may download the Beta from:<br>
|
||
|
||
|
||
<ul>
|
||
<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>
|
||
</ul>
|
||
|
||
<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>
|
||
</html>
|
||
|