The Shorewall team is pleased to announce the availability of Shorewall
4.4.26.
----------------------------------------------------------------------------
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) This release includes all corrections included in 4.4.25.1 through
.3.
2) In 4.4.25, ACCEPT behaved in the BLACKLIST section the same way as
in the other rules file sections. This could lead to connections
being accepted inadvertently.
Now, ACCEPT behaves like WHITELIST; that is, it exempts the packet
from the remaining rules in the BLACKLIST section.
3) Previously, Shorewall did not detect the ULOG and NFLOG
capabilities. This lead to run-time failures during
''start'' and
''restart'' as well as confusing error messages during
compilation
when ULOG or NFLOG was used when the LOG target was not available.
ULOG and NFLOG are now detected capabilities so, if you use a
capabilities file, you will need to regenerate it in order to use
these log levels.
4) The SAME tcrules target was broken in Shorewall 4.4.22. It now
works correctly again.
5) Previously, ''shorewall6 update'' did not update
shorewall6.conf. The
command now works as expected.
6) In earlier releases, the compiler was attempting to process the
params file before it was aware of the setting of CONFIG_PATH. This
could cause the params file to be missed if it was not located in
/etc/shorewall[6] or in the directory named in the start
(restart,compile,check,...) command.
Now, /sbin/shorewall[6] passes $CONFIG_PATH to the compiler
(/usr/share/shorewall/compiler.pl) in the new
''--config_path''
option.
----------------------------------------------------------------------------
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 secure
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) A new ''blrules'' file has been added as an alternative to
rules in
the BLACKLIST section of the rules file. When rules are present in
both the blrules file and in the BLACKLIST section, those in
blrules are processed first.
2) A ''-b'' option has been added to the
''update'' command. In addition
to updating the shorewall.conf file (shorewall6.conf), this option
causes the compiler to convert your current legacy blacklist
configuration to use the new blrules file.
Changes include:
a) blrules is populated with entries equivalent to your existing
blacklist file.
b) Your existing blacklist file is renamed blacklist.bak.
c) The ''blacklist'' keyword is removed from your zones,
interfaces
and hosts files. When one of these files is modified, the
unmodified original is saved in a .bak file.
As part of this change, the ''blacklog'' target is permitted
in the
blrules file when BLACKLIST_LOG_LEVEL is specified in
shorewall.conf (shorewall6.conf). It logs the packet at the
specified level, then disposes of it based on the setting of
BLACKLIST_DISPOSITION.
3) The Debian init files (with the exception of Shorewall-init) now
support the ''status'' command.
4) This release formalizes the feature that has long been
documented at http://www.shorewall.net/PacketMarking.html#Values.
The WIDE_TC_MARKS and HIGH_ROUTE_MARKS options have traditionally
been used to define the various fields in a packet/connection mark.
But more flexible control is provided using these options.
TC_BITS
The number of bits at the least-significant end of the mark
to be used for traffic shaping marking. May be zero.
PROVIDER_BITS
The number of bits in the mark to be used for provider
marks. May be zero.
PROVIDER_OFFSET
The offset from the right (low-order end) of the provider
number field. If non-zero, must be >= TC_BITS. Shorewall
automatically adjusts PROVIDER OFFSETs value to inforce this
restriction. May be zero, in which case the TC mark field
and Provider mark field overlay.
MASK_BITS
The number of low-order bits to be masked when clearing the
traffic shaping mark. Must be >= TC_BITS and <
PROVIDER_OFFSET (provider that PROVIDER_OFFSET > 0).
Beginning with Shorewall 4.4.12, the field between MASK_BITS and
PROVIDER_OFFSET can be used for any purpose you want.
Beginning with Shorewall 4.4.13, the first unused bit from the
right is used by Shorewall as an ''exclusion mark'' which
allows
exclusion in CONTINUE, NONAT and ACCEPT+ rules.
It is actually the values of the above four options that determine
how Packet/Connection Marks are layed out. Their default values are
derived from the settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS as
shown in the table at
http://www.shorewall.net/PacketMarking.html#Values.
The ''shorewall update'' (''shorewall6
update'') command will supply
values for these options based on the settings of WIDE_TC_MARKS and
HIGH_ROUTE_MARKS.
The ''shorewall show marks'' (''shorewall6 show
marks'') command shows
the range of each field in both decimal and hex.
Example (TC_BITS=0, MASK_BITS=0, PROVIDER_BITS=2,
PROVIDER_OFFSET=16, ZONE_BITS=4):
Shorewall 4.4.26 - Mark Layout at gw - Sun Nov 20
2:08:23 PST 2011
Traffic Shaping: Not Enabled
User:1-65535 (0x1-0xffff) mask 0xffff
Provider:65536-196608 (0x10000-0x30000) mask 0x30000
Zone:262144-3932160 (0x40000-0x3c0000) mask 0x3c0000
Exclusion:4194304 mask 0x400000
As of this release WIDE_TC_MARKS and HIGH_ROUTE_MARKS are
deprecated.
5) This release introduces limited support for using back-to-back veth
devices to access a bridge.
Consider this setup:
-- eth1 (zone1)
/
WAN ---- eth0 veth0 <-> veth1-- br0 --- eth2 (zone2)
\
-- eth3 (zone3)
In this configuration, it is veth0 that has an IP address; the
bridge does not.
Because veth1 is a port on br0, Netfilter allows filtering between
that interface and each of the other ports. All connections from
the firewall (fw) and the WAN ((net) enter the bridge through
veth1. All traffic from zone1-zone3 enter the routing firewall
through veth0.
Note that, in this configuration, packets between zones1-zone3 and
the rest of the world go through Netfilter twice. Assume that we
associate veth0 with an ip zone called ''bridge'' and veth1
with a
bport zone called ''portal''. Then the two traversals of
Netfilter
are:
a) Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the
destination zone is ''portal''.
b) Between veth0 and the final destination. The source zone is
bridge and the destination zone is either fw or net.
A similar scenario occurs with traffic originating in the net or
firewall zones and destined for zone1-zone3.
As you can see, the problem here is that in the first traversal, we
know the real source zone but not the real destination zone; and in
the second traversal, we know the real destination zone but not the
real source zone.
The solution allows us to know the real source zone during the
second traversal.
A new ZONE_BITS option is added to shorewall.conf
(shorewall6.conf). Its value determines the number of bits of the
packet mark to use for zone marks. When ZONE_BITS is non-zero,
Shorewall automatically assigns a mark value to each zone (the
firewall zone always has value 0). Zone marks are assigned to all
zones except those that specify ''nomark'' in the OPTION
column of
their zones file entry. In the above example, the bridge and portal
zones would have ''nomark'' specified.
With ZONE_BITS and ''nomark'' specified appropriately, now
each
packet from the ''bridge'' zone has a packet mark that lets
us know
which of the three bport zones (zone1-zone3) the packet originated
on.
Similarly, packets entering the bridge through veth1 have a mark
value that records whether the packet is from the net zone or the
fw zone.
As part of these changes, the compiler now accepts a zone name in
the MARK column of the rules file, when ZONE_BITS is non-zero. This
permits rules of this type:
ACCEPT bridge net ... ; mark=zone2
to control connections from zone2 to the net, and rules such as
ACCEPT portal zone1 ...; mark=net
to control connections from the net to zone1.
One final note; DNAT rules should be placed in the first traversal
(net->bridge on input).
See http://www.shorewall.net/bridge-Shorewall-perl for a fuller
example.
6) This release introduces optimization category 16. When this
category is enabled, sequences of ''compatible'' rules are
combined
into a single rule.
A sequence of rules is considered compatible if the rules differ
only in their destination ports and comments.
A sequence of combatible rules is often generated when macros are
invoked in sequence.
The ability to combine adjacent rules is limited by two factors:
- Destination port lists may only be combined up to a maximum of 15
ports, where a port-pair counts as two ports.
- Rules may only be combined until the length of their concatinated
comments reach 255 characters.
When either of these limits would be exceeded, the current combined
rule is emitted and the compiler attemts to combine rules beginning
with the one that would have exceeded the limit.
Adjacent combined comments are separated by '', ''. Empty
comments at
the front of a group of combined comments are replaced by ''Others
and''. Empty comments at the end of a group of combined comments are
replaced by ''and others''.
Example 1: Rules with comments "FOO", <empty> and
"BAR" would
result in the combined comment "FOO and others, BAR".
Example 2: Rules with comments <empty>, "FOO" and
"BAR" would reult
in the combined comment "Others and FOO, BAR".
Note: Optimize level 16 requires "Extended Multi-port Match" in
your
iptables and kernel.
7) The ''enable'' and ''disable'' commands,
previously supported only by
the compiled firewall script, are now supported by the CLI programs
(/sbin/shorewall, /sbin/shorewall-lite, etc.) as well.
In earlier releases, these commands only allowed the provider to be
specified by its physical interface name, thus making it impossible
to enable/disable individual providers sharing a single
interface. The commands now accept a provider name for all optional
providers. For those that share an interface, only the provider
name is accepted.
Thank you for using Shorewall,
-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 \________________________________________________
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d