-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In this release:
1) Dynamic Ipsec Zones now work.
2) Output Traffic Accounting by user/group is supported (thanks to
Tuomas Jormola).
3) The following negative test options are added in /etc/shorewall/ipsec
and /etc/shorewall/masq:
reqid!=<number>
spi!=<number>
proto!=esp|ah|ipcomp
mode!=tunnel|transport
tunnel-src!=<address>[/<mask>]
tunnel-dst!=<address>[/<mask>]
4) Source port mapping is now supported in /etc/shorewall/masq.
http://shorewall.net/pub/shorewall/2.1/shorewall-2.1.7
ftp://shorewall.net/pub/shorewall/2.1/shorewall-2.1.7
- -Tom
- --
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBMNAAO/MAbZfjDLIRAilEAJ9b2jpB2wFCRCScHyJ4kNnuo72g1ACfeSwZ
4rUU16OrL7dK1rfAIpVuWwQ=bFja
-----END PGP SIGNATURE-----
-------------- next part --------------
Shorewall 2.1.7
----------------------------------------------------------------------
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
Problems Corrected since 2.1.4
1) Per-interface options like ''norfc1918'' are not applied to
requests
that have been unencrypted as a result of an entry in the SPD.
Problems corrected since 2.1.6
1) Dynamic zones marked as ''ipsec'' in /etc/shorewall/ipsec
now work
correctly.
-----------------------------------------------------------------------
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
3) If shorewall.conf is upgraded to the latest version, it needs to be
modified to set STARTUP_ENABLED=Yes
4) The Leaf/Bering version of Shorewall was previously named:
shorwall-<version>.lrp
Beginning with 2.1, that file will now be named:
shorewall-lrp-<version>.tgz
Simply rename that file to ''shorwall.lrp'' when installing
it on your
LEAF/Bering system.
5) The ORIGINAL DEST column of the /etc/shorewall/rules file may no
longer contain a second (SNAT) address. You must use an entry in
/etc/shorewall/masq instead.
Example from Shorewall FAQ #1:
Prior to Shorewall 2.1:
/etc/shorewall/interfaces
loc eth1 detect routeback,...
/etc/shorewall/rules
DNAT loc loc:192.168.1.12 tcp 80 \
- 130.252.100.69:192.168.1.254
Shorewall 2.1 and Later:
/etc/shorewall/interfaces
loc eth1 detect routeback,...
/etc/shorewall/masq:
eth1 eth1 192.168.1.254 tcp 80
/etc/shorewall/rules:
DNAT loc loc:192.168.1.12 tcp 80 \
- 130.252.100.69
-----------------------------------------------------------------------
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"
6) The /etc/shorewall/startup_disabled file is no longer created when
Shorewall is first installed. Rather, the variable STARTUP_ENABLED
is set to ''No'' in /etc/shorewall/shorewall.conf. In order
to get
Shorewall to start, that variable''s value must be set to
''Yes''. This change accomplishes two things:
a) It prevents Shorewall from being started prematurely by the
user''s initialization scripts.
b) It causes /etc/shorewall/shorewall.conf to be modified so that
it won''t be replaced by upgrades using RPM.
7) Some additional support has been added for the 2.6 Kernel IPSEC
implementation. To use this support, you must have installed the
IPSEC policy match patch from Patch-0-Matic-ng. That patch affects
both your kernel and iptables.
There are two ways to specify that IPSEC is to be used when
communicating with a set of hosts; both methods involve the new
/etc/shorewall/ipsec file:
a) If encrypted communication is used with all hosts in a zone,
then you can designate the zone as an "ipsec" zone by placing
''Yes" in the IPSEC ONLY column in the /etc/shorewall/ipsec:
#ZONE IPSEC OPTIONS
# ONLY
vpn Yes
The hosts in the zone (if any) must be specified in
/etc/shorewall/hosts but you do not need to specify the
''ipsec''
option on the entries in that file (see below).
Dynamic zones involving IPSEC must use that technique.
Example:
Under 2.4 Kernel FreeS/Wan:
/etc/shorewall/zones:
net Net The big bad Internet
vpn VPN Remote Network
/etc/shorewall/interfaces:
net eth0 ...
vpn ipsec0 ...
Under 2.6 Kernel with this new support:
/etc/shorewall/zones:
net Net The big bad Internet
vpn VPN Remote Network
/etc/shorewall/interfaces:
net eth0 ...
/etc/shorewall/hosts:
vpn eth0:0.0.0.0/0
/etc/shorewall/ipsec
vpn Yes
b) If only part of the hosts in a zone require encrypted
communication, you may use of the new ''ipsec'' option in
/etc/shorewall/hosts to designate those hosts.
Example:
Under 2.4 Kernel FreeS/Wan:
/etc/shorewall/zones:
net Net The big bad Internet
loc Local Extended local zone
/etc/shorewall/interfaces:
net eth0 ...
loc eth1 ...
loc ipsec0 ...
Under 2.6 Kernel with this new support:
/etc/shorewall/zones:
net Net The big bad Internet
vpn VPN Remote Network
/etc/shorewall/interfaces:
net eth0 ...
loc eth1 ...
/etc/shorewall/hosts:
vpn eth0:0.0.0.0/0 ipsec,...
Regardless of which technique you choose, you can specify
additional SA options for the zone in the /etc/shorewall/ipsec
entry.
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
input-output, input and output characteristing of the security
policies to be used to decrypt (input) or encrypt (output) traffic
to/from the zone.
The available options are:
reqid[!]=<number> where <number> is specified using setkey(8) using
the ''unique:<number>'' option for the SPD level.
spi[!]=<number> where <number> is the SPI of the SA. Since
different SAs are used to encrypt and decrypt traffic, this
option should only be listed in the IN OPTIONS and OUT OPTIONS
columns.
proto[!]=ah|esp|ipcomp
mode[!]=transport|tunnel
tunnel-src[!]=<address>[/<mask>] (only available with mode=tunnel)
tunnel-dst[!]=<address>[/<mask>] (only available with
mode=tunnel). Because tunnel source and destination are
dependent on the direction of the traffic, these options
should only appear in the IN OPTIONS and OUT OPTIONS columns.
strict (if specified, packets must match all policies;
polcies are delimited by ''next'').
next (only available with strict)
Examples:
#ZONE IPSEC OPTIONS IN OUT
# ONLY OPTIONS OPTIONS
vpn Yes mode=tunnel,proto=esp spi=1000 spi=1001
loc No reqid=44,mode=transport
The /etc/shorewall/masq file has a new IPSEC column added. If you
specify Yes or yes in that column then the unencrypted packets will
have their source address changed. Otherwise, the unencrypted
packets will not have their source addresses changed. This column
may also contain a comma-separated list of the options specified
above in which case only those packets that will be encrypted
by an SA matching the given options will have their source address
changed.
8) To improve interoperability, tunnels of type ''ipsec'' no
longer
enforce the use of source port 500 for ISAKMP.
9) A new ''allowBcast'' builtin action has been added -- it
silently
allows broadcasts and multicasts.
10) The -c option in /sbin/shorewall commands is now deprecated. The
commands where -c was previously allowed now permit you to specify
a configuration directory after the command:
shorewall check [ <configuration-directory> ]
shorewall restart [ <configuration-directory> ]
shorewall start [ <configuration-directory> ]
11) Normally, when SNAT or MASQUERADE is applied to a tcp or udp
connection, Netfilter attempts to retain the source port
number. If it has to change to port number to avoid
<source address>,<source port> conflicts, it tries to do so
within port ranges ( < 512, 512-1023, and > 1023). You may
now specify an explicit range of source ports to be used
by following the address or address range (if any) in the
ADDRESS column with ":" and a port range in the format
<low-port>-<high-port>. You must specify either "tcp"
or
"udp" in the PROTO column.
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:
#INTERFACE SUBNET ADDRESS PROTO
eth0 192.168.1.0/24 :4000-5000 tcp
Example 2 -- SNAT with udp source ports 7000-8000:
#INTERFACE SUBNET ADDRESS PROTO
eth0 10.0.0.0/8 192.0.2.44:7000-8000 udp
12) You may now account by user/group ID for outbound traffic from the
firewall itself with entries in /etc/shorewall/accounting. Such
accounting rules must be placed in the OUTPUT chain.
See the comments at the top of /etc/shorewall/accounting for
details.
