The Shorewall team is pleased to announce the availability of Shorewall 4.4.13.
----------------------------------------------------------------------------
I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
----------------------------------------------------------------------------
1) Under rare circumstances where COMMENT is used to attach comments
to rules, OPTIMIZE 8 through 15 could result in invalid
iptables-restore (ip6tables-restore) input.
2) Under rare circumstances involving exclusion, OPTIMIZE 8 through 15
could result in invalid iptables-restore (ip6tables-restore) input.
3) The change in 4.4.12 to detect and use the new ipset match syntax
broke the ability to detect the old ipset match capability. Now,
both versions of the capability can be correctly detected.
4) Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail
if the last optional interface tested was not available.
5) Exclusion in the blacklist file was correctly validated but was then
ignored when generating iptables (ip6tables) rules.
6) Previously, non-trivial exclusion (more than one excluded
address/net) in CONTINUE, NONAT and ACCEPT+ rules generated
valid but incorrect iptables input. This has been corrected but
requires that your iptables/kernel support marking rules in any
Netfilter table (CONTINUE in the tcrules file does not require this
support).
This fix implements a new 'Mark in any table' capability; those
who utilize a capabilities file should re-generate the file using
this release.
7) Interface handling has been extensively modified in this release
to correct a number of problems with the earlier
implementation. Among those problems:
- Invalid shell variable names could be generated in the firewall
script. The generated firewall script uses shell variables to
track the availability of optional and required interfaces and
to record detected gateways, detected addresses, etc.
- The same shell variable name could be generated by two different
interface names.
- Entries in the interfaces file with a wildcard physical name
(physical name ends with "+") and with the 'optional' option were
handled strangely.
o If there were references to specific interfaces that matched
the wildcard, those entries were handled as if they had been
defined as optional in the interfaces file.
o If there were no references matching the wildcard, then the
'optional' option was effectively ignored.
The new implementation:
- Insures valid shell variable names.
- Insures that shell variable names are unique.
- Handles interface names appearing in the INTERFACE column of the
providers file as a special case for 'optional'. If the name
matches a wildcard entry in the interfaces file then the
usability of the specific interface is tracked individually.
- Handles the availabilty of other interfaces matching a wildcard
as a group; if there is one useable interface in the group then
the wildcard itself is considered usable.
The following example illustrates this use case:
/etc/shorewall/interfaces
net ppp+ - optional
/etc/shorewall/shorewall.conf
REQUIRE_INTERFACE=Yes
If there is any usable PPP interface then the firewall will be
allowed to start. Previously, the firewall would never be allowed
to start.
8) When a comma-separated list of 'src' and/or 'dst' was specified in
an ipset invocation (e.g., "+fooset[src,src]), all but the first 'src'
or 'dst' was previously ignored when generating the resulting
iptables rule.
9) Beginning with Shorewall 4.4.9, the SAME target in tcrules has
generated invalid iptables (ip6tables) input. That target now
generates correct input.
10) Ipsets associated with 'dynamic' zones were being created during
'restart' but not during 'start'.
11) To work around an issue in Netfilter/iptables, Shorewall now uses
state match rather than conntrack match for UNTRACKED state
matching.
12) If the routestopped files contains NOTRACK rules, 'shorewall* clear'
did not clear the raw table.
13) An error message was incorrectly generated if a port range of the
form :<port> (e.g., :22) appeared.
14) An error is now generated if '*' appears in an interface name.
----------------------------------------------------------------------------
I I. K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
1) On systems running Upstart, shorewall-init cannot reliably start the
firewall before interfaces are brought up.
----------------------------------------------------------------------------
I I I. N E W F E A T U R E S I N T H I S R E L E A S E
----------------------------------------------------------------------------
1) Entries in the rules file (both Shorewall and Shorewall6) may now
contain zone lists in the SOURCE and DEST column. A zone list is a
comma-separated list of zone names where each name appears in the
zones file. A zone list may be optionally followed by a plus sign
("+") to indicate that the rule should apply to intra-zone traffic
as well as to inter-zone traffic.
Zone lists behave like 'all' and 'any' with respect to Optimization
1. If the rule matches the applicable policy for a given (source
zone, dest zone), then the rule will be suppessed for that pair of
zones unless overridden by the '!' suffix on the target in the
ACTION column (e.g., ACCEPT!, DROP!:info, etc.).
Additionally, 'any', 'all' and zone lists may be qualified in the
same way as a single zone.
Examples:
fw,dmz:90.90.191.120/29
all:+blacklist
The 'all' and 'any' keywords now support exclusion in the form of a
comma-separated list of excluded zones.
Examples:
all!fw (same as all-).
any+!dmz,loc (All zones except 'dmz' and 'loc' and
include intra-zone rules).
2) An IPSEC column has been added to the accounting file, allowing you
to segregate IPSEC traffic from non-IPSEC traffic. See 'man
shorewall-accounting' (man shorewall6-accounting) for details.
With this change, there are now three trees of accounting chains:
- The one rooted in the 'accounting' chain.
- The one rooted in the 'accipsecin' chain. This tree handles
traffic that has been decrypted on the firewall. Rules in this
tree cannot specify an interface name in the DEST column.
- The one rooted in the 'accipsecout' chain. This tree handles
traffic that will be encrypted on the firewall. Rules in this
tree cannot specify an interface name in the SOURCE column.
In reality, when there are bridges defined in the configuration,
there is a fourth tree rooted in the 'accountout' chain. That chain
handles traffic that originates on the firewall (both IPSEC and
non-IPSEC).
This change also implements a couple of new warnings:
- WARNING: Adding rule to unreferenced accounting chain <name>
The first reference to user-defined accounting chain <name> is
not a JUMP or COUNT from an already-defined chain.
- WARNING: Accounting chain <name> has o references
The named chain contains accounting rules but no JUMP or COUNT
specifies that chain as the target.
3) Shorewall now supports the SECMARK and CONNSECMARK targets for
manipulating the SELinux context of packets.
See the shorewall-secmarks and shorewall6-secmarks manpages for
details.
As part of this change, the tcrules file now accepts $FW in the
DEST column for marking packets in the INPUT chain.
4) Blacklisting has undergone considerable change in Shorewall 4.4.13.
a) Blacklisting is now based on zones rather than on interfaces and
host groups.
b) Near compatibility with earlier releases is maintained.
c) The keywords 'src' and 'dst' are now preferred in the OPTIONS
column in /etc/shoreawll/blacklist, replacing 'from' and 'to'
respectively. The old keywords are still supported.
d) The 'blacklist' keyword may now appear in the OPTIONS,
IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones.
i) In the IN_OPTIONS column, it indicates that packets received
on the interface are checked against the 'src' entries in
/etc/shorewall/blacklist.
ii) In the OUT_OPTIONS column, it indicates that packets being
sent to the interface are checked against the 'dst' entries.
iii) Placing 'blacklist' in the OPTIONS column is equivalent to
placing in in both the IN_OPTIONS and OUT_OPTIONS columns.
e) The 'blacklist' option in the OPTIONS column of
/etc/shorewall/interfaces or /etc/shorewall/hosts is now
equivalent to placing it in the IN_OPTIONS column of the
associates record in /etc/shorewall/zones. If no zone is given
in the ZONE column of /etc/shorewall/interfaces, the 'blacklist'
option is ignored with a warning (it was previously ignored
silently).
f) The 'blacklist' option in the /etc/shorewall/interfaces and
/etc/shorewall/hosts files is now deprecated but will continue
to be supported for several releases. A warning will be added at
least one release before support is removed.
5) There is now an OUT-BANDWIDTH column in
/etc/shorewall/tcinterfaces.
The format of this column is:
<rate>[:[<burst>][:[<latency>][:[<peak>][:[<minburst>]]]]]
These terms are described in tc-tbf(8). Shorewall supplies default
values as follows:
<burst> = 10kb
<latency> = 200ms
The remaining options are defaulted by tc.
6) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
/etc/shorewall/tcinterfaces now accepts an optional burst parameter.
<rate>[:<burst>]
The default <burst> is 10kb. A larger <burst> can help make the
<rate> more accurate; often for fast lines, the enforced rate is
well below the specified <rate>.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
