Hello community,
here is the log from the commit of package shorewall for openSUSE:Factory checked in at 2011-12-05 12:45:34
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/shorewall (Old)
and /work/SRC/openSUSE:Factory/.shorewall.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "shorewall", Maintainer is ""
Changes:
--------
--- /work/SRC/openSUSE:Factory/shorewall/shorewall.changes 2011-11-14 13:44:19.000000000 +0100
+++ /work/SRC/openSUSE:Factory/.shorewall.new/shorewall.changes 2011-12-05 12:45:52.000000000 +0100
@@ -1,0 +2,36 @@
+Sat Dec 3 10:23:47 UTC 2011 - toganm@opensuse.org
+
+- Update to 4.4.26 For more details see changelog.txt and
+ releasenotes.txt
+ * This release includes all corrections included in 4.4.25.1
+ through .3.
+ * 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.
+ * 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.
+ * The SAME tcrules target was broken in Shorewall 4.4.22. It now
+ works correctly again.
+ * Previously, 'shorewall6 update' did not update shorewall6.conf.
+ The command now works as expected.
+ * 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.
+
+-------------------------------------------------------------------
Old:
----
shorewall-4.4.25.3.tar.bz2
shorewall-docs-html-4.4.25.3.tar.bz2
shorewall-init-4.4.25.3.tar.bz2
shorewall-lite-4.4.25.3.tar.bz2
shorewall6-4.4.25.3.tar.bz2
shorewall6-lite-4.4.25.3.tar.bz2
New:
----
shorewall-4.4.26.tar.bz2
shorewall-docs-html-4.4.26.tar.bz2
shorewall-init-4.4.26.tar.bz2
shorewall-lite-4.4.26.tar.bz2
shorewall6-4.4.26.tar.bz2
shorewall6-lite-4.4.26.tar.bz2
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ shorewall.spec ++++++
--- /var/tmp/diff_new_pack.t2k5xS/_old 2011-12-05 12:45:54.000000000 +0100
+++ /var/tmp/diff_new_pack.t2k5xS/_new 2011-12-05 12:45:54.000000000 +0100
@@ -18,18 +18,18 @@
Name: shorewall
-Version: 4.4.25.3
+Version: 4.4.26
Release: 1
License: GPL-2.0
Summary: Shoreline Firewall is an iptables-based firewall for Linux systems
Url: http://www.shorewall.net/
Group: Productivity/Networking/Security
-Source0: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.24/%name-%version.t...
-Source1: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.24/%name-lite-%vers...
-Source2: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.24/%name-init-%vers...
-Source3: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.24/%{name}6-lite-%version.tar.bz2
-Source4: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.24/%{name}6-%version.tar.bz2
-Source5: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.24/%name-docs-html-...
+Source0: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.26/%name-%version.t...
+Source1: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.26/%name-lite-%vers...
+Source2: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.26/%name-init-%vers...
+Source3: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.26/%{name}6-lite-%version.tar.bz2
+Source4: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.26/%{name}6-%version.tar.bz2
+Source5: http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.26/%name-docs-html-...
Source6: %name-4.4.22.rpmlintrc
Source7: README.openSUSE
# PATCH-FIX-UPSTREAM init-4.4.14 toganm@opensuse.org -- Required-Stop and Short descriprtion
++++++ shorewall-4.4.25.3.tar.bz2 -> shorewall-4.4.26.tar.bz2 ++++++
++++ 7087 lines of diff (skipped)
++++++ shorewall-docs-html-4.4.25.3.tar.bz2 -> shorewall-docs-html-4.4.26.tar.bz2 ++++++
++++ 6902 lines of diff (skipped)
++++++ shorewall-init-4.4.25.3.tar.bz2 -> shorewall-init-4.4.26.tar.bz2 ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.25.3/changelog.txt new/shorewall-init-4.4.26/changelog.txt
--- old/shorewall-init-4.4.25.3/changelog.txt 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-init-4.4.26/changelog.txt 2011-12-02 16:57:58.000000000 +0100
@@ -1,8 +1,64 @@
-Changes in 4.4.25.3
+Changes in 4.4.26 Final
-1) Fix wildcard interfaces.
+1) Fix 'shorewall6 update'.
-2) Add 'status' support to the Debian init scripts.
+2) Add tracing to optimization category 16.
+
+3) Allow provider names in enable/disable and externalize these
+ commands.
+
+4) Allow the params file to reside in a directory other than $CONFDIR.
+
+Changes in 4.4.26 RC 2
+
+1) Fix SAME target.
+
+2) Correct update of mark layout.
+
+Changes in 4.4.26 RC 1
+
+1) Implement Optimize level 16.
+
+Changes in 4.4.26 Beta 3
+
+1) Make zone types a power of 2.
+
+2) Add ZONE_BITS configuration option.
+
+3) Add zone automark.
+
+4) Correct blacklist conversion.
+
+Changes in 4.4.26 Beta 4.
+
+1) Don't issue a warning for orphan bport zones when ZONE_BITS > 0.
+
+2) Add new mark-layout options to the .conf files.
+
+3) Describe the new mark-layout options in the manpages.
+
+4) Deprecated WIDE_TS_MARKS and HIGH_ROUTE_MARKS.
+
+5) Add 'show marks' command.
+
+Changes in 4.4.26 Beta 3
+
+1) Formalize the mark-layout options.
+
+2) Add support for back-to-back veths to access a bridge.
+
+Changes in 4.4.26 Beta 2
+
+1) ULOG and NFLOG detection.
+
+Changes in 4.4.26 Beta 1
+
+1) Add 'blrules' file.
+
+2) Make ACCEPT a synonym of WHILELIST in the blrules file and
+ BLACKLIST section.
+
+3) Automated conversion of legacy blacklist configurations.
Changes in 4.4.25.2
@@ -10,10 +66,6 @@
2) Add DropSmurfs and TCPFlags to actions.std.
-3) Document the 'ignore' option.
-
-4) Make replacement of '+' by '*' in case statements global.
-
Changes in 4.4.25.1
1) Reload 'blacklistsection' chains during 'refresh'.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.25.3/install.sh new/shorewall-init-4.4.26/install.sh
--- old/shorewall-init-4.4.25.3/install.sh 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-init-4.4.26/install.sh 2011-12-02 16:57:58.000000000 +0100
@@ -23,7 +23,7 @@
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
-VERSION=4.4.25.3
+VERSION=4.4.26
usage() # $1 = exit status
{
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.25.3/releasenotes.txt new/shorewall-init-4.4.26/releasenotes.txt
--- old/shorewall-init-4.4.25.3/releasenotes.txt 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-init-4.4.26/releasenotes.txt 2011-12-02 16:57:58.000000000 +0100
@@ -1,6 +1,6 @@
----------------------------------------------------------------------------
- S H O R E W A L L 4 . 4 . 2 5 . 3
+ S H O R E W A L L 4 . 4 . 2 6
----------------------------------------------------------------------------
I. PROBLEMS CORRECTED IN THIS RELEASE
@@ -14,296 +14,273 @@
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
----------------------------------------------------------------------------
-4.4.25.3
+1) This release includes all corrections included in 4.4.25.1 through
+ .3.
-1) Previously, the following configuration produced an incorrect
- ruleset:
+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.
- zones:
-
- host firewall
- uw ipv4
- net ipv4
-
- interfaces:
-
- - enet detect physical=+
-
- hosts:
-
- net enet:0.0.0.0/0
- uw enet:$N_ALL_UW_AFFILIATED
-
- Here's an example of the problem; from 'shorewall show INPUT':
-
- Chain INPUT (policy DROP 0 packets, 0 bytes)
- pkts bytes target prot opt in out source ...
- 1678 54427 dynamic all -- * * 0.0.0.0/0 ...
- 33631 4085K enet_in all -- * * 0.0.0.0/0 ...
- 0 0 ACCEPT all -- lo * 0.0.0.0/0 ...
- 0 0 enet_in all -- * * 0.0.0.0/0 ...
- ...
+----------------------------------------------------------------------------
+ I I. K N O W N P R O B L E M S R E M A I N I N G
+----------------------------------------------------------------------------
- Note that the ACCEPT rule for the loopback device occurs after
- an unconditional jump to 'enet_in' and that there are two
- such jumps.
+1) On systems running Upstart, shorewall-init cannot reliably secure
+ the firewall before interfaces are brought up.
- Now, this sequence is generated:
+----------------------------------------------------------------------------
+ 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
+----------------------------------------------------------------------------
- Chain INPUT (policy DROP 0 packets, 0 bytes)
- pkts bytes target prot opt in out source ...
- 1678 54427 dynamic all -- * * 0.0.0.0/0 ...
- 0 0 ACCEPT all -- lo * 0.0.0.0/0 ...
- 33631 4085K enet_in all -- * * 0.0.0.0/0 ...
- ...
+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.
-2) The Debian init scripts (with the exception of Shorewall-init) now
+3) The Debian init files (with the exception of Shorewall-init) now
support the 'status' command.
-4.4.25.2
+4) This release formalizes the feature that has long been
+ documented at http://www.shorewall.net/PacketMarking.html#Values.
-1) Previously, if all the following were true:
+ 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.
- - AUTOMAKE=Yes
- - Current compiled script (/var/lib/shorewall/firewall or
- /var/lib/shorewall6/firewall) up to date
- - LEGACY_FASTSTART=No
- - There was a saved configuration
+ TC_BITS
- then rather than start the current configuration, 'shorewall start
- -f' or 'shorewall6 start -f' would incorrectly restore the saved
- configuration.
+ The number of bits at the least-significant end of the mark
+ to be used for traffic shaping marking. May be zero.
-2) The DropSmurfs and TCPFlags actions are now available in
- Shorewall6. They were previously omitted from the IPv6 actions.std
- file.
+ PROVIDER_BITS
-3) The 'rawpost' table was previously omitted from the output of the
- 'dump' command. It is now displayed.
+ The number of bits in the mark to be used for provider
+ marks. May be zero.
-4) Previously, if a configuration contained more than one wildcard
- interface (physical name ending in '+'), then the generated script
- might not work properly with Shorewall-init. This defect dates back
- to the introduction of Shorewall-init.
+ PROVIDER_OFFSET
- Example:
+ 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.
- ZONE INTERFACE BROADCAST OPTIONS
- z1 eth+ - optional
- z2 veth+ - optional
+ MASK_BITS
- The script will contain a case statement of this form:
+ 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).
- case $interface in
- ...
- eth*|veth+)
- ...
+ Beginning with Shorewall 4.4.12, the field between MASK_BITS and
+ PROVIDER_OFFSET can be used for any purpose you want.
-4.4.25.1
+ 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.
-1) A 'refresh' command with no chains or tables specified will now
- reload chains created by entries in the BLACKLIST section of the
- rules file.
+ 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.
-2) The rules compiler previously failed to detect the 'Flow Filter'
- capability. That capability is now correctly detected.
+ The 'shorewall update' ('shorewall6 update') command will supply
+ values for these options based on the settings of WIDE_TC_MARKS and
+ HIGH_ROUTE_MARKS.
-3) The IN_BANDWIDTH handling change in 4.4.25 was incompatible with
- moribund distributions such as RHEL4. Restoring IN_BANDWIDTH
- functionality on those releases required a new 'Basic Filter'
- capability.
-
-4.4.25
+ The 'shorewall show marks' ('shorewall6 show marks') command shows
+ the range of each field in both decimal and hex.
-1) A defect in the optimizer that allowed incompatible rules to be
- combined has been corrected.
+ Example (TC_BITS=0, MASK_BITS=0, PROVIDER_BITS=2,
+ PROVIDER_OFFSET=16, ZONE_BITS=4):
- Example:
+ Shorewall 4.4.26 - Mark Layout at gw - Sun Nov 20
+ 2:08:23 PST 2011
- Rule1: -i eth1 -j chainx
- Rule in chainx: -i eth2 -j ACCEPT
- Incorrect result: -i eth2 -j ACCEPT
+ 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
- With the change in this release, Rule1 will remain as it is.
+ As of this release WIDE_TC_MARKS and HIGH_ROUTE_MARKS are
+ deprecated.
-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.
+5) This release introduces limited support for using back-to-back veth
+ devices to access a bridge.
-3) Previously, capital letters were disallowed in IPv6 addresses. They
- are now permitted.
+ Consider this setup:
-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:
+ -- eth1 (zone1)
+ /
+ WAN ---- eth0 veth0 <-> veth1-- br0 --- eth2 (zone2)
+ \
+ -- eth3 (zone3)
- Either "to" is duplicate, or "cache" is garbage
+ In this configuration, it is veth0 that has an IP address; the
+ bridge does not.
-5) When copying IPv6 routes, the generated script previously attempted
- to copy 'cache' entries. Those entries are now omitted.
+ 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.
-6) Previously, the use of large provider numbers could cause some
- Shorewall-generated routing rules to be ineffective.
+ 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:
- Example (provider numbers 110 and 120):
+ a) Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the
+ destination zone is 'portal'.
- 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 <===========
+ b) Between veth0 and the final destination. The source zone is
+ bridge and the destination zone is either fw or net.
- Now, all routing rules generated by provider interface IP (and IP6)
- addresses are created at priority 20000.
+ A similar scenario occurs with traffic originating in the net or
+ firewall zones and destined for zone1-zone3.
- 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
+ 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.
-7) In some contexts, IPv6 addresses of the form ::i.j.k.l were
- incorrectly classified as invalid by the configuration compiler.
+ The solution allows us to know the real source zone during the
+ second traversal.
-----------------------------------------------------------------------------
- I I. K N O W N P R O B L E M S R E M A I N I N G
-----------------------------------------------------------------------------
+ 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.
-1) On systems running Upstart, shorewall-init cannot reliably secure
- the firewall before interfaces are brought up.
+ 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.
-----------------------------------------------------------------------------
- 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
-----------------------------------------------------------------------------
+ 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.
-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.
+ 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:
- 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).
+ ACCEPT bridge net ... ; mark=zone2
- 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
+ to control connections from zone2 to the net, and rules such as
- /etc/shorewall/rules:
+ ACCEPT portal zone1 ...; mark=net
- SECTION NEW
- DROP:info wlan:!+macipmap all
+ to control connections from the net to zone1.
-2) '6in4' has been added as a synonum for '6to4' in the TYPE column of
- the tunnels file.
+ One final note; DNAT rules should be placed in the first traversal
+ (net->bridge on input).
-3) The handling of IN_BANDWIDTH in both /etc/shorewall/tcdevices and
- /etc/shorewall/tcinterfaces has been changed. Previously:
+ See http://www.shorewall.net/bridge-Shorewall-perl for a fuller
+ example.
- a) Simple rate/burst policing was applied using the value(s)
- supplied.
+6) This release introduces optimization category 16. When this
+ category is enabled, sequences of 'compatible' rules are combined
+ into a single rule.
- b) IPv4 and IPv6 were policed separately.
+ A sequence of rules is considered compatible if the rules differ
+ only in their destination ports and comments.
- 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.
+ A sequence of combatible rules is often generated when macros are
+ invoked in sequence.
- You specify an estimeting filter by preceding the IN-BANDWIDTH with
- a tilde ('~').
+ The ability to combine adjacent rules is limited by two factors:
- Example: ~40mbit
+ - Destination port lists may only be combined up to a maximum of 15
+ ports, where a port-pair counts as two ports.
- This example limits incoming traffic to an *average* rate of 40mbit.
+ - Rules may only be combined until the length of their concatinated
+ comments reach 255 characters.
- There are two other other parameters that can be specified, in
- addition to the average rate - <interval> and
- . There is an excellent description of these
- parameters in the document referenced above.
+ 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.
- Example: ~40mbit:1sec:8sec
+ 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'.
- In that example, the <interval> is 1 second and the
- is 8 seconds. If not given, the default values are
- 250ms and 4 seconds. Both parameters must be supplied if either is
- supplied.
+ Example 1: Rules with comments "FOO", <empty> and "BAR" would
+ result in the combined comment "FOO and others, BAR".
- 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.
+ Example 2: Rules with comments <empty>, "FOO" and "BAR" would reult
+ in the combined comment "Others and FOO, BAR".
-4) Shorewall6 now supports the 'balance' and 'fallback' provider
- options. These options are restricted to one interface per
- configuration for each option.
+ Note: Optimize level 16 requires "Extended Multi-port Match" in your
+ iptables and kernel.
-5) The scripts generated by Shorewall6 now support the 'enable' and
- 'disable' commands.
+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.
-6) A 'MARK' column has been added to the route_rules file. See
- shorewall-route_rules (5) and shorewall6-route_rules (5) for
- details.
+ 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.
----------------------------------------------------------------------------
I V. R E L E A S E 4 . 4 H I G H L I G H T S
@@ -520,27 +497,271 @@
where 'iface' is a capitalized interface name (e.g., ETH0) and
'provider' is the capitalized name of a provider.
-15) Support for the OPTIONS column in /etc/shorewall/blacklist
- (/etc/shorewall6/blacklist) has been removed. Blacklisting by
- destination IP address will be included in a later Shorewall
- release.
-
-16) If your /etc/shorewall/params (or /etc/shorewall6/params) file
+15) If your /etc/shorewall/params (or /etc/shorewall6/params) file
sends output to Standard Output, you need to be aware that the
output will be redirected to Standard Error beginning with
Shorewall 4.4.16.
-17) Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
+16) Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
deprecated. With EXPORTPARAMS=No, the variables set by
/etc/shorewall/params (/etc/shorewall6/params) at compile time are
now available in the compiled firewall script.
-18) The 'iprange' and 'ipaddr' commands require the 'bc' utility.
+17) The 'iprange' and 'ipaddr' commands require the 'bc' utility.
+
+18) Beginning with Shorewall 4.4.26, the WIDE_TC_MARKS and
+ HIGH_ROUTE_MARKS options are deprecated in favor of TC_BITS,
+ MARK_BITS, PROVIDER_BITS and PROVIDER_OFFSET. The 'shorewall
+ update' ('shorewall6 update') command will set these net options
+ based on the values of the deprecated ones.
----------------------------------------------------------------------------
V I. P R O B L E M S C O R R E C T E D A N D N E W F E A T U R E S
I N P R I O R R E L E A S E S
----------------------------------------------------------------------------
+ P R O B L E M S C O R R E C T E D I N 4 . 4 . 2 5
+----------------------------------------------------------------------------
+
+4.4.25.2
+
+1) Previously, if all the following were true:
+
+ - AUTOMAKE=Yes
+ - Current compiled script (/var/lib/shorewall/firewall or
+ /var/lib/shorewall6/firewall) up to date
+ - LEGACY_FASTSTART=No
+ - There was a saved configuration
+
+ then rather than start the current configuration, 'shorewall start
+ -f' or 'shorewall6 start -f' would incorrectly restore the saved
+ configuration.
+
+2) The DropSmurfs and TCPFlags actions are now available in
+ Shorewall6. They were previously omitted from the IPv6 actions.std
+ file.
+
+3) The 'rawpost' table was previously omitted from the output of the
+ 'dump' command. It is now displayed.
+
+4) Previously, if a configuration contained more than one wildcard
+ interface (physical name ending in '+'), then the generated script
+ might not work properly with Shorewall-init. This defect dates back
+ to the introduction of Shorewall-init.
+
+ Example:
+
+ ZONE INTERFACE BROADCAST OPTIONS
+ z1 eth+ - optional
+ z2 veth+ - optional
+
+ The script will contain a case statement of this form:
+
+ case $interface in
+ ...
+ eth*|veth+)
+ ...
+
+4.4.25.1
+
+1) A 'refresh' command with no chains or tables specified will now
+ reload chains created by entries in the BLACKLIST section of the
+ rules file.
+
+2) The rules compiler previously failed to detect the 'Flow Filter'
+ capability. That capability is now correctly detected.
+
+3) The IN_BANDWIDTH handling change in 4.4.25 was incompatible with
+ moribund distributions such as RHEL4. Restoring IN_BANDWIDTH
+ functionality on those releases required a new 'Basic Filter'
+ capability.
+
+4.4.25
+
+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.
+
+
+----------------------------------------------------------------------------
+ N E W F E A T U R E S I N 4 . 4 . 2 5
+----------------------------------------------------------------------------
+
+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
+ . 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
+ 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.
+
+----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 2 4
----------------------------------------------------------------------------
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.25.3/shorewall-init.spec new/shorewall-init-4.4.26/shorewall-init.spec
--- old/shorewall-init-4.4.25.3/shorewall-init.spec 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-init-4.4.26/shorewall-init.spec 2011-12-02 16:57:58.000000000 +0100
@@ -1,6 +1,6 @@
%define name shorewall-init
-%define version 4.4.25
-%define release 3
+%define version 4.4.26
+%define release 0base
Summary: Shorewall-init adds functionality to Shoreline Firewall (Shorewall).
Name: %{name}
@@ -119,10 +119,18 @@
%doc COPYING changelog.txt releasenotes.txt
%changelog
-* Thu Nov 10 2011 Tom Eastep tom@shorewall.net
-- Updated to 4.4.25-3
-* Thu Nov 03 2011 Tom Eastep tom@shorewall.net
-- Updated to 4.4.25-2
+* Tue Nov 29 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0base
+* Sun Nov 20 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0RC1
+* Sat Nov 19 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta4
+* Thu Nov 17 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta3
+* Sat Nov 12 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta2
+* Wed Nov 02 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta1
* Sun Oct 30 2011 Tom Eastep tom@shorewall.net
- Updated to 4.4.25-1
* Thu Oct 27 2011 Tom Eastep tom@shorewall.net
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.25.3/uninstall.sh new/shorewall-init-4.4.26/uninstall.sh
--- old/shorewall-init-4.4.25.3/uninstall.sh 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-init-4.4.26/uninstall.sh 2011-12-02 16:57:58.000000000 +0100
@@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Shorewall Firewall
-VERSION=4.4.25.3
+VERSION=4.4.26
usage() # $1 = exit status
{
++++++ shorewall-lite-4.4.25.3.tar.bz2 -> shorewall-lite-4.4.26.tar.bz2 ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/changelog.txt new/shorewall-lite-4.4.26/changelog.txt
--- old/shorewall-lite-4.4.25.3/changelog.txt 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-lite-4.4.26/changelog.txt 2011-12-02 16:57:59.000000000 +0100
@@ -1,8 +1,64 @@
-Changes in 4.4.25.3
+Changes in 4.4.26 Final
-1) Fix wildcard interfaces.
+1) Fix 'shorewall6 update'.
-2) Add 'status' support to the Debian init scripts.
+2) Add tracing to optimization category 16.
+
+3) Allow provider names in enable/disable and externalize these
+ commands.
+
+4) Allow the params file to reside in a directory other than $CONFDIR.
+
+Changes in 4.4.26 RC 2
+
+1) Fix SAME target.
+
+2) Correct update of mark layout.
+
+Changes in 4.4.26 RC 1
+
+1) Implement Optimize level 16.
+
+Changes in 4.4.26 Beta 3
+
+1) Make zone types a power of 2.
+
+2) Add ZONE_BITS configuration option.
+
+3) Add zone automark.
+
+4) Correct blacklist conversion.
+
+Changes in 4.4.26 Beta 4.
+
+1) Don't issue a warning for orphan bport zones when ZONE_BITS > 0.
+
+2) Add new mark-layout options to the .conf files.
+
+3) Describe the new mark-layout options in the manpages.
+
+4) Deprecated WIDE_TS_MARKS and HIGH_ROUTE_MARKS.
+
+5) Add 'show marks' command.
+
+Changes in 4.4.26 Beta 3
+
+1) Formalize the mark-layout options.
+
+2) Add support for back-to-back veths to access a bridge.
+
+Changes in 4.4.26 Beta 2
+
+1) ULOG and NFLOG detection.
+
+Changes in 4.4.26 Beta 1
+
+1) Add 'blrules' file.
+
+2) Make ACCEPT a synonym of WHILELIST in the blrules file and
+ BLACKLIST section.
+
+3) Automated conversion of legacy blacklist configurations.
Changes in 4.4.25.2
@@ -10,10 +66,6 @@
2) Add DropSmurfs and TCPFlags to actions.std.
-3) Document the 'ignore' option.
-
-4) Make replacement of '+' by '*' in case statements global.
-
Changes in 4.4.25.1
1) Reload 'blacklistsection' chains during 'refresh'.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/install.sh new/shorewall-lite-4.4.26/install.sh
--- old/shorewall-lite-4.4.25.3/install.sh 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-lite-4.4.26/install.sh 2011-12-02 16:57:59.000000000 +0100
@@ -22,7 +22,7 @@
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
-VERSION=4.4.25.3
+VERSION=4.4.26
usage() # $1 = exit status
{
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/lib.base new/shorewall-lite-4.4.26/lib.base
--- old/shorewall-lite-4.4.25.3/lib.base 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-lite-4.4.26/lib.base 2011-12-02 16:57:59.000000000 +0100
@@ -28,7 +28,7 @@
#
SHOREWALL_LIBVERSION=40407
-SHOREWALL_CAPVERSION=40425
+SHOREWALL_CAPVERSION=40426
[ -n "${VARDIR:=/var/lib/shorewall}" ]
[ -n "${SHAREDIR:=/usr/share/shorewall}" ]
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/lib.cli new/shorewall-lite-4.4.26/lib.cli
--- old/shorewall-lite-4.4.25.3/lib.cli 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-lite-4.4.26/lib.cli 2011-12-02 16:57:59.000000000 +0100
@@ -29,7 +29,7 @@
#
fatal_error() # $@ = Message
{
- echo " $@" >&2
+ echo " ERROR: $@" >&2
exit 2
}
@@ -751,6 +751,12 @@
[ $# -gt 1 ] && usage 1
perip_accounting
;;
+ marks)
+ [ $# -gt 1 ] && usage 1
+ echo "$g_product $SHOREWALL_VERSION Mark Layout at $g_hostname - $(date)"
+ echo
+ [ -f ${VARDIR}/marks ] && cat ${VARDIR}/marks;
+ ;;
*)
if [ "$g_product" = Shorewall ]; then
case $1 in
@@ -1729,6 +1735,8 @@
LOGMARK_TARGET=
IPMARK_TARGET=
LOG_TARGET=Yes
+ ULOG_TARGET=
+ NFLOG_TARGET=
PERSISTENT_SNAT=
FLOW_FILTER=
FWMARK_RT_MASK=
@@ -1886,6 +1894,8 @@
qt $IPTABLES -A $chain -g $chain1 && GOTO_TARGET=Yes
qt $IPTABLES -A $chain -j LOGMARK && LOGMARK_TARGET=Yes
qt $IPTABLES -A $chain -j LOG || LOG_TARGET=
+ qt $IPTABLES -A $chain -j ULOG && ULOG_TARGET=Yes
+ qt $IPTABLES -A $chain -j NFLOG && NFLOG_TARGET=Yes
qt $IPTABLES -A $chain -j MARK --set-mark 5 && MARK_ANYWHERE=Yes
qt $IPTABLES -A $chain -j ACCOUNT --addr 192.168.1.0/29 --tname $chain && ACCOUNT_TARGET=Yes
qt $IPTABLES -A $chain -j AUDIT --type drop && AUDIT_TARGET=Yes
@@ -1977,6 +1987,8 @@
report_capability "LOGMARK Target" $LOGMARK_TARGET
report_capability "IPMARK Target" $IPMARK_TARGET
report_capability "LOG Target" $LOG_TARGET
+ report_capability "ULOG Target" $ULOG_TARGET
+ report_capability "NFLOG Target" $NFLOG_TARGET
report_capability "Persistent SNAT" $PERSISTENT_SNAT
report_capability "TPROXY Target" $TPROXY_TARGET
report_capability "FLOW Classifier" $FLOW_FILTER
@@ -2050,6 +2062,8 @@
report_capability1 LOGMARK_TARGET
report_capability1 IPMARK_TARGET
report_capability1 LOG_TARGET
+ report_capability1 ULOG_TARGET
+ report_capability1 NFLOG_TARGET
report_capability1 PERSISTENT_SNAT
report_capability1 TPROXY_TARGET
report_capability1 FLOW_FILTER
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/manpages/shorewall-lite-vardir.5 new/shorewall-lite-4.4.26/manpages/shorewall-lite-vardir.5
--- old/shorewall-lite-4.4.25.3/manpages/shorewall-lite-vardir.5 2011-11-11 14:52:13.000000000 +0100
+++ new/shorewall-lite-4.4.26/manpages/shorewall-lite-vardir.5 2011-12-02 17:03:20.000000000 +0100
@@ -2,12 +2,12 @@
.\" Title: shorewall-lite-vardir
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.75.2 http://docbook.sf.net/
-.\" Date: 11/11/2011
+.\" Date: 12/02/2011
.\" Manual: [FIXME: manual]
.\" Source: [FIXME: source]
.\" Language: English
.\"
-.TH "SHOREWALL\-LITE\-VAR" "5" "11/11/2011" "[FIXME: source]" "[FIXME: manual]"
+.TH "SHOREWALL\-LITE\-VAR" "5" "12/02/2011" "[FIXME: source]" "[FIXME: manual]"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/manpages/shorewall-lite.8 new/shorewall-lite-4.4.26/manpages/shorewall-lite.8
--- old/shorewall-lite-4.4.25.3/manpages/shorewall-lite.8 2011-11-11 14:52:15.000000000 +0100
+++ new/shorewall-lite-4.4.26/manpages/shorewall-lite.8 2011-12-02 17:03:22.000000000 +0100
@@ -2,12 +2,12 @@
.\" Title: shorewall-lite
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.75.2 http://docbook.sf.net/
-.\" Date: 11/11/2011
+.\" Date: 12/02/2011
.\" Manual: [FIXME: manual]
.\" Source: [FIXME: source]
.\" Language: English
.\"
-.TH "SHOREWALL\-LITE" "8" "11/11/2011" "[FIXME: source]" "[FIXME: manual]"
+.TH "SHOREWALL\-LITE" "8" "12/02/2011" "[FIXME: source]" "[FIXME: manual]"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
@@ -34,10 +34,14 @@
\fBshorewall\-lite\fR [\fBtrace\fR|\fBdebug\fR\ [\fBnolock\fR]] [\-\fIoptions\fR] \fBallow\fR \fIaddress\fR
.HP \w'\fBshorewall\-lite\fR\ 'u
\fBshorewall\-lite\fR [\fBtrace\fR|\fBdebug\fR\ [\fBnolock\fR]] [\-\fIoptions\fR] \fBclear\fR
+.HP \w'\fBshorewall\fR\ 'u
+\fBshorewall\fR [\fBtrace\fR|\fBdebug\fR\ [\fBnolock\fR]] [\-\fIoptions\fR] \fBdisable\fR \fIinterface\fR
.HP \w'\fBshorewall\-lite\fR\ 'u
-\fBshorewall\-lite\fR [\fBtrace\fR|\fBdebug\fR\ [\fBnolock\fR]] [\-\fIoptions\fR] \fBdrop\fR \fIaddress\fR
+\fBshorewall\-lite\fR [\fBtrace\fR|\fBdebug\fR\ [\fBnolock\fR]] [\-\fIoptions\fR] \fBdrop\fR {\ \fIinterface\fR\ |\ \fIprovider\fR\ }
.HP \w'\fBshorewall\-lite\fR\ 'u
\fBshorewall\-lite\fR [\fBtrace\fR|\fBdebug\fR] [\-\fIoptions\fR] \fBdump\fR [\fB\-x\fR] [\fB\-m\fR]
+.HP \w'\fBshorewall\fR\ 'u
+\fBshorewall\fR [\fBtrace\fR|\fBdebug\fR\ [\fBnolock\fR]] [\-\fIoptions\fR] \fBenable\fR {\ \fIinterface\fR\ |\ \fIprovider\fR\ }
.HP \w'\fBshorewall\-lite\fR\ 'u
\fBshorewall\-lite\fR [\fBtrace\fR|\fBdebug\fR] [\-\fIoptions\fR] \fBforget\fR [\fIfilename\fR]
.HP \w'\fBshorewall\-lite\fR\ 'u
@@ -191,6 +195,16 @@
is comma\-separated list whose elements are a host or network address\&.
.RE
.PP
+\fBdisable\fR
+.RS 4
+Added in Shorewall 4\&.4\&.26\&. Disables the optional provider associated with the specified
+\fIinterface\fR
+or
+\fIprovider\fR\&. Where more than one provider share a single network interface, a
+\fIprovider\fR
+name must be given\&.
+.RE
+.PP
\fBdrop\fR
.RS 4
Causes traffic from the listed
@@ -208,6 +222,16 @@
option causes any MAC addresses included in Shorewall Lite log messages to be displayed\&.
.RE
.PP
+\fBenable\fR
+.RS 4
+Added in Shorewall 4\&.4\&.26\&. Enables the optional provider associated with the specified
+\fIinterface\fR
+or
+\fIprovider\fR\&. Where more than one provider share a single network interface, a
+\fIprovider\fR
+name must be given\&.
+.RE
+.PP
\fBforget\fR
.RS 4
Deletes /var/lib/shorewall\-lite/\fIfilenam\fRe and /var/lib/shorewall\-lite/save\&. If no
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/manpages/shorewall-lite.conf.5 new/shorewall-lite-4.4.26/manpages/shorewall-lite.conf.5
--- old/shorewall-lite-4.4.25.3/manpages/shorewall-lite.conf.5 2011-11-11 14:52:11.000000000 +0100
+++ new/shorewall-lite-4.4.26/manpages/shorewall-lite.conf.5 2011-12-02 17:03:18.000000000 +0100
@@ -2,12 +2,12 @@
.\" Title: shorewall-lite.conf
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.75.2 http://docbook.sf.net/
-.\" Date: 11/11/2011
+.\" Date: 12/02/2011
.\" Manual: [FIXME: manual]
.\" Source: [FIXME: source]
.\" Language: English
.\"
-.TH "SHOREWALL\-LITE\&.CO" "5" "11/11/2011" "[FIXME: source]" "[FIXME: manual]"
+.TH "SHOREWALL\-LITE\&.CO" "5" "12/02/2011" "[FIXME: source]" "[FIXME: manual]"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/manpages/shorewall-lite.xml new/shorewall-lite-4.4.26/manpages/shorewall-lite.xml
--- old/shorewall-lite-4.4.25.3/manpages/shorewall-lite.xml 2011-11-11 14:52:16.000000000 +0100
+++ new/shorewall-lite-4.4.26/manpages/shorewall-lite.xml 2011-12-02 17:03:22.000000000 +0100
@@ -41,6 +41,19 @@
</cmdsynopsis>
<cmdsynopsis>
+ <command>shorewall</command>
+
+ <option>trace</option>|<option>debug</option><arg><option>nolock</option></arg></arg>
+
+ <arg>-<replaceable>options</replaceable></arg>
+
+ <arg choice="plain"><option>disable</option></arg>
+
+ <arg choice="plain"><replaceable>interface</replaceable></arg>
+ </cmdsynopsis>
+
+ <cmdsynopsis>
<command>shorewall-lite</command>
<option>trace</option>|<option>debug</option><arg><option>nolock</option></arg></arg>
+
+ <arg>-<replaceable>options</replaceable></arg>
+
+ <arg choice="plain"><option>enable</option></arg>
+
+ <arg choice="plain">{ <replaceable>interface</replaceable> |
+ <replaceable>provider</replaceable> }</arg>
+ </cmdsynopsis>
+
+ <cmdsynopsis>
<command>shorewall-lite</command>
<arg choice="opt"><option>trace</option>|<option>debug</option></arg>
@@ -458,6 +486,18 @@
</varlistentry>
<varlistentry>
+ <term><emphasis role="bold">disable</emphasis></term>
+
+ <listitem>
+ <para>Added in Shorewall 4.4.26. Disables the optional provider
+ associated with the specified <replaceable>interface</replaceable>
+ or <replaceable>provider</replaceable>. Where more than one provider
+ share a single network interface, a
+ <replaceable>provider</replaceable> name must be given.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><emphasis role="bold">drop</emphasis></term>
<listitem>
@@ -481,6 +521,18 @@
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><emphasis role="bold">enable</emphasis></term>
+
+ <listitem>
+ <para>Added in Shorewall 4.4.26. Enables the optional provider
+ associated with the specified <replaceable>interface</replaceable>
+ or <replaceable>provider</replaceable>. Where more than one provider
+ share a single network interface, a
+ <replaceable>provider</replaceable> name must be given.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><emphasis role="bold">forget</emphasis></term>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/releasenotes.txt new/shorewall-lite-4.4.26/releasenotes.txt
--- old/shorewall-lite-4.4.25.3/releasenotes.txt 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-lite-4.4.26/releasenotes.txt 2011-12-02 16:57:59.000000000 +0100
@@ -1,6 +1,6 @@
----------------------------------------------------------------------------
- S H O R E W A L L 4 . 4 . 2 5 . 3
+ S H O R E W A L L 4 . 4 . 2 6
----------------------------------------------------------------------------
I. PROBLEMS CORRECTED IN THIS RELEASE
@@ -14,296 +14,273 @@
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
----------------------------------------------------------------------------
-4.4.25.3
+1) This release includes all corrections included in 4.4.25.1 through
+ .3.
-1) Previously, the following configuration produced an incorrect
- ruleset:
+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.
- zones:
-
- host firewall
- uw ipv4
- net ipv4
-
- interfaces:
-
- - enet detect physical=+
-
- hosts:
-
- net enet:0.0.0.0/0
- uw enet:$N_ALL_UW_AFFILIATED
-
- Here's an example of the problem; from 'shorewall show INPUT':
-
- Chain INPUT (policy DROP 0 packets, 0 bytes)
- pkts bytes target prot opt in out source ...
- 1678 54427 dynamic all -- * * 0.0.0.0/0 ...
- 33631 4085K enet_in all -- * * 0.0.0.0/0 ...
- 0 0 ACCEPT all -- lo * 0.0.0.0/0 ...
- 0 0 enet_in all -- * * 0.0.0.0/0 ...
- ...
+----------------------------------------------------------------------------
+ I I. K N O W N P R O B L E M S R E M A I N I N G
+----------------------------------------------------------------------------
- Note that the ACCEPT rule for the loopback device occurs after
- an unconditional jump to 'enet_in' and that there are two
- such jumps.
+1) On systems running Upstart, shorewall-init cannot reliably secure
+ the firewall before interfaces are brought up.
- Now, this sequence is generated:
+----------------------------------------------------------------------------
+ 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
+----------------------------------------------------------------------------
- Chain INPUT (policy DROP 0 packets, 0 bytes)
- pkts bytes target prot opt in out source ...
- 1678 54427 dynamic all -- * * 0.0.0.0/0 ...
- 0 0 ACCEPT all -- lo * 0.0.0.0/0 ...
- 33631 4085K enet_in all -- * * 0.0.0.0/0 ...
- ...
+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.
-2) The Debian init scripts (with the exception of Shorewall-init) now
+3) The Debian init files (with the exception of Shorewall-init) now
support the 'status' command.
-4.4.25.2
+4) This release formalizes the feature that has long been
+ documented at http://www.shorewall.net/PacketMarking.html#Values.
-1) Previously, if all the following were true:
+ 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.
- - AUTOMAKE=Yes
- - Current compiled script (/var/lib/shorewall/firewall or
- /var/lib/shorewall6/firewall) up to date
- - LEGACY_FASTSTART=No
- - There was a saved configuration
+ TC_BITS
- then rather than start the current configuration, 'shorewall start
- -f' or 'shorewall6 start -f' would incorrectly restore the saved
- configuration.
+ The number of bits at the least-significant end of the mark
+ to be used for traffic shaping marking. May be zero.
-2) The DropSmurfs and TCPFlags actions are now available in
- Shorewall6. They were previously omitted from the IPv6 actions.std
- file.
+ PROVIDER_BITS
-3) The 'rawpost' table was previously omitted from the output of the
- 'dump' command. It is now displayed.
+ The number of bits in the mark to be used for provider
+ marks. May be zero.
-4) Previously, if a configuration contained more than one wildcard
- interface (physical name ending in '+'), then the generated script
- might not work properly with Shorewall-init. This defect dates back
- to the introduction of Shorewall-init.
+ PROVIDER_OFFSET
- Example:
+ 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.
- ZONE INTERFACE BROADCAST OPTIONS
- z1 eth+ - optional
- z2 veth+ - optional
+ MASK_BITS
- The script will contain a case statement of this form:
+ 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).
- case $interface in
- ...
- eth*|veth+)
- ...
+ Beginning with Shorewall 4.4.12, the field between MASK_BITS and
+ PROVIDER_OFFSET can be used for any purpose you want.
-4.4.25.1
+ 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.
-1) A 'refresh' command with no chains or tables specified will now
- reload chains created by entries in the BLACKLIST section of the
- rules file.
+ 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.
-2) The rules compiler previously failed to detect the 'Flow Filter'
- capability. That capability is now correctly detected.
+ The 'shorewall update' ('shorewall6 update') command will supply
+ values for these options based on the settings of WIDE_TC_MARKS and
+ HIGH_ROUTE_MARKS.
-3) The IN_BANDWIDTH handling change in 4.4.25 was incompatible with
- moribund distributions such as RHEL4. Restoring IN_BANDWIDTH
- functionality on those releases required a new 'Basic Filter'
- capability.
-
-4.4.25
+ The 'shorewall show marks' ('shorewall6 show marks') command shows
+ the range of each field in both decimal and hex.
-1) A defect in the optimizer that allowed incompatible rules to be
- combined has been corrected.
+ Example (TC_BITS=0, MASK_BITS=0, PROVIDER_BITS=2,
+ PROVIDER_OFFSET=16, ZONE_BITS=4):
- Example:
+ Shorewall 4.4.26 - Mark Layout at gw - Sun Nov 20
+ 2:08:23 PST 2011
- Rule1: -i eth1 -j chainx
- Rule in chainx: -i eth2 -j ACCEPT
- Incorrect result: -i eth2 -j ACCEPT
+ 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
- With the change in this release, Rule1 will remain as it is.
+ As of this release WIDE_TC_MARKS and HIGH_ROUTE_MARKS are
+ deprecated.
-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.
+5) This release introduces limited support for using back-to-back veth
+ devices to access a bridge.
-3) Previously, capital letters were disallowed in IPv6 addresses. They
- are now permitted.
+ Consider this setup:
-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:
+ -- eth1 (zone1)
+ /
+ WAN ---- eth0 veth0 <-> veth1-- br0 --- eth2 (zone2)
+ \
+ -- eth3 (zone3)
- Either "to" is duplicate, or "cache" is garbage
+ In this configuration, it is veth0 that has an IP address; the
+ bridge does not.
-5) When copying IPv6 routes, the generated script previously attempted
- to copy 'cache' entries. Those entries are now omitted.
+ 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.
-6) Previously, the use of large provider numbers could cause some
- Shorewall-generated routing rules to be ineffective.
+ 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:
- Example (provider numbers 110 and 120):
+ a) Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the
+ destination zone is 'portal'.
- 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 <===========
+ b) Between veth0 and the final destination. The source zone is
+ bridge and the destination zone is either fw or net.
- Now, all routing rules generated by provider interface IP (and IP6)
- addresses are created at priority 20000.
+ A similar scenario occurs with traffic originating in the net or
+ firewall zones and destined for zone1-zone3.
- 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
+ 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.
-7) In some contexts, IPv6 addresses of the form ::i.j.k.l were
- incorrectly classified as invalid by the configuration compiler.
+ The solution allows us to know the real source zone during the
+ second traversal.
-----------------------------------------------------------------------------
- I I. K N O W N P R O B L E M S R E M A I N I N G
-----------------------------------------------------------------------------
+ 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.
-1) On systems running Upstart, shorewall-init cannot reliably secure
- the firewall before interfaces are brought up.
+ 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.
-----------------------------------------------------------------------------
- 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
-----------------------------------------------------------------------------
+ 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.
-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.
+ 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:
- 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).
+ ACCEPT bridge net ... ; mark=zone2
- 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
+ to control connections from zone2 to the net, and rules such as
- /etc/shorewall/rules:
+ ACCEPT portal zone1 ...; mark=net
- SECTION NEW
- DROP:info wlan:!+macipmap all
+ to control connections from the net to zone1.
-2) '6in4' has been added as a synonum for '6to4' in the TYPE column of
- the tunnels file.
+ One final note; DNAT rules should be placed in the first traversal
+ (net->bridge on input).
-3) The handling of IN_BANDWIDTH in both /etc/shorewall/tcdevices and
- /etc/shorewall/tcinterfaces has been changed. Previously:
+ See http://www.shorewall.net/bridge-Shorewall-perl for a fuller
+ example.
- a) Simple rate/burst policing was applied using the value(s)
- supplied.
+6) This release introduces optimization category 16. When this
+ category is enabled, sequences of 'compatible' rules are combined
+ into a single rule.
- b) IPv4 and IPv6 were policed separately.
+ A sequence of rules is considered compatible if the rules differ
+ only in their destination ports and comments.
- 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.
+ A sequence of combatible rules is often generated when macros are
+ invoked in sequence.
- You specify an estimeting filter by preceding the IN-BANDWIDTH with
- a tilde ('~').
+ The ability to combine adjacent rules is limited by two factors:
- Example: ~40mbit
+ - Destination port lists may only be combined up to a maximum of 15
+ ports, where a port-pair counts as two ports.
- This example limits incoming traffic to an *average* rate of 40mbit.
+ - Rules may only be combined until the length of their concatinated
+ comments reach 255 characters.
- There are two other other parameters that can be specified, in
- addition to the average rate - <interval> and
- . There is an excellent description of these
- parameters in the document referenced above.
+ 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.
- Example: ~40mbit:1sec:8sec
+ 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'.
- In that example, the <interval> is 1 second and the
- is 8 seconds. If not given, the default values are
- 250ms and 4 seconds. Both parameters must be supplied if either is
- supplied.
+ Example 1: Rules with comments "FOO", <empty> and "BAR" would
+ result in the combined comment "FOO and others, BAR".
- 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.
+ Example 2: Rules with comments <empty>, "FOO" and "BAR" would reult
+ in the combined comment "Others and FOO, BAR".
-4) Shorewall6 now supports the 'balance' and 'fallback' provider
- options. These options are restricted to one interface per
- configuration for each option.
+ Note: Optimize level 16 requires "Extended Multi-port Match" in your
+ iptables and kernel.
-5) The scripts generated by Shorewall6 now support the 'enable' and
- 'disable' commands.
+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.
-6) A 'MARK' column has been added to the route_rules file. See
- shorewall-route_rules (5) and shorewall6-route_rules (5) for
- details.
+ 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.
----------------------------------------------------------------------------
I V. R E L E A S E 4 . 4 H I G H L I G H T S
@@ -520,27 +497,271 @@
where 'iface' is a capitalized interface name (e.g., ETH0) and
'provider' is the capitalized name of a provider.
-15) Support for the OPTIONS column in /etc/shorewall/blacklist
- (/etc/shorewall6/blacklist) has been removed. Blacklisting by
- destination IP address will be included in a later Shorewall
- release.
-
-16) If your /etc/shorewall/params (or /etc/shorewall6/params) file
+15) If your /etc/shorewall/params (or /etc/shorewall6/params) file
sends output to Standard Output, you need to be aware that the
output will be redirected to Standard Error beginning with
Shorewall 4.4.16.
-17) Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
+16) Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
deprecated. With EXPORTPARAMS=No, the variables set by
/etc/shorewall/params (/etc/shorewall6/params) at compile time are
now available in the compiled firewall script.
-18) The 'iprange' and 'ipaddr' commands require the 'bc' utility.
+17) The 'iprange' and 'ipaddr' commands require the 'bc' utility.
+
+18) Beginning with Shorewall 4.4.26, the WIDE_TC_MARKS and
+ HIGH_ROUTE_MARKS options are deprecated in favor of TC_BITS,
+ MARK_BITS, PROVIDER_BITS and PROVIDER_OFFSET. The 'shorewall
+ update' ('shorewall6 update') command will set these net options
+ based on the values of the deprecated ones.
----------------------------------------------------------------------------
V I. P R O B L E M S C O R R E C T E D A N D N E W F E A T U R E S
I N P R I O R R E L E A S E S
----------------------------------------------------------------------------
+ P R O B L E M S C O R R E C T E D I N 4 . 4 . 2 5
+----------------------------------------------------------------------------
+
+4.4.25.2
+
+1) Previously, if all the following were true:
+
+ - AUTOMAKE=Yes
+ - Current compiled script (/var/lib/shorewall/firewall or
+ /var/lib/shorewall6/firewall) up to date
+ - LEGACY_FASTSTART=No
+ - There was a saved configuration
+
+ then rather than start the current configuration, 'shorewall start
+ -f' or 'shorewall6 start -f' would incorrectly restore the saved
+ configuration.
+
+2) The DropSmurfs and TCPFlags actions are now available in
+ Shorewall6. They were previously omitted from the IPv6 actions.std
+ file.
+
+3) The 'rawpost' table was previously omitted from the output of the
+ 'dump' command. It is now displayed.
+
+4) Previously, if a configuration contained more than one wildcard
+ interface (physical name ending in '+'), then the generated script
+ might not work properly with Shorewall-init. This defect dates back
+ to the introduction of Shorewall-init.
+
+ Example:
+
+ ZONE INTERFACE BROADCAST OPTIONS
+ z1 eth+ - optional
+ z2 veth+ - optional
+
+ The script will contain a case statement of this form:
+
+ case $interface in
+ ...
+ eth*|veth+)
+ ...
+
+4.4.25.1
+
+1) A 'refresh' command with no chains or tables specified will now
+ reload chains created by entries in the BLACKLIST section of the
+ rules file.
+
+2) The rules compiler previously failed to detect the 'Flow Filter'
+ capability. That capability is now correctly detected.
+
+3) The IN_BANDWIDTH handling change in 4.4.25 was incompatible with
+ moribund distributions such as RHEL4. Restoring IN_BANDWIDTH
+ functionality on those releases required a new 'Basic Filter'
+ capability.
+
+4.4.25
+
+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.
+
+
+----------------------------------------------------------------------------
+ N E W F E A T U R E S I N 4 . 4 . 2 5
+----------------------------------------------------------------------------
+
+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
+ . 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
+ 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.
+
+----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 2 4
----------------------------------------------------------------------------
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/shorewall-lite new/shorewall-lite-4.4.26/shorewall-lite
--- old/shorewall-lite-4.4.25.3/shorewall-lite 2011-11-11 14:31:44.000000000 +0100
+++ new/shorewall-lite-4.4.26/shorewall-lite 2011-12-02 16:36:23.000000000 +0100
@@ -365,8 +365,10 @@
echo " allow <address> ..."
echo " clear"
echo " delete <interface>[:<host-list>] ... <zone>"
+ echo " disable <interface>"
echo " drop <address> ..."
echo " dump [ -x ]"
+ echo " enable <interface>"
echo " forget [ <file name> ]"
echo " help"
echo " ipcalc { <address>/<vlsm> | <address> <netmask> }"
@@ -664,7 +666,7 @@
;;
status)
[ $# -eq 1 ] || usage 1
- [ "$(id -u)" != 0 ] && fatal_error "ERROR: The status command may only be run by root"
+ [ "$(id -u)" != 0 ] && fatal_error "The status command may only be run by root"
echo "Shorewall Lite $SHOREWALL_VERSION Status at $g_hostname - $(date)"
echo
if shorewall_is_started ; then
@@ -754,6 +756,14 @@
shift
add_command $@
;;
+ disable|enable)
+ get_config Yes
+ if shorewall_is_started; then
+ run_it ${VARDIR}/firewall $g_debugging $@
+ else
+ fatal_error "Shorewall is not running"
+ fi
+ ;;
save)
[ -n "$debugging" ] && set -x
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/shorewall-lite.spec new/shorewall-lite-4.4.26/shorewall-lite.spec
--- old/shorewall-lite-4.4.25.3/shorewall-lite.spec 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-lite-4.4.26/shorewall-lite.spec 2011-12-02 16:57:59.000000000 +0100
@@ -1,6 +1,6 @@
%define name shorewall-lite
-%define version 4.4.25
-%define release 3
+%define version 4.4.26
+%define release 0base
Summary: Shoreline Firewall Lite is an iptables-based firewall for Linux systems.
Name: %{name}
@@ -103,10 +103,18 @@
%doc COPYING changelog.txt releasenotes.txt
%changelog
-* Thu Nov 10 2011 Tom Eastep tom@shorewall.net
-- Updated to 4.4.25-3
-* Thu Nov 03 2011 Tom Eastep tom@shorewall.net
-- Updated to 4.4.25-2
+* Tue Nov 29 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0base
+* Sun Nov 20 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0RC1
+* Sat Nov 19 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta4
+* Thu Nov 17 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta3
+* Sat Nov 12 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta2
+* Wed Nov 02 2011 Tom Eastep tom@shorewall.net
+- Updated to 4.4.26-0Beta1
* Sun Oct 30 2011 Tom Eastep tom@shorewall.net
- Updated to 4.4.25-1
* Thu Oct 27 2011 Tom Eastep tom@shorewall.net
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-lite-4.4.25.3/uninstall.sh new/shorewall-lite-4.4.26/uninstall.sh
--- old/shorewall-lite-4.4.25.3/uninstall.sh 2011-11-11 14:46:56.000000000 +0100
+++ new/shorewall-lite-4.4.26/uninstall.sh 2011-12-02 16:57:59.000000000 +0100
@@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Shorewall Firewall
-VERSION=4.4.25.3
+VERSION=4.4.26
usage() # $1 = exit status
{
++++++ shorewall-4.4.25.3.tar.bz2 -> shorewall6-4.4.26.tar.bz2 ++++++
++++ 100617 lines of diff (skipped)
++++++ shorewall-lite-4.4.25.3.tar.bz2 -> shorewall6-lite-4.4.26.tar.bz2 ++++++
++++ 10276 lines of diff (skipped)
--
To unsubscribe, e-mail: opensuse-commit+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-commit+help@opensuse.org