2006-04-10 23:16:02 +02:00
|
|
|
|
Shorewall 3.2.0 Beta 5
|
2005-11-27 21:59:47 +01:00
|
|
|
|
|
2006-01-07 18:33:10 +01:00
|
|
|
|
Note to users upgrading from Shorewall 2.x or 3.0
|
2005-12-01 18:58:24 +01:00
|
|
|
|
|
|
|
|
|
Most problems associated with upgrades come from two causes:
|
|
|
|
|
|
|
|
|
|
- The user didn't read and follow the migration considerations in these
|
|
|
|
|
release notes.
|
|
|
|
|
|
|
|
|
|
- The user mis-handled the /etc/shorewall/shorewall.conf file during
|
|
|
|
|
upgrade. Shorewall is designed to allow the default behavior of
|
|
|
|
|
the product to evolve over time. To make this possible, the design
|
|
|
|
|
assumes that you will not replace your current shorewall.conf file
|
|
|
|
|
during upgrades. If you feel absolutely compelled to have the latest
|
|
|
|
|
comments and options in your shorewall.conf then you must proceed
|
|
|
|
|
carefully.
|
|
|
|
|
|
2005-12-10 00:49:54 +01:00
|
|
|
|
While you are at it, if you have a file named /etc/shorewall/rfc1918 then
|
|
|
|
|
please check that file. If it has addresses listed that are NOT in one of
|
2006-01-26 00:58:12 +01:00
|
|
|
|
these three ranges, then please rename the file to
|
|
|
|
|
/etc/shorewall/rfc1918.old.
|
2005-12-10 00:49:54 +01:00
|
|
|
|
|
|
|
|
|
10.0.0.0 - 10.255.255.255
|
|
|
|
|
172.16.0.0 - 172.31.255.255
|
|
|
|
|
192.168.0.0 - 192.168.255.255
|
|
|
|
|
|
2005-12-07 17:35:28 +01:00
|
|
|
|
Please see the "Migration Considerations" below for additional upgrade
|
|
|
|
|
information.
|
|
|
|
|
|
2006-04-10 23:16:02 +02:00
|
|
|
|
Problems Corrected in 3.2.0 Beta 5
|
2005-12-10 00:40:22 +01:00
|
|
|
|
|
2006-04-11 00:52:10 +02:00
|
|
|
|
1) On systems such as LEAF Bering that either don't have the 'mktemp' utility
|
2006-04-10 23:16:02 +02:00
|
|
|
|
or whose 'mktemp' cannot create a temporary directory, firewall compilation
|
|
|
|
|
failed with the message:
|
2006-03-24 01:05:09 +01:00
|
|
|
|
|
2006-04-10 23:16:02 +02:00
|
|
|
|
ERROR: No Interfaces Defined
|
2006-04-05 04:08:33 +02:00
|
|
|
|
|
2006-04-10 23:16:02 +02:00
|
|
|
|
after a shell error message indicating that the stripped interfaces
|
|
|
|
|
file in /tmp/shorewall-NNNN/ couldn't be opened.
|
2006-04-05 04:08:33 +02:00
|
|
|
|
|
2006-04-12 22:29:13 +02:00
|
|
|
|
2) With DETECT_DNAT_IPADDRS=No in shorewall.conf, DNAT rules didn't work.
|
|
|
|
|
|
2006-04-13 17:00:42 +02:00
|
|
|
|
3) Previously, if your kernel did not supply the mangle table FORWARD chain
|
|
|
|
|
then "shorewall [re]start" would fail.
|
|
|
|
|
|
2006-04-16 00:40:03 +02:00
|
|
|
|
4) Regardless of the setting of ADD_SNAT_IPADDRS, Shorewall will delete
|
|
|
|
|
the ADDRESS in an SNAT rule (/etc/shorewall/masq) during [re]start.
|
|
|
|
|
|
2006-04-17 21:59:51 +02:00
|
|
|
|
5) Previously, if your kernel did not supply the mangle table FORWARD chain
|
|
|
|
|
then "shorewall [re]start" would fail. Now, if your mangle table does
|
|
|
|
|
not supply this chain, Shorewall will avoid using that either that chain or
|
|
|
|
|
the mangle table POSTROUTING chain. This change is strictly to stop Shorewall
|
|
|
|
|
from blowing up during [re]start on very old kernels (such as 2.4.17
|
|
|
|
|
running on a PS2); if your kernel does not support these chains and you
|
|
|
|
|
try to mark packets in either of them using entries in
|
|
|
|
|
/etc/shorewall/tcrules, [re]start will fail.
|
|
|
|
|
|
2006-04-10 23:16:02 +02:00
|
|
|
|
Other changes in 3.2.0 Beta 5
|
2006-04-05 04:08:33 +02:00
|
|
|
|
|
2006-04-11 00:52:10 +02:00
|
|
|
|
1) The "shorewall refresh" command no longer refreshes traffic shaping.
|
|
|
|
|
Use "shorewall restart" instead if you need to reprocess the
|
|
|
|
|
tcrules, tcdevices and tcclasses files.
|
2006-04-05 04:08:33 +02:00
|
|
|
|
|
2006-04-14 19:10:14 +02:00
|
|
|
|
2) Per a suggestion by Steve Heber, the rtrules file has been renamed
|
|
|
|
|
route_rules.
|
|
|
|
|
|
2006-01-07 18:33:10 +01:00
|
|
|
|
Migration Considerations:
|
2005-12-10 00:40:22 +01:00
|
|
|
|
|
2006-03-24 18:26:56 +01:00
|
|
|
|
1) If you are upgrading from Shorewall 2.x, it is essential that you read
|
|
|
|
|
the Shorewall 3.0.5 release notes:
|
|
|
|
|
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/3.0/shorewall-3.0.5/releasenotes.txt
|
|
|
|
|
|
|
|
|
|
2) A number of macros have been split into two. The macros affected are:
|
2006-02-27 16:54:05 +01:00
|
|
|
|
|
2006-01-30 07:33:16 +01:00
|
|
|
|
IMAP LDAP NNTP POP3 SMTP
|
2006-02-27 16:54:05 +01:00
|
|
|
|
|
2006-01-30 07:33:16 +01:00
|
|
|
|
Each of these macros now handles only traffic on the native (plaintext)
|
|
|
|
|
port. There is a corresponding macro with S added to the end of the
|
|
|
|
|
name for the SSL version of the same protocol. Thus each macro results
|
|
|
|
|
in the insertion of only one port per invocation.
|
|
|
|
|
|
|
|
|
|
The Web macro has not been split, but two new macros, HTTP and HTTPS have
|
|
|
|
|
been created. The Web macro is deprecated in favour of these new macros,
|
|
|
|
|
and may be removed from future Shorewall releases.
|
|
|
|
|
|
|
|
|
|
These changes have been made to ensure no unexpected ports are opened due
|
|
|
|
|
to the use of macros.
|
2005-12-10 00:40:22 +01:00
|
|
|
|
|
2006-03-24 18:26:56 +01:00
|
|
|
|
3) In previous Shorewall releases, DNAT and REDIRECT rules supported a
|
2006-04-18 00:24:18 +02:00
|
|
|
|
special syntax for exclusion of a sub-zone from the effect of the rule.
|
2006-02-02 18:35:28 +01:00
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
Z2 is a subzone of Z1:
|
|
|
|
|
|
|
|
|
|
DNAT Z1!Z2 loc:192.168.1.4 ...
|
|
|
|
|
|
2006-02-27 16:54:05 +01:00
|
|
|
|
That feature has never worked correctly when Z2 is a dynamic zone.
|
2006-02-03 18:08:37 +01:00
|
|
|
|
Furthermore, now that Shorewall supports exclusion lists, the capability
|
2006-02-02 18:35:28 +01:00
|
|
|
|
is redundant since the above rule can now be written in the form:
|
|
|
|
|
|
|
|
|
|
DNAT Z1:!<list of exclusions> loc:192.168.1.4 ...
|
|
|
|
|
|
|
|
|
|
Beginning with Shorewall 3.2.0, the special exclusion syntax will no
|
|
|
|
|
longer be supported.
|
|
|
|
|
|
2006-03-24 18:26:56 +01:00
|
|
|
|
4) Important if you use the QUEUE target.
|
2006-02-12 21:45:57 +01:00
|
|
|
|
|
|
|
|
|
In the /etc/shorewall/rules file and in actions, you may now specify
|
|
|
|
|
'tcpsyn' in the PROTO column. 'tcpsyn' is equivalent to 'tcp' but also
|
|
|
|
|
requires that the SYN flag is set and the RST, FIN and ACK flags be
|
|
|
|
|
off ("--syn" is added to the iptables rule).
|
|
|
|
|
|
|
|
|
|
As part of this change, Shorewall no longer adds the "--syn" option
|
|
|
|
|
to TCP rules that specify QUEUE as their target.
|
|
|
|
|
|
2006-03-24 18:26:56 +01:00
|
|
|
|
5) Extension Scripts may require change
|
2006-03-24 02:01:31 +01:00
|
|
|
|
|
2006-03-24 18:26:56 +01:00
|
|
|
|
In previous releases, extension scripts were executed during [re]start
|
|
|
|
|
by using the Bourne Shell "." operator. In addition to executing commands
|
|
|
|
|
during [re]start, these scripts had to "save" the commands to be executed
|
|
|
|
|
during "shorewall restore".
|
|
|
|
|
|
|
|
|
|
This clumsiness has been eliminated in Shorewall 3.2. In Shorewall 3.2,
|
|
|
|
|
extension scripts are copied in-line into the compiled program and are
|
|
|
|
|
executed in-line during "start", "restart" and "restore".
|
|
|
|
|
|
|
|
|
|
This new approach has two implications for existing scripts.
|
|
|
|
|
|
|
|
|
|
a) It is no longer necessary to save the commands; so functions like
|
|
|
|
|
'save_command', 'run_and_save_command' and 'ensure_and_save_command'
|
|
|
|
|
need no longer be called. The generated program will contain
|
|
|
|
|
functions with these names:
|
|
|
|
|
|
|
|
|
|
save_command() - does nothing
|
|
|
|
|
run_and_save_command() - runs the passed command
|
|
|
|
|
ensure_and_save_command() - runs the passed command and
|
|
|
|
|
stops the firewall if the command
|
|
|
|
|
fails.
|
|
|
|
|
|
|
|
|
|
These functions should provide for transparent migration of
|
|
|
|
|
scripts that use them until you can get around to eliminating
|
|
|
|
|
their use completely.
|
|
|
|
|
|
|
|
|
|
b) When the extension script is copied into the compiled program, it
|
|
|
|
|
is indented to line up with the surrounding code. If you have 'awk'
|
|
|
|
|
installed on your system, the Shorewall compiler will correctly handle
|
|
|
|
|
line continuation (last character on the line = "\"). If you do not
|
|
|
|
|
have awk, it will not be possible to use line-continuation in your
|
|
|
|
|
extension scripts.
|
|
|
|
|
|
|
|
|
|
In no case is it possible to continue a quoted string over multiple lines
|
|
|
|
|
without having additional whitespace inserted into the string.
|
2006-03-24 02:01:31 +01:00
|
|
|
|
|
2006-01-07 18:33:10 +01:00
|
|
|
|
New Features:
|
2005-12-10 00:40:22 +01:00
|
|
|
|
|
2006-02-24 20:04:57 +01:00
|
|
|
|
1) Shorewall has always been very noisy (lots of messages). No longer.
|
2006-02-24 20:00:23 +01:00
|
|
|
|
|
|
|
|
|
You set the default level of verbosity using the VERBOSITY option in
|
|
|
|
|
shorewall.conf. If you don't set it (as would be the case of you use your
|
2006-04-18 00:24:18 +02:00
|
|
|
|
old shorewall.conf file) then VERBOSITY defaults to a value of 2 which
|
|
|
|
|
results in behavior compatible with previous Shorewall versions.
|
|
|
|
|
A value of 1 suppresses some of the output (like the old -q option did)
|
|
|
|
|
while a value of 0 makes Shorewall almost silent. A value of -1
|
|
|
|
|
suppresses all output except warning and error messages.
|
2006-02-24 20:00:23 +01:00
|
|
|
|
|
|
|
|
|
The value specified in the 3.2 shorewall.conf is 1. So you can make
|
|
|
|
|
Shorewall as verbose as previously using a single -v and you can make it
|
|
|
|
|
silent by using a single -q.
|
|
|
|
|
|
|
|
|
|
If the default is set at 2, you can still make a command silent by using
|
|
|
|
|
two "q"s (e.g., shorewall -qq restart).
|
|
|
|
|
|
|
|
|
|
In summary, each "q" subtracts one from VERBOSITY while each "v" adds one
|
|
|
|
|
to VERBOSITY.
|
|
|
|
|
|
|
|
|
|
The "shorewall show log", "shorewall logwatch" and "shorewall dump"
|
|
|
|
|
commands require VERBOSITY to be greater than or equal to 3 to display MAC
|
|
|
|
|
addresses.This is consistent with the previous implementation which
|
|
|
|
|
required a single -v to enable MAC display but means that if you set
|
|
|
|
|
VERBOSITY=0 in shorewall.conf, then you will need to include -vvv in
|
|
|
|
|
commands that display log records in order to have MACs displayed.
|
|
|
|
|
|
2006-04-18 00:24:18 +02:00
|
|
|
|
To make the display of MAC addresses let cumbersome, a '-m' option has
|
|
|
|
|
been added to the "show" and logwatch commands:
|
|
|
|
|
|
|
|
|
|
shorewall show -m log
|
|
|
|
|
shorewall logwatch -m
|
|
|
|
|
|
2006-02-24 20:00:23 +01:00
|
|
|
|
2) A new 'shorewall compile' command has been added.
|
2005-12-10 00:40:22 +01:00
|
|
|
|
|
2006-02-18 05:11:38 +01:00
|
|
|
|
shorewall compile [ -e ] [ -d <distro> ] [ <config directory> ] <script file>
|
2005-12-10 00:40:22 +01:00
|
|
|
|
|
2006-01-07 20:22:58 +01:00
|
|
|
|
where:
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-24 20:00:23 +01:00
|
|
|
|
-e Allows the generated script to run
|
|
|
|
|
on a system without Shorewall installed.
|
|
|
|
|
Generates an error if the configuration uses
|
2006-01-13 00:26:37 +01:00
|
|
|
|
an option that would prevent the generated
|
|
|
|
|
script from running on a system other than
|
2006-02-03 16:10:46 +01:00
|
|
|
|
where the 'compile' command is running (see
|
2006-01-13 00:26:37 +01:00
|
|
|
|
additional consideration a) below).
|
2006-02-04 17:04:07 +01:00
|
|
|
|
-d <distro> Compile the script for execution on the
|
2006-02-03 18:08:37 +01:00
|
|
|
|
distribution specified by <distro>. Currently,
|
2006-03-01 17:46:19 +01:00
|
|
|
|
the supported distributions are:
|
|
|
|
|
|
|
|
|
|
suse
|
|
|
|
|
redhat (which includes Fedora Core and
|
|
|
|
|
CentOS).
|
2006-03-03 00:31:27 +01:00
|
|
|
|
debian
|
2006-02-03 18:08:37 +01:00
|
|
|
|
|
|
|
|
|
Note that specifying a distribution should
|
|
|
|
|
only be required if you intend to install
|
|
|
|
|
the compiled script in /etc/init.d on the
|
2006-03-01 17:46:19 +01:00
|
|
|
|
target system and the target system runs
|
|
|
|
|
a distribution different from the system
|
|
|
|
|
where you are doing your compiles.
|
2006-02-03 18:08:37 +01:00
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
2006-03-01 17:46:19 +01:00
|
|
|
|
shorewall compile -e -d redhat foo
|
2006-02-03 18:08:37 +01:00
|
|
|
|
|
|
|
|
|
Additional distributions are expected to be
|
|
|
|
|
supported shortly.
|
|
|
|
|
|
2006-01-07 18:33:10 +01:00
|
|
|
|
<config directory> Is an optional directory to be searched for
|
|
|
|
|
configuration files prior to those listed
|
2006-01-26 00:58:12 +01:00
|
|
|
|
in CONFIG_DIR in
|
|
|
|
|
/etc/shorewall/shorewall.conf.
|
2006-01-13 18:08:23 +01:00
|
|
|
|
<script file> Is the name of the output file.
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
The 'compile' command processes the configuration and generates a
|
|
|
|
|
script file which may then be executed (either directly or using the
|
2006-01-26 00:58:12 +01:00
|
|
|
|
'shorewall restore' command) to configure the firewall.
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-01-14 19:35:50 +01:00
|
|
|
|
The generated script contains error checking and will terminate if an
|
|
|
|
|
important command fails. Before terminating:
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-01-26 00:58:12 +01:00
|
|
|
|
a) The script will check for the existence of the restore script
|
|
|
|
|
specified by the RESTOREFILE variable in shorewall.conf. If that
|
|
|
|
|
restore script exists, it is executed.
|
2006-01-14 19:35:50 +01:00
|
|
|
|
|
2006-01-26 00:58:12 +01:00
|
|
|
|
b) If the restore script doesn't exist but Shorewall appears to be
|
2006-02-24 20:00:23 +01:00
|
|
|
|
installed on the system, the equivalent of an
|
|
|
|
|
"/sbin/shorewall stop" command is executed.
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-01-07 20:22:58 +01:00
|
|
|
|
Some additional considerations:
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
a) It is possible to run 'compile' on one system and then run the
|
|
|
|
|
generated script on another system but there are certain
|
2006-01-14 02:38:50 +01:00
|
|
|
|
limitations.
|
2006-01-13 00:26:37 +01:00
|
|
|
|
|
2006-02-24 20:00:23 +01:00
|
|
|
|
1) A compatible version of Shorewall must be running on the remote
|
|
|
|
|
system unless you use the "-e" option when you compile the script.
|
2006-02-24 20:28:41 +01:00
|
|
|
|
Currently, "compatible" means Shorewall 3.1.5 or later.
|
2006-01-13 00:26:37 +01:00
|
|
|
|
2) The 'detectnets' interface option is not allowed.
|
2006-02-03 18:08:37 +01:00
|
|
|
|
3) You must supply the file /etc/shorewall/capabilities to provide
|
|
|
|
|
the compiler with knowledge of the capabilities of the system
|
|
|
|
|
where the script is to be run. The /etc/shorewall/capabilities
|
|
|
|
|
file included in this release includes instructions for its
|
2006-02-24 20:00:23 +01:00
|
|
|
|
use. Also, find information below about how to create the
|
|
|
|
|
file using the 'shorecap' program.
|
|
|
|
|
4) If your /etc/shorewall/params file contains code other than simple
|
|
|
|
|
assignment statements with contant values, then you should move
|
|
|
|
|
that code to /etc/shorewall/init. That way, the code will be
|
|
|
|
|
executed on the target system when the compiled script is run rather
|
|
|
|
|
than on the local system at compile time.
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-20 23:28:47 +01:00
|
|
|
|
b) If you run the "shorewall compile" or "shorewall check" commands under
|
2006-02-13 18:57:42 +01:00
|
|
|
|
a user other than 'root', then you must supply
|
|
|
|
|
/etc/shorewall/capabilities.
|
|
|
|
|
|
2006-02-20 23:28:47 +01:00
|
|
|
|
c) To aid in building /etc/shorewall/capabilities, a 'shorecap' program
|
2006-03-03 00:31:27 +01:00
|
|
|
|
is provided. The program is installed in the /usr/share/shorewall/
|
|
|
|
|
directory.
|
2006-02-13 18:57:42 +01:00
|
|
|
|
|
2006-03-03 00:31:27 +01:00
|
|
|
|
The program can be copied to the target system and run there to
|
|
|
|
|
produce a capabilities file taylored for that system. The capabilities
|
2006-02-13 18:57:42 +01:00
|
|
|
|
file can then be copied to the local system where it can be used
|
|
|
|
|
when compiling firewall programs targeted for the remote system.
|
|
|
|
|
|
|
|
|
|
For instructions about running shorecap, see the comments at the
|
|
|
|
|
top of the program file (it's a simple shell script).
|
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
Compilation generates a complete program. This program is suitable for
|
|
|
|
|
installation into /etc/init.d and, when generated with the "-e" option,
|
|
|
|
|
can serve as your firewall on a system that doesn't even have Shorewall
|
|
|
|
|
installed.
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
The generated program supports the following commands:
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
<program> [ -q ] [ -v ] [ -n ] start
|
|
|
|
|
<program> [ -q ] [ -v ] [ -n ] stop
|
|
|
|
|
<program> [ -q ] [ -v ] [ -n ] clear
|
2006-02-03 16:27:54 +01:00
|
|
|
|
<program> [ -q ] [ -v ] [ -n ] restart
|
2006-02-03 16:10:46 +01:00
|
|
|
|
<program> [ -q ] [ -v ] [ -n ] status
|
|
|
|
|
<program> [ -q ] [ -v ] [ -n ] version
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-24 20:00:23 +01:00
|
|
|
|
The options have the same meaning as they do with /sbin/shorewall
|
|
|
|
|
(see above).
|
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
The "shorewall start" and "shorewall restart" commands have been
|
|
|
|
|
rewritten to use compilation. They both compile a temporary program
|
|
|
|
|
then run it. This results in a slightly longer elapsed time than the
|
|
|
|
|
similar commands required under earlier versions of Shorewall but new
|
|
|
|
|
connections are blocked for a much smaller percentage of that time.
|
2005-12-14 17:18:38 +01:00
|
|
|
|
|
2006-02-24 20:00:23 +01:00
|
|
|
|
If an error is found during the compilation phase, /sbin/shorewall
|
|
|
|
|
terminates and the Shorewall state is unchanged.
|
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
Under Shorewall 3.1.5, "shorewall restart" takes roughly 16.5 seconds
|
|
|
|
|
on my firewall:
|
2006-01-07 20:22:58 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
real 0m16.599s
|
|
|
|
|
user 0m6.292s
|
|
|
|
|
sys 0m9.885s
|
|
|
|
|
|
|
|
|
|
Of the elapsed 16.5 seconds, new connections are disabled less than
|
|
|
|
|
3.5 seconds. Here are some numbers for comparison:
|
2006-01-07 20:22:58 +01:00
|
|
|
|
|
2006-01-25 23:33:50 +01:00
|
|
|
|
A) shorewall restart (Shorewall 3.0.4)
|
2006-01-07 20:22:58 +01:00
|
|
|
|
|
|
|
|
|
real 0m17.540s
|
|
|
|
|
user 0m5.956s
|
|
|
|
|
sys 0m10.737s
|
|
|
|
|
|
2006-01-25 23:33:50 +01:00
|
|
|
|
B) ./foo restart # foo created using "shorewall compile"
|
2006-01-07 20:22:58 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
real 0m3.297s
|
|
|
|
|
user 0m1.444s
|
|
|
|
|
sys 0m1.728s
|
2006-01-07 20:22:58 +01:00
|
|
|
|
|
2006-01-25 23:33:50 +01:00
|
|
|
|
C) shorewall restore (Shorewall 3.0.4) # Restores from file generated by
|
|
|
|
|
# "shorewall save"
|
2006-01-07 20:22:58 +01:00
|
|
|
|
|
|
|
|
|
real 0m1.164s
|
|
|
|
|
user 0m0.556s
|
|
|
|
|
sys 0m0.608s
|
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
D) shorewall restore (shorewall 3.1.5)
|
2006-01-25 23:33:50 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
real 0m1.637s
|
|
|
|
|
user 0m0.728s
|
|
|
|
|
sys 0m0.584s
|
2006-01-25 23:33:50 +01:00
|
|
|
|
|
2006-02-03 16:10:46 +01:00
|
|
|
|
The time difference between B and C reflects the difference between
|
|
|
|
|
"iptables-restore" and multiple executions of "iptables". The time
|
|
|
|
|
difference between C and D results from the fact that the "restore"
|
|
|
|
|
command in Shorewall 3.1 runs the compiled program in a way that
|
|
|
|
|
turns all iptables commands into no-ops then invokes
|
|
|
|
|
iptables-restore. The system is a 1.4Ghz Celeron with 512MB RAM.
|
2006-01-26 00:58:12 +01:00
|
|
|
|
|
|
|
|
|
As a final part of this change, the "check" command now compiles the
|
2006-02-24 20:04:57 +01:00
|
|
|
|
current configuration and writes the compiled output to /dev/null. So
|
|
|
|
|
"check" performs all of the same checks that compile does. Note that
|
|
|
|
|
there is still no guarantee that the generated script won't encounter
|
|
|
|
|
run-time errors.
|
2006-02-02 00:43:12 +01:00
|
|
|
|
|
|
|
|
|
2) The /etc/shorewall/maclist file has a new column layout. The first column
|
|
|
|
|
is now DISPOSITION. This column determines what to do with matching
|
|
|
|
|
packets and can have the value ACCEPT or DROP (if MACLIST_TABLE=filter, it
|
|
|
|
|
can also contain REJECT). This change is upward compatible so your existing
|
|
|
|
|
maclist file can still be used.
|
|
|
|
|
|
|
|
|
|
ACCEPT, DROP and REJECT may be optionally followed by a log level to
|
|
|
|
|
cause the packet to be logged.
|
|
|
|
|
|
2006-02-13 18:57:42 +01:00
|
|
|
|
4) In macro files, you can now use the reserved words SOURCE and DEST
|
|
|
|
|
in the columns of the same names. When Shorewall expands the
|
|
|
|
|
macro, it will substitute the SOURCE from the macro invocation for
|
|
|
|
|
SOURCE and the DEST from the invocation for DEST. This allows you
|
|
|
|
|
to write macros that act in both directions (from source to destination
|
|
|
|
|
and from destination to source).
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
macro.FOO:
|
|
|
|
|
|
|
|
|
|
PARAM SOURCE DEST udp 500
|
|
|
|
|
PARAM DEST SOURCE udp 500
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
|
|
|
|
|
|
FOO/ACCEPT fw net
|
|
|
|
|
|
|
|
|
|
Resulting rules:
|
|
|
|
|
|
|
|
|
|
ACCEPT fw net udp 500
|
|
|
|
|
ACCEPT net fw udp 500
|
|
|
|
|
|
|
|
|
|
This new feature has been used to implement the SMBBI macro.
|
|
|
|
|
SMBBI is the same as the SMB macro with the exception that
|
|
|
|
|
it passes SMB traffic in both directions whereas SMB only
|
|
|
|
|
passes that traffic in one direction.
|
|
|
|
|
|
|
|
|
|
5) In the /etc/shorewall/rules file and in actions, you may now specify
|
|
|
|
|
'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also
|
|
|
|
|
requires that the SYN flag is set and the RST, FIN and ACK flags be
|
|
|
|
|
off ("--syn" is added to the iptables rule).
|
|
|
|
|
|
|
|
|
|
As part of this change, Shorewall no longer adds the "--syn" option
|
|
|
|
|
to TCP rules that specify QUEUE as their target.
|
|
|
|
|
|
2006-02-20 23:28:47 +01:00
|
|
|
|
6) /sbin/shorewall now supports a "-t" option that causes all progress
|
|
|
|
|
messages to be timestamped.
|
|
|
|
|
|
|
|
|
|
Example (VERBOSITY=0 in shorewall.conf):
|
|
|
|
|
|
|
|
|
|
gateway:/etc/shorewall # shorewall -t restart
|
|
|
|
|
07:08:51 Compiling...
|
|
|
|
|
07:09:05 Shorewall configuration compiled to /var/lib/shorewall/.restart
|
|
|
|
|
07:09:05 Restarting Shorewall....
|
|
|
|
|
07:09:08 done.
|
|
|
|
|
gateway:/etc/shorewall #
|
2006-03-24 00:26:41 +01:00
|
|
|
|
|
|
|
|
|
7) A 'refreshed' extension script has been added -- it is executed after
|
|
|
|
|
"shorewall refresh" has finished.
|
|
|
|
|
|
|
|
|
|
8) Two new dynamic blacklisting commands have been added:
|
|
|
|
|
|
|
|
|
|
logdrop -- like 'drop' but causes the dropped packets to be logged.
|
|
|
|
|
|
|
|
|
|
logreject -- like 'reject' but causes the rejected packets to be
|
|
|
|
|
logged.
|
|
|
|
|
|
|
|
|
|
Packets are logged at the BLACKLIST_LOGLEVEL if one was specified at the
|
|
|
|
|
last "shorewall [re]start"; otherwise, they are logged at the 'info'
|
|
|
|
|
log level.
|
|
|
|
|
|
2006-03-28 20:14:40 +02:00
|
|
|
|
9) A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When
|
|
|
|
|
this option is set to "Yes", it causes subzones to be treated differently
|
|
|
|
|
with respect to policies.
|
|
|
|
|
|
|
|
|
|
Subzones are defined by following their name with ":" and a list of parent
|
|
|
|
|
zones (in /etc/shorewall/zones). Normally, you want to have a set of
|
|
|
|
|
special rules for the subzone and if a connection doesn't match any of
|
|
|
|
|
those subzone-specific rules then you want the parent zone rules to be
|
|
|
|
|
applied. With IMPLICIT_CONTINUE=Yes, that happens automatically.
|
|
|
|
|
|
|
|
|
|
If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
|
|
|
|
|
subzones are not subject to this special treatment.
|
|
|
|
|
|
|
|
|
|
With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
|
|
|
|
|
by including an explicit policy (one that does not specify "all" in either
|
|
|
|
|
the SOURCE or the DEST columns).
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
|
|
|
|
|
|
par ipv4
|
|
|
|
|
chld:par ipv4
|
|
|
|
|
|
|
|
|
|
Traffic to/from the 'chld' zone will first pass through the applicable
|
|
|
|
|
'chld' rules and if none of those rules match then it will be passed through
|
|
|
|
|
the appropriate 'par' rules. If the connection request does not match
|
|
|
|
|
any of the 'par' rules then the relevant 'par' policy is applied.
|
|
|
|
|
|
|
|
|
|
If you want the fw->chld policy to be ACCEPT, simply add this entry to
|
|
|
|
|
/etc/shorewall/policy:
|
|
|
|
|
|
|
|
|
|
$FW chld ACCEPT
|
|
|
|
|
|
|
|
|
|
Traffic from all other zones to 'chld' will be subject to the implicit
|
|
|
|
|
CONTINUE policy.
|
|
|
|
|
|
2006-04-10 23:16:02 +02:00
|
|
|
|
10) Shorewall now includes support for explicit routing rules when the
|
2006-04-14 19:10:14 +02:00
|
|
|
|
/etc/shorewall/providers file is used. A new file,
|
|
|
|
|
/etc/shorewall/route_rules can be used to add routing rules based on
|
|
|
|
|
packet source and/or destination.
|
2006-04-10 23:16:02 +02:00
|
|
|
|
|
|
|
|
|
The file has the following columns:
|
|
|
|
|
|
|
|
|
|
SOURCE(optonal) An ip address (network or host) that
|
|
|
|
|
matches the source IP address in a packet.
|
|
|
|
|
May also be specified as an interface
|
|
|
|
|
name optionally followed by ":" and an
|
|
|
|
|
address. If the define 'lo' is specified,
|
|
|
|
|
the packet must originate from the firewall
|
|
|
|
|
itself.
|
|
|
|
|
|
|
|
|
|
DEST(optional) An ip address (network or host) that
|
|
|
|
|
matches the destination IP address in a packet.
|
|
|
|
|
|
|
|
|
|
If you choose to omit either SOURCE or DEST,
|
|
|
|
|
place "-" in the column. Note that you
|
|
|
|
|
may not omit both SOURCE and DEST.
|
|
|
|
|
|
|
|
|
|
PROVIDER The provider to route the traffic through.
|
|
|
|
|
May be expressed either as the provider name
|
|
|
|
|
or the provider number.
|
|
|
|
|
|
|
|
|
|
PRIORITY
|
|
|
|
|
The rule's priority which determines the order
|
|
|
|
|
in which the rules are processed.
|
|
|
|
|
|
|
|
|
|
1000-1999 Before Shorewall-generated
|
|
|
|
|
'MARK' rules
|
|
|
|
|
|
|
|
|
|
11000- 11999 After 'MARK' rules but before
|
|
|
|
|
Shorewall-generated rules for
|
|
|
|
|
provider interfaces.
|
|
|
|
|
|
|
|
|
|
26000-26999 After provider interface rules but
|
|
|
|
|
before 'default' rule.
|
|
|
|
|
|
|
|
|
|
Rules with equal priority are applied in
|
|
|
|
|
the order in which they appear in the file.
|
|
|
|
|
|
|
|
|
|
Example: You want all traffic coming in on eth1 to be routed to the ISP1
|
|
|
|
|
provider:
|
|
|
|
|
|
|
|
|
|
#PROVIDER PRIORITY SOURCE DEST
|
|
|
|
|
ISP1 1000 eth1
|
|
|
|
|
|
|
|
|
|
11) Prior to now, it has not been possible to use connection marking in
|
|
|
|
|
/etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
|
|
|
|
|
'track' option.
|
|
|
|
|
|
|
|
|
|
Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
|
|
|
|
|
shorewall.conf to effectively divide the packet mark and connection mark
|
|
|
|
|
into two 8-byte mark fields.
|
|
|
|
|
|
|
|
|
|
When you do this:
|
|
|
|
|
|
|
|
|
|
a) The MARK field in the providers file must have a value that is
|
|
|
|
|
less than 65536 and that is a multiple of 256 (using hex
|
|
|
|
|
representation, the values are 0x0100-0xFF00 with the low-order
|
|
|
|
|
8 bits being zero).
|
|
|
|
|
|
|
|
|
|
b) You may only set those mark values in the PREROUTING chain.
|
|
|
|
|
|
|
|
|
|
c) Marks used for traffic shaping must still be in the range of 1-255
|
|
|
|
|
and may still not be set in the PREROUTING chain.
|
|
|
|
|
|
|
|
|
|
d) When you SAVE or RESTORE in tcrules, only the TC mark value is
|
|
|
|
|
saved or restored. Shorewall handles saving and restoring the
|
|
|
|
|
routing (provider) marks.
|