forked from extern/shorewall_code
f82055bca8
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1502 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
164 lines
4.8 KiB
Plaintext
Executable File
164 lines
4.8 KiB
Plaintext
Executable File
Shorewall 2.1.0
|
|
|
|
----------------------------------------------------------------------
|
|
Problems Corrected since 2.0.3
|
|
|
|
1) A non-empty DEST entry in /etc/shorewall/tcrules will generate an
|
|
error and Shorewall fails to start.
|
|
|
|
2) A potential security vulnerablilty in the way that Shorewall
|
|
handles temporary files and directories has been corrected.
|
|
|
|
3) Two problems with logging NAT rules (DNAT and REDIRECT) could cause
|
|
startup failures.
|
|
|
|
4) Some users have reported the pkttype match option in iptables/
|
|
Netfilter failing to match certain broadcast packets. The result
|
|
is that the firewall log shows a lot of broadcast packets.
|
|
|
|
Users experiencing this problem can use PKTTYPE=No in
|
|
shorewall.conf to cause Shorewall to use IP address filtering of
|
|
broadcasts rather than packet type.
|
|
|
|
Problems Corrected since 2.1.0
|
|
|
|
1) The "check" command fails with the following message:
|
|
|
|
iptables: No chain/target/match by that name
|
|
|
|
-----------------------------------------------------------------------
|
|
Issues when migrating from Shorewall 2.0 to Shorewall 2.1:
|
|
|
|
1) Shorewall configuration files except shorewall.conf are now empty
|
|
(they contain only comments). If you wish to retain the defaults
|
|
in any of the following files, you should copy these files before
|
|
upgrading them then restore them after the upgrade:
|
|
|
|
/etc/shorewall/zones
|
|
/etc/shorewall/policy
|
|
/etc/shorewall/tos
|
|
|
|
2) The following builtin actions have been removed and have been
|
|
replaced by the new action logging implementation described in the
|
|
new features below.
|
|
|
|
logNotSyn
|
|
rLogNotSyn
|
|
dLogNotSyn
|
|
|
|
-----------------------------------------------------------------------
|
|
New Features:
|
|
|
|
1) ICMP packets that are in the INVALID state are now dropped by the
|
|
Reject and Drop default actions. They do so using the new
|
|
'dropInvalid' builtin action.
|
|
|
|
2) The /etc/shorewall/masq file INTERFACE column now allows additional
|
|
options.
|
|
|
|
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT
|
|
rules defined in the /etc/shorewall/nat file. If you preceed the
|
|
interface name with a plus sign ("+") then the rule will be
|
|
evaluated before one-to-one NAT.
|
|
|
|
Examples:
|
|
|
|
+eth0
|
|
+eth1:192.0.2.32/27
|
|
|
|
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an
|
|
entry by following the interface name by ":" but no digit.
|
|
|
|
Examples:
|
|
|
|
eth0:
|
|
eth1::192.0.2.32/27
|
|
+eth3:
|
|
|
|
3) Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
|
|
you to override the setting of ADD_IP_ALIASES=Yes by following the
|
|
interface name with ":" but no digit.
|
|
|
|
4) All configuration files in the Shorewall distribution with the
|
|
exception of shorewall.conf are now empty. In particular, the
|
|
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
|
|
files now have no active entries. Hopefully this will stop the
|
|
questions on the support and development lists regarding why the
|
|
default entries are the way they are.
|
|
|
|
5) Previously, specifying a log level (and optionally a log tag) on a
|
|
rule that specified a user-defined (or Shorewall-defined) action
|
|
would log all traffic passed to the action. Beginning with this
|
|
release, specifying a log level in a rule that specifies a user-
|
|
or Shorewall-defined action will cause each rule in the action to
|
|
be logged with the specified level (and tag).
|
|
|
|
The extent to which logging of action rules occurs is goverend by
|
|
the following:
|
|
|
|
a) When you invoke an action and specify a log level, only those
|
|
rules in the action that have no log level will be changed to log
|
|
at the level specified at the action invocation.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/action.foo:
|
|
|
|
ACCEPT - - tcp 22
|
|
bar:info
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
foo:debug fw net
|
|
|
|
Logging in the invoke 'foo' action will be:
|
|
|
|
ACCEPT:debug - - tcp 22
|
|
bar:info
|
|
|
|
b) If you follow the log level with "!" then logging will
|
|
be at that level for all rules recursively invoked by the action
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/action.foo:
|
|
|
|
ACCEPT - - tcp 22
|
|
bar:info
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
foo:debug! fw net
|
|
|
|
Logging in the invoke 'foo' action will be:
|
|
|
|
ACCEPT:debug - - tcp 22
|
|
bar:debug!
|
|
|
|
This change has an effect on extension scripts used with
|
|
user-defined actions. If you define an action 'acton' and you have
|
|
a /etc/shorewall/acton script then when that script is invoked,
|
|
the following three variables will be set for use by the script:
|
|
|
|
$CHAIN = the name of the chain where your rules are to be
|
|
placed. When logging is used on an action invocation,
|
|
Shorewall creates a chain with a slightly different name from
|
|
the action itself.
|
|
|
|
$LEVEL = Log level. If empty, no logging was specified.
|
|
|
|
$TAG = Log Tag.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
acton:info:test
|
|
|
|
Your /etc/shorewall/acton file will be run with:
|
|
|
|
$CHAIN="acton1"
|
|
$LEVEL="info"
|
|
$TAG="test"
|
|
|