mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-13 01:41:01 +01:00
8f5d49a517
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5637 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
753 lines
30 KiB
Plaintext
753 lines
30 KiB
Plaintext
Shorewall 3.4.2
|
|
|
|
Release Highlights
|
|
|
|
1) Shorewall can now be tailored to reduce its footprint on embedded
|
|
systems. As part of this change, actions are now completely
|
|
optional.
|
|
|
|
See http://www.shorewall.net/Modularization.html for details.
|
|
|
|
2) Exclusion is now possible in /etc/shorewall/hosts. This is required
|
|
for bridge/firewalls under kernel 2.6.20 and later.
|
|
|
|
See http://www.shorewall.net/NewBridge.html.
|
|
|
|
3) Shorewall and Shorewall Lite now include man pages. There is a
|
|
man page for shorewall(8), one for shorewall-lite(8) and one for
|
|
each configuration file. As part of this change, all documentation
|
|
has been removed from Shorewall configuration files. This should
|
|
make it easier from users to upgrade from one release to the next
|
|
since the configuration files will only change when column is added
|
|
or renamed.
|
|
|
|
See http://www.shorewall.net/manpages/Manpages.html
|
|
|
|
4) Shorewall now remembers the changes that it has made to routing as
|
|
a result of entries in /etc/shorewall/providers and
|
|
/etc/shorewall/route_rules and reverses those changes when
|
|
appropriate.
|
|
|
|
Problems corrected in Shorewall 3.4.2
|
|
|
|
1) The /usr/share/shorewall[-lite]/modules file has been updated for
|
|
kernel 2.6.20.
|
|
|
|
2) The /proc/net/ip_conntrack pseudo-file has been inexplicably
|
|
renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
|
|
library has been updated to look for both files.
|
|
|
|
3) Shoreall 3.4 was not consistent with respect to its treatment of
|
|
log level 'none' and 'none!' and built-in actions. In particular,
|
|
specifying 'none' with the Limit action produced a run-time error.
|
|
Shorewall now correctly suppresses generation of log messages when
|
|
a log level of 'none' or 'none!' is given to a built-in action.
|
|
|
|
4) Tunnels of type 'ipsecnat' would sometimes fail to work because of
|
|
a missing rule.
|
|
|
|
Migration Considerations:
|
|
|
|
If you are migrating from a Shorewall version earlier than 3.2.0 then
|
|
please see the 3.2.9 release notes for additional migration
|
|
information.
|
|
|
|
http://www.shorewall.net/pub/shorewall/3.2/shorewall-3.2.9/releasenotes.txt
|
|
|
|
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) Insure correct operation. Default actions can also avoid common
|
|
pitfalls like dropping connection requests on 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.4. 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.
|
|
|
|
3) This issue only applies if you have entries in
|
|
/etc/shorewall/providers.
|
|
|
|
Previously, Shorewall has not attempted to undo the changes it has
|
|
made to the firewall's routing as a result of entries in
|
|
/etc/shorewall/providers and /etc/shorewall/routes. Beginning with
|
|
this release, Shorewall will attempt to undo these changes.
|
|
|
|
See item 15 under new features below for additional information.
|
|
|
|
This change can present a migration issue in that the
|
|
initial routing configuration when this version of Shorewall is
|
|
installed has probably been changed by Shorewall already. Hence,
|
|
when Shorewall restores the original configuration, it will be
|
|
installing a configuration that the previously-installed version
|
|
has already modified.
|
|
|
|
The steps to correcting this after you have installed this version
|
|
of Shorewall are as follows:
|
|
|
|
a) "shorewall[-lite] stop"
|
|
b) Be sure that the files /var/lib/shorewall[-lite]/default_route
|
|
and /var/lib/shorewall[-lite]/undo_routing do not exist. If they
|
|
do exist, remove them.
|
|
b) Either restart networking or reboot.
|
|
|
|
4) This issue only applies if you run Shorewall Lite.
|
|
|
|
The /etc/shorewall-lite/shorewall.conf file has been renamed
|
|
/etc/shorewall-lite/shorewall-lite.conf. When you upgrade,
|
|
your shorewall.conf file will be renamed shorewall-lite.conf.
|
|
|
|
New Features in Shorewall 3.4:
|
|
|
|
1) In order to accomodate small embedded applications, Shorewall 3.4
|
|
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.4:
|
|
|
|
- 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.base. The base Shorewall library required by all programs,
|
|
including compiled firewall scripts. This library is also
|
|
released as part of Shorewall Lite and is installed in
|
|
/usr/share/shorewall-lite/.
|
|
|
|
- lib.cli. Library containing the code common to /sbin/shorewall,
|
|
/sbin/shorewall-lite. This library is also released as part of
|
|
Shorewall Lite and is installed in /usr/share/shorewall-lite/.
|
|
|
|
- lib.config. Library containing the code that is common to
|
|
/usr/share/shorewall/compiler and /usr/share/shorewall/firewall.
|
|
|
|
- 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
|
|
or if you use DNAT or REDIRECT rules.
|
|
|
|
- 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.
|
|
- Omitting all unused extension scripts.
|
|
|
|
See http://www.shorewall.net/Modularization.html for additional
|
|
details.
|
|
|
|
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.4, 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 (if any)
|
|
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
|
|
|
|
4) 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
|
|
|
|
5) Previously, zone names were restricted to five characters in
|
|
length. That limit derives from the --log-prefix in Netfilter log
|
|
messages which must be 29 bytes or less in length. With the
|
|
standard Shorewall LOGFORMAT, that leaves 11 characters for the
|
|
chain name; given that many chain names are of the form
|
|
<zone1>2<zone2>, that gives a maximum zone name length of 5.
|
|
|
|
Beginning with this release, the maximum length of a zone name is
|
|
dependent on the LOGFORMAT (the maximum length may never be less
|
|
than 5 but it may be greater than 5). For example, setting
|
|
LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters.
|
|
|
|
6) Netfilter provides support for attachment of comments to Netfilter
|
|
rules. Comments can be up to 255 bytes in length and are visible
|
|
using the "shorewall show <chain>", "shorewall show nat",
|
|
"shorewall show mangle" and "shorewall dump" commands. Comments are
|
|
delimited by '/* ... */" in the output.
|
|
|
|
Beginning with Shorewall 3.4, you may place COMMENT lines in the
|
|
/etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat
|
|
and /etc/shorewall/masq files and in action files. The remainder of
|
|
the line is treated as a comment and it will be attached as a
|
|
Netfilter comment to the rule(s) generated by succeding entries
|
|
in the file.
|
|
|
|
Note: Do not prefix the comment with "#". Shorewall's two-pass
|
|
compiler strips off "#" comments in the first pass and processes
|
|
COMMENT lines in the second pass. Hence, by the time that COMMENT
|
|
is processed, the "#" and everything following it has been removed
|
|
(see example below).
|
|
|
|
To stop the current comment from being attached to further
|
|
rules, simply include COMMENT on a line by itself (so that the
|
|
following rules will have no comment) or specify a new COMMENT.
|
|
|
|
If you do not have Comment support in your iptables/kernel (see the
|
|
output of "shorewall[-lite] show capabilities") then COMMENTS are
|
|
ignored with this warning:
|
|
|
|
COMMENT ignored -- requires comment support in iptables/Netfilter
|
|
|
|
Example from my rules file:
|
|
|
|
#SOURCE SOURCE DEST PROTO DEST PORT(S)
|
|
|
|
COMMENT Stop Microsoft Noise
|
|
|
|
REJECT loc net tcp 137,445
|
|
REJECT loc net udp 137:139
|
|
|
|
COMMENT # Stop comment from being attached to rules below
|
|
|
|
The output of "shorewall show loc2net" includes (folded):
|
|
|
|
0 0 reject tcp -- * * 0.0.0.0/0
|
|
0.0.0.0/0 multiport dports 137,445 /* Stop Microsoft Noise */
|
|
0 0 reject udp -- * * 0.0.0.0/0
|
|
0.0.0.0/0 udp dpts:137:139 /* Stop Microsoft Noise */
|
|
|
|
7) A new macro (macro.RDP) has been added for Microsoft Remote
|
|
Desktop. This macro was contributed by Tuomo Soini.
|
|
|
|
8) A new 'maclog' extension file has been added. This file is
|
|
processed just before logging based on the setting of
|
|
MACLIST_LOG_LEVEL is done. When the extension is invoked, the CHAIN
|
|
variable will contain the name of the chain where rules should be
|
|
inserted. Remember that if you have specified MACLIST_TABLE=mangle,
|
|
then your run_iptables commands should include "-t mangle".
|
|
|
|
9) The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to
|
|
more accurately describe the contents of the column.
|
|
|
|
10) Previously, it was not possible to use exclusion in
|
|
/etc/shorewall/hosts. Beginning with this release, you may now use
|
|
exclusion lists in entries in this file. Exclusion lists are
|
|
discussed at:
|
|
|
|
http://www.shorewall.net/configuration_file_basics.htm#Exclusion.
|
|
|
|
Example:
|
|
|
|
loc eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28
|
|
|
|
In that example, the 'loc' zone is defined to be the subnet
|
|
192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4
|
|
and hosts in the sub-network 192.168.1.16/28.
|
|
|
|
11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing"
|
|
commands have been added. The first produces the same output as "ip
|
|
addr ls". The second produces a report about your routing rules and
|
|
tables.
|
|
|
|
12) Beginning with this release, Shorewall and Shorewall Lite will
|
|
share common change logs and release notes.
|
|
|
|
13) In Shorewall versions prior to 3.4, multiple jumps to a '2all'
|
|
chain could be generated in succession.
|
|
|
|
Example from an earlier shorewall version:
|
|
|
|
gateway:~ # shorewall-lite show eth2_fwd
|
|
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006
|
|
|
|
Counters reset Thu Oct 19 08:34:47 PDT 2006
|
|
|
|
Chain eth2_fwd (1 references)
|
|
pkts bytes target prot opt in out source destination
|
|
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
|
|
0 0 wifi2all all -- * eth0 0.0.0.0/0 0.0.0.0/0
|
|
0 0 wifi2all all -- * br0 0.0.0.0/0 0.0.0.0/0
|
|
0 0 wifi2all all -- * eth3 0.0.0.0/0 0.0.0.0/0
|
|
0 0 wifi2all all -- * tun+ 0.0.0.0/0 0.0.0.0/0
|
|
gateway:~ #
|
|
|
|
This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.
|
|
|
|
gateway:~ # shorewall-lite show eth2_fwd
|
|
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006
|
|
|
|
Counters reset Thu Oct 19 09:15:19 PDT 2006
|
|
|
|
Chain eth2_fwd (1 references)
|
|
pkts bytes target prot opt in out source destination
|
|
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
|
|
0 0 wifi2all all -- * * 0.0.0.0/0 0.0.0.0/0
|
|
gateway:~ #
|
|
|
|
Note that with OPTIMIZE=1, traffic destined for an
|
|
interface/Address that falls outside of all defined zones may now
|
|
be logged out of a '2all' chain rather than out of the FORWARD
|
|
chain.
|
|
|
|
The OPTIMIZE setting also controls the suppression of redundant
|
|
wildcard rules (those specifying "all" in the SOURCE or DEST
|
|
column). A wildcard rule is considered to be redundant when it
|
|
has the same ACTION and Log Level as the applicable policy.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/policy
|
|
|
|
#SOURCE DEST POLICY LEVEL
|
|
loc net ACCEPT
|
|
|
|
/etc/shorewall/rules
|
|
|
|
#ACTION SOURCE DEST PROTO DEST
|
|
# PORT(S)
|
|
...
|
|
ACCEPT all all icmp 8
|
|
|
|
OPTIMIZE=0
|
|
|
|
gateway:~ # shorewall show loc2net
|
|
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006
|
|
|
|
Counters reset Thu Oct 26 07:54:58 PDT 2006
|
|
|
|
Chain loc2net (1 references)
|
|
pkts bytes target prot opt in out source destination
|
|
...
|
|
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
|
|
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
|
|
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
|
|
|
|
gateway:~
|
|
|
|
OPTIMIZE=1
|
|
|
|
gateway:~ # shorewall show loc2net
|
|
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006
|
|
|
|
Counters reset Thu Oct 26 07:56:38 PDT 2006
|
|
|
|
Chain loc2net (1 references)
|
|
pkts bytes target prot opt in out source destination
|
|
...
|
|
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
|
|
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
|
|
|
|
gateway:~
|
|
|
|
If you really want a rule that duplicates the policy, follow the
|
|
action with "!":
|
|
|
|
#ACTION SOURCE DEST PROTO DEST
|
|
# PORT(S)
|
|
...
|
|
ACCEPT! all all icmp 8
|
|
|
|
14) IP Address ranges are now allowed in the drop, reject, allow and
|
|
logdrop shorewall[-lite] commands.
|
|
|
|
15) Previously, Shorewall has not attempted to undo the changes it has
|
|
made to the firewall's routing as a result of entries in
|
|
/etc/shorewall/providers and /etc/shorewall/routes. Beginning with
|
|
this release, Shorewall will attempt to undo these changes.
|
|
|
|
When Shorewall starts or is restarted and there are entries in
|
|
/etc/shorewall/providers, Shorewall will capture the contents
|
|
of /etc/shorewall/rt_tables and will restore that database when
|
|
Shorewall is stopped or restarted. Similarly, the default route
|
|
will be captured the first time that you [re]start Shorewall using
|
|
this version and will be restored under the following conditions:
|
|
|
|
a) shorewall stop
|
|
b) shorewall clear
|
|
c) shorewall restart or restore and there are no entries in
|
|
/etc/shorewall/providers.
|
|
|
|
Once the default route has been restored, Shorewall will delete
|
|
the saved copy so that it will once again be captured at the next
|
|
shorewall start or shorewall restore.
|
|
|
|
16) Shorewall no longer includes policy matches in its generated
|
|
ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC
|
|
networks are defined using the 'ipsec' option in
|
|
/etc/shorewall/hosts).
|
|
|
|
17) The Makefile installed in /usr/share/shorewall/configfiles/ is now
|
|
the same one mentioned at
|
|
http://www.shorewall.net/CompiledPrograms.html.
|
|
|
|
Once the file is copied into an export directory, you modify the
|
|
setting of the HOST variable to match the name of the remote
|
|
firewall.
|
|
|
|
The default target is the "firewall" script so "make" compiles the
|
|
firewall script if any of the configuration files have
|
|
changed. "make install" builds "firewall" if necessary then
|
|
installs it on the remote firewall. "make capabilities" will
|
|
generate the "capabilities" file. "make save" will save the running
|
|
configuration on the remote firewall.
|
|
|
|
18) Shorewall and Shorewall Lite now include the following manpages.
|
|
|
|
shorewall-accounting(5)
|
|
shorewall-actions(5)
|
|
shorewall-blacklist(5)
|
|
shorewall.conf(5)
|
|
shorewall-ecn(5)
|
|
shorewall-exclusion(5)
|
|
shorewall-hosts(5)
|
|
shorewall-interfaces(5)
|
|
shorewall-lite.conf(5)
|
|
shorewall-lite(8)
|
|
shorewall-maclist(5)
|
|
shorewall-masq(5)
|
|
shorewall-nat(5)
|
|
shorewall-nesting(5)
|
|
shorewall-netmap(5)
|
|
shorewall-params(5)
|
|
shorewall-policy(5)
|
|
shorewall-providers(5)
|
|
shorewall-proxyarp(5)
|
|
shorewall-rfc1918(5)
|
|
shorewall-route_rules(5)
|
|
shorewall-routestopped(5)
|
|
shorewall-rules(5)
|
|
shorewall-tcclasses(5)
|
|
shorewall-tcdevices(5)
|
|
shorewall-tcrules(5)
|
|
shorewall-template(5)
|
|
shorewall-tos(5)
|
|
shorewall-tunnels(5)
|
|
shorewall(8)
|
|
shorewall-zones(5)
|
|
|
|
Now that the manpages are in place, command-specific help has been
|
|
removed since it duplicates information in the man pages.
|
|
|
|
19) From the beginning, the Shorewall configuration files in
|
|
/etc/shorewall/ have contained documentary comments. While these
|
|
comments are useful, they present an upgrade problem. Beginning
|
|
with this release, these comments are removed from the
|
|
configuration files themselves and are replaced by the manpages
|
|
described in the preceding release note entry.
|
|
|
|
20) Shorewall now uses tc fwmark filters to classify packets for
|
|
traffic shaping when the DEVICE isn't an interface described in
|
|
/etc/shorewall/interfaces. This is in preparation for the upcoming
|
|
change to the way that --physdev-out works in iptables/Netfilter;
|
|
that change is now scheduled for kernel 2.6.20.
|
|
|
|
21) If your kernel and iptables have extended multiport support, then
|
|
Shorewall will use that support for the destination port when
|
|
generating rules from entries in the /etc/shorewall/tcrules file.
|
|
|
|
22) The 'safe-start' and 'safe-restart' command have been
|
|
improved. Both now accept an optional directory name; if supplied,
|
|
Shorewall will look first in that directory for configuration
|
|
files.
|
|
|
|
The commands have also been enhanced to only restore the
|
|
configuration once in the event of a failure. Previously, if there
|
|
was a current 'save' command in effect, then that configuration
|
|
would be restored on a failure and then the last-running
|
|
configuration would be restored.
|
|
|
|
23) The 'try' command has been reimplemented with new semantics.
|
|
|
|
If Shorewall is started then the firewall state is saved to a
|
|
temporary saved configuration (/var/lib/shorewall/.try). Next, if
|
|
Shorewall is currently started then a restart command is issued;
|
|
otherwise, a start command is performed. if an error occurs during
|
|
the compliation phase of the restart or start, the command
|
|
terminates without changing the Shorewall state. If an error occurs
|
|
during the restart phase, then a 'shorewall restore' is performed
|
|
using the saved configuration. If an error occurs during the start
|
|
phase, then Shorewall is cleared. If the start/restart succeeds
|
|
and a timeout is specified then a 'clear' or 'restore' is performed
|
|
after timeout seconds.
|
|
|
|
24) The syntax of the 'export' command has been made slightly
|
|
friendlier.
|
|
|
|
The old syntax:
|
|
|
|
export <directory1> [user@]system:[<directory2>]
|
|
|
|
It is now:
|
|
|
|
export <directory1> [user@]system[:<directory2>]
|
|
|
|
In other words, if you don't need to specify <directory2>, you may
|
|
omit the colon (":") following the system name.
|
|
|
|
The old syntax is still accepted -- that is, you can still
|
|
type:
|
|
|
|
export firewall2:
|
|
|
|
which is equivalent to
|
|
|
|
export firewall2
|
|
|
|
25) Shorewall commands may be speeded up slightly by using a
|
|
'capabilities' file. The 'capabilities' file was originally
|
|
designed for use with Shorewall Lite and records the
|
|
iptables/Netfilter features available on the target system.
|
|
|
|
To generate a capabilities file, execute the following command as
|
|
root:
|
|
|
|
shorewall show -f capabilities > /etc/shorewall/capabilities
|
|
|
|
When you install a new kernel and/or iptables, be sure to generate
|
|
a new capabilities file.
|
|
|
|
26) When syslogd is run with the -C option (which in some
|
|
implementations causes syslogd to log to an in-memory circular
|
|
buffer), /sbin/shorewall will now use the 'logread' command to read
|
|
the log from that buffer. This is for combatibility with OpenWRT.
|
|
|
|
27) There is now a ":T" qualifier in /etc/shorewall/tcrules which
|
|
causes the resulting rule to be inserted into the POSTROUTING
|
|
chain.
|
|
|
|
28) The program /usr/share/shorewall/wait4ifup can be used to wait for
|
|
a network device (such as a ppp device) to reach the UP state.
|
|
|
|
/usr/share/shorewall/wait4ifup <interface> [ <seconds> ]
|
|
|
|
The program will wait for up to <seconds> seconds for the
|
|
named <interface> to reach the UP state. If <seconds> is not given,
|
|
60 seconds is assumed.
|
|
|
|
The exit status is zero if <interface> comes up within <seconds>
|
|
seconds and non-zero otherwise.
|
|
|
|
29) Previously, 'ipsecnat' tunnels allowed AH traffic by default
|
|
(unless 'isecnat:noah' was given). Given that AH is incompatible
|
|
with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.
|
|
|
|
30) Shorewall now generates half as many rules as previously in the
|
|
'blacklst' chain when BLACKLIST_LOGLEVEL is specified.
|
|
|
|
31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in
|
|
shorewall.conf then Shorewall will not process
|
|
/etc/shorewall/params when the compiled script is run. With
|
|
EXPORTPARAMS=No, any shell variables needed at run-time must be set
|
|
in /etc/shorewall/init.
|
|
|
|
In a Shorewall/Shorewall Lite environment, this allows
|
|
/etc/shorewall/params to be written to run exclusively
|
|
on the administrative system while /etc/shorewall/init runs
|
|
exclusively on the firewall system.
|
|
|
|
So shell variables required at compile time may be set in
|
|
/etc/shorewall/params and those required at run-time may be set in
|
|
/etc/shorewall/init.
|
|
|
|
Note 1: If you need shell variables values in your
|
|
/etc/shorewall/stop or /etc/shorewall/stopped script, then you need
|
|
to set their values in /etc/shorewall/stop. /etc/shorewall/init is
|
|
not invoked during processing of the 'stop' and 'clear' commands.
|
|
|
|
Note 2: EXPORTPARAMS was actually introduced in Shorewall version
|
|
3.2.9. It is described here for the benefit of those who did not
|
|
install that version.
|
|
|
|
Problems Corrected in 3.4.1
|
|
|
|
1) The "shorewall-[lite] [re]start and stop" commands reset the
|
|
proxy_arp flag on all interfaces on the system making it impossible
|
|
to control proxy arp manually with Shorewall installed. There was a
|
|
partial fix included in 3.4.0; unfortunately, it did not correct the
|
|
problem completely. Shorewall 3.4.1 includes the rest of the change
|
|
necessarey to only clear proxy arp if there were entries in
|
|
/etc/shorewall/proxyarp the last time that Shorewall was
|
|
[re]started.
|
|
|
|
2) If the log-prefix in a log message exceeded 29 characters,
|
|
'shorewall restart' fails with 'truncate: command not found' and a
|
|
possible segmentation fault in iptables.
|
|
|
|
3) Log messages specifying a log tag had two spaces appended to the
|
|
log prefix. This could cause mysterious "log-prefix truncated"
|
|
messages.
|
|
|
|
4) When nested zones were defined in the /etc/shorewall/zones file and
|
|
IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,
|
|
shell error messages ( usually '<zone>: not found' ) during
|
|
compilation resulted.
|
|
|
|
5) Use of CONTINUE policies lead to startup errors with a message
|
|
such as the following:
|
|
|
|
Applying Policies...
|
|
iptables v1.3.7: Couldn't load target
|
|
`CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open
|
|
shared object file: No such file or directory
|
|
|
|
Try `iptables -h' or 'iptables --help' for more information.
|
|
|
|
ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"
|
|
Failed
|
|
|
|
6) If there were hosts defined as 'critical' in
|
|
/etc/shorewall/routestopped then problems occured in two cases:
|
|
|
|
i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall
|
|
clear' was issued.
|
|
|
|
ii) On Shorewall or Shorewall lite system when 'start' or 'restart'
|
|
failed during execution of the compiled script and there was no saved
|
|
configuration ('shorewall[-lite] save' has not been issued).
|
|
|
|
The symptoms were that the following shell messages were issued and
|
|
the 'critical' hosts were not enabled:
|
|
|
|
/var/lib/shorewall/.start: line nnn: source_ip_range: command not found
|
|
/var/lib/shorewall/.start: line nnm: dest_ip_range: command not found
|
|
|
|
Other changes in 3.4.1
|
|
|
|
1) Several changes are included which allow testing of experimental
|
|
versions of Shorewall on systems with 3.4.1 and later 3.4 releases
|
|
installed. Among these changes is the detection and reporting of
|
|
"Address Type Match" which may be used in future 3.4 releases.
|
|
These changes have no effect on normal Shorewall operation.
|
|
|