The Shorewall team is pleased to announce the availability of Shorewall 4.4.25.
Problems corrected:
1) A defect in the optimizer that allowed incompatible rules to be
combined has been corrected.
Example:
Rule1: -i eth1 -j chainx
Rule in chainx: -i eth2 -j ACCEPT
Incorrect result: -i eth2 -j ACCEPT
With the change in this release, Rule1 will remain as it is.
2) Routes and rules added as a result of entries in
/etc/shorewall6/providers were previously not deleted by
'stop' or 'restart'. Repeated 'restart' commands could therefore
lead to an incorrect routing configuration.
3) Previously, capital letters were disallowed in IPv6 addresses. They
are now permitted.
4) If the COPY column in /etc/shorewall6/providers was non-empty,
previously a run-time error could occur when copying a table. The
diagnostic produced by ip was:
Either "to" is duplicate, or "cache" is garbage
5) When copying IPv6 routes, the generated script previously attempted
to copy 'cache' entries. Those entries are now omitted.
6) Previously, the use of large provider numbers could cause some
Shorewall-generated routing rules to be ineffective.
Example (provider numbers 110 and 120):
0: from all lookup local
10109: from all fwmark 0x6e/0xff lookup 110
10119: from all fwmark 0x78/0xff lookup 120
11000: from 2001:470:1f04:262::1/64 lookup 110
11001: from 2001:470:c:316::1/64 lookup 120
32766: from all lookup main
47904: from 2001:470:8388::1 lookup 110 <===========
50464: from 2001:470:f032::1 lookup 120 <===========
Now, all routing rules generated by provider interface IP (and IP6)
addresses are created at priority 20000.
0: from all lookup local
10109: from all fwmark 0x6e/0xff lookup 110
10119: from all fwmark 0x78/0xff lookup 120
11000: from 2001:470:1f04:262::1/64 lookup 110
11001: from 2001:470:c:316::1/64 lookup 120
20000: from 2001:470:8388::1 lookup 110 <===========
20000: from 2001:470:f032::1 lookup 120 <===========
32766: from all lookup main
7) In some contexts, IPv6 addresses of the form ::i.j.k.l were
incorrectly classified as invalid by the configuration compiler.
New Features
1) The original static blacklisting implementation was
interface-oriented and only handled blacklisting by source
address. In Shorewall 4.4.12, the ability to blacklist by
destination address was added and blacklisting could be specified
as a ZONE option. This change, plus additional changes in
subsequent releases has lead to an implementation that is complex
and hard to extend.
In this release, a new static blacklisting facility has been
implemented. This facility is separate from the legacy facility, so
existing configurations will continue to work without change.
A BLACKLIST section has been added to the rules file. This section
is now the first section, having been added ahead of the ALL
section. The set of packets that are subject to blacklisting is
still governed by the setting of BLACKLISTNEWONLY in
shorewall.conf. The settings of BLACKLIST_LOGLEVEL and
BLACKLIST_DISPOSITION are not relevant to the new implementation.
Most of the actions available in other sections of the rules file
are available in the BLACKLIST section and logging is specified on
a rule-by-rule basis in the normal way.
In addition to the other actions available, a WHITELIST action has
been added which exempts matching packets from being passed to the
remaining rules in the section.
Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has
a companion blacklisting chain. The name of the blacklisting chain
is formed by appending "~" to the zone2zone chain. For example,
'net2fw' blacklist rules appear in the chain net2fw~.
There is a likelihood that multiple blacklisting chains will have
exactly the same rules. This is especially true when 'all' is used
as the zone name in the SOURCE and/or DEST columns. When
optimization level 8 is used, these identical chains are combined
into a single chain with the name ~blacklistN, where N is a number
(possibly with multiple digits).
The 'nosurfs' and 'tcpflags' interface options generate rules that
will be traversed prior to those in the BLACKLIST section. If you
want similar rules to be travered on packets that were not dropped
or rejected in the BLACKLIST chain, you can use the new
'DropSmurfs' and/or 'TCPFlags' standard actions.
The DropSmurfs action has a single parameter whose default value
is '-'. The action silently drops smurfs without auditing. If you
want to audit these drops, use DropSmurfs(audit). Logging can be
specified in the normal way (e.g., DropSmurfs:info).
The TCPFlags action has two parameters whose default values are
DROP and -. The first action determines what is to be done with
matching packets and can have the values DROP, REJECT or ACCEPT. If
you want the action to be audited, pass 'audit' in the second
parameter.
Example: TCPFlags(REJECT,audit)
Again, logging is specified in the normal way.
The 'maclist' interface option can also generate rules that are
traversed prior to those in the BLACKLIST section. If you want them
to come after the the blacklist rules, simply recode your maclist
rules in the NEW section of the rules file. The 'macipmap' ipset
type is ideally suited for this task.
Example: assumes the ipset name is macipmap and that the
zone to be verified is named wlan
/etc/shorewall/rules:
SECTION NEW
DROP:info wlan:!+macipmap all
2) '6in4' has been added as a synonum for '6to4' in the TYPE column of
the tunnels file.
3) The handling of IN_BANDWIDTH in both /etc/shorewall/tcdevices and
/etc/shorewall/tcinterfaces has been changed. Previously:
a) Simple rate/burst policing was applied using the value(s)
supplied.
b) IPv4 and IPv6 were policed separately.
Beginning with this release, you have the option of configuring a
rate estimated policing filter. This type of filter is discussed at
http://ace-host.stuart.id.au/russell/files/tc/doc/extimators.txt.
You specify an estimeting filter by preceding the IN-BANDWIDTH with
a tilde ('~').
Example: ~40mbit
This example limits incoming traffic to an *average* rate of 40mbit.
There are two other other parameters that can be specified, in
addition to the average rate - <interval> and
<decay_interval>. There is an excellent description of these
parameters in the document referenced above.
Example: ~40mbit:1sec:8sec
In that example, the <interval> is 1 second and the
<decay_interval> is 8 seconds. If not given, the default values are
250ms and 4 seconds. Both parameters must be supplied if either is
supplied.
Also in this release, the policing of IPv4 and IPv6 has been
combined so a single filter is applied to all traffic on a
configured interface.
4) Shorewall6 now supports the 'balance' and 'fallback' provider
options. These options are restricted to one interface per
configuration for each option.
5) The scripts generated by Shorewall6 now support the 'enable' and
'disable' commands.
6) A 'MARK' column has been added to the route_rules file. See
shorewall-route_rules (5) and shorewall6-route_rules (5) for
details.
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 \________________________________________________
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
