forked from extern/shorewall_code
5119e64659
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4617 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
231 lines
8.5 KiB
Plaintext
231 lines
8.5 KiB
Plaintext
Shorewall 3.3.3
|
|
|
|
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.3
|
|
|
|
None.
|
|
|
|
Other changes in 3.3.2
|
|
|
|
1) For users whose kernel and iptables have Extended MARK Target
|
|
support, it is now possible to logically AND or OR a value into the
|
|
current packet mark by preceding the mark value (and optional mask)
|
|
with an ampersand ("&") or vertical bar ("|") respectively.
|
|
|
|
Example: To logically OR the value 4 into the mark value for
|
|
packets from 192.168.1.1:
|
|
|
|
#MARK SOURCE
|
|
|4 192.168.1.1
|
|
|
|
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
|