Hello community, here is the log from the commit of package shorewall for openSUSE:Factory checked in at 2012-01-19 09:44:39 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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-12-15 16:07:48.000000000 +0100 +++ /work/SRC/openSUSE:Factory/.shorewall.new/shorewall.changes 2012-01-19 09:44:41.000000000 +0100 @@ -1,0 +2,82 @@ +Mon Jan 16 14:13:20 UTC 2012 - [email protected] + +- Update to 4.4.27.2. For more details see changelog.txt and + releasenotes.txt + + * A long-standing problem with Shorewall's 'save' facility has + been discovered. The defect can cause rules to be dropped during + 'save' so that they are not available to be reapplied during + 'restore'. This can occur in 'safe-restart' when the prompt is + not acknowledged or when it is acknowledged with 'n'. + + The problem can occur when: + + a) There are IPSEC zones or hosts present; and + b) GOTO Target support is available in the kernel and + iptables. + + Example of rule that will be dropped: + + -A eth2_fwd -m policy --dir in --pol ipsec -g AAA_frwd + + The defective code has been corrected so that rules are no + longer dropped. + + +------------------------------------------------------------------- +Thu Jan 12 19:33:16 UTC 2012 - [email protected] + +- Update to 4.4.27.1. For more details see changelog.txt and + releasenotes.txt + + * When optimization category 4 is used, unconditional jumps at + the end of chains are replaced with the rules in the target + chain. This can result in rulesets that are considerably larger + than necessary. Beginning with this release, replacement will + only occur if: + + a) The jump is the only reference to the target chain; or + b) The target chain contains 3 or less rules. + + * The feature introduced in 4.4.25 that allowed provider names in + the 'enable' and 'disable' commands was only implemented for + 'enable'. It is now implemented for 'disable' as well. + + * When detecting IPv6 global addresses through an interface, + Shorewall6-generated scripts were ignoring addresses beginning + with '3'. + + * A typo in /usr/share/shorewall/prog.header caused an 'awk' script + to fail when saving a multi-hop default route during 'start'. + + * The value '0' is once again accepted in the IN_BANDWIDTH + columns of tcinterfaces and tcrules, and causes no ingress + policing to be configured. + + * MARK_IN_FORWARD_CHAIN=Yes no longer generates an error when + $FW:<address> is entered in the SOURCE column of the tcrules + file. + + * In most Shorewall 4.4 versions, if an exported params file + (EXPORTPARAMS=Yes in shorewall.conf) generates any output to + stdout, then the following messages would appear during + start/restart: + + Compiling /etc/shorewall/routestopped... + Shorewall configuration compiled to + /var/lib/shorewall/.restart + printf: 214: Build: expected numeric value + printf: 214: ipset: expected numeric value + printf: 214: of: expected numeric value + Processing /etc/shorewall/params ... + Build ipset of blacklisted addresses + Usage: /var/lib/shorewall/.restart [ options ] <command> + + <command> is one of: + start + stop + ... + + This has now been corrected. + +------------------------------------------------------------------- @@ -4 +86 @@ -- Update to 4.4.26.1 For more details see chnagelog.txt and +- Update to 4.4.26.1 For more details see changelog.txt and Old: ---- shorewall-4.4.26.1.tar.bz2 shorewall-docs-html-4.4.26.1.tar.bz2 shorewall-init-4.4.26.1.tar.bz2 shorewall-lite-4.4.26.1.tar.bz2 shorewall6-4.4.26.1.tar.bz2 shorewall6-lite-4.4.26.1.tar.bz2 New: ---- shorewall-4.4.27.2.tar.bz2 shorewall-docs-html-4.4.27.2.tar.bz2 shorewall-init-4.4.27.2.tar.bz2 shorewall-lite-4.4.27.2.tar.bz2 shorewall6-4.4.27.2.tar.bz2 shorewall6-lite-4.4.27.2.tar.bz2 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ shorewall.spec ++++++ --- /var/tmp/diff_new_pack.5ft1Yt/_old 2012-01-19 09:44:42.000000000 +0100 +++ /var/tmp/diff_new_pack.5ft1Yt/_new 2012-01-19 09:44:42.000000000 +0100 @@ -1,7 +1,7 @@ # # spec file for package shorewall # -# Copyright (c) 2011 SUSE LINUX Products GmbH, Nuernberg, Germany. +# Copyright (c) 2012 SUSE LINUX Products GmbH, Nuernberg, Germany. # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed @@ -17,7 +17,7 @@ Name: shorewall -Version: 4.4.26.1 +Version: 4.4.27.2 Release: 0 Summary: Shoreline Firewall is an iptables-based firewall for Linux systems License: GPL-2.0 ++++++ shorewall-4.4.26.1.tar.bz2 -> shorewall-4.4.27.2.tar.bz2 ++++++ ++++ 27933 lines of diff (skipped) ++++++ shorewall-docs-html-4.4.26.1.tar.bz2 -> shorewall-docs-html-4.4.27.2.tar.bz2 ++++++ ++++ 6200 lines of diff (skipped) ++++++ shorewall-init-4.4.26.1.tar.bz2 -> shorewall-init-4.4.27.2.tar.bz2 ++++++ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.26.1/changelog.txt new/shorewall-init-4.4.27.2/changelog.txt --- old/shorewall-init-4.4.26.1/changelog.txt 2011-12-13 15:49:28.000000000 +0100 +++ new/shorewall-init-4.4.27.2/changelog.txt 2012-01-14 16:47:41.000000000 +0100 @@ -1,15 +1,72 @@ -Changes in 4.4.26.1 +Changes in 4.4.27.2 -1) Belatedly update module versions. +1) Correct problem that can drop rules during 'save'. + +Changes in 4.4.27.1 + +1) Don't replicate long chains. + +2) Make 'debug' and 'trace' work in the Lite products. + +3) Allow Provider name in 'disable' command. + +4) Fix uninstall bugs. + +5) Allow output to stdout in an exported params file. + +Changes in 4.4.27 Final + +1) Handle 'audit' when BLACKLIST_LOGLEVEL specified but no audit in + BLACKLIST_DISPOSITION. + +Changes in 4.4.27 RC 2 + +1) Allow chain designator in CLASSIFY rules. + +2) Correct an error message. + +3) Verify helper names and protocols. + +Changes in 4.4.27 RC 1 + +1) Change /sbin/shorewall6 back to a file. -2) Bump CAPVERSION in the compiler. +2) Rename SHOREWALL_DIR -> g_shorewalldir in the shell code. -3) Correct a couple of minor typos. +3) Add USE_PHYSICAL_NAMES option. -4) Apply Chris Boot's patch for TC_ENABLED=Simple +4) Correct 'show ipa'. -5) Restore the quoted part of the 'Provider "..." compiled' progress - message. +5) Correct routing rules for ipv6 providers. + +Changes in 4.4.27 Beta 3 + +1) Merge lib.cli-lite into lib.cli + +2) Allow variables from the .conf file to be used in other config + files. + +3) Remove a redundant capabilities test. + +Changes in 4.4.27 Beta 2 + +1) Unify capability detection + +2) Implement CT target support. + +3) Apply Chris Boot's patch for TC_ENABLED=Shared + +4) Add RELATED_DISPOSITION and RELATED_LOG_LEVEL + +5) More code consolidation + +Changes in 4.4.27 Beta 1 + +1) Combine similar files + +Changes in 4.4.26.1 + +1) Belatedly update module versions. Changes in 4.4.26 Final diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.26.1/install.sh new/shorewall-init-4.4.27.2/install.sh --- old/shorewall-init-4.4.26.1/install.sh 2011-12-13 15:49:28.000000000 +0100 +++ new/shorewall-init-4.4.27.2/install.sh 2012-01-14 16:47:41.000000000 +0100 @@ -23,7 +23,7 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. # -VERSION=4.4.26.1 +VERSION=4.4.27.2 usage() # $1 = exit status { diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.26.1/releasenotes.txt new/shorewall-init-4.4.27.2/releasenotes.txt --- old/shorewall-init-4.4.26.1/releasenotes.txt 2011-12-13 15:49:28.000000000 +0100 +++ new/shorewall-init-4.4.27.2/releasenotes.txt 2012-01-14 16:47:41.000000000 +0100 @@ -1,6 +1,5 @@ - ---------------------------------------------------------------------------- - S H O R E W A L L 4 . 4 . 2 6 . 1 + S H O R E W A L L 4 . 4 . 2 7 . 2 ---------------------------------------------------------------------------- I. PROBLEMS CORRECTED IN THIS RELEASE @@ -14,293 +13,206 @@ 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.26.1 - -1) The Perl module version numbers have now been updated to reflect - changes in 4.4.26. - -2) The 4.4.26 rules compiler does not issue a warning when a - capabilities file was generated with Shorewall 4.4.25, even though - new capabilities were added in 4.4.26. This has been corrected so - that a warning is generated. - -3) When TC_ENABLED=Shared, CLASSIFY rules could not be used in the - tcrules file. Thanks to a patch from Chris Boot, this now works as - expected. - -4) The quoted part of the progress message 'Provider "..." compiled' - was inadvertently omitted by a change in Shorewall 4.4.23. That - text has now been restored. - -4.4.26 - -1) This release includes all corrections included in 4.4.25.1 through - .3. - -2) In 4.4.25, ACCEPT behaved in the BLACKLIST section the same way as - in the other rules file sections. This could lead to connections - being accepted inadvertently. - - Now, ACCEPT behaves like WHITELIST; that is, it exempts the packet - from the remaining rules in the BLACKLIST section. - -3) Previously, Shorewall did not detect the ULOG and NFLOG - capabilities. This lead to run-time failures during 'start' and - 'restart' as well as confusing error messages during compilation - when ULOG or NFLOG was used when the LOG target was not available. - - ULOG and NFLOG are now detected capabilities so, if you use a - capabilities file, you will need to regenerate it in order to use - these log levels. - -4) The SAME tcrules target was broken in Shorewall 4.4.22. It now - works correctly again. - -5) Previously, 'shorewall6 update' did not update shorewall6.conf. The - command now works as expected. - -6) In earlier releases, the compiler was attempting to process the - params file before it was aware of the setting of CONFIG_PATH. This - could cause the params file to be missed if it was not located in - /etc/shorewall[6] or in the directory named in the start - (restart,compile,check,...) command. - - Now, /sbin/shorewall[6] passes $CONFIG_PATH to the compiler - (/usr/share/shorewall/compiler.pl) in the new '--config_path' - option. - ----------------------------------------------------------------------------- - I I. K N O W N P R O B L E M S R E M A I N I N G ----------------------------------------------------------------------------- - -1) On systems running Upstart, shorewall-init cannot reliably secure - the firewall before interfaces are brought up. - ----------------------------------------------------------------------------- - I I I. N E W F E A T U R E S I N T H I S R E L E A S E ----------------------------------------------------------------------------- - -1) A new 'blrules' file has been added as an alternative to rules in - the BLACKLIST section of the rules file. When rules are present in - both the blrules file and in the BLACKLIST section, those in - blrules are processed first. - -2) A '-b' option has been added to the 'update' command. In addition - to updating the shorewall.conf file (shorewall6.conf), this option - causes the compiler to convert your current legacy blacklist - configuration to use the new blrules file. - - Changes include: - - a) blrules is populated with entries equivalent to your existing - blacklist file. - - b) Your existing blacklist file is renamed blacklist.bak. +4.4.27.2 - 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. +1) A long-standing problem with Shorewall's 'save' facility has been + discovered. The defect can cause rules to be dropped during 'save' + so that they are not available to be reapplied during + 'restore'. This can occur in 'safe-restart' when the prompt is not + acknowledged or when it is acknowledged with 'n'. - 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. + The problem can occur when: -3) The Debian init files (with the exception of Shorewall-init) now - support the 'status' command. + a) There are IPSEC zones or hosts present; and + b) GOTO Target support is available in the kernel and iptables. -4) This release formalizes the feature that has long been - documented at http://www.shorewall.net/PacketMarking.html#Values. + Example of rule that will be dropped: - 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. + -A eth2_fwd -m policy --dir in --pol ipsec -g AAA_frwd - TC_BITS + The defective code has been corrected so that rules are no longer + dropped. - The number of bits at the least-significant end of the mark - to be used for traffic shaping marking. May be zero. +4.4.27.1 - PROVIDER_BITS +1) When optimization category 4 is used, unconditional jumps at the + end of chains are replaced with the rules in the target chain. This + can result in rulesets that are considerably larger than + necessary. Beginning with this release, replacement will only occur + if: - The number of bits in the mark to be used for provider - marks. May be zero. + a) The jump is the only reference to the target chain; or + b) The target chain contains 3 or less rules. - PROVIDER_OFFSET +2) The feature introduced in 4.4.25 that allowed provider names in the + 'enable' and 'disable' commands was only implemented for + 'enable'. It is now implemented for 'disable' as well. - 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. +3) When detecting IPv6 global addresses through an interface, + Shorewall6-generated scripts were ignoring addresses beginning + with '3'. - MASK_BITS +4) A typo in /usr/share/shorewall/prog.header caused an 'awk' script + to fail when saving a multi-hop default route during 'start'. - 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). +5) The Shorewall uninstall.sh script previously removed the manpages + from all Shorewall packages. Similarly, the Shorewall6 uninstall.sh + script removed the Shorewall6 Lite manpages along with the + Shorewall6 manpages. Now, both scripts remove just the manpages + from their respective packages. - Beginning with Shorewall 4.4.12, the field between MASK_BITS and - PROVIDER_OFFSET can be used for any purpose you want. +6) The value '0' is once again accepted in the IN_BANDWIDTH columns of + tcinterfaces and tcrules, and causes no ingress policing to be + configured. - 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. +7) MARK_IN_FORWARD_CHAIN=Yes no longer generates an error when + $FW:<address> is entered in the SOURCE column of the tcrules 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. +8) In most Shorewall 4.4 versions, if an exported params file + (EXPORTPARAMS=Yes in shorewall.conf) generates any output to + stdout, then the following messages would appear during + start/restart: - The 'shorewall update' ('shorewall6 update') command will supply - values for these options based on the settings of WIDE_TC_MARKS and - HIGH_ROUTE_MARKS. + Compiling /etc/shorewall/routestopped... + Shorewall configuration compiled to /var/lib/shorewall/.restart + printf: 214: Build: expected numeric value + printf: 214: ipset: expected numeric value + printf: 214: of: expected numeric value + Processing /etc/shorewall/params ... + Build ipset of blacklisted addresses + Usage: /var/lib/shorewall/.restart [ options ] <command> - The 'shorewall show marks' ('shorewall6 show marks') command shows - the range of each field in both decimal and hex. + <command> is one of: + start + stop + ... - Example (TC_BITS=0, MASK_BITS=0, PROVIDER_BITS=2, - PROVIDER_OFFSET=16, ZONE_BITS=4): + This has now been corrected. - Shorewall 4.4.26 - Mark Layout at gw - Sun Nov 20 - 2:08:23 PST 2011 +4.4.27 - 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 +1) Shorewall 4.4.27 includes all defect corrections provider by + Shorewall 4.4.26.1. - As of this release WIDE_TC_MARKS and HIGH_ROUTE_MARKS are - deprecated. +2) When TC_ENABLED=Shared, CLASSIFY rules could not previously be used + in the tcrules file. Thanks to a patch from Chris Boot, this now + works as expected. -5) This release introduces limited support for using back-to-back veth - devices to access a bridge. +3) When providers were used in an IPv6 configuration, each time that + Shorewall6 was started or restarted, entries as follows would be + added to the IPv4 (!) routing rules: - Consider this setup: + 32767: from all lookup default - -- eth1 (zone1) - / - WAN ---- eth0 veth0 <-> veth1-- br0 --- eth2 (zone2) - \ - -- eth3 (zone3) + One such entry would be added for each provider. - In this configuration, it is veth0 that has an IP address; the - bridge does not. + Now, one such an entry is added to the IPv6 routing rules, only if + that entry does not already exist. - 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. +4) The formatting of the manpage info in the annotated configuration + files has been improved dramatically. - 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: +5) A blrules file generated by 'update -b' would fail the compilation + step with + + ERROR: Unknown ACTION (A_blacklog) - a) Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the - destination zone is 'portal'. + if all the following were true: - b) Between veth0 and the final destination. The source zone is - bridge and the destination zone is either fw or net. + a) BLACKLIST_DISPOSITION did not specify an audited disposition. + b) BLACKLIST_LOGLEVEL was specified + c) The 'audit' option appeared in one or more blacklist entries. - A similar scenario occurs with traffic originating in the net or - firewall zones and destined for zone1-zone3. +---------------------------------------------------------------------------- + I I. K N O W N P R O B L E M S R E M A I N I N G +---------------------------------------------------------------------------- - 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. +1) On systems running Upstart, shorewall-init cannot reliably secure + the firewall before interfaces are brought up. - The solution allows us to know the real source zone during the - second traversal. +---------------------------------------------------------------------------- + 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 +---------------------------------------------------------------------------- - 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) Up to this point, Shorewall has had a lot of very similar files in + multiple products. - 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. + Beginning with this release, the following files are identical. - 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. + - /sbin/shorewall + - /sbin/shorewall6 + - /sbin/shorewall-lite + - /sbin/shorewall6-lite - 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: + The program uses it's own file name to determine which role it is + to assume. It does that by initializing variables that are later + used within the various libraries. - ACCEPT bridge net ... ; mark=zone2 + Shorewall and Shorewall6 share use of /usr/share/shorewall/lib.base + /usr/share/shorewall/lib.cli, and /usr/share/shorewall/lib.common. - to control connections from zone2 to the net, and rules such as + /usr/share/shorewall6/lib.base is a small file that sets variables + and then sources /usr/share/shorewall/lib.base. - ACCEPT portal zone1 ...; mark=net + As before, shorewall and shorewall-lite share the same libraries + as do shorewall6 and shorwall6-lite. - to control connections from the net to zone1. + Shorewall includes a new library: /usr/share/shorewall/lib.cli-std. + /usr/share/shorewall[6]/lib.cli contains everything needed by the + Lite products. - One final note; DNAT rules should be placed in the first traversal - (net->bridge on input). +2) Shorewall now supports the CT target in the Netfilter 'raw' + table. See 'man shorewall-notrack' for details. - See http://www.shorewall.net/bridge-Shorewall-perl for a fuller - example. + The main use of this target is described in this paper: + http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf. -6) This release introduces optimization category 16. When this - category is enabled, sequences of 'compatible' rules are combined - into a single rule. + The paper a product of the vulnerability described in the 4.4.20 + release note which introduced the 'sfilter' facility. In the paper, + rules such as the following are recommended: - A sequence of rules is considered compatible if the rules differ - only in their destination ports and comments. + iptables -A PREROUTING -t raw -p tcp --dport 2121 \ + -d 1.2.3.4 -j CT --helper ftp - A sequence of combatible rules is often generated when macros are - invoked in sequence. + The equivalent entry in /etc/shorewall/notrack would be: - The ability to combine adjacent rules is limited by two factors: + #ACTION SOURCE DEST PROTO DEST + # PORT(S) + CT:helper:ftp 1.2.3.4 - tcp 2121 - - Destination port lists may only be combined up to a maximum of 15 - ports, where a port-pair counts as two ports. + As part of this change, Shorewall now verifies the helper name in + the HELPER column of the tcrules and tcpri files. - - Rules may only be combined until the length of their concatinated - comments reach 255 characters. +3) The above-referenced paper also advocates careful control of + RELATED rules. To allow such control, two new options have been + introduced in shorewall[6].conf: - 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. + - RELATED_DISPOSITION - 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'. + May be ACCEPT, A_ACCEPT, A_DROP, A_REJECT, DROP or REJECT. For + compatibility with earlier releases, the default is ACCEPT. + match any rule in the RELATED section of the rules file. - Example 1: Rules with comments "FOO", <empty> and "BAR" would - result in the combined comment "FOO and others, BAR". + - RELATED_LOG_LEVEL - Example 2: Rules with comments <empty>, "FOO" and "BAR" would reult - in the combined comment "Others and FOO, BAR". + Specifies a level for logging related packets. Default is empty + which means that no logging occurs. - Note: Optimize level 16 requires "Extended Multi-port Match" in your - iptables and kernel. +4) The options in shorewall.conf (shorewall6.conf) may now be used as + shell variables in other configuration files. -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. +5) A new option, USE_PHYSICAL_NAMES, has been added to shorewall.conf + and shorewall6.conf. Normally, when the rules compiler creates a + Netfilter chain that relates to an interface, the logical name of + the interface is used as the base for the chain name. For example, + if an interface has logical name OAKLAND and physical name eth0, + then the primary chain for input arriving on that interface is + normally 'OAKLAND_in'. When USE_PHYSICAL_NAMES=Yes, the name would + be 'eth0_in'. - 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. +6) CLASSIFY entries in tcrules may now be placed in the FORWARD or + PREROUTING chain by following the class Id with :F or :P + respectively. ---------------------------------------------------------------------------- I V. R E L E A S E 4 . 4 H I G H L I G H T S @@ -539,6 +451,291 @@ 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 6 +---------------------------------------------------------------------------- + +4.4.26.1 + +1) The Perl module version numbers have now been updated to reflect + changes in 4.4.26. + +2) The 4.4.26 rules compiler does not issue a warning when a + capabilities file was generated with Shorewall 4.4.25, even though + new capabilities were added in 4.4.26. This has been corrected so + that a warning is generated. + +3) When TC_ENABLED=Shared, CLASSIFY rules could not be used in the + tcrules file. Thanks to a patch from Chris Boot, this now works as + expected. + +4) The quoted part of the progress message 'Provider "..." compiled' + was inadvertently omitted by a change in Shorewall 4.4.23. That + text has now been restored. + +4.4.26 + +1) This release includes all corrections included in 4.4.25.1 through + .3. + +2) In 4.4.25, ACCEPT behaved in the BLACKLIST section the same way as + in the other rules file sections. This could lead to connections + being accepted inadvertently. + + Now, ACCEPT behaves like WHITELIST; that is, it exempts the packet + from the remaining rules in the BLACKLIST section. + +3) Previously, Shorewall did not detect the ULOG and NFLOG + capabilities. This lead to run-time failures during 'start' and + 'restart' as well as confusing error messages during compilation + when ULOG or NFLOG was used when the LOG target was not available. + + ULOG and NFLOG are now detected capabilities so, if you use a + capabilities file, you will need to regenerate it in order to use + these log levels. + +4) The SAME tcrules target was broken in Shorewall 4.4.22. It now + works correctly again. + +5) Previously, 'shorewall6 update' did not update shorewall6.conf. The + command now works as expected. + +6) In earlier releases, the compiler was attempting to process the + params file before it was aware of the setting of CONFIG_PATH. This + could cause the params file to be missed if it was not located in + /etc/shorewall[6] or in the directory named in the start + (restart,compile,check,...) command. + + Now, /sbin/shorewall[6] passes $CONFIG_PATH to the compiler + (/usr/share/shorewall/compiler.pl) in the new '--config_path' + option. + +---------------------------------------------------------------------------- + N E W F E A T U R E S I N 4 . 4 . 2 6 +---------------------------------------------------------------------------- + +1) A new 'blrules' file has been added as an alternative to rules in + the BLACKLIST section of the rules file. When rules are present in + both the blrules file and in the BLACKLIST section, those in + blrules are processed first. + +2) A '-b' option has been added to the 'update' command. In addition + to updating the shorewall.conf file (shorewall6.conf), this option + causes the compiler to convert your current legacy blacklist + configuration to use the new blrules file. + + Changes include: + + a) blrules is populated with entries equivalent to your existing + blacklist file. + + b) Your existing blacklist file is renamed blacklist.bak. + + c) The 'blacklist' keyword is removed from your zones, interfaces + and hosts files. When one of these files is modified, the + unmodified original is saved in a .bak file. + + As part of this change, the 'blacklog' target is permitted in the + blrules file when BLACKLIST_LOG_LEVEL is specified in + shorewall.conf (shorewall6.conf). It logs the packet at the + specified level, then disposes of it based on the setting of + BLACKLIST_DISPOSITION. + +3) The Debian init files (with the exception of Shorewall-init) now + support the 'status' command. + +4) This release formalizes the feature that has long been + documented at http://www.shorewall.net/PacketMarking.html#Values. + + The WIDE_TC_MARKS and HIGH_ROUTE_MARKS options have traditionally + been used to define the various fields in a packet/connection mark. + But more flexible control is provided using these options. + + TC_BITS + + The number of bits at the least-significant end of the mark + to be used for traffic shaping marking. May be zero. + + PROVIDER_BITS + + The number of bits in the mark to be used for provider + marks. May be zero. + + PROVIDER_OFFSET + + The offset from the right (low-order end) of the provider + number field. If non-zero, must be >= TC_BITS. Shorewall + automatically adjusts PROVIDER OFFSETs value to inforce this + restriction. May be zero, in which case the TC mark field + and Provider mark field overlay. + + MASK_BITS + + The number of low-order bits to be masked when clearing the + traffic shaping mark. Must be >= TC_BITS and <= + PROVIDER_OFFSET (provider that PROVIDER_OFFSET > 0). + + Beginning with Shorewall 4.4.12, the field between MASK_BITS and + PROVIDER_OFFSET can be used for any purpose you want. + + Beginning with Shorewall 4.4.13, the first unused bit from the + right is used by Shorewall as an 'exclusion mark' which allows + exclusion in CONTINUE, NONAT and ACCEPT+ rules. + + It is actually the values of the above four options that determine + how Packet/Connection Marks are layed out. Their default values are + derived from the settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS as + shown in the table at + http://www.shorewall.net/PacketMarking.html#Values. + + The 'shorewall update' ('shorewall6 update') command will supply + values for these options based on the settings of WIDE_TC_MARKS and + HIGH_ROUTE_MARKS. + + The 'shorewall show marks' ('shorewall6 show marks') command shows + the range of each field in both decimal and hex. + + Example (TC_BITS=0, MASK_BITS=0, PROVIDER_BITS=2, + PROVIDER_OFFSET=16, ZONE_BITS=4): + + Shorewall 4.4.26 - Mark Layout at gw - Sun Nov 20 + 2:08:23 PST 2011 + + Traffic Shaping: Not Enabled + User:1-65535 (0x1-0xffff) mask 0xffff + Provider:65536-196608 (0x10000-0x30000) mask 0x30000 + Zone:262144-3932160 (0x40000-0x3c0000) mask 0x3c0000 + Exclusion:4194304 mask 0x400000 + + As of this release WIDE_TC_MARKS and HIGH_ROUTE_MARKS are + deprecated. + +5) This release introduces limited support for using back-to-back veth + devices to access a bridge. + + Consider this setup: + + -- eth1 (zone1) + / + WAN ---- eth0 veth0 <-> veth1-- br0 --- eth2 (zone2) + \ + -- eth3 (zone3) + + In this configuration, it is veth0 that has an IP address; the + bridge does not. + + Because veth1 is a port on br0, Netfilter allows filtering between + that interface and each of the other ports. All connections from + the firewall (fw) and the WAN ((net) enter the bridge through + veth1. All traffic from zone1-zone3 enter the routing firewall + through veth0. + + Note that, in this configuration, packets between zones1-zone3 and + the rest of the world go through Netfilter twice. Assume that we + associate veth0 with an ip zone called 'bridge' and veth1 with a + bport zone called 'portal'. Then the two traversals of Netfilter + are: + + a) Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the + destination zone is 'portal'. + + b) Between veth0 and the final destination. The source zone is + bridge and the destination zone is either fw or net. + + A similar scenario occurs with traffic originating in the net or + firewall zones and destined for zone1-zone3. + + As you can see, the problem here is that in the first traversal, we + know the real source zone but not the real destination zone; and in + the second traversal, we know the real destination zone but not the + real source zone. + + The solution allows us to know the real source zone during the + second traversal. + + A new ZONE_BITS option is added to shorewall.conf + (shorewall6.conf). Its value determines the number of bits of the + packet mark to use for zone marks. When ZONE_BITS is non-zero, + Shorewall automatically assigns a mark value to each zone (the + firewall zone always has value 0). Zone marks are assigned to all + zones except those that specify 'nomark' in the OPTION column of + their zones file entry. In the above example, the bridge and portal + zones would have 'nomark' specified. + + With ZONE_BITS and 'nomark' specified appropriately, now each + packet from the 'bridge' zone has a packet mark that lets us know + which of the three bport zones (zone1-zone3) the packet originated + on. + + Similarly, packets entering the bridge through veth1 have a mark + value that records whether the packet is from the net zone or the + fw zone. + + As part of these changes, the compiler now accepts a zone name in + the MARK column of the rules file, when ZONE_BITS is non-zero. This + permits rules of this type: + + ACCEPT bridge net ... ; mark=zone2 + + to control connections from zone2 to the net, and rules such as + + ACCEPT portal zone1 ...; mark=net + + to control connections from the net to zone1. + + One final note; DNAT rules should be placed in the first traversal + (net->bridge on input). + + See http://www.shorewall.net/bridge-Shorewall-perl for a fuller + example. + +6) This release introduces optimization category 16. When this + category is enabled, sequences of 'compatible' rules are combined + into a single rule. + + A sequence of rules is considered compatible if the rules differ + only in their destination ports and comments. + + A sequence of combatible rules is often generated when macros are + invoked in sequence. + + The ability to combine adjacent rules is limited by two factors: + + - Destination port lists may only be combined up to a maximum of 15 + ports, where a port-pair counts as two ports. + + - Rules may only be combined until the length of their concatinated + comments reach 255 characters. + + When either of these limits would be exceeded, the current combined + rule is emitted and the compiler attemts to combine rules beginning + with the one that would have exceeded the limit. + + Adjacent combined comments are separated by ', '. Empty comments at + the front of a group of combined comments are replaced by 'Others + and'. Empty comments at the end of a group of combined comments are + replaced by 'and others'. + + Example 1: Rules with comments "FOO", <empty> and "BAR" would + result in the combined comment "FOO and others, BAR". + + Example 2: Rules with comments <empty>, "FOO" and "BAR" would reult + in the combined comment "Others and FOO, BAR". + + Note: Optimize level 16 requires "Extended Multi-port Match" in your + iptables and kernel. + +7) The 'enable' and 'disable' commands, previously supported only by + the compiled firewall script, are now supported by the CLI programs + (/sbin/shorewall, /sbin/shorewall-lite, etc.) as well. + + In earlier releases, these commands only allowed the provider to be + specified by its physical interface name, thus making it impossible + to enable/disable individual providers sharing a single + interface. The commands now accept a provider name for all optional + providers. For those that share an interface, only the provider + name is accepted. + +---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 4 . 4 . 2 5 ---------------------------------------------------------------------------- diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.26.1/shorewall-init.spec new/shorewall-init-4.4.27.2/shorewall-init.spec --- old/shorewall-init-4.4.26.1/shorewall-init.spec 2011-12-13 15:49:28.000000000 +0100 +++ new/shorewall-init-4.4.27.2/shorewall-init.spec 2012-01-14 16:47:41.000000000 +0100 @@ -1,6 +1,6 @@ %define name shorewall-init -%define version 4.4.26 -%define release 1 +%define version 4.4.27 +%define release 2 Summary: Shorewall-init adds functionality to Shoreline Firewall (Shorewall). Name: %{name} @@ -119,6 +119,22 @@ %doc COPYING changelog.txt releasenotes.txt %changelog +* Mon Jan 09 2012 Tom Eastep [email protected] +- Updated to 4.4.27-2 +* Mon Jan 02 2012 Tom Eastep [email protected] +- Updated to 4.4.27-1 +* Sun Dec 25 2011 Tom Eastep [email protected] +- Updated to 4.4.27-0base +* Fri Dec 23 2011 Tom Eastep [email protected] +- Updated to 4.4.27-0RC2 +* Sat Dec 17 2011 Tom Eastep [email protected] +- Updated to 4.4.27-0RC1 +* Sun Dec 11 2011 Tom Eastep [email protected] +- Updated to 4.4.27-0Beta3 +* Mon Dec 05 2011 Tom Eastep [email protected] +- Updated to 4.4.27-0Beta2 +* Sat Dec 03 2011 Tom Eastep [email protected] +- Updated to 4.4.27-0Beta1 * Sat Dec 03 2011 Tom Eastep [email protected] - Updated to 4.4.26-1 * Tue Nov 29 2011 Tom Eastep [email protected] diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/shorewall-init-4.4.26.1/uninstall.sh new/shorewall-init-4.4.27.2/uninstall.sh --- old/shorewall-init-4.4.26.1/uninstall.sh 2011-12-13 15:49:28.000000000 +0100 +++ new/shorewall-init-4.4.27.2/uninstall.sh 2012-01-14 16:47:41.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.26.1 +VERSION=4.4.27.2 usage() # $1 = exit status { ++++++ shorewall-lite-4.4.26.1.tar.bz2 -> shorewall-lite-4.4.27.2.tar.bz2 ++++++ ++++ 4371 lines of diff (skipped) ++++++ shorewall-4.4.26.1.tar.bz2 -> shorewall6-4.4.27.2.tar.bz2 ++++++ ++++ 105045 lines of diff (skipped) ++++++ shorewall-lite-4.4.26.1.tar.bz2 -> shorewall6-lite-4.4.27.2.tar.bz2 ++++++ ++++ 10184 lines of diff (skipped) -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
