mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-15 12:14:32 +01:00
c2ccd7fd3d
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@800 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
4830 lines
229 KiB
HTML
4830 lines
229 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type"
|
||
content="text/html; charset=windows-1252">
|
||
<title>Shorewall News</title>
|
||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||
</head>
|
||
<body>
|
||
<h1 style="text-align: center;">Shorewall News Archive<br>
|
||
</h1>
|
||
<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>
|
||
<b></b>
|
||
<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>
|
||
<font size="3"><a href="ftp://ftp.shorewall.com.au">ftp://ftp.shorewall.com.au</a></font></div>
|
||
<p><b>8/26/2003 - French Version of the Shorewall Setup Guide </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>
|
||
<blockquote> </blockquote>
|
||
<p><b>Problems Corrected:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>A problem seen on RH7.3 systems where Shorewall encountered start
|
||
errors when started using the "service" mechanism has been worked
|
||
around.<br>
|
||
<br>
|
||
</li>
|
||
<li>Where a list of IP addresses appears in the DEST column of a
|
||
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
|
||
nat table (one for each element in the list). Shorewall now correctly
|
||
creates a single DNAT rule with multiple "--to-destination" clauses.<br>
|
||
<br>
|
||
</li>
|
||
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
|
||
were mis-handled when they appeared in the DEST column of a rule.<br>
|
||
<br>
|
||
</li>
|
||
<li>A number of problems with rule parsing have been corrected.
|
||
Corrections involve the handling of "z1!z2" in the SOURCE column as
|
||
well as lists in the ORIGINAL DESTINATION column.<br>
|
||
<br>
|
||
</li>
|
||
<li>The message "Adding rules for DHCP" is now suppressed if there
|
||
are no DHCP rules to add.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>In earlier versions, an undocumented feature allowed entries in
|
||
the host file as follows:<br>
|
||
<br>
|
||
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>
|
||
<ul>
|
||
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
||
chains in the mangle table but will rather do all 'norfc1918' filtering
|
||
in the filter table (rfc1918 chain).</li>
|
||
<li>Recall that Shorewall DNAT rules generate two netfilter rules;
|
||
one in the nat table and one in the filter table. If the Connection
|
||
Tracking Match Extension is available, the rule in the filter table is
|
||
extended to check that the original destination address was the same as
|
||
specified (or defaulted to) in the DNAT rule.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
<br>
|
||
</li>
|
||
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
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>
|
||
<ul>
|
||
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
||
chains in the mangle table but will rather do all 'norfc1918' filtering
|
||
in the filter table (rfc1918 chain).</li>
|
||
<li>Recall that Shorewall DNAT rules generate two netfilter rules;
|
||
one in the nat table and one in the filter table. If the Connection
|
||
Tracking Match Extension is available, the rule in the filter table is
|
||
extended to check that the original destination address was the same as
|
||
specified (or defaulted to) in the DNAT rule.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
<br>
|
||
</li>
|
||
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
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>
|
||
<ul>
|
||
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
||
chains in the mangle table but will rather do all 'norfc1918' filtering
|
||
in the filter table (rfc1918 chain).</li>
|
||
<li>Recall that Shorewall DNAT rules generate two netfilter
|
||
rules; one in the nat table and one in the filter table. If the
|
||
Connection Tracking Match Extension is available, the rule in the
|
||
filter table is extended to check that the original destination address
|
||
was the same as specified (or defaulted to) in the DNAT rule.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
<br>
|
||
</li>
|
||
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
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>
|
||
<ol>
|
||
</ol>
|
||
<ul>
|
||
<li>To handle 'norfc1918' filtering, Shorewall will not create
|
||
chains in the mangle table but will rather do all 'norfc1918' filtering
|
||
in the filter table (rfc1918 chain).</li>
|
||
<li>Recall that Shorewall DNAT rules generate two netfilter rules;
|
||
one in the nat table and one in the filter table. If the Connection
|
||
Tracking Match Extension is available, the rule in the filter table is
|
||
extended to check that the original destination address was the same as
|
||
specified (or defaulted to) in the DNAT rule.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>6/17/2003 - Shorewall-1.4.5</b></p>
|
||
<p>Problems Corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>The command "shorewall debug try <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>
|
||
<ul>
|
||
<li> There is a policy for za to zb; or </li>
|
||
<li>There is at least one rule for za to zb.</li>
|
||
</ul>
|
||
</ul>
|
||
<ul>
|
||
<li>The /etc/shorewall/blacklist file now contains three columns. In
|
||
addition to the SUBNET/ADDRESS column, there are optional PROTOCOL and
|
||
PORT columns to block only certain applications from the blacklisted
|
||
addresses.<br>
|
||
</li>
|
||
</ul>
|
||
<p><b>9/11/2002 - Debian 1.3.7c Packages Available</b></p>
|
||
<p>Apt-get sources listed at <a
|
||
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>9/2/2002 - Shorewall 1.3.7c</b></p>
|
||
<p>This is a role up of a fix for "DNAT" rules where the source zone is
|
||
$FW (fw).</p>
|
||
<p><b>8/31/2002 - I'm not available</b></p>
|
||
<p>I'm currently on vacation -- please respect my need for a
|
||
couple of weeks free of Shorewall problem reports.</p>
|
||
<p>-Tom</p>
|
||
<p><b>8/26/2002 - Shorewall 1.3.7b</b></p>
|
||
<p>This is a role up of the "shorewall refresh" bug fix and the change
|
||
which reverses the order of "dhcp" and "norfc1918" checking.</p>
|
||
<p><b>8/26/2002 - French FTP Mirror is Operational</b></p>
|
||
<p><a target="_blank"
|
||
href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
|
||
is now available.</p>
|
||
<p><b>8/25/2002 - Shorewall Mirror in France</b></p>
|
||
<p>Thanks to a Shorewall user in Paris, the Shorewall web site is now
|
||
mirrored at <a target="_top" href="http://france.shorewall.net">http://france.shorewall.net</a>.</p>
|
||
<p><b>8/25/2002 - Shorewall 1.3.7a Debian Packages Available</b></p>
|
||
<p>Lorenzo Martignoni reports that the packages for version 1.3.7a are
|
||
available at <a
|
||
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its
|
||
Author -- Shorewall 1.3.7a released<img border="0"
|
||
src="images/j0233056.gif" width="50" height="80" align="middle"> </b></p>
|
||
<p>1.3.7a corrects problems occurring in rules file processing when
|
||
starting Shorewall 1.3.7.</p>
|
||
<p><b>8/22/2002 - Shorewall 1.3.7 Released 8/13/2002</b></p>
|
||
<p>Features in this release include:</p>
|
||
<ul>
|
||
<li>The 'icmp.def' file is now empty! The rules in that file were
|
||
required in ipchains firewalls but are not required in Shorewall. Users
|
||
who have ALLOWRELATED=No in <a href="Documentation.htm#Conf">shorewall.conf</a>
|
||
should see the <a href="errata.htm#Upgrade">Upgrade Issues</a>.</li>
|
||
<li>A 'FORWARDPING' option has been added to <a
|
||
href="Documentation.htm#Conf"> shorewall.conf</a>. The effect of
|
||
setting this variable to Yes is the same as the effect of adding an
|
||
ACCEPT rule for ICMP echo-request in <a
|
||
href="shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>.
|
||
Users who have such a rule in icmpdef are encouraged to switch to
|
||
FORWARDPING=Yes.</li>
|
||
<li>The loopback CLASS A Network (127.0.0.0/8) has been added to the
|
||
rfc1918 file.</li>
|
||
<li>Shorewall now works with iptables 1.2.7</li>
|
||
<li>The documentation and web site no longer uses FrontPage themes.</li>
|
||
</ul>
|
||
<p>I would like to thank John Distler for his valuable input regarding
|
||
TCP SYN and ICMP treatment in Shorewall. That input has led to marked
|
||
improvement in Shorewall in the last two releases.</p>
|
||
<p><b>8/13/2002 - Documentation in the <a target="_top"
|
||
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS Repository</a></b></p>
|
||
<p>The Shorewall-docs project now contains just the HTML and image
|
||
files
|
||
- the Frontpage files have been removed.</p>
|
||
<p><b>8/7/2002 - <i>STABLE</i></b> <b>branch added to <a
|
||
target="_top" href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
|
||
Repository</a></b></p>
|
||
<p>This branch will only be updated after I release a new version of
|
||
Shorewall so you can always update from
|
||
this branch to get the latest stable tree.</p>
|
||
<p><b>8/7/2002 - <a href="errata.htm#Upgrade">Upgrade Issues</a>
|
||
section
|
||
added to the <a href="errata.htm">Errata Page</a></b></p>
|
||
<p>Now there is one place to go to look for issues involved with
|
||
upgrading to recent versions of Shorewall.</p>
|
||
<p><b>8/7/2002 - Shorewall 1.3.6</b></p>
|
||
<p>This is primarily a bug-fix rollup with a couple of new features:</p>
|
||
<ul>
|
||
<li>The latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
||
Guides </a> including the <a href="shorewall_setup_guide.htm">Shorewall
|
||
Setup Guide.</a></li>
|
||
<li>Shorewall will now DROP TCP packets that are not part of or
|
||
related to an existing connection and that are not SYN packets. These
|
||
"New not SYN" packets may be optionally logged by setting the
|
||
LOGNEWNOTSYN option in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
||
<li>The processing of "New not SYN" packets may be extended by
|
||
commands in the new <a href="shorewall_extension_scripts.htm">newnotsyn
|
||
extension script</a>.</li>
|
||
</ul>
|
||
<p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>
|
||
<p>This interim release:</p>
|
||
<ul>
|
||
<li>Causes the firewall script to remove the lock file if it is
|
||
killed.</li>
|
||
<li>Once again allows lists in the second column of the <a
|
||
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a> file.</li>
|
||
<li>Includes the latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
||
Guides</a>.</li>
|
||
</ul>
|
||
<p><b>7/29/2002 - New Shorewall Setup Guide Available</b></p>
|
||
<p>The first draft of this guide is available at <a
|
||
href="http://www.shorewall.net/shorewall_setup_guide.htm">
|
||
http://www.shorewall.net/shorewall_setup_guide.htm</a>. The guide is
|
||
intended for use
|
||
by people who are setting up Shorewall to manage multiple public IP
|
||
addresses and by people who want to learn more about Shorewall than is
|
||
described in the single-address guides. Feedback on the new guide is
|
||
welcome.</p>
|
||
<p><b>7/28/2002 - Shorewall 1.3.5 Debian Package Available</b></p>
|
||
<p>Lorenzo Martignoni reports that the packages are version 1.3.5a and
|
||
are available at <a
|
||
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>7/27/2002 - Shorewall 1.3.5a Released</b></p>
|
||
<p>This interim release restores correct handling of REDIRECT rules. </p>
|
||
<p><b>7/26/2002 - Shorewall 1.3.5 Released</b></p>
|
||
<p>This will be the last Shorewall release for a while. I'm going to be
|
||
focusing on rewriting a lot of the documentation.</p>
|
||
<p><b> </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" 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>
|
||
<p><font size="2">Updated 11/07/2003 - <a href="support.htm">Tom Eastep</a>
|
||
</font></p>
|
||
<p><a href="copyright.htm"><font size="2"> Copyright</font> <20> <font
|
||
size="2">2001, 2002 Thomas M. Eastep.</font></a><br>
|
||
</p>
|
||
<br>
|
||
</body>
|
||
</html>
|