mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-15 19:01:19 +01:00
6aecd73c4b
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4565 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
273 lines
10 KiB
Plaintext
273 lines
10 KiB
Plaintext
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
|