holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity
f046ea3ab1
shorewall_code/STABLE/documentation/News.htm
teastep 7bb80bf3fe Shorewall-1.4.7a 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@774 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-10-21 22:22:44 +00:00

4609 lines
219 KiB
HTML
Raw Blame History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall News</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#3366ff" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall News Archive</font></h1>
</td>
</tr>
</tbody>
</table>
<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>
&nbsp;<br>
&nbsp;&nbsp; local: --limit: bad variable name<br>
&nbsp;&nbsp; iptables v1.2.8: Couldn't load match
`-j':/lib/iptables/libipt_-j.so:<br>
&nbsp;&nbsp; cannot open shared object file: No such file or directory<br>
&nbsp;&nbsp; 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>
&nbsp;<br>
&nbsp;&nbsp; Example of rule that previously caused "shorewall start"
to fail:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc&nbsp; $FW&nbsp;
icmp&nbsp;&nbsp;&nbsp; 0,8,11,12<br>
<br>
</li>
<li>Previously, if the following error message was issued, Shorewall
was left in an inconsistent state.<br>
&nbsp;<br>
&nbsp;&nbsp; Error: Unable to determine the routes 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 "&lt;zone&gt;_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>
&nbsp;&nbsp;&nbsp; <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>
&nbsp;<br>
&nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [: NONE: unexpected operator<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
Now, the absence of a policy generates an error message and the
firewall is stopped:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No policy defined from zone
&lt;source&gt; to zone &lt;dest&gt;<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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp; Loading /usr/share/shorewall/functions...<br>
&nbsp;&nbsp;&nbsp; Processing /etc/shorewall/params ...<br>
&nbsp;&nbsp;&nbsp; Processing /etc/shorewall/shorewall.conf...<br>
&nbsp;&nbsp;&nbsp; Giving up on lock file /var/lib/shorewall/lock<br>
&nbsp;&nbsp;&nbsp; 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>
&nbsp;<br>
&nbsp;&nbsp;&nbsp; Example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp; ACCEPT fw&nbsp; 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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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.&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
To specify a rate limit, <br>
<br>
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
&nbsp;<br>
&nbsp;
where<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
&lt;interval&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
accepted within an &lt;interval&gt;. If not given, the default of 5 is
assumed.<br>
&nbsp;<br>
There may be no white space between the ACTION and "&lt;" 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 "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;: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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
&nbsp;<br>
Let's take an example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp;&nbsp; <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="file:///vfat/Shorewall-docs/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><b> </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>
&nbsp;&nbsp;&nbsp; <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>
&nbsp;<br>
&nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [: NONE: unexpected operator<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
Now, the absence of a policy generates an error message and the
firewall is stopped:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No policy defined from zone
&lt;source&gt; to zone &lt;dest&gt;<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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp; Loading /usr/share/shorewall/functions...<br>
&nbsp;&nbsp;&nbsp; Processing /etc/shorewall/params ...<br>
&nbsp;&nbsp;&nbsp; Processing /etc/shorewall/shorewall.conf...<br>
&nbsp;&nbsp;&nbsp; Giving up on lock file /var/lib/shorewall/lock<br>
&nbsp;&nbsp;&nbsp; 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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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.&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
To specify a rate limit, <br>
<br>
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
&nbsp;<br>
&nbsp;
where<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
&lt;interval&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
accepted within an &lt;interval&gt;. If not given, the default of 5 is
assumed.<br>
&nbsp;<br>
There may be no white space between the ACTION and "&lt;" 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 "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;: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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
&nbsp;<br>
Let's take an example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp;&nbsp; <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="file:///vfat/Shorewall-docs/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><b> </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>
&nbsp;&nbsp;&nbsp; <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>
&nbsp;<br>
&nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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.&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
To specify a rate limit, <br>
<br>
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
&nbsp;<br>
&nbsp;
where<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
&lt;interval&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
accepted within an &lt;interval&gt;. If not given, the default of 5 is
assumed.<br>
&nbsp;<br>
There may be no white space between the ACTION and "&lt;" 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 "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;: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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
&nbsp;<br>
Let's take an example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp;&nbsp; <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><b> </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>
&nbsp;&nbsp;&nbsp; <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>
&nbsp;<br>
&nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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.&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
To specify a rate limit, <br>
<br>
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
&nbsp;<br>
&nbsp;
where<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
&lt;interval&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
accepted within an &lt;interval&gt;. If not given, the default of 5 is
assumed.<br>
&nbsp;<br>
There may be no white space between the ACTION and "&lt;" 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 "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;: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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
&nbsp;<br>
Let's take an example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp;&nbsp; <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="file:///vfat/Shorewall-docs/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>
<font size="3"><a href="ftp://ftp.shorewall.com.au">ftp://ftp.shorewall.com.au</a></font></div>
<p><b>8/26/2003 - French Version of the Shorewall Setup Guide&nbsp;</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><b> </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>
&nbsp;&nbsp;&nbsp; <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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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.&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
To specify a rate limit, <br>
<br>
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
&nbsp;<br>
&nbsp;
where<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
&lt;interval&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
accepted within an &lt;interval&gt;. If not given, the default of 5 is
assumed.<br>
&nbsp;<br>
There may be no white space between the ACTION and "&lt;" 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 "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;: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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
&nbsp;<br>
Let's take an example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp;&nbsp; <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><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>
&nbsp;&nbsp;&nbsp; <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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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.&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
To specify a rate limit, <br>
<br>
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
&nbsp;<br>
&nbsp;
where<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
&lt;interval&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
accepted within an &lt;interval&gt;. If not given, the default of 5 is
assumed.<br>
&nbsp;<br>
There may be no white space between the ACTION and "&lt;" 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 "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;: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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
&nbsp;<br>
Let's take an example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp;&nbsp; <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>&nbsp;</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>
&nbsp;&nbsp;&nbsp; <br>
The firewall script has been modified to eliminate the error messages</li>
<li>&nbsp;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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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.&nbsp; See the <a
href="file:///vfat/Shorewall-docs/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>
&nbsp;<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>
&nbsp;<br>
To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
&nbsp;<br>
&nbsp;&nbsp; where<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
&lt;interval&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
accepted within an &lt;interval&gt;. If not given, the default of 5 is
assumed.<br>
&nbsp;<br>
There may be no white space between the ACTION and "&lt;" 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 "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
&nbsp;<br>
Let's take an example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp;&nbsp; <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>&nbsp;</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>
&nbsp;&nbsp;&nbsp; <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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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>
&nbsp;<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>
&nbsp;<br>
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
<br>
generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
&nbsp;<br>
where:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
used by the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
is 'udp' or 'tcp' then this is the destination port number used by the
tunnel.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
the remote tunnel gateway<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP
address of the remote tunnel gateway.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
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/&lt;interface&gt;/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>&nbsp; <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: &nbsp;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>
&nbsp;&nbsp; <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: &nbsp;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>
&nbsp;&nbsp; <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><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>
<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 &lt;command&gt;).</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 &nbsp;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>
&nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
&nbsp;&nbsp; b) All traffic that is part of or related to an
already-existing connection.<br>
<br>
&nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.<br>
<br>
&nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
possible for people to shoot themselves in the foot.<br>
<br>
&nbsp;Example:<br>
<br>
&nbsp;/etc/shorewall/nat:<br>
<br>
&nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;/etc/shorewall/rules:<br>
<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 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><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.<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 &lt;command&gt;).<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: &nbsp;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>
<blockquote> </blockquote>
<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>
&nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
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>
&nbsp; &nbsp; z&nbsp;&nbsp; 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 &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
&nbsp; &nbsp; 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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;Multi-port Match: Available<br>
&nbsp; &nbsp;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>
<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>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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt; &lt;netmask&gt;
| &lt;address&gt;/&lt;vlsm&gt; ]<br>
<br>
Examples:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BROADCAST=192.168.1.255<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
192.168.1.0 255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BROADCAST=192.168.1.255<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iprange &lt;address&gt;-&lt;address&gt;<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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]# shorewall iprange
192.168.1.4-192.168.12.9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
&nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
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>
&nbsp;<br>
&nbsp;&nbsp;&nbsp; Example:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Policy for dmz to net is
REJECT using chain all2all<br>
&nbsp;<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-&gt;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> </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>
&nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
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>
&nbsp; &nbsp; z&nbsp;&nbsp; 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 &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
&nbsp; &nbsp; 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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;Multi-port Match: Available<br>
&nbsp; &nbsp;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>
<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>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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt; &lt;netmask&gt;
| &lt;address&gt;/&lt;vlsm&gt; ]<br>
<br>
Examples:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BROADCAST=192.168.1.255<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
192.168.1.0 255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BROADCAST=192.168.1.255<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iprange &lt;address&gt;-&lt;address&gt;<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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]# shorewall iprange
192.168.1.4-192.168.12.9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
&nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
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>
&nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
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>
&nbsp; &nbsp; z&nbsp;&nbsp; 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 &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
&nbsp; &nbsp; 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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;Multi-port Match: Available<br>
&nbsp; &nbsp;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>
<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>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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt; &lt;netmask&gt;
| &lt;address&gt;/&lt;vlsm&gt; ]<br>
<br>
Examples:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BROADCAST=192.168.1.255<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
192.168.1.0 255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BROADCAST=192.168.1.255<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iprange &lt;address&gt;-&lt;address&gt;<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>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]# shorewall iprange
192.168.1.4-192.168.12.9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
&nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
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 &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
&nbsp; &nbsp; 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
(&gt; 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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;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>
&nbsp; &nbsp;NAT: Available<br>
&nbsp; &nbsp;Packet Mangling: Available<br>
&nbsp; &nbsp;Multi-port Match: Available<br>
&nbsp; &nbsp;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>
<ol>
</ol>
<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>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 &lt;directory&gt;" 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>&nbsp;&nbsp;&nbsp; Problems corrected:</b><br>
<blockquote>None.<br>
</blockquote>
<b>&nbsp;&nbsp;&nbsp; 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>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOGFORMAT="fp=%s:%d a=%s "<br>
&nbsp;<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><b> </b><b> </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>
&nbsp;&nbsp; a) tcp - RST<br>
&nbsp;&nbsp; b) udp - ICMP port unreachable<br>
&nbsp;&nbsp; c) icmp - ICMP host unreachable<br>
&nbsp;&nbsp; d) Otherwise - ICMP host prohibited<br>
If you are running earlier software, Shorewall will follow it's
traditional convention:<br>
&nbsp;&nbsp; a) tcp - RST<br>
&nbsp;&nbsp; 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><b> </b><br>
</p>
&nbsp;&nbsp;&nbsp; <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>
&nbsp;&nbsp;&nbsp; <b>New Features:<br>
</b>
<ol>
<li>&nbsp;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>&nbsp;&nbsp;&nbsp; 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>&nbsp;&nbsp;&nbsp; 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>
&nbsp;<br>
&nbsp;&nbsp; Examples:<br>
&nbsp;&nbsp; shorewall/params.mgmt:<br>
&nbsp;&nbsp; MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3<br>
&nbsp;&nbsp; TIME_SERVERS=4.4.4.4<br>
&nbsp;&nbsp; BACKUP_SERVERS=5.5.5.5<br>
&nbsp;&nbsp; ----- end params.mgmt -----<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;&nbsp; shorewall/params:<br>
&nbsp;&nbsp; # Shorewall 1.3 /etc/shorewall/params<br>
&nbsp;&nbsp; [..]<br>
&nbsp;&nbsp; #######################################<br>
&nbsp; <br>
&nbsp; &nbsp;INCLUDE params.mgmt&nbsp;&nbsp;&nbsp; <br>
&nbsp; <br>
&nbsp;&nbsp; # params unique to this host here<br>
&nbsp;&nbsp; #LAST LINE - ADD YOUR ENTRIES ABOVE THIS
ONE - DO NOT REMOVE<br>
&nbsp;&nbsp; ----- end params -----<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;&nbsp; shorewall/rules.mgmt:<br>
&nbsp;&nbsp; ACCEPT
net:$MGMT_SERVERS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
$FW&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ACCEPT
$FW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net:$TIME_SERVERS&nbsp;&nbsp;&nbsp;
udp&nbsp;&nbsp;&nbsp; 123<br>
&nbsp;&nbsp; ACCEPT
$FW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net:$BACKUP_SERVERS&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
&nbsp;&nbsp; ----- end rules.mgmt -----<br>
&nbsp;<br>
&nbsp;&nbsp; shorewall/rules:<br>
&nbsp;&nbsp; # Shorewall version 1.3 - Rules File<br>
&nbsp;&nbsp; [..]<br>
&nbsp;&nbsp; #######################################<br>
&nbsp;<br>
&nbsp;&nbsp; INCLUDE rules.mgmt&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp; <br>
&nbsp;&nbsp; # rules unique to this host here<br>
&nbsp;&nbsp; #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT
REMOVE<br>
&nbsp;&nbsp; ----- end rules -----<br>
&nbsp;<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>
&nbsp;<br>
The 'routeback' option is similar to the old 'multi' option with two
exceptions:<br>
&nbsp;<br>
&nbsp;&nbsp; a) The option pertains to a particular
zone,interface,address tuple.<br>
&nbsp;<br>
&nbsp;&nbsp; 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>
&nbsp;<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><b> </b></p>
<b> </b>
<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<i> </i>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><b> </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 &lt;device&gt;:&lt;integer&gt; 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&lt;n&gt; 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>
&nbsp;&nbsp; a) You must be running kernel 2.4.20<br>
&nbsp;&nbsp; b) You must have applied the patch in<br>
&nbsp;&nbsp; http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
&nbsp;&nbsp; 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>&lt;n&gt;
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&nbsp; "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>
&nbsp;<br>
&nbsp;&nbsp; a) In the INTERFACE column of /etc/shorewall/masq<br>
&nbsp;&nbsp; b) In the INTERFACE column of /etc/shorewall/nat<br>
&nbsp;</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>
&nbsp;<br>
&nbsp;&nbsp; a) The subnets associated with other addresses on the
interface.<br>
&nbsp;&nbsp; b) Subnets accessed through local routers.<br>
&nbsp;<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>
&nbsp;<br>
Example 1 -- This is how it works in 1.3.14.<br>
&nbsp;&nbsp; <br>
<pre>&nbsp;&nbsp; [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>&nbsp; [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24&nbsp; scope link<br> 192.168.10.0/24&nbsp; proto kernel&nbsp; scope link&nbsp; src 192.168.10.254<br></pre>
<pre>&nbsp; [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>
&nbsp;<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>
&nbsp;<br>
Example 2 -- Suppose that your current config is as follows:<br>
&nbsp;&nbsp; <br>
<pre>&nbsp;&nbsp; [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.10.0/24&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>&nbsp;&nbsp; [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24&nbsp; scope link<br> 192.168.10.0/24&nbsp; proto kernel&nbsp; scope link&nbsp; src 192.168.10.254<br> [root@gateway test]#</pre>
&nbsp;<br>
&nbsp;&nbsp; In this case, the second entry in /etc/shorewall/masq is
no longer required.<br>
&nbsp;<br>
Example 3 -- What if your current configuration is like this?<br>
&nbsp;<br>
<pre>&nbsp;&nbsp; [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>&nbsp;&nbsp; [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24&nbsp; scope link<br> 192.168.10.0/24&nbsp; proto kernel&nbsp; scope link&nbsp; src 192.168.10.254<br> [root@gateway test]#</pre>
&nbsp;<br>
&nbsp;&nbsp; In this case, you would
want to change the entry in&nbsp; /etc/shorewall/masq to:<br>
<pre>&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.0/24&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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&nbsp; "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>
&nbsp;<br>
&nbsp;&nbsp; a) In the INTERFACE column of /etc/shorewall/masq<br>
&nbsp;&nbsp; b) In the INTERFACE column of /etc/shorewall/nat<br>
&nbsp;</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>
&nbsp;<br>
&nbsp;&nbsp; a) The subnets associated with other addresses on the
interface.<br>
&nbsp;&nbsp; b) Subnets accessed through local routers.<br>
&nbsp;<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>
&nbsp;<br>
Example 1 -- This is how it works in 1.3.14.<br>
&nbsp;&nbsp; <br>
<pre>&nbsp;&nbsp; [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>&nbsp; [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24&nbsp; scope link<br> 192.168.10.0/24&nbsp; proto kernel&nbsp; scope link&nbsp; src 192.168.10.254<br></pre>
<pre>&nbsp; [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>
&nbsp;<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>
&nbsp;<br>
Example 2 -- Suppose that your current config is as follows:<br>
&nbsp;&nbsp; <br>
<pre>&nbsp;&nbsp; [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.10.0/24&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>&nbsp;&nbsp; [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24&nbsp; scope link<br> 192.168.10.0/24&nbsp; proto kernel&nbsp; scope link&nbsp; src 192.168.10.254<br> [root@gateway test]#</pre>
&nbsp;<br>
&nbsp;&nbsp; In this case, the second entry in /etc/shorewall/masq is
no longer required.<br>
&nbsp;<br>
Example 3 -- What if your current configuration is like this?<br>
&nbsp;<br>
<pre>&nbsp;&nbsp; [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>&nbsp;&nbsp; [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24&nbsp; scope link<br> 192.168.10.0/24&nbsp; proto kernel&nbsp; scope link&nbsp; src 192.168.10.254<br> [root@gateway test]#</pre>
&nbsp;<br>
&nbsp;&nbsp; In this case, you would
want to change the entry in&nbsp; /etc/shorewall/masq to:<br>
<pre>&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ADDRESS<br> eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.0/24&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<b> </b></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>
&nbsp;&nbsp;&nbsp; <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
&nbsp;&nbsp;&nbsp; <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>&nbsp;</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>
&nbsp;&nbsp; Here are three rules from my previous rules file:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT&nbsp;&nbsp; net&nbsp;
dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT&nbsp;&nbsp; net&nbsp;
dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
<br>
&nbsp;&nbsp; These three rules ended up generating _three_ copies of<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
dmz:206.124.146.177 tcp smtp<br>
<br>
&nbsp;&nbsp; By writing the rules this way, I end up with only one copy
of the ACCEPT rule.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT-&nbsp; net&nbsp;
dmz:206.124.146.177 tcp smtp -&nbsp; 206.124.146.178<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT-&nbsp; net&nbsp;
dmz:206.124.146.177 tcp smtp -&nbsp; 206.124.146.179<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
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><b> </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>&nbsp;&nbsp;&nbsp; <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
&nbsp;&nbsp;&nbsp; <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>
<p> Features include:<br>
</p>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping rules
(tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging after an
error occurs. This places the point of the failure near the end of the
trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more than 40% with
my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been added which shows
the current packet classification filters. The output from this command
is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be
all caps) is now accepted as a valid syslog level and causes the
subject packets to be logged using the ULOG
target rather than the LOG target. This allows you to run ulogd
(available from <a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to a
separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain in the
mangle table ("shorewall show mangle" will show you the chains in
the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in <a
href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
marking input packets based on their destination even when you are
using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory with empty
'init', 'start', 'stop' and 'stopped' files. If you already have a file
with one of these names, don't worry -- the upgrade process won't
overwrite your file.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable to <a
href="Documentation.htm#Conf">shorewall.conf</a>. This variable
specifies the syslog level at which packets are logged as a result of
entries in the /etc/shorewall/rfc1918 file. Previously, these packets
were always logged at the 'info' level.<br>
</li>
</ol>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3<br>
</b></p>
This version corrects a problem with Blacklist logging. In Beta 2, if
BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall would
fail to start and "shorewall refresh" would also fail.<br>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b></p>
<p>The first public Beta version of Shorewall 1.3.12 is now available
(Beta 1 was made available only to a limited audience).<br>
</p>
Features include:<br>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping rules
(tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging after an
error occurs. This places the point of the failure near the end of the
trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by more than 40% with
my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been added which shows
the current packet classification filters. The output from this command
is also added as a separate page in "shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted as a valid syslog level
and causes the subject packets to be logged using the ULOG target
rather than the LOG target. This allows you to run ulogd (available
from <a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to a
separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD chain in the
mangle table ("shorewall show mangle" will show you the
chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in
shorewall.conf. This allows for marking input packets
based on their destination even when you are using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory with empty
'init', 'start', 'stop' and 'stopped' files. If you already have a file
with one of these names, don't worry -- the upgrade process won't
overwrite your file.</li>
</ol>
You may download the Beta from:<br>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
alt="Powered by Mandrake Linux" width="140" height="21" border="0"> </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&amp;id_art=250&amp;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>
&nbsp; &nbsp; 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-&gt;fw policies now generate a startup error. fw-&gt;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>&nbsp;&nbsp;&nbsp; <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
&nbsp;&nbsp;&nbsp; <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><b> </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><b> </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><b> </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 - &nbsp;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" width="50"
height="86" align="left"> 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 - &nbsp;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>
<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>
</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&nbsp; -- 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 border="0"
src="images/j0233056.gif" width="50" height="80" align="middle"> </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>&nbsp;</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/&lt;interface&gt;/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>&lt;zone&gt;</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>&lt;zone&gt;</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:&nbsp; 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>.&nbsp; 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>
&lt;configuration directory&gt;</i>). This command attempts "shorewall
-c <i> &lt;configuration directory&gt;</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&nbsp;</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&nbsp;
<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.&nbsp;</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>&nbsp;</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.&nbsp;</li>
</ul>
<p><b>11/20/2001 - The current version of Shorewall is 1.1.18.&nbsp;</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>.&nbsp;
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.&nbsp;</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.&nbsp;</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>
&nbsp;&nbsp;&nbsp; sea&nbsp;&nbsp;&nbsp;
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"&nbsp;</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&nbsp; 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.&nbsp; 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"&nbsp; column to /etc/shorewall/nat</a>. By placing "no" or
"No" in the new column, the NAT behavior of prior versions may be
retained.&nbsp;</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.&nbsp;</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).&nbsp;</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 border="0"
src="images/leaflogo.gif" width="49" height="36"> </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.&nbsp;</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.&nbsp;</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>
<p><font size="2">Updated 10/06/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2"> Copyright</font> <20> <font
size="2">2001, 2002 Thomas M. Eastep.</font></a><br>
</p>
<br>
</body>
</html>
View Git Blame Copy Permalink