mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-15 04:04:10 +01:00
e30c2a7ec8
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1081 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
5406 lines
240 KiB
HTML
5406 lines
240 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
<title>Shorewall News</title>
|
|
</head>
|
|
<body>
|
|
<h1 style="text-align: left;">Shorewall News Archive</h1>
|
|
<span style="font-weight: bold;">Tom Eastep<br>
|
|
<br>
|
|
</span>Copyright © 2001-2004 Thomas M. Eastep<br>
|
|
<p>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation;
|
|
with no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled “<span
|
|
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
|
Documentation License</a></span>”.<br>
|
|
</p>
|
|
<p>2004-01-13<br>
|
|
</p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<p><b>1/13/2004 - Shorewall 1.4.9</b><b><br>
|
|
</b></p>
|
|
<p>Problems Corrected since version 1.4.8:<br>
|
|
</p>
|
|
<ol>
|
|
<li>There has been a low continuing level of confusion over the
|
|
terms "Source NAT" (SNAT) and "Static NAT". To avoid future
|
|
confusion, all instances of "Static NAT" have been replaced with
|
|
"One-to-one NAT" in the documentation and configuration files.</li>
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
|
reworded for clarity.</li>
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
|
will
|
|
no longer produce an error if they attempt to add a rule that would
|
|
override a NONE policy. The logic for expanding these wild-card
|
|
rules now simply skips those (SOURCE,DEST) pairs that have a NONE
|
|
policy.</li>
|
|
<li>DNAT rules that also specified SNAT now work reliably.
|
|
Previously,
|
|
there were cases where the SNAT specification was effectively ignored.</li>
|
|
</ol>
|
|
<p>Migration Issues:<br>
|
|
<br>
|
|
None.<br>
|
|
<br>
|
|
New Features:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The documentation has been completely rebased to Docbook
|
|
XML. The
|
|
documentation is now released as separate HTML and XML packages.</li>
|
|
<li>To cut down on the number of "Why are these ports closed
|
|
rather
|
|
than stealthed?" questions, the SMB-related rules in
|
|
/etc/shorewall/common.def have been changed from 'reject' to
|
|
'DROP'.</li>
|
|
<li>For easier identification, packets logged under the
|
|
'norfc1918'
|
|
interface option are now logged out of chains named 'rfc1918'.
|
|
Previously, such packets were logged under chains named
|
|
'logdrop'.</li>
|
|
<li>Distributors and developers seem to be regularly inventing
|
|
new
|
|
naming conventions for kernel modules. To avoid the need to change
|
|
Shorewall code for each new convention, the MODULE_SUFFIX option
|
|
has been added to shorewall.conf. MODULE_SUFFIX may be set to the
|
|
suffix for module names in your particular distribution. If
|
|
MODULE_SUFFIX is not set in shorewall.conf, Shorewall will use the
|
|
list "o gz ko o.gz".<br>
|
|
<br>
|
|
To see what suffix is used by your distribution:<br>
|
|
<br>
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
<br>
|
|
All of the files listed should have the same suffix (extension).
|
|
Set MODULE_SUFFIX to that suffix.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
If all files end in ".kzo" then set
|
|
MODULE_SUFFIX="kzo"<br>
|
|
If all files end in ".kz.o" then set
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
<li>Support for user defined rule ACTIONS has been implemented
|
|
through two new files:<br>
|
|
<br>
|
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
|
/etc/shorewall/action.template - For each user defined
|
|
<action>, copy this file to
|
|
/etc/shorewall/action.<action> and add the appropriate rules
|
|
for that <action>. Once an <action> has been defined,
|
|
it may be used like any of the builtin ACTIONS (ACCEPT, DROP, etc.)
|
|
in /etc/shorewall/rules.<br>
|
|
<br>
|
|
Example: You want an action that logs a packet at the 'info' level
|
|
and accepts the connection.<br>
|
|
<br>
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
<br>
|
|
LogAndAccept<br>
|
|
<br>
|
|
You would then copy /etc/shorewall/action.template to
|
|
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
|
two
|
|
rules:<br>
|
|
LOG:info<br>
|
|
ACCEPT</li>
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
|
"Yes" (non-syn
|
|
TCP packets that are not part of an existing connection are filtered
|
|
according to the rules and policies rather than being dropped). I have
|
|
made this change for two reasons:<br>
|
|
<br>
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
|
any timeout during TCP session tear down results in the firewall
|
|
dropping all of the retries.<br>
|
|
<br>
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
|
lots of confusing messages when a connection got "stuck". While I could
|
|
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
|
dislike defaults that silently throw away packets.</li>
|
|
<li>The common.def file now contains an entry that silently drops
|
|
ICMP
|
|
packets with a null source address. Ad Koster reported a case where
|
|
these were occuring frequently as a result of a broken system on his
|
|
external network.</li>
|
|
</ol>
|
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b><b> </b></p>
|
|
<div style="margin-left: 40px;"><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
|
</div>
|
|
<p>Problems Corrected since version 1.4.8:</p>
|
|
<ol>
|
|
<li>There has been a low continuing level of confusion over the
|
|
terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion,
|
|
all instances of "Static NAT" have been replaced with "One-to-one NAT"
|
|
in the documentation and configuration files.</li>
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
|
reworded for clarity.</li>
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
|
will no longer produce an error if they attempt to add a rule that
|
|
would override a NONE policy. The logic for expanding these wild-card
|
|
rules now simply skips those (SOURCE,DEST) pairs that have a NONE
|
|
policy.</li>
|
|
<li>DNAT rules that also specified SNAT now work reliably.
|
|
Previously, there were cases where the SNAT specification was
|
|
effectively ignored.<br>
|
|
</li>
|
|
</ol>
|
|
<p>Migration Issues:</p>
|
|
<p> None.<br>
|
|
<br>
|
|
New Features: </p>
|
|
<ol>
|
|
<li>The documentation has been completely rebased to Docbook
|
|
XML. The documentation is now released as separate HTML and XML
|
|
packages.<br>
|
|
</li>
|
|
<li>To cut down on the number of "Why are these ports closed
|
|
rather than stealthed?" questions, the SMB-related rules in
|
|
/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.</li>
|
|
<li>For easier identification, packets logged under the
|
|
'norfc1918' interface option are now logged out of chains named
|
|
'rfc1918'. Previously, such packets were logged under chains named
|
|
'logdrop'.</li>
|
|
<li>Distributors and developers seem to be regularly inventing
|
|
new naming conventions for kernel modules. To avoid the need to change
|
|
Shorewall code for each new convention, the MODULE_SUFFIX option has
|
|
been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix
|
|
for module names in your particular distribution. If MODULE_SUFFIX is
|
|
not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
|
<br>
|
|
To see what suffix is used by your distribution:<br>
|
|
<br>
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
<br>
|
|
All of the files listed should have the same suffix (extension). Set
|
|
MODULE_SUFFIX to that suffix.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
If all files end in ".kzo" then set
|
|
MODULE_SUFFIX="kzo"<br>
|
|
If all files end in ".kz.o" then set
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
<li>Support for user defined rule ACTIONS has been implemented
|
|
through two new files:<br>
|
|
<br>
|
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
|
/etc/shorewall/action.template - For each user defined <action>,
|
|
copy this file to /etc/shorewall/action.<action> and add the
|
|
appropriate rules for that <action>. Once an <action> has
|
|
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
|
DROP, etc.) in /etc/shorewall/rules.<br>
|
|
<br>
|
|
Example: You want an action that logs a packet at the 'info' level and
|
|
accepts the connection.<br>
|
|
<br>
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
<br>
|
|
LogAndAccept<br>
|
|
<br>
|
|
You would then copy /etc/shorewall/action.template to
|
|
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
|
two
|
|
rules:<br>
|
|
LOG:info<br>
|
|
ACCEPT<br>
|
|
</li>
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
|
"Yes" (non-syn TCP packets that are not part of an existing connection
|
|
are filtered according to the rules and policies rather than being
|
|
dropped). I have made this change for two reasons:<br>
|
|
<br>
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
|
any timeout during TCP session tear down results in the firewall
|
|
dropping all of the retries.<br>
|
|
<br>
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
|
lots of confusing messages when a connection got "stuck". While I could
|
|
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
|
dislike defaults that silently throw away packets.<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back
|
|
On-line</b><b> <br>
|
|
</b></p>
|
|
<p>Our high-capacity server has been restored to service --
|
|
please let <a href="mailto:webmaster@shorewall.net">us</a> know if you
|
|
find any problems.</p>
|
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 1</b><b> </b></p>
|
|
<div style="margin-left: 40px;"><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
|
</div>
|
|
<p>Problems Corrected since version 1.4.8:</p>
|
|
<ol>
|
|
<li>There has been a low continuing level of confusion over the
|
|
terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion,
|
|
all instances of "Static NAT" have been replaced with "One-to-one NAT"
|
|
in the documentation and configuration files.</li>
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been
|
|
reworded for clarity.</li>
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
|
will no longer produce an error if they attempt to add a rule that
|
|
would override a NONE policy. The logic for expanding these wild-card
|
|
rules now simply skips those (SOURCE,DEST) pairs that have a NONE
|
|
policy.</li>
|
|
</ol>
|
|
<p>Migration Issues:</p>
|
|
<p> None.<br>
|
|
<br>
|
|
New Features: </p>
|
|
<ol>
|
|
<li>To cut down on the number of "Why are these ports closed
|
|
rather than stealthed?" questions, the SMB-related rules in
|
|
/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.</li>
|
|
<li>For easier identification, packets logged under the
|
|
'norfc1918' interface option are now logged out of chains named
|
|
'rfc1918'. Previously, such packets were logged under chains named
|
|
'logdrop'.</li>
|
|
<li>Distributors and developers seem to be regularly inventing
|
|
new naming conventions for kernel modules. To avoid the need to change
|
|
Shorewall code for each new convention, the MODULE_SUFFIX option has
|
|
been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix
|
|
for module names in your particular distribution. If MODULE_SUFFIX is
|
|
not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
|
<br>
|
|
To see what suffix is used by your distribution:<br>
|
|
<br>
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
<br>
|
|
All of the files listed should have the same suffix (extension). Set
|
|
MODULE_SUFFIX to that suffix.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
If all files end in ".kzo" then set
|
|
MODULE_SUFFIX="kzo"<br>
|
|
If all files end in ".kz.o" then set
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
<li>Support for user defined rule ACTIONS has been implemented
|
|
through two new files:<br>
|
|
<br>
|
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
|
/etc/shorewall/action.template - For each user defined <action>,
|
|
copy this file to /etc/shorewall/action.<action> and add the
|
|
appropriate rules for that <action>. Once an <action> has
|
|
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
|
DROP, etc.) in /etc/shorewall/rules.<br>
|
|
<br>
|
|
Example: You want an action that logs a packet at the 'info' level and
|
|
accepts the connection.<br>
|
|
<br>
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
<br>
|
|
LogAndAccept<br>
|
|
<br>
|
|
You would then copy /etc/shorewall/action.template to
|
|
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
|
two
|
|
rules:<br>
|
|
LOG:info<br>
|
|
ACCEPT<br>
|
|
</li>
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
|
"Yes" (non-syn TCP packets that are not part of an existing connection
|
|
are filtered according to the rules and policies rather than being
|
|
dropped). I have made this change for two reasons:<br>
|
|
<br>
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
|
any timeout during TCP session tear down results in the firewall
|
|
dropping all of the retries.<br>
|
|
<br>
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
|
lots of confusing messages when a connection got "stuck". While I could
|
|
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
|
dislike defaults that silently throw away packets.</li>
|
|
</ol>
|
|
<p><b>12/03/2003 - Support Torch Passed</b></p>
|
|
Effective today, I am reducing my participation in the day-to-day
|
|
support of Shorewall. As part of this shift to community-based
|
|
Shorewall support a new <a
|
|
href="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">Shorewall
|
|
Newbies mailing list</a> has been established to field questions and
|
|
problems from new users. I will not monitor that list personally. I
|
|
will continue my active development of Shorewall and will be available
|
|
via the development list to handle development issues -- Tom.
|
|
<p><b>11/07/2003 - Shorewall 1.4.8<br>
|
|
<br>
|
|
</b>Problems Corrected since version 1.4.7:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Tuomo Soini has supplied a correction to a problem that occurs
|
|
using some versions of 'ash'. The symptom is that "shorewall start"
|
|
fails with:<br>
|
|
<br>
|
|
local: --limit: bad variable name<br>
|
|
iptables v1.2.8: Couldn't load match
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
cannot open shared object file: No such file or
|
|
directory<br>
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
information.</li>
|
|
<li>Andres Zhoglo has supplied a correction that avoids trying to
|
|
use the multiport match iptables facility on ICMP rules.<br>
|
|
<br>
|
|
Example of rule that previously caused "shorewall
|
|
start" to fail:<br>
|
|
<br>
|
|
|
|
ACCEPT loc $FW
|
|
icmp 0,8,11,12<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if the following error message was issued,
|
|
Shorewall was left in an inconsistent state.<br>
|
|
<br>
|
|
Error: Unable to determine the routes through
|
|
interface xxx<br>
|
|
<br>
|
|
</li>
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.</li>
|
|
<li>In Shorewall 1.4.2, an optimization was added. This
|
|
optimization involved creating a chain named "<zone>_frwd"
|
|
for most zones defined using the /etc/shorewall/hosts file. It has
|
|
since been discovered that in many cases these new chains contain
|
|
redundant rules and that the "optimization" turns out to be less
|
|
than optimal. The implementation has now been corrected.</li>
|
|
<li>When the MARK value in a tcrules entry is followed by ":F" or
|
|
":P", the ":F" or ":P" was previously only applied to the first
|
|
Netfilter rule generated by the entry. It is now applied to all
|
|
entries.</li>
|
|
<li>An incorrect comment concerning Debian's use of the SUBSYSLOCK
|
|
option has been removed from shorewall.conf.</li>
|
|
<li>Previously, neither the 'routefilter' interface option nor the
|
|
ROUTE_FILTER parameter were working properly. This has been
|
|
corrected (thanks to Eric Bowles for his analysis and patch). The
|
|
definition of the ROUTE_FILTER option has changed however.
|
|
Previously, ROUTE_FILTER=Yes was documented as enabling route
|
|
filtering on all interfaces (which didn't work). Beginning with
|
|
this release, setting ROUTE_FILTER=Yes will enable route filtering
|
|
of all interfaces brought up while Shorewall is started. As a
|
|
consequence, ROUTE_FILTER=Yes can coexist with the use of the
|
|
'routefilter' option in the interfaces file.</li>
|
|
<li>If MAC verification was enabled on an interface with a /32
|
|
address and a broadcast address then an error would occur during
|
|
startup.</li>
|
|
<li>The NONE policy's intended use is to suppress the generating of
|
|
rules that can't possibly be traversed. This means that a policy of
|
|
NONE is inappropriate where the source or destination zone is $FW
|
|
or "all". Shorewall now generates an error message if such a policy
|
|
is given in /etc/shorewall/policy. Previously such a policy caused
|
|
"shorewall start" to fail.</li>
|
|
<li>The 'routeback' option was broken for wildcard interfaces
|
|
(e.g., "tun+"). This has been corrected so that 'routeback' now
|
|
works as expected in this case.<br>
|
|
</li>
|
|
</ol>
|
|
Migration Issues:<br>
|
|
<ol>
|
|
<li>The definition of the ROUTE_FILTER option in shorewall.conf has
|
|
changed as described in item 8) above.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
<ol>
|
|
<li>A new QUEUE action has been introduced for rules. QUEUE allows
|
|
you to pass connection requests to a user-space filter such as
|
|
ftwall (http://p2pwall.sourceforge.net). The ftwall program allows
|
|
for effective filtering of p2p applications such as Kazaa. For
|
|
example, to use ftwall to filter P2P clients in the 'loc' zone, you
|
|
would add the following rules:<br>
|
|
<br>
|
|
QUEUE loc
|
|
net tcp<br>
|
|
QUEUE loc
|
|
net udp<br>
|
|
QUEUE loc
|
|
fw udp<br>
|
|
<br>
|
|
You would normally want to place those three rules BEFORE any
|
|
ACCEPT rules for loc->net udp or tcp.<br>
|
|
<br>
|
|
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
|
|
Shorewall will only pass connection requests (SYN packets) to user
|
|
space. This is for compatibility with ftwall.</li>
|
|
<li>A BLACKLISTNEWNONLY option has been added to shorewall.conf.
|
|
When this option is set to "Yes", the blacklists (dynamic and
|
|
static) are only consulted for new connection requests. When set to
|
|
"No" (the default if the variable is not set), the blacklists are
|
|
consulted on every packet.<br>
|
|
<br>
|
|
Setting this option to "No" allows blacklisting to stop existing
|
|
connections from a newly blacklisted host but is more expensive in
|
|
terms of packet processing time. This is especially true if the
|
|
blacklists contain a large number of entries.</li>
|
|
<li>Chain names used in the /etc/shorewall/accounting file may now
|
|
begin with a digit ([0-9]) and may contain embedded dashes
|
|
("-").</li>
|
|
</ol>
|
|
<p><b>10/30/2003 - Shorewall 1.4.8 RC1<br>
|
|
</b></p>
|
|
Given the small number of new features and the relatively few lines
|
|
of code that were changed, there will be no Beta for 1.4.8.<br>
|
|
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<br>
|
|
</b>Problems Corrected since version 1.4.7:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Tuomo Soini has supplied a correction to a problem that occurs
|
|
using some versions of 'ash'. The symptom is that "shorewall start"
|
|
fails with:<br>
|
|
<br>
|
|
local: --limit: bad variable name<br>
|
|
iptables v1.2.8: Couldn't load match
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
cannot open shared object file: No such file or
|
|
directory<br>
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
information.</li>
|
|
<li>Andres Zhoglo has supplied a correction that avoids trying to
|
|
use the multiport match iptables facility on ICMP rules.<br>
|
|
<br>
|
|
Example of rule that previously caused "shorewall
|
|
start" to fail:<br>
|
|
<br>
|
|
|
|
ACCEPT loc $FW
|
|
icmp 0,8,11,12<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if the following error message was issued,
|
|
Shorewall was left in an inconsistent state.<br>
|
|
<br>
|
|
Error: Unable to determine the routes through
|
|
interface xxx<br>
|
|
<br>
|
|
</li>
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.</li>
|
|
<li>In Shorewall 1.4.2, an optimization was added. This
|
|
optimization involved creating a chain named "<zone>_frwd"
|
|
for most zones defined using the /etc/shorewall/hosts file. It has
|
|
since been discovered that in many cases these new chains contain
|
|
redundant rules and that the "optimization" turns out to be less
|
|
than optimal. The implementation has now been corrected.</li>
|
|
<li>When the MARK value in a tcrules entry is followed by ":F" or
|
|
":P", the ":F" or ":P" was previously only applied to the first
|
|
Netfilter rule generated by the entry. It is now applied to all
|
|
entries.</li>
|
|
<li>An incorrect comment concerning Debian's use of the SYBSYSLOCK
|
|
option has been removed from shorewall.conf.</li>
|
|
<li>Previously, neither the 'routefilter' interface option nor the
|
|
ROUTE_FILTER parameter were working properly. This has been
|
|
corrected (thanks to Eric Bowles for his analysis and patch). The
|
|
definition of the ROUTE_FILTER option has changed however.
|
|
Previously, ROUTE_FILTER=Yes was documented as enabling route
|
|
filtering on all interfaces (which didn't work). Beginning with
|
|
this release, setting ROUTE_FILTER=Yes will enable route filtering
|
|
of all interfaces brought up while Shorewall is started. As a
|
|
consequence, ROUTE_FILTER=Yes can coexist with the use of the
|
|
'routefilter' option in the interfaces file.</li>
|
|
</ol>
|
|
Migration Issues:<br>
|
|
<ol>
|
|
<li>The definition of the ROUTE_FILTER option in shorewall.conf has
|
|
changed as described in item 8) above.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
<ol>
|
|
<li>A new QUEUE action has been introduced for rules. QUEUE allows
|
|
you to pass connection requests to a user-space filter such as
|
|
ftwall (http://p2pwall.sourceforge.net). The ftwall program allows
|
|
for effective filtering of p2p applications such as Kazaa. For
|
|
example, to use ftwall to filter P2P clients in the 'loc' zone, you
|
|
would add the following rules:<br>
|
|
<br>
|
|
QUEUE loc
|
|
net tcp<br>
|
|
QUEUE loc
|
|
net udp<br>
|
|
QUEUE loc
|
|
fw udp<br>
|
|
<br>
|
|
You would normally want to place those three rules BEFORE any
|
|
ACCEPT rules for loc->net udp or tcp.<br>
|
|
<br>
|
|
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
|
|
Shorewall will only pass connection requests (SYN packets) to user
|
|
space. This is for compatibility with ftwall.</li>
|
|
<li>A BLACKLISTNEWNONLY option has been added to shorewall.conf.
|
|
When this option is set to "Yes", the blacklists (dynamic and
|
|
static) are only consulted for new connection requests. When set to
|
|
"No" (the default if the variable is not set), the blacklists are
|
|
consulted on every packet.<br>
|
|
<br>
|
|
Setting this option to "No" allows blacklisting to stop existing
|
|
connections from a newly blacklisted host but is more expensive in
|
|
terms of packet processing time. This is especially true if the
|
|
blacklists contain a large number of entries.</li>
|
|
<li>Chain names used in the /etc/shorewall/accounting file may now
|
|
begin with a digit ([0-9]) and may contain embedded dashes
|
|
("-").<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag
|
|
awards</b> <b><img
|
|
style="border: 0px solid ; width: 50px; height: 80px;"
|
|
src="images/j0233056.gif" align="middle" title="" alt="">Shorewall
|
|
1.4.7c released.</b></p>
|
|
<ol>
|
|
<li>The saga with "<zone>_frwd" chains continues. The 1.4.7c
|
|
script produces a ruleset that should work for everyone even if it
|
|
is not quite optimal. My apologies for this ongoing mess.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>10/24/2003 - Shorewall 1.4.7b</b></p>
|
|
This is a bugfx rollup of the 1.4.7a fixes plus:<br>
|
|
<ol>
|
|
<li>The fix for problem 5 in 1.4.7a was wrong with the result that
|
|
"<zone>_frwd" chains might contain too few rules. That wrong
|
|
code is corrected in this release.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>10/21/2003 - Shorewall 1.4.7a<br>
|
|
</b></p>
|
|
<p>This is a bugfix rollup of the following problem
|
|
corrections:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Tuomo Soini has supplied a correction to a problem that occurs
|
|
using some versions of 'ash'. The symptom is that "shorewall start"
|
|
fails with:<br>
|
|
<br>
|
|
local: --limit: bad variable name<br>
|
|
iptables v1.2.8: Couldn't load match
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
cannot open shared object file: No such file or
|
|
directory<br>
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
information.<br>
|
|
<br>
|
|
</li>
|
|
<li>Andres Zhoglo has supplied a correction that avoids trying to
|
|
use the multiport match iptables facility on ICMP rules.<br>
|
|
<br>
|
|
Example of rule that previously caused "shorewall
|
|
start" to fail:<br>
|
|
<br>
|
|
|
|
ACCEPT loc $FW
|
|
icmp 0,8,11,12<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if the following error message was issued,
|
|
Shorewall was left in an inconsistent state.<br>
|
|
<br>
|
|
Error: Unable to determine the routes through
|
|
interface xxx<br>
|
|
<br>
|
|
</li>
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.</li>
|
|
<li>In Shorewall 1.4.2, an optimization was added. This
|
|
optimization involved creating a chain named "<zone>_frwd"
|
|
for most zones defined using the /etc/shorewall/hosts file. It has
|
|
since been discovered that in many cases these new chains contain
|
|
redundant rules and that the "optimization" turns out to be less
|
|
than optimal. The implementation has now been corrected.</li>
|
|
<li>When the MARK value in a tcrules entry is followed by ":F" or
|
|
":P", the ":F" or ":P" was previously only applied to the first
|
|
Netfilter rule generated by the entry. It is now applied to all
|
|
entries.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>10/06/2003 - Shorewall 1.4.7</b><b><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font were
|
|
corrected since 1.4.7 RC2).</b><br>
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
|
was being tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
|
tcrules file. Previously, these addresses resulted in an invalid
|
|
iptables command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured
|
|
Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages
|
|
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip
|
|
addresses were being added to a PPP interface; the addresses were
|
|
successfully added in spite of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
(previously named "Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop' commands
|
|
now delete any existing rules for the subject IP address before
|
|
adding a new DROP or REJECT rule. Previously, there could be many
|
|
rules for the same IP address in the dynamic chain so that multiple
|
|
'allow' commands were required to re-enable traffic to/from the
|
|
address.</li>
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following
|
|
entry in /etc/shorewall/masq resulted in a startup error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall previously choked over IPV6 addresses configured on
|
|
interfaces in contexts where Shorewall needed to detect something
|
|
about the interface (such as when "detect" appears in the BROADCAST
|
|
column of the /etc/shorewall/interfaces file).</li>
|
|
<li>Shorewall will now load module files that are formed from the
|
|
module name by appending ".o.gz".</li>
|
|
<li>When Shorewall adds a route to a proxy ARP host and such a
|
|
route already exists, two routes resulted previously. This has been
|
|
corrected so that the existing route is replaced if it already
|
|
exists.</li>
|
|
<li>The rfc1918 file has been updated to reflect recent
|
|
allocations.</li>
|
|
<li>The documentation of the USER SET column in the rules file has
|
|
been corrected.</li>
|
|
<li>If there is no policy defined for the zones specified in a
|
|
rule, the firewall script previously encountered a shell syntax
|
|
error:<br>
|
|
<br>
|
|
[: NONE: unexpected
|
|
operator<br>
|
|
<br>
|
|
Now, the absence of a policy generates an error message and the
|
|
firewall is stopped:<br>
|
|
<br>
|
|
No policy defined from
|
|
zone <source> to zone <dest><br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if neither /etc/shorewall/common nor
|
|
/etc/shorewall/common.def existed, Shorewall would fail to start
|
|
and would not remove the lock file. Failure to remove the lock file
|
|
resulted in the following during subsequent attempts to start:<br>
|
|
<br>
|
|
Loading /usr/share/shorewall/functions...<br>
|
|
Processing /etc/shorewall/params ...<br>
|
|
Processing /etc/shorewall/shorewall.conf...<br>
|
|
Giving up on lock file
|
|
/var/lib/shorewall/lock<br>
|
|
Shorewall Not Started<br>
|
|
<br>
|
|
Shorewall now reports a fatal error if neither of these two files
|
|
exist and correctly removes the lock fille.</li>
|
|
<li>The order of processing the various options has been changed
|
|
such that blacklist entries now take precedence over the 'dhcp' <span
|
|
style="font-weight: bold;">i</span>nterface setting.</li>
|
|
<li>The log message generated from the 'logunclean' interface
|
|
option has been changed to reflect a disposition of LOG rather than
|
|
DROP.</li>
|
|
<li><span style="font-weight: bold;">When a user name and/or a
|
|
group name was specified in the USER SET column and the destination
|
|
zone was qualified with a IP address, the user and/or group name
|
|
was not being used to qualify the rule.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
ACCEPT fw net:192.0.2.12 tcp 23 - - -
|
|
vladimir:<br>
|
|
<br>
|
|
</span></li>
|
|
<li><span style="font-weight: bold;">The /etc/shorewall/masq file
|
|
has had the spurious "/" character at the front removed.<br>
|
|
<br>
|
|
</span></li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
|
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
|
for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
|
changed -- see the <a href="UserSets.html">User Set page</a> for
|
|
details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in
|
|
the first post-1.4.6 Snapshot has been removed. The facility had
|
|
too many idiosyncrasies for dial-up users to be a viable part of
|
|
Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter
|
|
will use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for
|
|
traffic accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of
|
|
this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the
|
|
corresponding ACCEPT rule in the filter table is not rate limited.
|
|
If you want to limit the filter table rule, you will need o create
|
|
two rules; a DNAT- rule and an ACCEPT rule which can be
|
|
rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST
|
|
fields, the limit will apply to each pair of zones individually
|
|
rather than as a single limit for all pairs of covered by the
|
|
rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate
|
|
per <interval><br>
|
|
<interval> is "sec" or
|
|
"min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5
|
|
is assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there
|
|
may be any white space within the burst specification. If you want
|
|
to specify logging of a rate-limited rule, the ":" and log level
|
|
comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the
|
|
/etc/shorewall/rules file. You may specify the rate limit there in
|
|
the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted;
|
|
in fact, since the burst is 4, the first four packets will be
|
|
accepted. After this, it will be 500ms (1 second divided by the
|
|
rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless
|
|
of how many packets reach it. Also, every 500ms which passes
|
|
without matching a packet, one of the bursts will be regained; if
|
|
no packets hit the rule for 2 second, the burst will be fully
|
|
recharged; back where we started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show"
|
|
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
|
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
|
for
|
|
details.</li>
|
|
</ol>
|
|
<p><b>10/02/2003 - Shorewall 1.4.7 RC2</b><b><br>
|
|
</b></p>
|
|
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b> <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>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
(previously named "Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop' commands
|
|
now delete any existing rules for the subject IP address before
|
|
adding a new DROP or REJECT rule. Previously, there could be many
|
|
rules for the same IP address in the dynamic chain so that multiple
|
|
'allow' commands were required to re-enable traffic to/from the
|
|
address.</li>
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following
|
|
entry in /etc/shorewall/masq resulted in a startup error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall previously choked over IPV6 addresses configured on
|
|
interfaces in contexts where Shorewall needed to detect something
|
|
about the interface (such as when "detect" appears in the BROADCAST
|
|
column of the /etc/shorewall/interfaces file).</li>
|
|
<li>Shorewall will now load module files that are formed from the
|
|
module name by appending ".o.gz".</li>
|
|
<li>When Shorewall adds a route to a proxy ARP host and such a
|
|
route already exists, two routes resulted previously. This has been
|
|
corrected so that the existing route is replaced if it already
|
|
exists.</li>
|
|
<li>The rfc1918 file has been updated to reflect recent
|
|
allocations.</li>
|
|
<li><span style="font-weight: bold;">The documentation of the USER
|
|
SET column in the rules file has been corrected.</span></li>
|
|
<li><span style="font-weight: bold;">If there is no policy defined
|
|
for the zones specified in a rule, the firewall script previously
|
|
encountered a shell syntax error:<br>
|
|
<br>
|
|
[: NONE: unexpected
|
|
operator<br>
|
|
<br>
|
|
Now, the absence of a policy generates an error message and the
|
|
firewall is stopped:<br>
|
|
<br>
|
|
No policy defined from
|
|
zone <source> to zone <dest><br>
|
|
<br>
|
|
</span></li>
|
|
<li><span style="font-weight: bold;">Previously, if neither
|
|
/etc/shorewall/common nor /etc/shorewall/common.def existed,
|
|
Shorewall would fail to start and would not remove the lock file.
|
|
Failure to remove the lock file resulted in the following during
|
|
subsequent attempts to start:<br>
|
|
<br>
|
|
Loading /usr/share/shorewall/functions...<br>
|
|
Processing /etc/shorewall/params ...<br>
|
|
Processing /etc/shorewall/shorewall.conf...<br>
|
|
Giving up on lock file
|
|
/var/lib/shorewall/lock<br>
|
|
Shorewall Not Started<br>
|
|
<br>
|
|
Shorewall now reports a fatal error if neither of these two files
|
|
exist and correctly removes the lock fille.</span></li>
|
|
<li><span style="font-weight: bold;">The order of processing the
|
|
various options has been changed such that blacklist entries now
|
|
take precedence over the 'dhcp' interface setting.</span></li>
|
|
<li><span style="font-weight: bold;">The log message generated from
|
|
the 'logunclean' interface option has been changed to reflect a
|
|
disposition of LOG rather than DROP.</span></li>
|
|
<li><span style="font-weight: bold;">The RFC1918 file has been
|
|
updated to reflect recent IANA allocations.<br>
|
|
</span></li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
|
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
|
for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
|
changed -- see the <a href="UserSets.html">User Set page</a> for
|
|
details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in
|
|
the first post-1.4.6 Snapshot has been removed. The facility had
|
|
too many idiosyncrasies for dial-up users to be a viable part of
|
|
Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter
|
|
will use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for
|
|
traffic accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of
|
|
this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the
|
|
corresponding ACCEPT rule in the filter table is not rate limited.
|
|
If you want to limit the filter table rule, you will need o create
|
|
two rules; a DNAT- rule and an ACCEPT rule which can be
|
|
rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST
|
|
fields, the limit will apply to each pair of zones individually
|
|
rather than as a single limit for all pairs of covered by the
|
|
rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate
|
|
per <interval><br>
|
|
<interval> is "sec" or
|
|
"min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5
|
|
is assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there
|
|
may be any white space within the burst specification. If you want
|
|
to specify logging of a rate-limited rule, the ":" and log level
|
|
comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the
|
|
/etc/shorewall/rules file. You may specify the rate limit there in
|
|
the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted;
|
|
in fact, since the burst is 4, the first four packets will be
|
|
accepted. After this, it will be 500ms (1 second divided by the
|
|
rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless
|
|
of how many packets reach it. Also, every 500ms which passes
|
|
without matching a packet, one of the bursts will be regained; if
|
|
no packets hit the rule for 2 second, the burst will be fully
|
|
recharged; back where we started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show"
|
|
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
|
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
|
for
|
|
details.</li>
|
|
</ol>
|
|
<p><b>9/18/2003 - Shorewall 1.4.7 RC 1</b><b><br>
|
|
</b></p>
|
|
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b> <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>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
(previously named "Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop' commands
|
|
now delete any existing rules for the subject IP address before
|
|
adding a new DROP or REJECT rule. Previously, there could be many
|
|
rules for the same IP address in the dynamic chain so that multiple
|
|
'allow' commands were required to re-enable traffic to/from the
|
|
address.</li>
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following
|
|
entry in /etc/shorewall/masq resulted in a startup error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall previously choked over IPV6 addresses configured on
|
|
interfaces in contexts where Shorewall needed to detect something
|
|
about the interface (such as when "detect" appears in the BROADCAST
|
|
column of the /etc/shorewall/interfaces file).</li>
|
|
<li>Shorewall will now load module files that are formed from the
|
|
module name by appending ".o.gz".</li>
|
|
<li style="font-weight: bold;">When Shorewall adds a route to a
|
|
proxy ARP host and such a route already exists, two routes resulted
|
|
previously. This has been corrected so that the existing route is
|
|
replaced if it already exists.</li>
|
|
<li><span style="font-weight: bold;">The rfc1918 file has been
|
|
updated to reflect recent allocations.</span><br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
|
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
|
for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
|
changed -- see the <a href="UserSets.html">User Set page</a> for
|
|
details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in
|
|
the first post-1.4.6 Snapshot has been removed. The facility had
|
|
too many idiosyncrasies for dial-up users to be a viable part of
|
|
Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter
|
|
will use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for
|
|
traffic accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of
|
|
this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the
|
|
corresponding ACCEPT rule in the filter table is not rate limited.
|
|
If you want to limit the filter table rule, you will need o create
|
|
two rules; a DNAT- rule and an ACCEPT rule which can be
|
|
rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST
|
|
fields, the limit will apply to each pair of zones individually
|
|
rather than as a single limit for all pairs of covered by the
|
|
rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate
|
|
per <interval><br>
|
|
<interval> is "sec" or
|
|
"min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5
|
|
is assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there
|
|
may be any white space within the burst specification. If you want
|
|
to specify logging of a rate-limited rule, the ":" and log level
|
|
comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the
|
|
/etc/shorewall/rules file. You may specify the rate limit there in
|
|
the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted;
|
|
in fact, since the burst is 4, the first four packets will be
|
|
accepted. After this, it will be 500ms (1 second divided by the
|
|
rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless
|
|
of how many packets reach it. Also, every 500ms which passes
|
|
without matching a packet, one of the bursts will be regained; if
|
|
no packets hit the rule for 2 second, the burst will be fully
|
|
recharged; back where we started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show"
|
|
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
|
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
|
for
|
|
details.</li>
|
|
</ol>
|
|
<p><b>9/15/2003 - Shorewall 1.4.7 Beta 2</b> <b><br>
|
|
</b></p>
|
|
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b> <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>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
(previously named "Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7" style="font-weight: bold;">The 'shorewall reject' and
|
|
'shorewall drop' commands now delete any existing rules for the
|
|
subject IP address before adding a new DROP or REJECT rule.
|
|
Previously, there could be many rules for the same IP address in
|
|
the dynamic chain so that multiple 'allow' commands were required
|
|
to re-enable traffic to/from the address.</li>
|
|
<li style="font-weight: bold;">When ADD_SNAT_ALIASES=Yes in
|
|
shorewall.conf, the following entry in /etc/shorewall/masq resulted
|
|
in a startup error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li style="font-weight: bold;">Shorewall previously choked over
|
|
IPV6 addresses configured on interfaces in contexts where Shorewall
|
|
needed to detect something about the interface (such as when
|
|
"detect" appears in the BROADCAST column of the
|
|
/etc/shorewall/interfaces file).</li>
|
|
<li><span style="font-weight: bold;">Shorewall will now load module
|
|
files that are formed from the module name by appending
|
|
".o.gz".</span><br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
|
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
|
for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
|
changed -- see the <a href="UserSets.html">User Set page</a> for
|
|
details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in
|
|
the first post-1.4.6 Snapshot has been removed. The facility had
|
|
too many idiosyncrasies for dial-up users to be a viable part of
|
|
Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter
|
|
will use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for
|
|
traffic accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of
|
|
this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the
|
|
corresponding ACCEPT rule in the filter table is not rate limited.
|
|
If you want to limit the filter table rule, you will need o create
|
|
two rules; a DNAT- rule and an ACCEPT rule which can be
|
|
rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST
|
|
fields, the limit will apply to each pair of zones individually
|
|
rather than as a single limit for all pairs of covered by the
|
|
rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate
|
|
per <interval><br>
|
|
<interval> is "sec" or
|
|
"min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5
|
|
is assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there
|
|
may be any white space within the burst specification. If you want
|
|
to specify logging of a rate-limited rule, the ":" and log level
|
|
comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the
|
|
/etc/shorewall/rules file. You may specify the rate limit there in
|
|
the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted;
|
|
in fact, since the burst is 4, the first four packets will be
|
|
accepted. After this, it will be 500ms (1 second divided by the
|
|
rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless
|
|
of how many packets reach it. Also, every 500ms which passes
|
|
without matching a packet, one of the bursts will be regained; if
|
|
no packets hit the rule for 2 second, the burst will be fully
|
|
recharged; back where we started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show"
|
|
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
|
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
|
for
|
|
details.</li>
|
|
</ol>
|
|
<p><b>8/27/2003 - Shorewall Mirror in Australia</b></p>
|
|
<p>Thanks to Dave Kempe and Solutions First (<a
|
|
href="http://www.solutionsfirst.com.au"><font size="3">http://www.solutionsfirst.com.au</font></a>),
|
|
there is now a
|
|
Shorewall Mirror in Australia:</p>
|
|
<div style="margin-left: 40px;"><a href="http://www.shorewall.com.au"
|
|
target="_top"><font size="3">http://www.shorewall.com.au</font></a><br>
|
|
<a href="ftp://ftp.shorewall.com.au"><font size="3">ftp://ftp.shorewall.com.au</font></a></div>
|
|
<p><b>8/26/2003 - French Version of the Shorewall Setup
|
|
Guide </b></p>
|
|
Thanks to Fabien <font size="3">Demassieux, there is now a <a
|
|
href="shorewall_setup_guide_fr.htm">French translation of the
|
|
Shorewall
|
|
Setup Guide</a>. Merci Beacoup, Fabien!</font>
|
|
<p><b>8/25/2003 - Shorewall 1.4.7 Beta 1</b> <b><br>
|
|
</b></p>
|
|
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b> <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>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
(previously named "Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
|
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
|
for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
|
changed -- see the <a href="UserSets.html">User Set page</a> for
|
|
details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in
|
|
the first post-1.4.6 Snapshot has been removed. The facility had
|
|
too many idiosyncrasies for dial-up users to be a viable part of
|
|
Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter
|
|
will use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for
|
|
traffic accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of
|
|
this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the
|
|
corresponding ACCEPT rule in the filter table is not rate limited.
|
|
If you want to limit the filter table rule, you will need o create
|
|
two rules; a DNAT- rule and an ACCEPT rule which can be
|
|
rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST
|
|
fields, the limit will apply to each pair of zones individually
|
|
rather than as a single limit for all pairs of covered by the
|
|
rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate
|
|
per <interval><br>
|
|
<interval> is "sec" or
|
|
"min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5
|
|
is assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there
|
|
may be any white space within the burst specification. If you want
|
|
to specify logging of a rate-limited rule, the ":" and log level
|
|
comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the
|
|
/etc/shorewall/rules file. You may specify the rate limit there in
|
|
the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted;
|
|
in fact, since the burst is 4, the first four packets will be
|
|
accepted. After this, it will be 500ms (1 second divided by the
|
|
rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless
|
|
of how many packets reach it. Also, every 500ms which passes
|
|
without matching a packet, one of the bursts will be regained; if
|
|
no packets hit the rule for 2 second, the burst will be fully
|
|
recharged; back where we started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show"
|
|
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
|
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
|
for
|
|
details.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>8/23/2003 - Snapshot 1.4.6_2003082</b><span
|
|
style="font-weight: bold;">3</span> <b></b></p>
|
|
<blockquote>
|
|
<p><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
|
was being tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
|
tcrules file. Previously, these addresses resulted in an invalid
|
|
iptables command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured
|
|
Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages
|
|
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip
|
|
addresses were being added to a PPP interface; the addresses were
|
|
successfully added in spite of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
(previously named "Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must
|
|
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
|
or 'save' commands.</li>
|
|
<li>To maintain strict compatibility with previous versions,
|
|
current uses of "shorewall drop" and "shorewall reject" should be
|
|
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
|
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
|
for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
|
changed -- see the <a href="UserSets.html">User Set page</a> for
|
|
details.</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each
|
|
interface defined in /etc/shorewall/interfaces. The 'drop' and
|
|
'reject' commands use the routing table to determine which of these
|
|
chains is to be used for blacklisting the specified IP
|
|
address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced
|
|
that do what 'drop' and 'reject' used to do; namely, when an
|
|
address is blacklisted using these new commands, it will be
|
|
blacklisted on all of your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter
|
|
will use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for
|
|
traffic accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of
|
|
this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the
|
|
corresponding ACCEPT rule in the filter table is not rate limited.
|
|
If you want to limit the filter table rule, you will need o create
|
|
two rules; a DNAT- rule and an ACCEPT rule which can be
|
|
rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST
|
|
fields, the limit will apply to each pair of zones individually
|
|
rather than as a single limit for all pairs of covered by the
|
|
rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate
|
|
per <interval><br>
|
|
<interval> is "sec" or
|
|
"min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5
|
|
is assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there
|
|
may be any white space within the burst specification. If you want
|
|
to specify logging of a rate-limited rule, the ":" and log level
|
|
comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the
|
|
/etc/shorewall/rules file. You may specify the rate limit there in
|
|
the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted;
|
|
in fact, since the burst is 4, the first four packets will be
|
|
accepted. After this, it will be 500ms (1 second divided by the
|
|
rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless
|
|
of how many packets reach it. Also, every 500ms which passes
|
|
without matching a packet, one of the bursts will be regained; if
|
|
no packets hit the rule for 2 second, the burst will be fully
|
|
recharged; back where we started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show"
|
|
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
|
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
|
for
|
|
details.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>8/13/2003 - Snapshot 1.4.6_20030813</b><b> </b>
|
|
<b></b></p>
|
|
<blockquote>
|
|
<p><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
|
was being tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
|
tcrules file. Previously, these addresses resulted in an invalid
|
|
iptables command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured
|
|
Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages
|
|
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip
|
|
addresses were being added to a PPP interface; the addresses were
|
|
successfully added in spite of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages</li>
|
|
<li> Interface-specific dynamic blacklisting chains are now
|
|
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
|
(previously named "Dynamic Chain").<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must
|
|
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
|
or 'save' commands.</li>
|
|
<li>To maintain strict compatibility with previous versions,
|
|
current uses of "shorewall drop" and "shorewall reject" should be
|
|
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each
|
|
interface defined in /etc/shorewall/interfaces. The 'drop' and
|
|
'reject' commands use the routing table to determine which of these
|
|
chains is to be used for blacklisting the specified IP
|
|
address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced
|
|
that do what 'drop' and 'reject' used to do; namely, when an
|
|
address is blacklisted using these new commands, it will be
|
|
blacklisted on all of your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter
|
|
will use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for
|
|
traffic accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of
|
|
this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the
|
|
corresponding ACCEPT rule in the filter table is not rate limited.
|
|
If you want to limit the filter table rule, you will need o create
|
|
two rules; a DNAT- rule and an ACCEPT rule which can be
|
|
rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate
|
|
limiting is specified on a rule with "all" in the SOURCE or DEST
|
|
fields, the limit will apply to each pair of zones individually
|
|
rather than as a single limit for all pairs of covered by the
|
|
rule.<br>
|
|
<br>
|
|
To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG
|
|
with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate
|
|
per <interval><br>
|
|
<interval> is "sec" or
|
|
"min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5
|
|
is assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there
|
|
may be any white space within the burst specification. If you want
|
|
to specify logging of a rate-limited rule, the ":" and log level
|
|
comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted;
|
|
in fact, since the burst is 4, the first four packets will be
|
|
accepted. After this, it will be 500ms (1 second divided by the
|
|
rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless
|
|
of how many packets reach it. Also, every 500ms which passes
|
|
without matching a packet, one of the bursts will be regained; if
|
|
no packets hit the rule for 2 second, the burst will be fully
|
|
recharged; back where we started.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>8/9/2003 - Snapshot 1.4.6_20030809</b><b> </b>
|
|
<b></b></p>
|
|
<blockquote>
|
|
<p><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
|
was being tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
|
tcrules file. Previously, these addresses resulted in an invalid
|
|
iptables command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured
|
|
Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages
|
|
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip
|
|
addresses were being added to a PPP interface; the addresses were
|
|
successfully added in spite of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must
|
|
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
|
or 'save' commands.</li>
|
|
<li>To maintain strict compatibility with previous versions,
|
|
current uses of "shorewall drop" and "shorewall reject" should be
|
|
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each
|
|
interface defined in /etc/shorewall/interfaces. The 'drop' and
|
|
'reject' commands use the routing table to determine which of these
|
|
chains is to be used for blacklisting the specified IP
|
|
address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced
|
|
that do what 'drop' and 'reject' used to do; namely, when an
|
|
address is blacklisted using these new commands, it will be
|
|
blacklisted on all of your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add
|
|
specific support for all of it. I have therefore decided to add
|
|
"generic" tunnel support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel
|
|
types. You usually add a zone to represent the systems at the other
|
|
end of the tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the
|
|
form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone>
|
|
<ip address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the
|
|
protocol used by the tunnel<br>
|
|
<port> if the
|
|
protocol is 'udp' or 'tcp' then this is the destination port number
|
|
used by the tunnel.<br>
|
|
<zone> is the zone
|
|
of the remote tunnel gateway<br>
|
|
<ip address> is the IP
|
|
address of the remote tunnel gateway.<br>
|
|
<gateway
|
|
zone> Optional. A comma-separated list of zone
|
|
names. If specified, the remote gateway is to be considered part of
|
|
these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the
|
|
/etc/shorewall/interfaces file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with
|
|
the result that this interface will only answer ARP 'who-has'
|
|
requests from hosts that are routed out through that interface.
|
|
Setting this option facilitates testing of your firewall where
|
|
multiple firewall interfaces are connected to the same HUB/Switch
|
|
(all interfaces connected to the single HUB/Switch should have this
|
|
option specified). Note that using such a configuration in a
|
|
production environment is strongly recommended against.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>8/5/2003 - Shorewall-1.4.6b</b><b> <br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6:</b><br>
|
|
<ol>
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
|
|
Shorewall would fail to start with the error "ERROR: Traffic
|
|
Control requires Mangle"; that problem has been corrected.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
|
tcrules file. Previously, these addresses resulted in an invalid
|
|
iptables command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured
|
|
Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages
|
|
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip
|
|
addresses were being added to a PPP interface; the addresses were
|
|
successfully added in spite of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages.</li>
|
|
</ol>
|
|
<p><b>8/5/2003 - Shorewall-1.4.6b</b> <b><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6:</b><br>
|
|
<ol>
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
|
|
Shorewall would fail to start with the error "ERROR: Traffic
|
|
Control requires Mangle"; that problem has been corrected.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
|
tcrules file. Previously, these addresses resulted in an invalid
|
|
iptables command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured
|
|
Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages
|
|
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip
|
|
addresses were being added to a PPP interface; the addresses were
|
|
successfully added in spite of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>7/31/2003 - Snapshot 1.4.6_20030731</b> <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 <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of
|
|
"No" for existing users which causes Shorewall's 'stopped' state
|
|
to continue as it has been; namely, in the stopped state only
|
|
traffic to/from hosts listed in /etc/shorewall/routestopped is
|
|
accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
|
addition to traffic to/from the hosts listed in
|
|
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself;
|
|
and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall
|
|
stop" entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is
|
|
still possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp
|
|
22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an
|
|
SSH connection with local system 192.168.1.5. I then create a
|
|
second SSH connection from that computer to the firewall and
|
|
confidently type "shorewall stop". As part of its stop processing,
|
|
Shorewall removes eth0:0 which kills my SSH connection to
|
|
192.168.1.5!!!</li>
|
|
</ol>
|
|
<p><b>7/27/2003 - Snapshot 1.4.6_20030727</b> <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 <command>).<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>7/26/2003 - Snapshot 1.4.6_20030726</b></p>
|
|
<blockquote>
|
|
<p><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<p><b>Problems Corrected since version 1.4.6:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
|
was being tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
|
tcrules file. Previously, these addresses resulted in an invalid
|
|
iptables command.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must
|
|
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
|
or 'save' commands.</li>
|
|
<li>To maintain strict compatibility with previous versions,
|
|
current uses of "shorewall drop" and "shorewall reject" should be
|
|
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
Shorewall now creates a dynamic blacklisting chain for each
|
|
interface defined in /etc/shorewall/interfaces. The 'drop' and
|
|
'reject' commands use the routing table to determine which of these
|
|
chains is to be used for blacklisting the specified IP
|
|
address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced
|
|
that do what 'drop' and 'reject' used to do; namely, when an
|
|
address is blacklisted using these new commands, it will be
|
|
blacklisted on all of your firewall's interfaces.
|
|
<p><b>7/22/2003 - Shorewall-1.4.6a</b> <b><br>
|
|
</b></p>
|
|
<b>Problems Corrected:</b><br>
|
|
<ol>
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
|
|
Shorewall would fail to start with the error "ERROR: Traffic
|
|
Control requires Mangle"; that problem has been corrected.</li>
|
|
</ol>
|
|
<p><b>7/20/2003 - Shorewall-1.4.6</b> <b><br>
|
|
</b></p>
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
|
start errors when started using the "service" mechanism has been
|
|
worked around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a
|
|
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in
|
|
the nat table (one for each element in the list). Shorewall now
|
|
correctly creates a single DNAT rule with multiple
|
|
"--to-destination" clauses.<br>
|
|
<br>
|
|
</li>
|
|
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
|
|
were mis-handled when they appeared in the DEST column of a
|
|
rule.<br>
|
|
<br>
|
|
</li>
|
|
<li>A number of problems with rule parsing have been corrected.
|
|
Corrections involve the handling of "z1!z2" in the SOURCE column as
|
|
well as lists in the ORIGINAL DESTINATION column.<br>
|
|
<br>
|
|
</li>
|
|
<li>The message "Adding rules for DHCP" is now suppressed if there
|
|
are no DHCP rules to add.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>In earlier versions, an undocumented feature allowed entries in
|
|
the host file as follows:<br>
|
|
<br>
|
|
z
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
<br>
|
|
This capability was never documented and has been removed in 1.4.6
|
|
to allow entries of the following format:<br>
|
|
<br>
|
|
z eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
|
|
removed from /etc/shorewall/shorewall.conf. These capabilities are
|
|
now automatically detected by Shorewall (see below).<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may
|
|
be specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the
|
|
first one on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin)
|
|
over a set of servers. Servers may be specified in a range of
|
|
addresses given as <first address>-<last address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
|
options have been removed and have been replaced by code that
|
|
detects whether these capabilities are present in the current
|
|
kernel. The output of the start, restart and check commands have
|
|
been enhanced to report the outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been
|
|
added. This extension is available in recent kernel/iptables
|
|
releases and allows for rules which match against elements in
|
|
netfilter's connection tracking table. Shorewall automatically
|
|
detects the availability of this extension and reports its
|
|
availability in the output of the start, restart and check
|
|
commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall
|
|
is changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
<ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
|
chains in the mangle table but will rather do all 'norfc1918'
|
|
filtering in the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter
|
|
rules;
|
|
one in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
ipcalc [ <address>
|
|
<netmask> | <address>/<vlsm> ]<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0/24<br>
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0 255.255.255.0<br>
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
Warning:<br>
|
|
<br>
|
|
If your shell only supports 32-bit signed arithmatic (ash or dash),
|
|
then the ipcalc command produces incorrect information for IP
|
|
addresses 128.0.0.0-1 and for /1 networks. Bash should produce
|
|
correct information for all valid IP addresses.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'iprange' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
iprange
|
|
<address>-<address><br>
|
|
<br>
|
|
This command decomposes a range of IP addressses into a list of
|
|
network and host addresses. The command can be useful if you need
|
|
to construct an efficient set of rules that accept connections from
|
|
a range of network addresses.<br>
|
|
<br>
|
|
Note: If your shell only supports 32-bit signed arithmetic (ash or
|
|
dash) then the range may not span 128.0.0.0.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
[root@gateway root]# shorewall
|
|
iprange 192.168.1.4-192.168.12.9<br>
|
|
192.168.1.4/30<br>
|
|
192.168.1.8/29<br>
|
|
192.168.1.16/28<br>
|
|
192.168.1.32/27<br>
|
|
192.168.1.64/26<br>
|
|
192.168.1.128/25<br>
|
|
192.168.2.0/23<br>
|
|
192.168.4.0/22<br>
|
|
192.168.8.0/22<br>
|
|
192.168.12.0/29<br>
|
|
192.168.12.8/31<br>
|
|
[root@gateway root]#<br>
|
|
<br>
|
|
</li>
|
|
<li>A list of host/net addresses is now allowed in an entry in
|
|
/etc/shorewall/hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
foo
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The "shorewall check" command now includes the chain name when
|
|
printing the applicable policy for each pair of zones.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
Policy for dmz to net is
|
|
REJECT using chain all2all<br>
|
|
<br>
|
|
This means that the policy for connections from the dmz to the
|
|
internet is REJECT and the applicable entry in the
|
|
/etc/shorewall/policy was the all->all policy.<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the 2.6 Kernel series has been added.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>7/15/2003 - New Mirror in Brazil</b><b><br>
|
|
</b></p>
|
|
Thanks to the folks at securityopensource.org.br, there is now a <a
|
|
href="http://shorewall.securityopensource.org.br" target="_top">Shorewall
|
|
mirror in Brazil</a>.
|
|
<p><b>7/15/2003 - Shorewall-1.4.6 RC 1</b> <b></b><b><br>
|
|
</b></p>
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
|
start errors when started using the "service" mechanism has been
|
|
worked around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a
|
|
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in
|
|
the nat table (one for each element in the list). Shorewall now
|
|
correctly creates a single DNAT rule with multiple
|
|
"--to-destination" clauses.<br>
|
|
<br>
|
|
</li>
|
|
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
|
|
were mis-handled when they appeared in the DEST column of a
|
|
rule.<br>
|
|
<br>
|
|
</li>
|
|
<li>A number of problems with rule parsing have been corrected.
|
|
Corrections involve the handling of "z1!z2" in the SOURCE column as
|
|
well as lists in the ORIGINAL DESTINATION column.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>In earlier versions, an undocumented feature allowed entries in
|
|
the host file as follows:<br>
|
|
<br>
|
|
z
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
<br>
|
|
This capability was never documented and has been removed in 1.4.6
|
|
to allow entries of the following format:<br>
|
|
<br>
|
|
z eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
|
|
removed from /etc/shorewall/shorewall.conf. These capabilities are
|
|
now automatically detected by Shorewall (see below).<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may
|
|
be specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the
|
|
first one on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin)
|
|
over a set of servers. Servers may be specified in a range of
|
|
addresses given as <first address>-<last address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
|
options have been removed and have been replaced by code that
|
|
detects whether these capabilities are present in the current
|
|
kernel. The output of the start, restart and check commands have
|
|
been enhanced to report the outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been
|
|
added. This extension is available in recent kernel/iptables
|
|
releases and allows for rules which match against elements in
|
|
netfilter's connection tracking table. Shorewall automatically
|
|
detects the availability of this extension and reports its
|
|
availability in the output of the start, restart and check
|
|
commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall
|
|
is changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
<ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
|
chains in the mangle table but will rather do all 'norfc1918'
|
|
filtering in the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter
|
|
rules;
|
|
one in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
ipcalc [ <address>
|
|
<netmask> | <address>/<vlsm> ]<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0/24<br>
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0 255.255.255.0<br>
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
Warning:<br>
|
|
<br>
|
|
If your shell only supports 32-bit signed arithmatic (ash or dash),
|
|
then the ipcalc command produces incorrect information for IP
|
|
addresses 128.0.0.0-1 and for /1 networks. Bash should produce
|
|
correct information for all valid IP addresses.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'iprange' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
iprange
|
|
<address>-<address><br>
|
|
<br>
|
|
This command decomposes a range of IP addressses into a list of
|
|
network and host addresses. The command can be useful if you need
|
|
to construct an efficient set of rules that accept connections from
|
|
a range of network addresses.<br>
|
|
<br>
|
|
Note: If your shell only supports 32-bit signed arithmetic (ash or
|
|
dash) then the range may not span 128.0.0.0.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
[root@gateway root]# shorewall
|
|
iprange 192.168.1.4-192.168.12.9<br>
|
|
192.168.1.4/30<br>
|
|
192.168.1.8/29<br>
|
|
192.168.1.16/28<br>
|
|
192.168.1.32/27<br>
|
|
192.168.1.64/26<br>
|
|
192.168.1.128/25<br>
|
|
192.168.2.0/23<br>
|
|
192.168.4.0/22<br>
|
|
192.168.8.0/22<br>
|
|
192.168.12.0/29<br>
|
|
192.168.12.8/31<br>
|
|
[root@gateway root]#<br>
|
|
<br>
|
|
</li>
|
|
<li>A list of host/net addresses is now allowed in an entry in
|
|
/etc/shorewall/hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
foo
|
|
eth1:192.168.1.0/24,192.168.2.0/24</li>
|
|
</ol>
|
|
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b></p>
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
|
start errors when started using the "service" mechanism has been
|
|
worked around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a
|
|
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in
|
|
the nat table (one for each element in the list). Shorewall now
|
|
correctly creates a single DNAT rule with multiple
|
|
"--to-destination" clauses.<br>
|
|
<br>
|
|
</li>
|
|
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
|
|
were mis-handled when they appeared in the DEST column of a
|
|
rule.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>In earlier versions, an undocumented feature allowed entries in
|
|
the host file as follows:<br>
|
|
<br>
|
|
z
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
<br>
|
|
This capability was never documented and has been removed in 1.4.6
|
|
to allow entries of the following format:<br>
|
|
<br>
|
|
z eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
|
|
removed from /etc/shorewall/shorewall.conf. These capabilities are
|
|
now automatically detected by Shorewall (see below).<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may
|
|
be specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the
|
|
first one on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin)
|
|
over a set of servers. Servers may be specified in a range of
|
|
addresses given as <first address>-<last address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
|
options have been removed and have been replaced by code that
|
|
detects whether these capabilities are present in the current
|
|
kernel. The output of the start, restart and check commands have
|
|
been enhanced to report the outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been
|
|
added. This extension is available in recent kernel/iptables
|
|
releases and allows for rules which match against elements in
|
|
netfilter's connection tracking table. Shorewall automatically
|
|
detects the availability of this extension and reports its
|
|
availability in the output of the start, restart and check
|
|
commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall
|
|
is changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
<ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
|
chains in the mangle table but will rather do all 'norfc1918'
|
|
filtering in the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter
|
|
rules;
|
|
one in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
ipcalc [ <address>
|
|
<netmask> | <address>/<vlsm> ]<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0/24<br>
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0 255.255.255.0<br>
|
|
|
|
CIDR=192.168.1.0/24<br>
|
|
|
|
NETMASK=255.255.255.0<br>
|
|
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
Warning:<br>
|
|
<br>
|
|
If your shell only supports 32-bit signed arithmatic (ash or dash),
|
|
then the ipcalc command produces incorrect information for IP
|
|
addresses 128.0.0.0-1 and for /1 networks. Bash should produce
|
|
correct information for all valid IP addresses.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'iprange' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
iprange
|
|
<address>-<address><br>
|
|
<br>
|
|
This command decomposes a range of IP addressses into a list of
|
|
network and host addresses. The command can be useful if you need
|
|
to construct an efficient set of rules that accept connections from
|
|
a range of network addresses.<br>
|
|
<br>
|
|
Note: If your shell only supports 32-bit signed arithmetic (ash or
|
|
dash) then the range may not span 128.0.0.0.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
[root@gateway root]# shorewall
|
|
iprange 192.168.1.4-192.168.12.9<br>
|
|
192.168.1.4/30<br>
|
|
192.168.1.8/29<br>
|
|
192.168.1.16/28<br>
|
|
192.168.1.32/27<br>
|
|
192.168.1.64/26<br>
|
|
192.168.1.128/25<br>
|
|
192.168.2.0/23<br>
|
|
192.168.4.0/22<br>
|
|
192.168.8.0/22<br>
|
|
192.168.12.0/29<br>
|
|
192.168.12.8/31<br>
|
|
[root@gateway root]#<br>
|
|
<br>
|
|
</li>
|
|
<li>A list of host/net addresses is now allowed in an entry in
|
|
/etc/shorewall/hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
foo
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b></p>
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
|
start errors when started using the "service" mechanism has been
|
|
worked around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a
|
|
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in
|
|
the nat table (one for each element in the list). Shorewall now
|
|
correctly creates a single DNAT rule with multiple
|
|
"--to-destination" clauses.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may
|
|
be specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in
|
|
/etc/shorewall/masq to use for SNAT is now documented.
|
|
ADD_SNAT_ALIASES=Yes is enabled for address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the
|
|
first one on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin)
|
|
over a set of servers. Up to 256 servers may be specified in a
|
|
range of addresses given as <first address>-<last
|
|
address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
Note that this capability has previously been available using a
|
|
combination of a DNAT- rule and one or more ACCEPT rules. That
|
|
technique is still preferable for load-balancing over a large
|
|
number of servers (> 16) since specifying a range in the DNAT
|
|
rule causes one filter table ACCEPT rule to be generated for each
|
|
IP address in the range.<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
|
options have been removed and have been replaced by code that
|
|
detects whether these capabilities are present in the current
|
|
kernel. The output of the start, restart and check commands have
|
|
been enhanced to report the outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been
|
|
added. This extension is available in recent kernel/iptables
|
|
releases and allows for rules which match against elements in
|
|
netfilter's connection tracking table. Shorewall automatically
|
|
detects the availability of this extension and reports its
|
|
availability in the output of the start, restart and check
|
|
commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter
|
|
capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall
|
|
is changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
<ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
|
chains in the mangle table but will rather do all 'norfc1918'
|
|
filtering in the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter
|
|
rules;
|
|
one in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>6/17/2003 - Shorewall-1.4.5</b></p>
|
|
<p>Problems Corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The command "shorewall debug try <directory>" now
|
|
correctly traces the attempt.</li>
|
|
<li>The INCLUDE directive now works properly in the zones file;
|
|
previously, INCLUDE in that file was ignored.</li>
|
|
<li>/etc/shorewall/routestopped records with an empty second column
|
|
are no longer ignored.<br>
|
|
</li>
|
|
</ol>
|
|
<p>New Features:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may
|
|
now contain a list of addresses. If the list begins with "!' then
|
|
the rule will take effect only if the original destination address
|
|
in the connection request does not match any of the addresses
|
|
listed.</li>
|
|
</ol>
|
|
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables
|
|
1.2.8</b></p>
|
|
<p>The firewall at shorewall.net has been upgraded to the 2.4.21
|
|
kernel and iptables 1.2.8 (using the "official" RPM from
|
|
netfilter.org). No problems have been encountered with this set of
|
|
software. The Shorewall version is 1.4.4b plus the accumulated
|
|
changes for 1.4.5.<br>
|
|
</p>
|
|
<p><b>6/8/2003 - Updated Samples</b></p>
|
|
<p>Thanks to Francesca Smith, the samples have been updated to
|
|
Shorewall version 1.4.4.</p>
|
|
<p><b>5/29/2003 - Shorewall-1.4.4b</b></p>
|
|
<p>Groan -- This version corrects a problem whereby the --log-level
|
|
was not being set when logging via syslog. The most commonly
|
|
reported symptom was that Shorewall messages were being written to
|
|
the console even though console logging was correctly configured
|
|
per FAQ 16.<br>
|
|
</p>
|
|
<p><b>5/27/2003 - Shorewall-1.4.4a</b></p>
|
|
The Fireparse --log-prefix fiasco continues. Tuomo Soini has
|
|
pointed out that the code in 1.4.4 restricts the length of short
|
|
zone names to 4 characters. I've produced version 1.4.4a that
|
|
restores the previous 5-character limit by conditionally omitting
|
|
the log rule number when the LOGFORMAT doesn't contain '%d'. <br>
|
|
<p><b>5/23/2003 - Shorewall-1.4.4</b></p>
|
|
I apologize for the rapid-fire releases but since there is a
|
|
potential configuration change required to go from 1.4.3a to 1.4.4,
|
|
I decided to make it a full release rather than just a bug-fix
|
|
release. <br>
|
|
<br>
|
|
<b> Problems corrected:</b><br>
|
|
<blockquote>None.<br>
|
|
</blockquote>
|
|
<b> New Features:<br>
|
|
</b>
|
|
<ol>
|
|
<li>A REDIRECT- rule target has been added. This target behaves for
|
|
REDIRECT in the same way as DNAT- does for DNAT in that the
|
|
Netfilter nat table REDIRECT rule is added but not the companion
|
|
filter table ACCEPT rule.<br>
|
|
<br>
|
|
</li>
|
|
<li>The LOGMARKER variable has been renamed LOGFORMAT and has been
|
|
changed to a 'printf' formatting template which accepts three
|
|
arguments (the chain name, logging rule number and the
|
|
disposition). To use LOGFORMAT with fireparse (<a
|
|
href="http://www.fireparse.com">http://www.fireparse.com</a>), set it
|
|
as:<br>
|
|
<br>
|
|
LOGFORMAT="fp=%s:%d a=%s "<br>
|
|
<br>
|
|
<b>CAUTION:</b> /sbin/shorewall uses the leading part of the
|
|
LOGFORMAT string (up to but not including the first '%') to find
|
|
log messages in the 'show log', 'status' and 'hits' commands. This
|
|
part should not be omitted (the LOGFORMAT should not begin with
|
|
"%") and the leading part should be sufficiently unique for
|
|
/sbin/shorewall to identify Shorewall messages.<br>
|
|
<br>
|
|
</li>
|
|
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule, the
|
|
logging now takes place in the nat table rather than in the filter
|
|
table. This way, only those connections that actually undergo DNAT
|
|
or redirection will be logged.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>5/20/2003 - Shorewall-1.4.3a</b> <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>
|
|
a) tcp - RST<br>
|
|
b) udp - ICMP port unreachable<br>
|
|
c) icmp - ICMP host unreachable<br>
|
|
d) Otherwise - ICMP host prohibited<br>
|
|
If you are running earlier software, Shorewall will follow it's
|
|
traditional convention:<br>
|
|
a) tcp - RST<br>
|
|
b) Otherwise - ICMP port unreachable</li>
|
|
<li>UDP port 135 is now silently dropped in the common.def chain.
|
|
Remember that this chain is traversed just before a DROP or REJECT
|
|
policy is enforced.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>5/18/2003 - Shorewall 1.4.3</b> <b></b><br>
|
|
</p>
|
|
<b>Problems Corrected:<br>
|
|
</b>
|
|
<ol>
|
|
<li>There were several cases where Shorewall would fail to remove a
|
|
temporary directory from /tmp. These cases have been
|
|
corrected.</li>
|
|
<li>The rules for allowing all traffic via the loopback interface
|
|
have been moved to before the rule that drops status=INVALID
|
|
packets. This insures that all loopback traffic is allowed even if
|
|
Netfilter connection tracking is confused.</li>
|
|
</ol>
|
|
<b>New Features:<br>
|
|
</b>
|
|
<ol>
|
|
<li> IPV6-IPV4 (6to4) tunnels are now supported in the
|
|
/etc/shorewall/tunnels file.</li>
|
|
<li value="2">You may now change the leading portion of the
|
|
--log-prefix used by Shorewall using the LOGMARKER variable in
|
|
shorewall.conf. By default, "Shorewall:" is used.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>5/10/2003 - Shorewall Mirror in Asia<br>
|
|
</b></p>
|
|
<p>Ed Greshko has established a mirror in Taiwan -- Thanks Ed!<br>
|
|
</p>
|
|
<p><b>5/8/2003 - Shorewall Mirror in Chile</b></p>
|
|
Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago
|
|
Chile.
|
|
<p><b>4/21/2003 - Samples updated for Shorewall version
|
|
1.4.2</b></p>
|
|
<p>Thanks to Francesca Smith, the sample configurations are now
|
|
upgraded to Shorewall version 1.4.2.</p>
|
|
<p><b>4/9/2003 - Shorewall 1.4.2</b><br>
|
|
</p>
|
|
<p><b> Problems Corrected:</b></p>
|
|
<blockquote>
|
|
<ol>
|
|
<li>TCP connection requests rejected out of the <b>common</b>
|
|
chain
|
|
are now properly rejected with TCP RST; previously, some of these
|
|
requests were rejected with an ICMP port-unreachable response.</li>
|
|
<li>'traceroute -I' from behind the firewall previously timed out
|
|
on the first hop (e.g., to the firewall). This has been worked
|
|
around.</li>
|
|
</ol>
|
|
</blockquote>
|
|
<p><b> New Features:</b></p>
|
|
<ol>
|
|
<li>Where an entry in the/etc/shorewall/hosts file specifies a
|
|
particular host or network, Shorewall now creates an intermediate
|
|
chain for handling input from the related zone. This can
|
|
substantially reduce the number of rules traversed by connections
|
|
requests from such zones.<br>
|
|
<br>
|
|
</li>
|
|
<li>Any file may include an INCLUDE directive. An INCLUDE directive
|
|
consists of the word INCLUDE followed by a file name and causes the
|
|
contents of the named file to be logically included into the file
|
|
containing the INCLUDE. File names given in an INCLUDE directive
|
|
are assumed to reside in /etc/shorewall or in an alternate
|
|
configuration directory if one has been specified for the
|
|
command.<br>
|
|
<br>
|
|
Examples:<br>
|
|
shorewall/params.mgmt:<br>
|
|
MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3<br>
|
|
TIME_SERVERS=4.4.4.4<br>
|
|
BACKUP_SERVERS=5.5.5.5<br>
|
|
----- end params.mgmt -----<br>
|
|
<br>
|
|
<br>
|
|
shorewall/params:<br>
|
|
# Shorewall 1.3 /etc/shorewall/params<br>
|
|
[..]<br>
|
|
#######################################<br>
|
|
<br>
|
|
INCLUDE params.mgmt <br>
|
|
<br>
|
|
# params unique to this host here<br>
|
|
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT
|
|
REMOVE<br>
|
|
----- end params -----<br>
|
|
<br>
|
|
<br>
|
|
shorewall/rules.mgmt:<br>
|
|
ACCEPT
|
|
net:$MGMT_SERVERS
|
|
$FW tcp 22<br>
|
|
ACCEPT
|
|
$FW
|
|
net:$TIME_SERVERS udp 123<br>
|
|
ACCEPT
|
|
$FW
|
|
net:$BACKUP_SERVERS tcp 22<br>
|
|
----- end rules.mgmt -----<br>
|
|
<br>
|
|
shorewall/rules:<br>
|
|
# Shorewall version 1.3 - Rules File<br>
|
|
[..]<br>
|
|
#######################################<br>
|
|
<br>
|
|
INCLUDE rules.mgmt <br>
|
|
<br>
|
|
# rules unique to this host here<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO
|
|
NOT REMOVE<br>
|
|
----- end rules -----<br>
|
|
<br>
|
|
INCLUDE's may be nested to a level of 3 -- further nested INCLUDE
|
|
directives are ignored with a warning message.<br>
|
|
<br>
|
|
</li>
|
|
<li>Routing traffic from an interface back out that interface
|
|
continues to be a problem. While I firmly believe that this should
|
|
never happen, people continue to want to do it. To limit the damage
|
|
that such nonsense produces, I have added a new 'routeback' option
|
|
in /etc/shorewall/interfaces and /etc/shorewall/hosts. When used in
|
|
/etc/shorewall/interfaces, the 'ZONE' column may not contain '-';
|
|
in other words, 'routeback' can't be used as an option for a
|
|
multi-zone interface. The 'routeback' option CAN be specified
|
|
however on individual group entries in /etc/shorewall/hosts.<br>
|
|
<br>
|
|
The 'routeback' option is similar to the old 'multi' option with
|
|
two exceptions:<br>
|
|
<br>
|
|
a) The option pertains to a particular
|
|
zone,interface,address tuple.<br>
|
|
<br>
|
|
b) The option only created infrastructure to pass
|
|
traffic from (zone,interface,address) tuples back to themselves
|
|
(the 'multi' option affected all (zone,interface,address) tuples
|
|
associated with the given 'interface').<br>
|
|
<br>
|
|
See the '<a href="upgrade_issues.htm">Upgrade Issues</a>' for
|
|
information about how this new option may affect your
|
|
configuration.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>3/24/2003 - Shorewall 1.4.1</b> <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 <device>:<integer> in
|
|
/etc/shorewall/interfaces now generate an error.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall 1.4 implements behavior consistent with
|
|
OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error
|
|
at startup as will specification of the 'noping' or 'filterping'
|
|
interface options.<br>
|
|
<br>
|
|
</li>
|
|
<li>The 'routestopped' option in the /etc/shorewall/interfaces and
|
|
/etc/shorewall/hosts files is no longer supported and will generate
|
|
an error at startup if specified.<br>
|
|
<br>
|
|
</li>
|
|
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
|
|
longer accepted.<br>
|
|
<br>
|
|
</li>
|
|
<li>The ALLOWRELATED variable in shorewall.conf is no longer
|
|
supported. Shorewall 1.4 behavior is the same as 1.3 with
|
|
ALLOWRELATED=Yes.<br>
|
|
<br>
|
|
</li>
|
|
<li>The icmp.def file has been removed.<br>
|
|
</li>
|
|
</ol>
|
|
Changes for 1.4 include:<br>
|
|
<ol>
|
|
<li>The /etc/shorewall/shorewall.conf file has been completely
|
|
reorganized into logical sections.<br>
|
|
<br>
|
|
</li>
|
|
<li>LOG is now a valid action for a rule
|
|
(/etc/shorewall/rules).<br>
|
|
<br>
|
|
</li>
|
|
<li>The firewall script and version file are now installed in
|
|
/usr/share/shorewall.<br>
|
|
<br>
|
|
</li>
|
|
<li>Late arriving DNS replies are now silently dropped in the
|
|
common chain by default.<br>
|
|
<br>
|
|
</li>
|
|
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
|
|
1.4 no longer unconditionally accepts outbound ICMP packets. So if
|
|
you want to 'ping' from the firewall, you will need the appropriate
|
|
rule or policy.<br>
|
|
<br>
|
|
</li>
|
|
<li>CONTINUE is now a valid action for a rule
|
|
(/etc/shorewall/rules).<br>
|
|
<br>
|
|
</li>
|
|
<li>802.11b devices with names of the form wlan<n> now
|
|
support the 'maclist' option.<br>
|
|
<br>
|
|
</li>
|
|
<li>Explicit Congestion Notification (ECN - RFC 3168) may now be
|
|
turned off on a host or network basis using the new
|
|
/etc/shorewall/ecn file. To use this facility:<br>
|
|
<br>
|
|
a) You must be running kernel 2.4.20<br>
|
|
b) You must have applied the patch in<br>
|
|
http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
|
|
c) You must have iptables 1.2.7a installed.<br>
|
|
<br>
|
|
</li>
|
|
<li>The /etc/shorewall/params file is now processed first so that
|
|
variables may be used in the /etc/shorewall/shorewall.conf
|
|
file.<br>
|
|
<br>
|
|
</li>
|
|
<li value="10">Shorewall now gives a more helpful diagnostic when
|
|
the 'ipchains' compatibility kernel module is loaded and a
|
|
'shorewall start' command is issued.<br>
|
|
<br>
|
|
</li>
|
|
<li>The SHARED_DIR variable has been removed from shorewall.conf.
|
|
This variable was for use by package maintainers and was not
|
|
documented for general use.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now ignores 'default' routes when detecting masq'd
|
|
networks.</li>
|
|
</ol>
|
|
<p><b>3/10/2003 - Shoreall 1.3.14a</b></p>
|
|
<p>A roleup of the following bug fixes and other updates:</p>
|
|
<ul>
|
|
<li>There is an updated rfc1918 file that reflects the resent
|
|
allocation of 222.0.0.0/8 and 223.0.0.0/8.</li>
|
|
</ul>
|
|
<ul>
|
|
<li>The documentation for the routestopped file claimed that a
|
|
comma-separated list could appear in the second column while the
|
|
code only supported a single host or network address.</li>
|
|
<li>Log messages produced by 'logunclean' and 'dropunclean' were
|
|
not rate-limited.</li>
|
|
<li>802.11b devices with names of the form <i>wlan</i><n>
|
|
don't support the 'maclist' interface option.</li>
|
|
<li>Log messages generated by RFC 1918 filtering are not rate
|
|
limited.</li>
|
|
<li>The firewall fails to start in the case where you have "eth0
|
|
eth1" in /etc/shorewall/masq and the default route is through
|
|
eth1</li>
|
|
</ul>
|
|
<p><b>2/8/2003 - Shoreawall 1.3.14</b></p>
|
|
<p>New features include</p>
|
|
<ol>
|
|
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
|
|
When set to Yes, Shorewall ping handling is as it has always been
|
|
(see http://www.shorewall.net/ping.html).<br>
|
|
<br>
|
|
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules
|
|
and policies just like any other connection request. The
|
|
FORWARDPING=Yes option in shorewall.conf and the 'noping' and
|
|
'filterping' options in /etc/shorewall/interfaces will all generate
|
|
an error.<br>
|
|
<br>
|
|
</li>
|
|
<li>It is now possible to direct Shorewall to create a "label" such
|
|
as "eth0:0" for IP addresses that it creates under
|
|
ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by
|
|
specifying the label instead of just the interface name:<br>
|
|
<br>
|
|
a) In the INTERFACE column of /etc/shorewall/masq<br>
|
|
b) In the INTERFACE column of /etc/shorewall/nat<br>
|
|
</li>
|
|
<li>Support for OpenVPN Tunnels.<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for VLAN devices with names of the form $DEV.$VID
|
|
(e.g., eth0.0)<br>
|
|
<br>
|
|
</li>
|
|
<li>In /etc/shorewall/tcrules, the MARK value may be optionally
|
|
followed by ":" and either 'F' or 'P' to designate that the marking
|
|
will occur in the FORWARD or PREROUTING chains respectively. If
|
|
this additional specification is omitted, the chain used to mark
|
|
packets will be determined by the setting of the
|
|
MARK_IN_FORWARD_CHAIN option in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
|
|
<br>
|
|
</li>
|
|
<li>When an interface name is entered in the SUBNET column of the
|
|
/etc/shorewall/masq file, Shorewall previously masqueraded traffic
|
|
from only the first subnet defined on that interface. It did not
|
|
masquerade traffic from:<br>
|
|
<br>
|
|
a) The subnets associated with other addresses on the
|
|
interface.<br>
|
|
b) Subnets accessed through local routers.<br>
|
|
<br>
|
|
Beginning with Shorewall 1.3.14, if you enter an interface name in
|
|
the SUBNET column, shorewall will use the firewall's routing table
|
|
to construct the masquerading/SNAT rules.<br>
|
|
<br>
|
|
Example 1 -- This is how it works in 1.3.14.<br>
|
|
<br>
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
</pre>
|
|
<pre> [root@gateway test]# shorewall start<br>
|
|
...<br>
|
|
Masqueraded Subnets and Hosts:<br>
|
|
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
|
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
|
Processing /etc/shorewall/tos...
|
|
</pre>
|
|
<br>
|
|
When upgrading to Shorewall 1.3.14, if you have multiple local
|
|
subnets connected to an interface that is specified in the SUBNET
|
|
column of an /etc/shorewall/masq entry, your /etc/shorewall/masq
|
|
file will need changing. In most cases, you will simply be able to
|
|
remove redundant entries. In some cases though, you might want to
|
|
change from using the interface name to listing specific
|
|
subnetworks if the change described above will cause masquerading
|
|
to occur on subnetworks that you don't wish to masquerade.<br>
|
|
<br>
|
|
Example 2 -- Suppose that your current config is as follows:<br>
|
|
<br>
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
eth0 192.168.10.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#
|
|
</pre>
|
|
<br>
|
|
In this case, the second entry in /etc/shorewall/masq
|
|
is no longer required.<br>
|
|
<br>
|
|
Example 3 -- What if your current configuration is like this?<br>
|
|
<br>
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#
|
|
</pre>
|
|
<br>
|
|
In this case, you would want to change the entry
|
|
in /etc/shorewall/masq to:<br>
|
|
<pre> #INTERFACE SUBNET ADDRESS<br>
|
|
eth0 192.168.1.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
</li>
|
|
</ol>
|
|
<p><br>
|
|
<b>2/5/2003 - Shorewall Support included in Webmin 1.060</b></p>
|
|
<p>Webmin version 1.060 now has Shorewall support included as
|
|
standard. See <a href="http://www.webmin.com">http://www.webmin.com</a>.<br>
|
|
<b><br>
|
|
2/4/2003 - Shorewall 1.3.14-RC1</b></p>
|
|
<p>Includes the Beta 2 content plus support for OpenVPN
|
|
tunnels.</p>
|
|
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2</b></p>
|
|
<p>Includes the Beta 1 content plus restores VLAN device names of
|
|
the form $dev.$vid (e.g., eth0.1)</p>
|
|
<p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b><br>
|
|
</p>
|
|
<p>The Beta includes the following changes:<br>
|
|
</p>
|
|
<ol>
|
|
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
|
|
When set to Yes, Shorewall ping handling is as it has always been
|
|
(see http://www.shorewall.net/ping.html).<br>
|
|
<br>
|
|
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules
|
|
and policies just like any other connection request. The
|
|
FORWARDPING=Yes option in shorewall.conf and the 'noping' and
|
|
'filterping' options in /etc/shorewall/interfaces will all generate
|
|
an error.<br>
|
|
<br>
|
|
</li>
|
|
<li>It is now possible to direct Shorewall to create a "label" such
|
|
as "eth0:0" for IP addresses that it creates under
|
|
ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by
|
|
specifying the label instead of just the interface name:<br>
|
|
<br>
|
|
a) In the INTERFACE column of /etc/shorewall/masq<br>
|
|
b) In the INTERFACE column of /etc/shorewall/nat<br>
|
|
</li>
|
|
<li>When an interface name is entered in the SUBNET column of the
|
|
/etc/shorewall/masq file, Shorewall previously masqueraded traffic
|
|
from only the first subnet defined on that interface. It did not
|
|
masquerade traffic from:<br>
|
|
<br>
|
|
a) The subnets associated with other addresses on the
|
|
interface.<br>
|
|
b) Subnets accessed through local routers.<br>
|
|
<br>
|
|
Beginning with Shorewall 1.3.14, if you enter an interface name in
|
|
the SUBNET column, shorewall will use the firewall's routing table
|
|
to construct the masquerading/SNAT rules.<br>
|
|
<br>
|
|
Example 1 -- This is how it works in 1.3.14.<br>
|
|
<br>
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
</pre>
|
|
<pre> [root@gateway test]# shorewall start<br>
|
|
...<br>
|
|
Masqueraded Subnets and Hosts:<br>
|
|
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
|
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
|
Processing /etc/shorewall/tos...
|
|
</pre>
|
|
<br>
|
|
When upgrading to Shorewall 1.3.14, if you have multiple local
|
|
subnets connected to an interface that is specified in the SUBNET
|
|
column of an /etc/shorewall/masq entry, your /etc/shorewall/masq
|
|
file will need changing. In most cases, you will simply be able to
|
|
remove redundant entries. In some cases though, you might want to
|
|
change from using the interface name to listing specific
|
|
subnetworks if the change described above will cause masquerading
|
|
to occur on subnetworks that you don't wish to masquerade.<br>
|
|
<br>
|
|
Example 2 -- Suppose that your current config is as follows:<br>
|
|
<br>
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
eth0 192.168.10.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#
|
|
</pre>
|
|
<br>
|
|
In this case, the second entry in /etc/shorewall/masq
|
|
is no longer required.<br>
|
|
<br>
|
|
Example 3 -- What if your current configuration is like this?<br>
|
|
<br>
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#
|
|
</pre>
|
|
<br>
|
|
In this case, you would want to change the entry
|
|
in /etc/shorewall/masq to:<br>
|
|
<pre> #INTERFACE SUBNET ADDRESS<br>
|
|
eth0 192.168.1.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
|
</pre>
|
|
<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>
|
|
<a
|
|
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
|
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
<a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a>
|
|
<p><b>1/17/2003 - shorewall.net has MOVED</b><b> </b></p>
|
|
<p>Thanks to the generosity of Alex Martin and <a
|
|
href="http://www.rettc.com">Rett Consulting</a>, www.shorewall.net and
|
|
ftp.shorewall.net are now hosted on a system in Bellevue,
|
|
Washington. A big thanks to Alex for making this happen.<br>
|
|
</p>
|
|
<p><b>1/13/2003 - Shorewall 1.3.13<br>
|
|
</b></p>
|
|
<p>Just includes a few things that I had on the burner:<br>
|
|
</p>
|
|
<ol>
|
|
<li>A new 'DNAT-' action has been added for entries in the
|
|
/etc/shorewall/rules file. DNAT- is intended for advanced users who
|
|
wish to minimize the number of rules that connection requests must
|
|
traverse.<br>
|
|
<br>
|
|
A Shorewall DNAT rule actually generates two iptables rules: a
|
|
header rewriting rule in the 'nat' table and an ACCEPT rule in the
|
|
'filter' table. A DNAT- rule only generates the first of these
|
|
rules. This is handy when you have several DNAT rules that would
|
|
generate the same ACCEPT rule.<br>
|
|
<br>
|
|
Here are three rules from my previous rules file:<br>
|
|
<br>
|
|
DNAT
|
|
net dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
|
|
DNAT
|
|
net dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
|
|
ACCEPT net
|
|
dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
|
|
<br>
|
|
These three rules ended up generating _three_ copies
|
|
of<br>
|
|
<br>
|
|
ACCEPT net
|
|
dmz:206.124.146.177 tcp smtp<br>
|
|
<br>
|
|
By writing the rules this way, I end up with only one
|
|
copy of the ACCEPT rule.<br>
|
|
<br>
|
|
DNAT- net
|
|
dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
|
|
DNAT- net
|
|
dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
|
|
ACCEPT net
|
|
dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
|
|
<br>
|
|
</li>
|
|
<li>The 'shorewall check' command now prints out the applicable
|
|
policy between each pair of zones.<br>
|
|
<br>
|
|
</li>
|
|
<li>A new CLEAR_TC option has been added to shorewall.conf. If this
|
|
option is set to 'No' then Shorewall won't clear the current
|
|
traffic control rules during [re]start. This setting is intended
|
|
for use by people that prefer to configure traffic shaping when the
|
|
network interfaces come up rather than when the firewall is
|
|
started. If that is what you want to do, set TC_ENABLED=Yes and
|
|
CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
|
|
way, your traffic shaping rules can still use the 'fwmark'
|
|
classifier based on packet marking defined in
|
|
/etc/shorewall/tcrules.<br>
|
|
<br>
|
|
</li>
|
|
<li>A new SHARED_DIR variable has been added that allows
|
|
distribution packagers to easily move the shared directory (default
|
|
/usr/lib/shorewall). Users should never have a need to change the
|
|
value of this shorewall.conf setting.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>1/6/2003 - <big><big><big>BURNOUT</big></big></big></b>
|
|
<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> <a
|
|
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
|
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
<a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
|
|
</p>
|
|
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>
|
|
<p>Features include:<br>
|
|
</p>
|
|
<ol>
|
|
<li>"shorewall refresh" now reloads the traffic shaping rules
|
|
(tcrules and tcstart).</li>
|
|
<li>"shorewall debug [re]start" now turns off debugging after an
|
|
error occurs. This places the point of the failure near the end of
|
|
the trace rather than up in the middle of it.</li>
|
|
<li>"shorewall [re]start" has been speeded up by more than 40% with
|
|
my configuration. Your milage may vary.</li>
|
|
<li>A "shorewall show classifiers" command has been added which
|
|
shows the current packet classification filters. The output from
|
|
this command is also added as a separate page in "shorewall
|
|
monitor"</li>
|
|
<li>ULOG (must be all caps) is now accepted as a valid syslog level
|
|
and causes the subject packets to be logged using the ULOG target
|
|
rather than the LOG target. This allows you to run ulogd (available
|
|
from <a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
|
|
and log all Shorewall messages <a href="shorewall_logging.html">to
|
|
a separate log file</a>.</li>
|
|
<li>If you are running a kernel that has a FORWARD chain in the
|
|
mangle table ("shorewall show mangle" will show you the chains in
|
|
the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
|
|
marking input packets based on their destination even when you are
|
|
using Masquerading or SNAT.</li>
|
|
<li>I have cluttered up the /etc/shorewall directory with empty
|
|
'init', 'start', 'stop' and 'stopped' files. If you already have a
|
|
file with one of these names, don't worry -- the upgrade process
|
|
won't overwrite your file.</li>
|
|
<li>I have added a new RFC1918_LOG_LEVEL variable to <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a>. This variable
|
|
specifies the syslog level at which packets are logged as a result
|
|
of entries in the /etc/shorewall/rfc1918 file. Previously, these
|
|
packets were always logged at the 'info' level.<br>
|
|
</li>
|
|
</ol>
|
|
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3<br>
|
|
</b></p>
|
|
This version corrects a problem with Blacklist logging. In Beta 2,
|
|
if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall
|
|
would fail to start and "shorewall refresh" would also fail.<br>
|
|
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b></p>
|
|
<p>The first public Beta version of Shorewall 1.3.12 is now
|
|
available (Beta 1 was made available only to a limited
|
|
audience).<br>
|
|
</p>
|
|
Features include:<br>
|
|
<ol>
|
|
<li>"shorewall refresh" now reloads the traffic shaping rules
|
|
(tcrules and tcstart).</li>
|
|
<li>"shorewall debug [re]start" now turns off debugging after an
|
|
error occurs. This places the point of the failure near the end of
|
|
the trace rather than up in the middle of it.</li>
|
|
<li>"shorewall [re]start" has been speeded up by more than 40% with
|
|
my configuration. Your milage may vary.</li>
|
|
<li>A "shorewall show classifiers" command has been added which
|
|
shows the current packet classification filters. The output from
|
|
this command is also added as a separate page in "shorewall
|
|
monitor"</li>
|
|
<li>ULOG (must be all caps) is now accepted as a valid syslog level
|
|
and causes the subject packets to be logged using the ULOG target
|
|
rather than the LOG target. This allows you to run ulogd (available
|
|
from <a href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
|
|
and log all Shorewall messages <a href="shorewall_logging.html">to
|
|
a separate log file</a>.</li>
|
|
<li>If you are running a kernel that has a FORWARD chain in the
|
|
mangle table ("shorewall show mangle" will show you the chains in
|
|
the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in
|
|
shorewall.conf. This allows for marking input packets based on
|
|
their destination even when you are using Masquerading or
|
|
SNAT.</li>
|
|
<li>I have cluttered up the /etc/shorewall directory with empty
|
|
'init', 'start', 'stop' and 'stopped' files. If you already have a
|
|
file with one of these names, don't worry -- the upgrade process
|
|
won't overwrite your file.</li>
|
|
</ol>
|
|
You may download the Beta from:<br>
|
|
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
|
|
</blockquote>
|
|
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
|
|
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
|
|
alt="Powered by Mandrake Linux" 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&id_art=250&LANG_=en#GOTO_250">
|
|
Multi Network Firewall (MNF)</a> product. Here is the <a
|
|
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
|
|
release</a>.<br>
|
|
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b></p>
|
|
<p>Two months and 3 days after I ordered Mandrake 9.0, it was
|
|
finally delivered. I have installed 9.0 on one of my systems and I
|
|
am now in a position to support Shorewall users who run Mandrake
|
|
9.0.</p>
|
|
<p><b>12/6/2002 - Debian 1.3.11a Packages Available<br>
|
|
</b></p>
|
|
<p>Apt-get sources listed at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
<p><b>12/3/2002 - Shorewall 1.3.11a</b></p>
|
|
<p>This is a bug-fix roll up which includes Roger Aich's fix for
|
|
DNAT with excluded subnets (e.g., "DNAT foo!bar ..."). Current
|
|
1.3.11 users who don't need rules of this type need not upgrade to
|
|
1.3.11.</p>
|
|
<p><b>11/24/2002 - Shorewall 1.3.11</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A 'tcpflags' option has been added to entries in <a
|
|
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
|
|
This
|
|
option causes Shorewall to make a set of sanity check on TCP packet
|
|
header flags.</li>
|
|
<li>It is now allowed to use 'all' in the SOURCE or DEST column in
|
|
a <a href="Documentation.htm#Rules">rule</a>. When used, 'all' must
|
|
appear by itself (in may not be qualified) and it does not enable
|
|
intra-zone traffic. For example, the rule<br>
|
|
<br>
|
|
ACCEPT loc all tcp 80<br>
|
|
<br>
|
|
does not enable http traffic from 'loc' to 'loc'.</li>
|
|
<li>Shorewall's use of the 'echo' command is now compatible with
|
|
bash clones such as ash and dash.</li>
|
|
<li>fw->fw policies now generate a startup error. fw->fw
|
|
rules generate a warning and are ignored</li>
|
|
</ul>
|
|
<p><b>11/14/2002 - Shorewall Documentation in PDF Format</b></p>
|
|
<p>Juraj Ontkanin has produced a PDF containing the Shorewall
|
|
1.3.10 documenation. the PDF may be downloaded from</p>
|
|
<p> <a
|
|
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
|
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
<a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
|
|
</p>
|
|
<p><b>11/09/2002 - Shorewall is Back at SourceForge</b> <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 - 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 - Debian 1.3.8 Packages Available<br>
|
|
</b></p>
|
|
<p>Apt-get sources listed at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
<p><b>9/16/2002 - Shorewall 1.3.8</b></p>
|
|
<p>In this version:<br>
|
|
</p>
|
|
<ul>
|
|
<li>A <a href="Documentation.htm#Conf">NEWNOTSYN</a> option has
|
|
been added to shorewall.conf. This option determines whether
|
|
Shorewall accepts TCP packets which are not part of an established
|
|
connection and that are not 'SYN' packets (SYN flag on and ACK flag
|
|
off).</li>
|
|
<li>The need for the 'multi' option to communicate between zones za
|
|
and zb on the same interface is removed in the case where the chain
|
|
'za2zb' and/or 'zb2za' exists. 'za2zb' will exist if:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
|
<ul>
|
|
<li>There is a policy for za to zb; or</li>
|
|
<li>There is at least one rule for za to zb.</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>The /etc/shorewall/blacklist file now contains three columns.
|
|
In addition to the SUBNET/ADDRESS column, there are optional
|
|
PROTOCOL and PORT columns to block only certain applications from
|
|
the blacklisted addresses.<br>
|
|
</li>
|
|
</ul>
|
|
<p><b>9/11/2002 - Debian 1.3.7c Packages Available</b></p>
|
|
<p>Apt-get sources listed at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
<p><b>9/2/2002 - Shorewall 1.3.7c</b></p>
|
|
<p>This is a role up of a fix for "DNAT" rules where the source
|
|
zone is $FW (fw).</p>
|
|
<p><b>8/31/2002 - I'm not available</b></p>
|
|
<p>I'm currently on vacation -- please respect my need for a
|
|
couple of weeks free of Shorewall problem reports.</p>
|
|
<p>-Tom</p>
|
|
<p><b>8/26/2002 - Shorewall 1.3.7b</b></p>
|
|
<p>This is a role up of the "shorewall refresh" bug fix and the
|
|
change which reverses the order of "dhcp" and "norfc1918"
|
|
checking.</p>
|
|
<p><b>8/26/2002 - French FTP Mirror is Operational</b></p>
|
|
<p><a target="_blank"
|
|
href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
|
|
is now available.</p>
|
|
<p><b>8/25/2002 - Shorewall Mirror in France</b></p>
|
|
<p>Thanks to a Shorewall user in Paris, the Shorewall web site is
|
|
now mirrored at <a target="_top" href="http://france.shorewall.net">http://france.shorewall.net</a>.</p>
|
|
<p><b>8/25/2002 - Shorewall 1.3.7a Debian Packages
|
|
Available</b></p>
|
|
<p>Lorenzo Martignoni reports that the packages for version 1.3.7a
|
|
are available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
<p><b>8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for
|
|
its Author -- Shorewall 1.3.7a released<img border="0"
|
|
src="images/j0233056.gif" width="50" height="80" align="middle"
|
|
alt="Brown Paper Bag Graphic"></b></p>
|
|
<p>1.3.7a corrects problems occurring in rules file processing when
|
|
starting Shorewall 1.3.7.</p>
|
|
<p><b>8/22/2002 - Shorewall 1.3.7 Released 8/13/2002</b></p>
|
|
<p>Features in this release include:</p>
|
|
<ul>
|
|
<li>The 'icmp.def' file is now empty! The rules in that file were
|
|
required in ipchains firewalls but are not required in Shorewall.
|
|
Users who have ALLOWRELATED=No in <a href="Documentation.htm#Conf">shorewall.conf</a>
|
|
should see the <a href="errata.htm#Upgrade">Upgrade Issues</a>.</li>
|
|
<li>A 'FORWARDPING' option has been added to <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a>. The effect of
|
|
setting
|
|
this variable to Yes is the same as the effect of adding an ACCEPT
|
|
rule for ICMP echo-request in <a href="shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>.
|
|
Users
|
|
who have such a rule in icmpdef are encouraged to switch to
|
|
FORWARDPING=Yes.</li>
|
|
<li>The loopback CLASS A Network (127.0.0.0/8) has been added to
|
|
the rfc1918 file.</li>
|
|
<li>Shorewall now works with iptables 1.2.7</li>
|
|
<li>The documentation and web site no longer uses FrontPage
|
|
themes.</li>
|
|
</ul>
|
|
<p>I would like to thank John Distler for his valuable input
|
|
regarding TCP SYN and ICMP treatment in Shorewall. That input has
|
|
led to marked improvement in Shorewall in the last two
|
|
releases.</p>
|
|
<p><b>8/13/2002 - Documentation in the <a target="_top"
|
|
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
|
|
Repository</a></b></p>
|
|
<p>The Shorewall-docs project now contains just the HTML and image
|
|
files - the Frontpage files have been removed.</p>
|
|
<p><b>8/7/2002 - <i>STABLE</i></b> <b>branch added to <a
|
|
target="_top" href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
|
|
Repository</a></b></p>
|
|
<p>This branch will only be updated after I release a new version
|
|
of Shorewall so you can always update from this branch to get the
|
|
latest stable tree.</p>
|
|
<p><b>8/7/2002 - <a href="errata.htm#Upgrade">Upgrade Issues</a>
|
|
section added to the <a href="errata.htm">Errata Page</a></b></p>
|
|
<p>Now there is one place to go to look for issues involved with
|
|
upgrading to recent versions of Shorewall.</p>
|
|
<p><b>8/7/2002 - Shorewall 1.3.6</b></p>
|
|
<p>This is primarily a bug-fix rollup with a couple of new
|
|
features:</p>
|
|
<ul>
|
|
<li>The latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
|
Guides</a> including the <a href="shorewall_setup_guide.htm">Shorewall
|
|
Setup Guide.</a></li>
|
|
<li>Shorewall will now DROP TCP packets that are not part of or
|
|
related to an existing connection and that are not SYN packets.
|
|
These "New not SYN" packets may be optionally logged by setting the
|
|
LOGNEWNOTSYN option in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
|
<li>The processing of "New not SYN" packets may be extended by
|
|
commands in the new <a href="shorewall_extension_scripts.htm">newnotsyn
|
|
extension
|
|
script</a>.</li>
|
|
</ul>
|
|
<p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>
|
|
<p>This interim release:</p>
|
|
<ul>
|
|
<li>Causes the firewall script to remove the lock file if it is
|
|
killed.</li>
|
|
<li>Once again allows lists in the second column of the <a
|
|
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a> file.</li>
|
|
<li>Includes the latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
|
Guides</a>.</li>
|
|
</ul>
|
|
<p><b>7/29/2002 - New Shorewall Setup Guide Available</b></p>
|
|
<p>The first draft of this guide is available at <a
|
|
href="http://www.shorewall.net/shorewall_setup_guide.htm">http://www.shorewall.net/shorewall_setup_guide.htm</a>.
|
|
The guide is intended for use by people who are setting up
|
|
Shorewall to manage multiple public IP addresses and by people who
|
|
want to learn more about Shorewall than is described in the
|
|
single-address guides. Feedback on the new guide is welcome.</p>
|
|
<p><b>7/28/2002 - Shorewall 1.3.5 Debian Package Available</b></p>
|
|
<p>Lorenzo Martignoni reports that the packages are version 1.3.5a
|
|
and are available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
<p><b>7/27/2002 - Shorewall 1.3.5a Released</b></p>
|
|
<p>This interim release restores correct handling of REDIRECT
|
|
rules.</p>
|
|
<p><b>7/26/2002 - Shorewall 1.3.5 Released</b></p>
|
|
<p>This will be the last Shorewall release for a while. I'm going
|
|
to be focusing on rewriting a lot of the documentation.</p>
|
|
<p><b> </b> In this version:</p>
|
|
<ul>
|
|
<li>Empty and invalid source and destination qualifiers are now
|
|
detected in the rules file. It is a good idea to use the 'shorewall
|
|
check' command before you issue a 'shorewall restart' command be be
|
|
sure that you don't have any configuration problems that will
|
|
prevent a successful restart.</li>
|
|
<li>Added <b>MERGE_HOSTS</b> variable in <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a> to provide saner
|
|
behavior of the /etc/shorewall/hosts file.</li>
|
|
<li>The time that the counters were last reset is now displayed in
|
|
the heading of the 'status' and 'show' commands.</li>
|
|
<li>A <b>proxyarp</b> option has been added for entries in <a
|
|
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
|
|
This
|
|
option facilitates Proxy ARP sub-netting as described in the Proxy
|
|
ARP subnetting mini-HOWTO (<a
|
|
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>).
|
|
Specifying the proxyarp option for an interface causes Shorewall to
|
|
set /proc/sys/net/ipv4/conf/<interface>/proxy_arp.</li>
|
|
<li>The Samples have been updated to reflect the new capabilities
|
|
in this release.</li>
|
|
</ul>
|
|
<p><b>7/16/2002 - New Mirror in Argentina</b></p>
|
|
<p>Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall
|
|
mirror in Argentina. Thanks Buanzo!!!</p>
|
|
<p><b>7/16/2002 - Shorewall 1.3.4 Released</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A new <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>
|
|
file has been added. This file is intended to eventually replace
|
|
the <b>routestopped</b> option in the /etc/shorewall/interface and
|
|
/etc/shorewall/hosts files. This new file makes remote firewall
|
|
administration easier by allowing any IP or subnet to be enabled
|
|
while Shorewall is stopped.</li>
|
|
<li>An /etc/shorewall/stopped <a href="Documentation.htm#Scripts">extension
|
|
script</a> has been added.
|
|
This script is invoked after Shorewall has stopped.</li>
|
|
<li>A <b>DETECT_DNAT_ADDRS</b> option has been added to <a
|
|
href="Documentation.htm#Conf">/etc/shoreall/shorewall.conf</a>. When
|
|
this option is selected, DNAT rules only apply when the destination
|
|
address is the external interface's primary IP address.</li>
|
|
<li>The <a href="shorewall_quickstart_guide.htm">QuickStart
|
|
Guide</a> has been broken into three guides and has been almost
|
|
entirely rewritten.</li>
|
|
<li>The Samples have been updated to reflect the new capabilities
|
|
in this release.</li>
|
|
</ul>
|
|
<p><b>7/8/2002 - Shorewall 1.3.3 Debian Package Available</b></p>
|
|
<p>Lorenzo Marignoni reports that the packages are available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
<p><b>7/6/2002 - Shorewall 1.3.3 Released</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>Entries in /etc/shorewall/interface that use the wildcard
|
|
character ("+") now have the "multi" option assumed.</li>
|
|
<li>The 'rfc1918' chain in the mangle table has been renamed
|
|
'man1918' to make log messages generated from that chain
|
|
distinguishable from those generated by the 'rfc1918' chain in the
|
|
filter table.</li>
|
|
<li>Interface names appearing in the hosts file are now validated
|
|
against the interfaces file.</li>
|
|
<li>The TARGET column in the rfc1918 file is now checked for
|
|
correctness.</li>
|
|
<li>The chain structure in the nat table has been changed to reduce
|
|
the number of rules that a packet must traverse and to correct
|
|
problems with NAT_BEFORE_RULES=No</li>
|
|
<li>The "hits" command has been enhanced.</li>
|
|
</ul>
|
|
<p><b>6/25/2002 - Samples Updated for 1.3.2</b></p>
|
|
<p>The comments in the sample configuration files have been updated
|
|
to reflect new features introduced in Shorewall 1.3.2.</p>
|
|
<p><b>6/25/2002 - Shorewall 1.3.1 Debian Package Available</b></p>
|
|
<p>Lorenzo Marignoni reports that the package is available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
<p><b>6/19/2002 - Documentation Available in PDF Format</b></p>
|
|
<p>Thanks to Mike Martinez, the Shorewall Documentation is now
|
|
available for <a href="download.htm">download</a> in <a
|
|
href="http://www.adobe.com">Adobe</a> PDF format.</p>
|
|
<p><b>6/16/2002 - Shorewall 1.3.2 Released</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A <a href="Documentation.htm#Starting">logwatch command</a> has
|
|
been added to /sbin/shorewall.</li>
|
|
<li>A <a href="blacklisting_support.htm">dynamic blacklist
|
|
facility</a> has been added.</li>
|
|
<li>Support for the <a href="Documentation.htm#Conf">Netfilter
|
|
multiport match function</a> has been added.</li>
|
|
<li>The files <b>firewall, functions</b> and <b>version</b> have
|
|
been moved from /etc/shorewall to /var/lib/shorewall.</li>
|
|
</ul>
|
|
<p><b>6/6/2002 - Why CVS Web access is Password Protected</b></p>
|
|
<p>Last weekend, I installed the CVS Web package to provide
|
|
brower-based access to the Shorewall CVS repository. Since then, I
|
|
have had several instances where my server was almost unusable due
|
|
to the high load generated by website copying tools like HTTrack
|
|
and WebStripper. These mindless tools:</p>
|
|
<ul>
|
|
<li>Ignore robot.txt files.</li>
|
|
<li>Recursively copy everything that they find.</li>
|
|
<li>Should be classified as weapons rather than tools.</li>
|
|
</ul>
|
|
<p>These tools/weapons are particularly damaging when combined with
|
|
CVS Web because they doggedly follow every link in the
|
|
cgi-generated HTML resulting in 1000s of executions of the
|
|
cvsweb.cgi script. Yesterday, I spend several hours implementing
|
|
measures to block these tools but unfortunately, these measures
|
|
resulted in my server OOM-ing under even moderate load.</p>
|
|
<p>Until I have the time to understand the cause of the OOM (or
|
|
until I buy more RAM if that is what is required), CVS Web access
|
|
will remain Password Protected.</p>
|
|
<p><b>6/5/2002 - Shorewall 1.3.1 Debian Package Available</b></p>
|
|
<p>Lorenzo Marignoni reports that the package is available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
<p><b>6/2/2002 - Samples Corrected</b></p>
|
|
<p>The 1.3.0 samples configurations had several serious problems
|
|
that prevented DNS and SSH from working properly. These problems
|
|
have been corrected in the <a href="/pub/shorewall/samples-1.3.1">1.3.1
|
|
samples.</a></p>
|
|
<p><b>6/1/2002 - Shorewall 1.3.1 Released</b></p>
|
|
<p>Hot on the heels of 1.3.0, this release:</p>
|
|
<ul>
|
|
<li>Corrects a serious problem with "all <i><zone></i>
|
|
CONTINUE" policies. This problem is present in all versions of
|
|
Shorewall that support the CONTINUE policy. These previous versions
|
|
optimized away the "all2<i><zone></i>" chain and replaced it
|
|
with the "all2all" chain with the usual result that a policy of
|
|
REJECT was enforced rather than the intended CONTINUE policy.</li>
|
|
<li>Adds an <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</a>
|
|
file for
|
|
defining the exact behavior of the <a
|
|
href="Documentation.htm#Interfaces">'norfc1918' interface
|
|
option</a>.</li>
|
|
</ul>
|
|
<p><b>5/29/2002 - Shorewall 1.3.0 Released</b></p>
|
|
<p>In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall
|
|
1.3.0 includes:</p>
|
|
<ul>
|
|
<li>A 'filterping' interface option that allows ICMP echo-request
|
|
(ping) requests addressed to the firewall to be handled by entries
|
|
in /etc/shorewall/rules and /etc/shorewall/policy.</li>
|
|
</ul>
|
|
<p><b>5/23/2002 - Shorewall 1.3 RC1 Available</b></p>
|
|
<p>In addition to the changes in Beta 1 and Beta 2, RC1 (Version
|
|
1.2.92) incorporates the following:</p>
|
|
<ul>
|
|
<li>Support for the /etc/shorewall/whitelist file has been
|
|
withdrawn. If you need whitelisting, see <a
|
|
href="/1.3/whitelisting_under_shorewall.htm">these
|
|
instructions</a>.</li>
|
|
</ul>
|
|
<p><b>5/19/2002 - Shorewall 1.3 Beta 2 Available</b></p>
|
|
<p>In addition to the changes in Beta 1, this release which carries
|
|
the designation 1.2.91 adds:</p>
|
|
<ul>
|
|
<li>The structure of the firewall is changed markedly. There is now
|
|
an INPUT and a FORWARD chain for each interface; this reduces the
|
|
number of rules that a packet must traverse, especially in
|
|
complicated setups.</li>
|
|
<li><a href="Documentation.htm#Exclude">Sub-zones may now be
|
|
excluded from DNAT and REDIRECT rules.</a></li>
|
|
<li>The names of the columns in a number of the configuration files
|
|
have been changed to be more consistent and self-explanatory and
|
|
the documentation has been updated accordingly.</li>
|
|
<li>The sample configurations have been updated for 1.3.</li>
|
|
</ul>
|
|
<p><b>5/17/2002 - Shorewall 1.3 Beta 1 Available</b></p>
|
|
<p>Beta 1 carries the version designation 1.2.90 and implements the
|
|
following features:</p>
|
|
<ul>
|
|
<li>Simplified rule syntax which makes the intent of each rule
|
|
clearer and hopefully makes Shorewall easier to learn.</li>
|
|
<li>Upward compatibility with 1.2 configuration files has been
|
|
maintained so that current users can migrate to the new syntax at
|
|
their convenience.</li>
|
|
<li><b><font color="#cc6666">WARNING: Compatibility with the
|
|
old parameterized sample configurations has NOT been maintained.
|
|
Users still running those configurations should migrate to the new
|
|
sample configurations before upgrading to 1.3 Beta
|
|
1.</font></b></li>
|
|
</ul>
|
|
<p><b>5/4/2002 - Shorewall 1.2.13 is Available</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#Whitelist">White-listing</a> is
|
|
supported.</li>
|
|
<li><a href="Documentation.htm#Policy">SYN-flood protection</a> is
|
|
added.</li>
|
|
<li>IP addresses added under <a href="Documentation.htm#Conf">ADD_IP_ALIASES
|
|
and ADD_SNAT_ALIASES</a>
|
|
now inherit the VLSM and Broadcast Address of the interface's
|
|
primary IP address.</li>
|
|
<li>The order in which port forwarding DNAT and Static DNAT <a
|
|
href="Documentation.htm#Conf">can now be reversed</a> so that port
|
|
forwarding rules can override the contents of <a
|
|
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</li>
|
|
</ul>
|
|
<p><b>4/30/2002 - Shorewall Debian News</b></p>
|
|
<p>Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both
|
|
the <a href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
|
Testing Branch</a> and the <a
|
|
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
Unstable Branch</a>.</p>
|
|
<p><b>4/20/2002 - Shorewall 1.2.12 is Available</b></p>
|
|
<ul>
|
|
<li>The 'try' command works again</li>
|
|
<li>There is now a single RPM that also works with SuSE.</li>
|
|
</ul>
|
|
<p><b>4/17/2002 - Shorewall Debian News</b></p>
|
|
<p>Lorenzo Marignoni reports that:</p>
|
|
<ul>
|
|
<li>Shorewall 1.2.10 is in the <a
|
|
href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
|
Testing Branch</a></li>
|
|
<li>Shorewall 1.2.11 is in the <a
|
|
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
Unstable Branch</a></li>
|
|
</ul>
|
|
<p>Thanks, Lorenzo!</p>
|
|
<p><b>4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE</b></p>
|
|
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan
|
|
Mohr</a>, there is now a Shorewall 1.2.11 <a
|
|
href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm">
|
|
SuSE RPM</a> available.</p>
|
|
<p><b>4/13/2002 - Shorewall 1.2.11 Available</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>The 'try' command now accepts an optional timeout. If the
|
|
timeout is given in the command, the standard configuration will
|
|
automatically be restarted after the new configuration has been
|
|
running for that length of time. This prevents a remote admin from
|
|
being locked out of the firewall in the case where the new
|
|
configuration starts but prevents access.</li>
|
|
<li>Kernel route filtering may now be enabled globally using the
|
|
new ROUTE_FILTER parameter in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
|
<li>Individual IP source addresses and/or subnets may now be
|
|
excluded from masquerading/SNAT.</li>
|
|
<li>Simple "Yes/No" and "On/Off" values are now case-insensitive in
|
|
/etc/shorewall/shorewall.conf.</li>
|
|
</ul>
|
|
<p><b>4/13/2002 - Hamburg Mirror now has FTP</b></p>
|
|
<p>Stefan now has an FTP mirror at <a target="_blank"
|
|
href="ftp://germany.shorewall.net/pub/shorewall">ftp://germany.shorewall.net/pub/shorewall</a>.
|
|
Thanks Stefan!</p>
|
|
<p><b>4/12/2002 - New Mirror in Hamburg</b></p>
|
|
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan
|
|
Mohr</a>, there is now a mirror of the Shorewall website at <a
|
|
target="_top" href="http://germany.shorewall.net">http://germany.shorewall.net</a>.</p>
|
|
<p><b>4/10/2002 - Shorewall QuickStart Guide Version 1.1
|
|
Available</b></p>
|
|
<p><a href="shorewall_quickstart_guide.htm">Version 1.1 of the
|
|
QuickStart Guide</a> is now available. Thanks to those who have
|
|
read version 1.0 and offered their suggestions. Corrections have
|
|
also been made to the sample scripts.</p>
|
|
<p><b>4/9/2002 - Shorewall QuickStart Guide Version 1.0
|
|
Available</b></p>
|
|
<p><a href="shorewall_quickstart_guide.htm">Version 1.0 of the
|
|
QuickStart Guide</a> is now available. This Guide and its
|
|
accompanying sample configurations are expected to provide a
|
|
replacement for the recently withdrawn parameterized samples.</p>
|
|
<p><b>4/8/2002 - Parameterized Samples Withdrawn</b></p>
|
|
<p>Although the <a
|
|
href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized
|
|
samples</a> have allowed people to get a firewall up and running
|
|
quickly, they have unfortunately set the wrong level of expectation
|
|
among those who have used them. I am therefore withdrawing support
|
|
for the samples and I am recommending that they not be used in new
|
|
Shorewall installations.</p>
|
|
<p><b>4/2/2002 - Updated Log Parser</b></p>
|
|
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided
|
|
an updated version of his <a href="pub/shorewall/parsefw/">CGI-based
|
|
log parser</a> with corrected
|
|
date handling.</p>
|
|
<p><b>3/30/2002 - Shorewall Website Search Improvements</b></p>
|
|
<p>The quick search on the home page now excludes the mailing list
|
|
archives. The <a href="htdig/search.html">Extended Search</a>
|
|
allows excluding the archives or restricting the search to just the
|
|
archives. An archive search form is also available on the <a
|
|
href="http://lists.shorewall.net/mailing_list.htm">mailing list
|
|
information page</a>.</p>
|
|
<p><b>3/28/2002 - Debian Shorewall News (From Lorenzo
|
|
Martignoni)</b></p>
|
|
<ul>
|
|
<li>The 1.2.10 Debian Package is available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
|
|
<li>Shorewall 1.2.9 is now in the <a
|
|
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
Unstable Distribution</a>.</li>
|
|
</ul>
|
|
<p><b>3/25/2002 - Log Parser Available</b></p>
|
|
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided
|
|
a <a href="pub/shorewall/parsefw/">CGI-based log parser</a> for
|
|
Shorewall. Thanks John.</p>
|
|
<p><b>3/20/2002 - Shorewall 1.2.10 Released</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A "shorewall try" command has been added (syntax: shorewall try <i><configuration
|
|
directory></i>). This command attempts
|
|
"shorewall -c <i><configuration directory></i> start" and if
|
|
that results in the firewall being stopped due to an error, a
|
|
"shorewall start" command is executed. The 'try' command allows you
|
|
to create a new <a href="Documentation.htm#Configs">configuration</a>
|
|
and attempt to start
|
|
it; if there is an error that leaves your firewall in the stopped
|
|
state, it will automatically be restarted using the default
|
|
configuration (in /etc/shorewall).</li>
|
|
<li>A new variable ADD_SNAT_ALIASES has been added to <a
|
|
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>. If
|
|
this
|
|
variable is set to "Yes", Shorewall will automatically add IP
|
|
addresses listed in the third column of the <a
|
|
href="Documentation.htm#Masq">/etc/shorewall/masq</a> file.</li>
|
|
<li>Copyright notices have been added to the documenation.</li>
|
|
</ul>
|
|
<p><b>3/11/2002 - Shorewall 1.2.9 Released</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>Filtering by <a href="Documentation.htm#MAC">MAC address</a>
|
|
has been added. MAC addresses may be used as the source address in:
|
|
<ul>
|
|
<li>Filtering rules (<a href="Documentation.htm#Rules">/etc/shorewall/rules</a>)</li>
|
|
<li>Traffic Control Classification Rules (<a
|
|
href="traffic_shaping.htm#tcrules">/etc/shorewall/tcrules</a>)</li>
|
|
<li>TOS Rules (<a href="Documentation.htm#TOS">/etc/shorewall/tos</a>)</li>
|
|
<li>Blacklist (<a href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a>)</li>
|
|
</ul>
|
|
</li>
|
|
<li>Several bugs have been fixed</li>
|
|
<li>The 1.2.9 Debian Package is also available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
|
|
</ul>
|
|
<p><b>3/1/2002 - 1.2.8 Debian Package is Available</b></p>
|
|
<p>See <a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
<p><b>2/25/2002 - New Two-interface Sample</b></p>
|
|
<p>I've enhanced the two interface sample to allow access from the
|
|
firewall to servers in the local zone - <a
|
|
href="http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz">
|
|
http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz</a></p>
|
|
<p><b>2/23/2002 - Shorewall 1.2.8 Released</b></p>
|
|
<p>Do to a serious problem with 1.2.7, I am releasing 1.2.8. It
|
|
corrects problems associated with the lock file used to prevent
|
|
multiple state-changing operations from occuring simultaneously. My
|
|
apologies for any inconvenience my carelessness may have
|
|
caused.</p>
|
|
<p><b>2/22/2002 - Shorewall 1.2.7 Released</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>UPnP probes (UDP destination port 1900) are now silently
|
|
dropped in the <i>common</i> chain</li>
|
|
<li>RFC 1918 checking in the mangle table has been streamlined to
|
|
no longer require packet marking. RFC 1918 checking in the filter
|
|
table has been changed to require half as many rules as
|
|
previously.</li>
|
|
<li>A 'shorewall check' command has been added that does a cursory
|
|
validation of the zones, interfaces, hosts, rules and policy
|
|
files.</li>
|
|
</ul>
|
|
<p><b>2/18/2002 - 1.2.6 Debian Package is Available</b></p>
|
|
<p>See <a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
<p><b>2/8/2002 - Shorewall 1.2.6 Released</b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>$-variables may now be used anywhere in the configuration files
|
|
except /etc/shorewall/zones.</li>
|
|
<li>The interfaces and hosts files now have their contents
|
|
validated before any changes are made to the existing Netfilter
|
|
configuration. The appearance of a zone name that isn't defined in
|
|
/etc/shorewall/zones causes "shorewall start" and "shorewall
|
|
restart" to abort without changing the Shorewall state. Unknown
|
|
options in either file cause a warning to be issued.</li>
|
|
<li>A problem occurring when BLACKLIST_LOGLEVEL was not set has
|
|
been corrected.</li>
|
|
</ul>
|
|
<p><b>2/4/2002 - Shorewall 1.2.5 Debian Package Available</b></p>
|
|
<p>see <a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
<p><b>2/1/2002 - Shorewall 1.2.5 Released</b></p>
|
|
<p>Due to installation problems with Shorewall 1.2.4, I have
|
|
released Shorewall 1.2.5. Sorry for the rapid-fire development.</p>
|
|
<p>In version 1.2.5:</p>
|
|
<ul>
|
|
<li>The installation problems have been corrected.</li>
|
|
<li><a href="Documentation.htm#Masq">SNAT</a> is now
|
|
supported.</li>
|
|
<li>A "shorewall version" command has been added</li>
|
|
<li>The default value of the STATEDIR variable in
|
|
/etc/shorewall/shorewall.conf has been changed to
|
|
/var/lib/shorewall in order to conform to the GNU/Linux File
|
|
Hierarchy Standard, Version 2.2.</li>
|
|
</ul>
|
|
<p><b>1/28/2002 - Shorewall 1.2.4 Released</b></p>
|
|
<ul>
|
|
<li>The "fw" zone <a href="Documentation.htm#FW">may now be given a
|
|
different name</a>.</li>
|
|
<li>You may now place end-of-line comments (preceded by '#') in any
|
|
of the configuration files</li>
|
|
<li>There is now protection against against two state changing
|
|
operations occuring concurrently. This is implemented using the
|
|
'lockfile' utility if it is available (lockfile is part of
|
|
procmail); otherwise, a less robust technique is used. The lockfile
|
|
is created in the STATEDIR defined in /etc/shorewall/shorewall.conf
|
|
and has the name "lock".</li>
|
|
<li>"shorewall start" no longer fails if "detect" is specified in <a
|
|
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
|
|
for an
|
|
interface with subnet mask 255.255.255.255.</li>
|
|
</ul>
|
|
<p><b>1/27/2002 - Shorewall 1.2.3 Debian Package Available</b> --
|
|
see <a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
<p><b>1/20/2002 - Corrected firewall script available </b></p>
|
|
<p>Corrects a problem with BLACKLIST_LOGLEVEL. See <a href="errata.htm">the
|
|
errata</a> for details.</p>
|
|
<p><b>1/19/2002 - Shorewall 1.2.3 Released</b></p>
|
|
<p>This is a minor feature and bugfix release. The single new
|
|
feature is:</p>
|
|
<ul>
|
|
<li>Support for TCP MSS Clamp to PMTU -- This support is usually
|
|
required when the internet connection is via PPPoE or PPTP and may
|
|
be enabled using the <a href="Documentation.htm#ClampMSS">CLAMPMSS</a>
|
|
option in
|
|
/etc/shorewall/shorewall.conf.</li>
|
|
</ul>
|
|
<p>The following problems were corrected:</p>
|
|
<ul>
|
|
<li>The "shorewall status" command no longer hangs.</li>
|
|
<li>The "shorewall monitor" command now displays the icmpdef
|
|
chain</li>
|
|
<li>The CLIENT PORT(S) column in tcrules is no longer ignored</li>
|
|
</ul>
|
|
<p><b>1/18/2002 - Shorewall 1.2.2 packaged with new</b> <a
|
|
href="http://leaf.sourceforge.net">LEAF</a> <b>release</b></p>
|
|
<p>Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF
|
|
distribution that includes Shorewall 1.2.2. See <a
|
|
href="http://leaf.sourceforge.net/devel/jnilo">http://leaf.sourceforge.net/devel/jnilo</a>
|
|
for details.</p>
|
|
<p><b>1/11/2002 - Debian Package (.deb) Now Available -</b> Thanks
|
|
to <a href="mailto:lorenzo.martignoni@milug.org">Lorenzo
|
|
Martignoni</a>, a 1.2.2 Shorewall Debian package is now available.
|
|
There is a link to Lorenzo's site from the <a href="download.htm">Shorewall
|
|
download page</a>.</p>
|
|
<p><b>1/9/2002 - Updated 1.2.2 /sbin/shorewall available -</b> <a
|
|
href="/pub/shorewall/errata/1.2.2/shorewall">This corrected
|
|
version</a> restores the "shorewall status" command to health.</p>
|
|
<p><b>1/8/2002 - Shorewall 1.2.2 Released</b></p>
|
|
<p>In version 1.2.2</p>
|
|
<ul>
|
|
<li>Support for IP blacklisting has been added
|
|
<ul>
|
|
<li>You specify whether you want packets from blacklisted hosts
|
|
dropped or rejected using the <a href="Documentation.htm#BLDisposition">BLACKLIST_DISPOSITION</a>
|
|
setting
|
|
in /etc/shorewall/shorewall.conf</li>
|
|
<li>You specify whether you want packets from blacklisted hosts
|
|
logged and at what syslog level using the <a
|
|
href="Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL</a> setting in
|
|
/etc/shorewall/shorewall.conf</li>
|
|
<li>You list the IP addresses/subnets that you wish to blacklist
|
|
in <a href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a></li>
|
|
<li>You specify the interfaces you want checked against the
|
|
blacklist using the new "<a href="Documentation.htm#BLInterface">blacklist</a>"
|
|
option in
|
|
/etc/shorewall/interfaces.</li>
|
|
<li>The black list is refreshed from /etc/shorewall/blacklist by
|
|
the "shorewall refresh" command.</li>
|
|
</ul>
|
|
</li>
|
|
<li>Use of TCP RST replies has been expanded
|
|
<ul>
|
|
<li>TCP connection requests rejected because of a REJECT policy
|
|
are
|
|
now replied with a TCP RST packet.</li>
|
|
<li>TCP connection requests rejected because of a protocol=all
|
|
rule
|
|
in /etc/shorewall/rules are now replied with a TCP RST packet.</li>
|
|
</ul>
|
|
</li>
|
|
<li>A <a href="Documentation.htm#Logfile">LOGFILE</a> specification
|
|
has been added to /etc/shorewall/shorewall.conf. LOGFILE is used to
|
|
tell the /sbin/shorewall program where to look for Shorewall
|
|
messages.</li>
|
|
</ul>
|
|
<p><b>1/5/2002 - New Parameterized Samples (<a
|
|
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.2.0/"
|
|
target="_blank">version 1.2.0</a>) released.</b> These are minor
|
|
updates
|
|
to the previously-released samples. There are two new rules
|
|
added:</p>
|
|
<ul>
|
|
<li>Unless you have explicitly enabled Auth connections (tcp port
|
|
113) to your firewall, these connections will be REJECTED rather
|
|
than DROPPED. This speeds up connection establishment to some
|
|
servers.</li>
|
|
<li>Orphan DNS replies are now silently dropped.</li>
|
|
</ul>
|
|
<p>See the README file for upgrade instructions.</p>
|
|
<p><b>1/1/2002 - <u><font color="#ff6633">Shorewall Mailing List
|
|
Moving</font></u></b></p>
|
|
<p>The Shorewall mailing list hosted at <a
|
|
href="http://sourceforge.net">Sourceforge</a> is moving to
|
|
Shorewall.net. If you are a current subscriber to the list at
|
|
Sourceforge, please <a href="shorewall_mailing_list_migration.htm">see
|
|
these instructions</a>.
|
|
If you would like to subscribe to the new list, visit <a
|
|
href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>.</p>
|
|
<p><b>12/31/2001 - Shorewall 1.2.1 Released</b></p>
|
|
<p>In version 1.2.1:</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#LogUncleanOption">Logging of
|
|
Mangled/Invalid Packets</a> is added. </li>
|
|
<li>The <a href="IPIP.htm">tunnel script</a> has been
|
|
corrected.</li>
|
|
<li>'shorewall show tc' now correctly handles tunnels.</li>
|
|
</ul>
|
|
<p><b>12/21/2001 - Shorewall 1.2.0 Released!</b> - <b>I couldn't
|
|
resist releasing 1.2 on 12/21/2001</b></p>
|
|
<p>Version 1.2 contains the following new features:</p>
|
|
<ul>
|
|
<li>Support for <a href="traffic_shaping.htm">Traffic
|
|
Control/Shaping</a></li>
|
|
<li>Support for <a href="Documentation.htm#Unclean">Filtering of
|
|
Mangled/Invalid Packets</a></li>
|
|
<li>Support for <a href="IPIP.htm">GRE Tunnels</a></li>
|
|
</ul>
|
|
<p>For the next month or so, I will continue to provide corrections
|
|
to version 1.1.18 as necessary so that current version 1.1.x users
|
|
will not be forced into a quick upgrade to 1.2.0 just to have
|
|
access to bug fixes.</p>
|
|
<p>For those of you who have installed one of the Beta RPMS, you
|
|
will need to use the "--oldpackage" option when upgrading to
|
|
1.2.0:</p>
|
|
<blockquote>
|
|
<p>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</p>
|
|
</blockquote>
|
|
<p><b>12/19/2001 - Thanks to <a href="mailto:scowles@infohiiway.com">Steve
|
|
Cowles</a>, there is now a
|
|
Shorewall mirror in Texas.</b> This web site is mirrored at <a
|
|
href="http://www.infohiiway.com/shorewall" target="_top">http://www.infohiiway.com/shorewall</a>
|
|
and the ftp site is
|
|
at <a href="ftp://ftp.infohiiway.com/pub/mirrors/shorewall">ftp://ftp.infohiiway.com/pub/mirrors/shorewall</a>.<b>
|
|
</b></p>
|
|
<p><b>11/30/2001 - A new set of the parameterized <a
|
|
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample
|
|
Configurations</a> has been released</b>. In this version:</p>
|
|
<ul>
|
|
<li>Ping is now allowed between the zones.</li>
|
|
<li>In the three-interface configuration, it is now possible to
|
|
configure the internet services that are to be available to servers
|
|
in the DMZ. </li>
|
|
</ul>
|
|
<p><b>11/20/2001 - The current version of Shorewall is
|
|
1.1.18. </b></p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>The spelling of ADD_IP_ALIASES has been corrected in the
|
|
shorewall.conf file</li>
|
|
<li>The logic for deleting user-defined chains has been simplified
|
|
so that it avoids a bug in the LRP version of the 'cut'
|
|
utility.</li>
|
|
<li>The /var/lib/lrpkg/shorwall.conf file has been corrected to
|
|
properly display the NAT entry in that file.</li>
|
|
</ul>
|
|
<p><b>11/19/2001 - Thanks to <a href="mailto:shorewall@timelord.sk">Juraj
|
|
Ontkanin</a>, there is now a
|
|
Shorewall mirror in the Slovak Republic</b>. The website is now
|
|
mirrored at <a href="http://www.nrg.sk/mirror/shorewall" target="_top">http://www.nrg.sk/mirror/shorewall</a>
|
|
and the FTP site is
|
|
mirrored at <a href="ftp://ftp.nrg.sk/mirror/shorewall">ftp://ftp.nrg.sk/mirror/shorewall</a>.</p>
|
|
<p><b>11/2/2001 - Announcing Shorewall Parameter-driven Sample
|
|
Configurations.</b> There are three sample configurations:</p>
|
|
<ul>
|
|
<li>One Interface -- for a standalone system.</li>
|
|
<li>Two Interfaces -- A masquerading firewall.</li>
|
|
<li>Three Interfaces -- A masquerading firewall with DMZ.</li>
|
|
</ul>
|
|
<p>Samples may be downloaded from <a
|
|
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17">ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17</a>
|
|
. See the README file for instructions.</p>
|
|
<p><b>11/1/2001 - The current version of Shorewall is
|
|
1.1.17</b>. I intend this to be the last of the 1.1 Shorewall
|
|
releases.</p>
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>The handling of <a href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>
|
|
has been
|
|
corrected. </li>
|
|
</ul>
|
|
<p><b>10/22/2001 - The current version of Shorewall is 1.1.16</b>.
|
|
In this version:</p>
|
|
<ul>
|
|
<li>A new "shorewall show connections" command has been added.</li>
|
|
<li>In the "shorewall monitor" output, the currently tracked
|
|
connections are now shown on a separate page.</li>
|
|
<li>Prior to this release, Shorewall unconditionally added the
|
|
external IP adddress(es) specified in /etc/shorewall/nat. Beginning
|
|
with version 1.1.16, a new parameter (<a
|
|
href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>) may be set to
|
|
"no"
|
|
(or "No") to inhibit this behavior. This allows IP aliases created
|
|
using your distribution's network configuration tools to be used in
|
|
static NAT. </li>
|
|
</ul>
|
|
<p><b>10/15/2001 - The current version of Shorewall is 1.1.15.</b>
|
|
In this version:</p>
|
|
<ul>
|
|
<li>Support for nested zones has been improved. See <a
|
|
href="Documentation.htm#Nested">the documentation</a> for details</li>
|
|
<li>Shorewall now correctly checks the alternate configuration
|
|
directory for the 'zones' file.</li>
|
|
</ul>
|
|
<p><b>10/4/2001 - The current version of Shorewall is 1.1.14.</b>
|
|
In this version</p>
|
|
<ul>
|
|
<li>Shorewall now supports alternate configuration directories.
|
|
When an alternate directory is specified when starting or
|
|
restarting Shorewall (e.g., "shorewall -c /etc/testconf restart"),
|
|
Shorewall will first look for configuration files in the alternate
|
|
directory then in /etc/shorewall. To create an alternate
|
|
configuration simply:<br>
|
|
1. Create a New Directory<br>
|
|
2. Copy to that directory any of your configuration files that you
|
|
want to change.<br>
|
|
3. Modify the copied files as needed.<br>
|
|
4. Restart Shorewall specifying the new directory.</li>
|
|
<li>The rules for allowing/disallowing icmp echo-requests (pings)
|
|
are now moved after rules created when processing the rules file.
|
|
This allows you to add rules that selectively allow/deny ping based
|
|
on source or destination address.</li>
|
|
<li>Rules that specify multiple client ip addresses or subnets no
|
|
longer cause startup failures.</li>
|
|
<li>Zone names in the policy file are now validated against the
|
|
zones file.</li>
|
|
<li>If you have <a href="Documentation.htm#MangleEnabled">packet
|
|
mangling</a> support enabled, the "<a
|
|
href="Documentation.htm#Interfaces">norfc1918</a>" interface option
|
|
now
|
|
logs and drops any incoming packets on the interface that have an
|
|
RFC 1918 destination address.</li>
|
|
</ul>
|
|
<p><b>9/12/2001 - The current version of Shorewall is 1.1.13</b>.
|
|
In this version</p>
|
|
<ul>
|
|
<li>Shell variables can now be used to parameterize Shorewall
|
|
rules.</li>
|
|
<li>The second column in the hosts file may now contain a
|
|
comma-separated list.<br>
|
|
<br>
|
|
Example:<br>
|
|
sea
|
|
eth0:130.252.100.0/24,206.191.149.0/24</li>
|
|
<li>Handling of multi-zone interfaces has been improved. See the <a
|
|
href="Documentation.htm#Interfaces">documentation for the
|
|
/etc/shorewall/interfaces file</a>.</li>
|
|
</ul>
|
|
<p><b>8/28/2001 - The current version of Shorewall is 1.1.12</b>.
|
|
In this version</p>
|
|
<ul>
|
|
<li>Several columns in the rules file may now contain
|
|
comma-separated lists.</li>
|
|
<li>Shorewall is now more rigorous in parsing the options in
|
|
/etc/shorewall/interfaces.</li>
|
|
<li>Complementation using "!" is now supported in rules.</li>
|
|
</ul>
|
|
<p><b>7/28/2001 - The current version of Shorewall is 1.1.11</b>.
|
|
In this version</p>
|
|
<ul>
|
|
<li>A "shorewall refresh" command has been added to allow for
|
|
refreshing the rules associated with the broadcast address on a
|
|
dynamic interface. This command should be used in place of
|
|
"shorewall restart" when the internet interface's IP address
|
|
changes.</li>
|
|
<li>The /etc/shorewall/start file (if any) is now processed after
|
|
all temporary rules have been deleted. This change prevents the
|
|
accidental removal of rules added during the processing of that
|
|
file.</li>
|
|
<li>The "dhcp" interface option is now applicable to firewall
|
|
interfaces used by a DHCP server running on the firewall.</li>
|
|
<li>The RPM can now be built from the .tgz file using "rpm
|
|
-tb" </li>
|
|
</ul>
|
|
<p><b>7/6/2001 - The current version of Shorewall is 1.1.10.</b> In
|
|
this version</p>
|
|
<ul>
|
|
<li>Shorewall now enables Ipv4 Packet Forwarding by default. Packet
|
|
forwarding may be disabled by specifying IP_FORWARD=Off in
|
|
/etc/shorewall/shorewall.conf. If you don't want Shorewall to
|
|
enable or disable packet forwarding, add IP_FORWARDING=Keep to your
|
|
/etc/shorewall/shorewall.conf file.</li>
|
|
<li>The "shorewall hits" command no longer lists extraneous service
|
|
names in its last report.</li>
|
|
<li>Erroneous instructions in the comments at the head of the
|
|
firewall script have been corrected.</li>
|
|
</ul>
|
|
<p><b>6/23/2001 - The current version of Shorewall is 1.1.9.</b> In
|
|
this version</p>
|
|
<ul>
|
|
<li>The "tunnels" file <u>really</u> is in the RPM now.</li>
|
|
<li>SNAT can now be applied to port-forwarded connections.</li>
|
|
<li>A bug which would cause firewall start failures in some dhcp
|
|
configurations has been fixed.</li>
|
|
<li>The firewall script now issues a message if you have the name
|
|
of an interface in the second column in an entry in
|
|
/etc/shorewall/masq and that interface is not up.</li>
|
|
<li>You can now configure Shorewall so that it <a
|
|
href="Documentation.htm#NatEnabled">doesn't require the NAT and/or
|
|
mangle netfilter modules</a>.</li>
|
|
<li>Thanks to Alex Polishchuk, the "hits" command from
|
|
seawall is now in shorewall.</li>
|
|
<li>Support for <a href="IPIP.htm">IPIP tunnels</a> has been
|
|
added.</li>
|
|
</ul>
|
|
<p><b>6/18/2001 - The current version of Shorewall is 1.1.8</b>. In
|
|
this version</p>
|
|
<ul>
|
|
<li>A typo in the sample rules file has been corrected.</li>
|
|
<li>It is now possible to restrict masquerading by <a
|
|
href="Documentation.htm#Masq">destination host or subnet.</a></li>
|
|
<li>It is now possible to have static <a href="NAT.htm#LocalPackets">NAT
|
|
rules applied to packets originating on
|
|
the firewall itself</a>.</li>
|
|
</ul>
|
|
<p><b>6/2/2001 - The current version of Shorewall is 1.1.7.</b> In
|
|
this version</p>
|
|
<ul>
|
|
<li>The TOS rules are now deleted when the firewall is
|
|
stopped.</li>
|
|
<li>The .rpm will now install regardless of which version of
|
|
iptables is installed.</li>
|
|
<li>The .rpm will now install without iproute2 being
|
|
installed.</li>
|
|
<li>The documentation has been cleaned up.</li>
|
|
<li>The sample configuration files included in Shorewall have been
|
|
formatted to 80 columns for ease of editing on a VGA console.</li>
|
|
</ul>
|
|
<p><b>5/25/2001 - The current version of Shorewall is 1.1.6</b>. In
|
|
this version</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#lograte">You may now rate-limit the
|
|
packet log.</a></li>
|
|
<li>Previous versions of Shorewall have an implementation of Static
|
|
NAT which violates the principle of least surprise. NAT only
|
|
occurs for packets arriving at (DNAT) or send from (SNAT) the
|
|
interface named in the INTERFACE column of /etc/shorewall/nat.
|
|
Beginning with version 1.1.6, NAT effective regardless of which
|
|
interface packets come from or are destined to. To get
|
|
compatibility with prior versions, I have added a new "ALL <a
|
|
href="NAT.htm#AllInterFaces">"ALL INTERFACES" column to
|
|
/etc/shorewall/nat</a>. By placing "no" or "No" in the new column,
|
|
the NAT behavior of prior versions may be retained. </li>
|
|
<li>The treatment of <a href="IPSEC.htm#RoadWarrior">IPSEC Tunnels
|
|
where the remote gateway is a standalone system has been
|
|
improved</a>. Previously, it was necessary to include an additional
|
|
rule allowing UDP port 500 traffic to pass through the tunnel.
|
|
Shorewall will now create this rule automatically when you place
|
|
the name of the remote peer's zone in a new GATEWAY ZONE column in
|
|
/etc/shorewall/tunnels. </li>
|
|
</ul>
|
|
<p><b>5/20/2001 - The current version of Shorewall is 1.1.5.</b> In
|
|
this version</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#modules">You may now pass parameters
|
|
when loading netfilter modules and you can specify the modules to
|
|
load.</a></li>
|
|
<li>Compressed modules are now loaded. This requires that you
|
|
modutils support loading compressed modules.</li>
|
|
<li><a href="Documentation.htm#TOS">You may now set the Type of
|
|
Service (TOS) field in packets.</a></li>
|
|
<li>Corrected rules generated for port redirection (again).</li>
|
|
</ul>
|
|
<p><b>5/10/2001 - The current version of Shorewall is 1.1.4.</b> In
|
|
this version</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#Conf">Accepting RELATED connections
|
|
is now optional.</a></li>
|
|
<li>Corrected problem where if "shorewall start" aborted early (due
|
|
to kernel configuration errors for example), superfluous 'sed'
|
|
error messages were reported.</li>
|
|
<li>Corrected rules generated for port redirection.</li>
|
|
<li>The order in which iptables kernel modules are loaded has been
|
|
corrected (Thanks to Mark Pavlidis). </li>
|
|
</ul>
|
|
<p><b>4/28/2001 - The current version of Shorewall is 1.1.3.</b> In
|
|
this version</p>
|
|
<ul>
|
|
<li>Correct message issued when Proxy ARP address added (Thanks to
|
|
Jason Kirtland).</li>
|
|
<li>/tmp/shorewallpolicy-$$ is now removed if there is an error
|
|
while starting the firewall.</li>
|
|
<li>/etc/shorewall/icmp.def and /etc/shorewall/common.def are now
|
|
used to define the icmpdef and common chains unless overridden by
|
|
the presence of /etc/shorewall/icmpdef or
|
|
/etc/shorewall/common.</li>
|
|
<li>In the .lrp, the file /var/lib/lrpkg/shorwall.conf has been
|
|
corrected. An extra space after "/etc/shorwall/policy" has been
|
|
removed and "/etc/shorwall/rules" has been added.</li>
|
|
<li>When a sub-shell encounters a fatal error and has stopped the
|
|
firewall, it now kills the main shell so that the main shell will
|
|
not continue.</li>
|
|
<li>A problem has been corrected where a sub-shell stopped the
|
|
firewall and main shell continued resulting in a perplexing error
|
|
message referring to "common.so" resulted.</li>
|
|
<li>Previously, placing "-" in the PORT(S) column in
|
|
/etc/shorewall/rules resulted in an error message during start.
|
|
This has been corrected.</li>
|
|
<li>The first line of "install.sh" has been corrected -- I had
|
|
inadvertently deleted the initial "#".</li>
|
|
</ul>
|
|
<p><b>4/12/2001 - The current version of Shorewall is 1.1.2.</b> In
|
|
this version</p>
|
|
<ul>
|
|
<li>Port redirection now works again.</li>
|
|
<li>The icmpdef and common chains <a href="Documentation.htm#Icmpdef">may
|
|
now be user-defined</a>.</li>
|
|
<li>The firewall no longer fails to start if "routefilter" is
|
|
specified for an interface that isn't started. A warning message is
|
|
now issued in this case.</li>
|
|
<li>The LRP Version is renamed "shorwall" for 8,3 MSDOS file system
|
|
compatibility.</li>
|
|
<li>A couple of LRP-specific problems were corrected.</li>
|
|
</ul>
|
|
<p><b>4/8/2001 - Shorewall is now affiliated with the <a
|
|
href="http://leaf.sourceforge.net">Leaf Project</a></b> <a
|
|
href="http://leaf.sourceforge.net"><img border="0"
|
|
src="images/leaflogo.gif" alt="Leaf Logo" 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. </li>
|
|
</ul>
|
|
<p><b>3/25/2001 - The current version of Shorewall is 1.1.0. In
|
|
this version:</b></p>
|
|
<ul>
|
|
<li>Log messages now indicate the packet disposition.</li>
|
|
<li>Error messages have been improved.</li>
|
|
<li>The ability to define zones consisting of an enumerated set of
|
|
hosts and/or subnetworks has been added.</li>
|
|
<li>The zone-to-zone chain matrix is now sparse so that only those
|
|
chains that contain meaningful rules are defined.</li>
|
|
<li>240.0.0.0/4 and 169.254.0.0/16 have been added to the source
|
|
subnetworks whose packets are dropped under the <i>norfc1918</i>
|
|
interface option.</li>
|
|
<li>Exits are now provided for executing an user-defined script
|
|
when a chain is defined, when the firewall is initialized, when the
|
|
firewall is started, when the firewall is stopped and when the
|
|
firewall is cleared.</li>
|
|
<li>The Linux kernel's route filtering facility can now be
|
|
specified selectively on network interfaces.</li>
|
|
</ul>
|
|
<p><b>3/19/2001 - The current version of Shorewall is 1.0.4. This
|
|
version:</b></p>
|
|
<ul>
|
|
<li>Allows user-defined zones. Shorewall now has only one
|
|
pre-defined zone (fw) with the remaining zones being defined in the
|
|
new configuration file /etc/shorewall/zones. The
|
|
/etc/shorewall/zones file released in this version provides
|
|
behavior that is compatible with Shorewall 1.0.3. </li>
|
|
<li>Adds the ability to specify logging in entries in the
|
|
/etc/shorewall/rules file.</li>
|
|
<li>Correct handling of the icmp-def chain so that only ICMP
|
|
packets are sent through the chain.</li>
|
|
<li>Compresses the output of "shorewall monitor" if awk is
|
|
installed. Allows the command to work if awk isn't installed
|
|
(although it's not pretty).</li>
|
|
</ul>
|
|
<p><b>3/13/2001 - The current version of Shorewall is 1.0.3. This
|
|
is a bug-fix release with no new features.</b></p>
|
|
<ul>
|
|
<li>The PATH variable in the firewall script now includes
|
|
/usr/local/bin and /usr/local/sbin.</li>
|
|
<li>DMZ-related chains are now correctly deleted if the DMZ is
|
|
deleted.</li>
|
|
<li>The interface OPTIONS for "gw" interfaces are no longer
|
|
ignored.</li>
|
|
</ul>
|
|
<p><b>3/8/2001 - The current version of Shorewall is 1.0.2. It
|
|
supports an additional "gw" (gateway) zone for tunnels and it
|
|
supports IPSEC tunnels with end-points on the firewall. There is
|
|
also a .lrp available now.</b></p>
|
|
</body>
|
|
</html>
|