shorewall_code/STABLE2/releasenotes.txt
teastep b6f49d77ac Shorewall 2.0.2a
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1330 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2004-05-16 17:10:55 +00:00

237 lines
9.3 KiB
Plaintext

Shorewall 2.0.2a
----------------------------------------------------------------------
Problems Corrected since 2.0.1
1) The /etc/init.d/shorewall script installed on Debian by install.sh
failed silently due to a missing file
(/usr/share/shorewall/wait4ifup). That file is not part of the
normal Shorewall distribution and is provided by the Debian
maintainer.
2) A meaningless warning message out of the proxyarp file processing
has been eliminated.
3) The "shorewall delete" command now correctly removes all dynamic
rules pertaining to the host(s) being deleted. Thanks to Stefan
Engel for this correction.
Problems Corrected since 2.0.2
1) The 'firewall' script is not purging temporary restore files in
/var/lib/shorewall. These files have names of the form
"restore-nnnnn".
2) The /var/lib/shorewall/restore script did not load the kernel
modules specified in /etc/shorewall/modules.
-----------------------------------------------------------------------
Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:
1) Extension Scripts
In order for extension scripts to work properly with the new
iptables-save/restore integration (see New Feature 1 below), some
change may be required to your extension scripts.
If your extension scripts are executing commands other than iptables
then those commands must also be written to the restore file (a
temporary file in /var/lib/shorewall that is renamed
/var/lib/shorewall/restore-base at the end of the operation).
The following functions should be of help:
A. save_command() -- saves the passed command to the restore file.
Example:
save_command echo Operation Complete
That command would simply write "echo Operation Complete" to the
restore file.
B. run_and_save_command() -- saves the passed command to the restore
file then executes it. The return value is the exit status of the
command.
Example:
run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"
Note that as in this example, when the command involves file
redirection then the entire command must be enclosed in quotes. This
applies to all of the functions described here.
C. ensure_and_save_command() -- runs the passed command. If the
command fails, the firewall is restored to it's prior saved state
and the operation is terminated. If the command succeeds, the
command is written to the restore file.
2) Dynamic Zone support.
If you don't need to use the "shorewall add" and "shorewall delete"
commands, you should set DYNAMIC_ZONES=No in
/etc/shorewall/shorewall.conf.
New Features:
1) Shorewall has now been integrated with
iptables-save/iptables-restore to provide very fast start and
restart. The elements of this integration are as follows:
a) The 'shorewall save' command now saves the current configuration
in addition to the current dynamic blacklist. If you have
dynamic zones, you will want to issue 'shorewall save' when the
zones are empty or the current contents of the zones will be
restored by the 'shorewall restore' and 'shorewall -f start'
commands.
b) The 'shorewall restore' command has been added. This command
restores the configuration at the time of the last 'save'.
c) The -f (fast) option has been added to 'shorewall start'. When
specified (e.g. 'shorewall -f start'), shorewall will perform a
'shorewall restore' if there is a saved configuration. If there
is no saved configuration, a normal 'shorewall start' is
performed.
d) The /etc/init.d/shorewall script now translates the 'start'
command into 'shorewall -f start' so that fast restart is
possible.
e) When a state-changing command encounters an error and there is a
current saved configuration, that configuration will be restored
(currently, the firewall is placed in the 'stopped' state).
f) If you have previously saved the running configuration and want
Shorewall to discard it, use the 'shorewall forget' command.
WARNING: iptables 1.2.9 is broken with respect to iptables-save;
If your kernel has connection tracking match support, you must
patch iptables 1.2.9 with the iptables patch availale from
the Shorewall errata page.
2) The previous implementation of dynamic zones was difficult to
maintain. I have changed the code to make dynamic zones optional
under the control of the DYNAMIC_ZONES option in
/etc/shorewall/shorewall.conf.
3) In earlier Shorewall 2.0 releases, Shorewall searches in order the
following directories for configuration files.
a) The directory specified in a 'try' command or specified using
the -c option.
b) /etc/shorewall
c) /usr/share/shorewall
In this release, the CONFIG_PATH option is added to shorewall.conf.
CONFIG_PATH contains a list of directory names separated by colons
(":"). If not set or set to a null value (e.g., CONFIG_PATH="") then
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
Now Shorewall searches for shorewall.conf according to the old
rules and for other configuration files as follows:
a) The directory specified in a 'try' command or specified using
the -c option.
b) Each directory in $CONFIG_PATH is searched in sequence.
In case it is not obvious, your CONFIG_PATH should include
/usr/share/shorewall and your shorewall.conf file must be in the
directory specified via -c or in a try command, in /etc/shorewall
or in /usr/share/shorewall.
For distribution packagers, the default CONFIG_PATH is set in
/usr/share/shorewall/configpath. You can customize this file to
have a default that differs from mine.
4) Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL column
would only take effect if the ALL INTERFACES column also contained
Yes or yes. Now, the LOCAL columns contents are treated
independently of the contents of the ALL INTERFACES column.
5) The folks at Mandrake have created yet another kernel module
naming convention (module names end in "ko.gz"). As a consequence,
beginning with this release, if MODULE_SUFFIX isn't specified in
shorewall.conf, then the default value is "o gz ko o.gz ko.gz".
6) An updated bogons file is included in this release.
7) In /etc/shorewall/rules and in action files generated from
/usr/share/shorewall/action.template, rules that perform logging can
specify an optional "log tag". A log tag is a string of alphanumeric
characters and is specified by following the log level with ":" and
the log tag.
Example:
ACCEPT:info:ftp net dmz tcp 21
The log tag is appended to the log prefix generated by the LOGPREFIX
variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will
generate "Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank).
The maximum length of a log prefix supported by iptables is 29
characters; if a larger prefix is generated, Shorewall will issue a
warning message and will truncate the prefix to 29 characters.
8) A new "-q" option has been added to /sbin/shorewall commands. It
causes the start, restart, check and refresh commands to produce
much less output so that warning messages are more visible (when
testing this change, I discovered a bug where a bogus warning
message was being generated).
9) Shorewall now uses 'modprobe' to load kernel modules if that utility
is available in the PATH; otherwise, 'insmod' is used.
10) It is now possible to restrict entries in the /etc/shorewall/masq
file to particular protocols and destination port(s). Two new
columns (PROTO and PORT(S)) have been added to the file.
Example:
You want all outgoing SMTP traffic entering the firewall
on eth1 to be sent from eth0 with source IP address
206.124.146.177. You want all other outgoing traffic
from eth1 to be sent from eth0 with source IP address
206.124.146.176.
eth0 eth1 206.124.146.177 tcp 25
eth0 eth1 206.124.146.176
THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
Assuming that 10.0.0.0/8 is the only host/network connected
to eth1, the progress message at "shorewall start" would be:
Masqueraded Networks and Hosts:
To 0.0.0.0/0 (tcp 25) from 10.0.0.0/8 through eth0 using 206.124.146.177
To 0.0.0.0/0 (all) from 10.0.0.0/8 through eth0 using 206.124.146.176
11) Two new actions are available in the /etc/shorewall/rules file.
ACCEPT+ -- Behaves like ACCEPT with the exception that it exempts
matching connections from subsequent DNAT[-] and
REDIRECT[-] rules.
NONAT -- Exempts matching connections from subsequent DNAT[-]
and REDIRECT[-] rules.
12) A new extension script 'initdone' has been added. This script is invoked
at the same point as the 'common' script was previously and is useful for
users who mis-used that script under Shorewall 1.x (the script was intended
for adding rules to the 'common' chain but many users treated it as a script
for adding rules before Shorewall's).
13) Installing/Upgrading Shorewall on Slackware has been
improved. Slackware users must use the tarball and must modify
settings in the install.sh script before running it as follows:
DEST="/etc/rc.d"
INIT="rc.firewall"
Thanks to Alex Wilms for helping with this change.