Mostly bug fixes in this one. The shorewall-lite footprint has become smaller as
a result of splitting the former 'functions' file into two libraries: lib.base
and lib.config. See the release notes for details.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [EMAIL PROTECTED]
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Shorewall 3.3.2
Note to users upgrading from Shorewall 3.0 or 3.2
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.
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
these three ranges, then please rename the file to
/etc/shorewall/rfc1918.old.
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
If you have a file named /etc/shorewall/modules, please remove
it. The default modules file is now located in /usr/share/shorewall/
(see the "Migration Considerations" below).
Please see the "Migration Considerations" below for additional upgrade
information.
Problems Corrected in 3.3.2
1) The 'proxyarp' option in /etc/shorewall/interfaces was not
triggering the loading of lib.proxyarp with the result that the
option was ignored unless there were also entries in
/etc/shorewall/proxyarp.
2) If both /etc/shorewall/tcdevices and /etc/shorewall/tcclasses were
empty then the compiler would fail with:
setup_traffic_shaping: command not found
3) Previously, the directory name in the command "shorewall start
<directory name>" was being dropped by "/sbin/shorewall".
4) Previous, when /usr/share/shorewall/xmodules had been copied to
/etc/shorewall/modules, Shorewall was not looking in the correct
directory for the "xt_..." modules. There are two parts to the fix:
- The /usr/share/shorewall/xmodules file has been removed. The
/usr/share/shorewall/modules file will now load all required
modules regardless of which kernel version you are running.
- The MODULESDIR option can now contain a colon-separated list of
directories to search for modules with the default being:
/lib/modules/$(uname -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname
-r)/kernel/net/netfilter
5) Rules in /etc/shorewall/tos which specify zones defined
using entries in /etc/shorewall/hosts applied to all traffic
to/from the zone interfaces (the bridge port, ipset or IP
address(es) in the zone definition were ignored).
6) Previously, 'shorewall-lite dump' did not report traffic shaping
information even if TC_ENABLED was set to Yes or Internal in the
shorewall.conf file used to compile the exported firewall script.
To correct this problem, the firewall script must be recompiled and
re-exported.
Other changes in 3.3.2
1) /usr/share/shorewall/functions has been renamed
/usr/share/shorewall/lib.base. It remains symbolically linked by
its old name so that existing scripts that source this file will
continue to work.
2) /usr/share/shorewall/lib.base (formerly /etc/shorewall/functions)
has been split into two libraries:
- /usr/share/shorewall/lib.base -- code common to all Shorewall
components. This file is also released as part of Shorewall Lite.
- /usr/share/shorewall/lib.config -- configuration file parsing
code common to /usr/share/shorewall/compiler and
/usr/share/shorewall/firewall.
3) The output of "shorewall show log" and "shorewall logwatch" now
include the name of the log file being accessed.
Migration Considerations:
1) Shorewall supports the notion of "default actions". A default
action defines a set of rules that are applied before a policy is
enforced. Default actions accomplish two goals:
a) Relieve log congestion. Default actions typically include rules
to silently drop or reject traffic that would otherwise be logged
when the policy is enforced.
b) Ensure correct operation. Default actions can also avoid common
pitfalls like dropping connection requests on port TCP port
113. If these connections are dropped (rather than rejected)
then you may encounter problems connecting to internet services
that utilize the AUTH protocol of client authentication.
In prior Shorewall versions, default actions (action.Drop and
action.Reject) were defined for DROP and REJECT policies in
/usr/share/shorewall/actions.std. These could be overridden in
/etc/shorewall/actions.
This approach has two drawbacks:
a) All DROP policies must use the same default action and all
REJECT policies must use the same default action.
b) Now that we have modularized action processing (see the New
Features section below), we need a way to define default rules
for a policy that does not involve actions.
If you have not overridden the defaults using entries in
/etc/shorewall/actions then you need make no changes to migrate to
Shorewall version 3.3. Otherwise, please see item 3) in the New
Features below.
2) The 'Limit' action is now a builtin. If you have 'Limit' listed in
/etc/shorewall/actions, remove the entry. Also remove the files
/etc/shorewall/action.Limit and/or /etc/shorewall/Limit if you have
them.
New Features:
1) In order to accomodate small embedded applications, Shorewall 3.3
is now modularized. In addition to the base files, there are
loadable "libraries" that may be included or omitted from an
embedded system as required.
Loadable Shorewall libraries reside in /usr/share/shorewall/ and
have names that begin with "lib.". The following libraries are
included in Shorewall 3.3:
- lib.accounting. Must be available if you include entries in
/etc/shorewall/accounting.
- lib.actions. Must be available if you do not specify
USE_ACTIONS=No in /etc/shorewall/shorewall.conf.
- lib.dynamiczones. Must be available if you specify
DYNAMIC_ZONES=Yes in shorewall.conf.
- lib.maclist. Must be available if you specify the 'maclist'
option in /etc/shorewall/interfaces or /etc/shorewall/hosts.
- lib.nat. Must be available if you have entries in
/etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap.
- lib.providers. Must be available if you have entries in
/etc/shorewall/providers.
- lib.proxyarp. Must be available if you have entries in
/etc/shorewall/proxyarp or if you specify the 'proxyarp' option
in /etc/shorewall/interfaces.
- lib.tc. Must be available if you have entries in
/etc/shorewall/tcdevices and /etc/shorewall/tcclasses.
- lib.tcrules. Must be available if you have entries in
/etc/shorewall/tcrules.
- lib.tunnels. Must be available if you have entries in
/etc/shorewall/tunnels.
Embedded applications can further decrease the size of the Shorewall
footprint by:
- Omitting the macro files.
- Only including the 'modules' file appropriate for the kernel in
use.
- Omitting all unused extension scripts.
- Stripping the comments (except for copyright) from the various
files.
2) As hinted in the previous bullet, there is a new USE_ACTIONS option
in /etc/shorewall/shorewall.conf. Shorewall actions can be very
powerful but they also require a lot of code to implement. Embedded
applications can omit that code by setting
USE_ACTIONS=No. Shorewall will ignore all action-related files
including /usr/share/shorewall/actions.std and
/etc/shorewall/actions. Builtin actions will still be available for
use in rules and macros.
The 'Limit' action has been converted to a builtin so that Limit is
available even when USE_ACTIONS=No.
See the next item for more information.
3) Prior to Shorewall 3.3, default actions were specified in
/usr/share/shorewall/actions.std or in /etc/shorewall/actions.
This approach has two drawbacks:
a) All DROP policies must use the same default action and all
REJECT policies must use the same default action.
b) Now that we have modularized action processing (see the New
Features section below), we need a way to define default rules
for a policy that does not involve actions.
The solution is two-fold:
- Four new options have been added to the
/etc/shorewall/shorewall.conf file that allow specifying the
default action for DROP, REJECT, ACCEPT and QUEUE.
The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and
QUEUE_DEFAULT.
DROP_DEFAULT describes the rules to be applied before a
connection request is dropped by a DROP policy; REJECT_DEFAULT
describes the rules to be applied if a connection request is
rejected by a REJECT policy. The other two are similar for
ACCEPT and QUEUE policies.
The value assigned to these may be:
a) The name of an action.
b) The name of a macro
c) 'None' or 'none'
The default values are:
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT=none
QUEUE_DEFAULT=none
If USE_ACTIONS=Yes, then these values refer to action.Drop and
action.Reject respectively. If USE_ACTIONS=No, then these values
refer to macro.Drop and macro.Reject.
If you set the value of either option to "None" then no default
action will be used and the default action or macro must be
specified in /etc/shorewall/policy
- The POLICY column in /etc/shorewall/policy has been extended.
In /etc/shorewall/policy, when the POLICY is DROP, REJECT,
ACCEPT or QUEUE then the policy may be followed by ":" and one
of the following:
a) The word "None" or "none". This causes any default
action defined in /etc/shorewall/shorewall.conf
to be omitted for this policy.
b) The name of an action (requires that USE_ACTIONS=Yes
in shorewall.conf). That action will be invoked
before the policy is enforced.
c) The name of a macro. The rules in that macro will
be applied before the policy is enforced. This
does not require USE_ACTIONS=Yes.
Example:
#SOURCE DEST POLICY LOG
# LEVEL
loc net ACCEPT
net all DROP:MyDrop info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT:MyReject info
Shorewall Lite 3.3.2
Problems Corrected in 3.3.2
None.
Other changes in 3.3.2
1) The output of "shorewall show log" and "shorewall logwatch" now
include the name of the log file being accessed.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
