---------------------------------------------------------------------------- S H O R E W A L L 5 . 1 . 4 . 1 ------------------------------ M a y 2 6 , 2 0 1 7 ---------------------------------------------------------------------------- I. PROBLEMS CORRECTED IN THIS RELEASE II. KNOWN PROBLEMS REMAINING III. NEW FEATURES IN THIS RELEASE IV. MIGRATION ISSUES V. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES ---------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------- 5.1.4.1 1) The introductory material in shorewall-rules(5) has been cleaned up. 2) The information about LOGFORMAT in shorewall[6].conf(5) and shorewall[6]-zones(5) has been expanded. In Shorewall 5.1.0, the setting of LOGFORMAT in the default and sample .conf files was changed to "%s:%s " to enable 10-character zone names (up from 5 characters using the default "Shorewall:%s:%s:" setting). As part of this change, if a shorewall.conf file which did not set LOGFORMAT is updated using "shorewall update", LOGFORMAT is set to "Shorewall:%s:%s:" to preserve the existing behavior. This can have an effect on new installations, however in that scipts or log analyzers can no longer be configured to simply look for "Shorewall:" in log messages unless the setting of LOGFORMAT is changed. The manpages (and the Migration Considerations below) have been updated to describe how to locate these messages using the new "%s:%s " setting. 3) The BLACKLIST action was inadvertently omitted from Shorewall6 in Shorewall 5.1.1. That has been corrected. 5.1.4 1) This release contains defect repair through Shorewall 5.1.3.1. 2) Previously, if a Shorewall Variable ( e.g., @chain ) was the target of a conditional ?RESET directive (one that was enclosed in ?if... ?else...?endif logic), the compiler could incorrectly use an existing chain created from the action rather than creating a new (and different) chain. That has been corrected. 3) Previously, if alternate input format specified a column that had already been specified, the contents of that column were silently overwritten. Now, a warning message is issued stating that the prior value has been replaced by the newer value. 4) Previously, a string-valued interface option, such as 'physical', could be given an empty value (e.g., "physical=,"), and the compiler would fail to flag it. Now, this usage raises an error. 5) Previously, the 'tunnel-src' and 'tunnel-dst' zone options would generate an error under Shorewall6. That has been corrected. 6) A number of small documentation corrections have been made. ---------------------------------------------------------------------------- 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. 2) The 'enable', 'reenable' and 'disable' commands do not work correctly in configurations with USE_DEFAULT_RT=No and optional providers listed in the DUPLICATE column. 3) While the 'ip' utility now accepts IPv6 routes with multiple 'nexthop' destinations, these routes are not balanced. They are rather instantiated as a sequence of single routes with different metrics. Furthermore, the 'ip route replace' command fails on such routes. Beginning with Shorewall6 5.0.15, the generated script uses a "delete..add.." sequence on these routes rather than a single "replace" command. ---------------------------------------------------------------------------- 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) All IPv6 standard actions have been deleted and their logic has been added to their IPv4 counterparts who can now handle both address families. 2) Previously, ?error and ?require messages as well as verbose ?info and ?warning messages (those that report the file and line numbers) generated from an action file would report the action file name and line number rather than the file and line number where the action was invoked. The file and line number where the action was invoked were listed second. Beginning with this release, the invoking file and line number are listed first and the action file and line number are not reported. This allows for creation of clearer messages. Example: Previously, when an invalid value was passed for the 'bricks' parameter to the GlusterFS action on line 45 of the rules file, a message such as the following was issued (folded to 76 columns): ERROR: Invalid value for Bricks (2000) /usr/share/shorewall/action.GlusterFS (line 15) from /etc/shorewall/rules (line 45) Note that the message seems to imply that the error is in action.GlusterFS rather than in the rules file. Beginning with this release, the message will be: ERROR: Invalid value (2000) for the GlusterFS Bricks argument /etc/shorewall/rules (line 45) Note: This change only affects actions, including inline actions. Macros will continue to report the old way. 3) IPv6 UPnP support (including MINIUPNPD) is now available. 4) A PERL_HASH_SEED option has been added to allow the Perl hash seed to be specified. See shorewall.conf(5) and perlsec(1) for details. ---------------------------------------------------------------------------- I V. M I G R A T I O N I S S U E S ---------------------------------------------------------------------------- 1) If you are migrating from Shorewall 4.6.x or earlier, please see http://www.shorewall.net/pub/shorewall/5.0/shorewall-5.0.15/releasenotes.txt 2) Shorewall 5.1 now has a single CLI program, ${SBINDIR}/shorewall (normally /sbin/shorewall). This program performs all of the same functions previously performed by /sbin/shorewall, /sbin/shorewall6, /sbin/shorewall-lite and /sbin/shorewall6-lite and is installed as part of the Shorewall-core package. It's default 'personality' is determined by the Shorewall packages installed: a) If the Shorewall package is installed, then by default, /sbin/shorewall behaves as in prior versions. b) If the Shorewall package is not installed, but the Shorewall-lite package is present, then /sbin/shorewall behaves as did /sbin/shorewall-lite in prior versions. c) If neither the Shorewall nor Shorewall-lite packages are installed, but the Shorewall6-lite package is installed, then /sbin/shorewall behaves as did /sbin/shorewall6-lite in prior versions. The program's personality can be altered through use of two new options. -6 When specified, changes the personality from Shorewall to Shorewall6 or from Shorewall-lite to Shorewall6-lite. -l When specified, changes the personality from Shorewall to Shorewall-lite or from Shorewall6 to Shorewall6-lite. This option is only required when both the standard package (Shorewall or Shorewall6) and the corresponding -lite package are installed on the system. The following is a comparison of Shorewall 5.0 and Shorewall 5.1 with respect to the CLI invocation: All four packages installed: Shorewall 5.0 Shorewall 5.1 shorewall shorewall shorewall6 shorewall -6 shorewall-lite shorewall -l shorewall6-lite shorewall -6l Only Shorewall-lite and Shorewall6-lite installed: Shorewall 5.0 Shorewall 5.1 shorewall-lite shorewall shorewall6-lite shorewall -6 A single shorewall(8) manpage now describes the CLI. The shorewall6(8), shorewall-lite(8) and shorewall6-lite(8) manpages are now minimal and refer the reader to shorewall(8). For backward compatibility, Shorewall6, Shorewall-lite and Shorewall6-lite install symlinks $SBINDIR/shorewall6, $SBINDIR/shorewall-lite and $SBINDIR/shorewall6-lite respectively. When the shorewall program is invoked through one of these symlinks, it adopts the appropriate personality. 3) The CHAIN_SCRIPTS option in the .conf files has been eliminated, and the compiler no longer looks for script files with the same name as a chain or action. If you are using such files, you will need to convert them into equivalent ?begin perl .... ?end perl text or to use the IP[6]TABLES target and/or inline matches. For the common case where you have an action xxx with an empty action.xxx file and have perl code in a file named xxx, the compiler will now generate a fatal error: ERROR: File action.xxx is empty and file xxx exists - the two must be combined as described in the Migration Considerations section of the Shorewall release notes For information about resolving this error, see http://www.shorewall.org/Shorewall-5.html#idp41228128. 4) The Netfilter team have removed support for the rawpost table, so Shorewall no longer supports features requiring that table (stateless netmapping in the netmap file). The good news is that, since kernel 3.7, Netfilter supports stateful IPv6 network mapping which is now also supported in Shorewall6 (see shorewall6-netmap(5)). 5) The (undocumented) Makefiles haven't been maintained for many releases and have been removed. 6) Beginning with Shorewall 5.1.2, The DROP_DEFAULT, REJECT_DEFAULT, etc. options may now specify a comma-separated list of actions rather than just a single action. The actions are invoked in the order in which they are listed and each action may optionally be followed by a colon (":") and a log level. The POLICY column in shorewall[6]-policy can now specify a similar list of actions. In that file, the list may be preceded by a plus sign ("+"), in which case the listed actions will be in addition to those listed in the related _DEFAULT setting in shorewall[6].conf. With these changes, the Drop and Reject policy actions are now deprecated in favor of a list of smaller actions. A warning is issued when these deprecated actions are used; the warning refers the reader to http://www.shorewall.net/Actions.html#Default. 7) Beginning with Shorewall 5.1.2, the allowBcast, dropBcast, and Broadcast no longer handle multicast. Multicast is handeled separately in actions allowMcast, dropMcast and Multicast. The now-deprecated Drop and Reject policy actions have been modified so that they continue to silently drop multicast packets. ---------------------------------------------------------------------------- V. N O T E S F R O M O T H E R 5 . 1 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 5 . 1 . 3 ---------------------------------------------------------------------------- 5.1.3.1 1) There was a typo in the BLACKLIST_DEFAULT settings in the 5.1.3 sample config files, which resulted in a compilation error. That typo has been corrected. 2) There was also a typo in the two-interface IPv4 sample snat file; 192.168.0.0/16 was inadvertently entered as 92.168.0.0/16. That has been corrected. 3) Previously, when processing the policy file, 'all+' was incorrectly treated the same as 'all'. That has been corrected so that 'all+' causes intra-zone traffic to be included in the policy. 5.1.3 1) This release includes defect repair for releases through 5.1.2.4. 2) The documentation for 'reload' has been corrected: - A command synopsis has been added in shorewall(8). - The command synopsis in the 'help' output has been corrected. 3) The CONFIG_PATH setting has been corrected in the IPv6 Universal sample configuration. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 2 ---------------------------------------------------------------------------- 1) The tarball installers and uninstallers have been unified and now use a common library that is included in each tarball (Matt Darfuille). 2) The installers now print a diagnostic if the relevant shorewallrc file cannot be loaded (Matt Darfuille). 3) The /etc/default/... files installed on Debian are now dependent on whether systemd is used or not (Matt Darfuille). 4) In Perl 5.8.1 and again in 5.18.0, the Perl developers altered the behavior of the hash function used in the implementation of hashes. The hash key is now chosen randomly as a defense against DOS attacks targeting Perl programs. Such attacks supply input data that causes a single hash bucket to be used. While those changes improved security, they cause non-deterministic program behavior when the 'keys', 'values' and 'each' functions are used. Prior to this release, Shorewall sorted the lists produced by those functions to ensure that consecutive compilations of the same configuration produced the same ruleset. In this release, compilation speed has been improved by removing the sort calls and by instructing Perl to use a constant hash key. Note: The ruleset produced by this release will be equivalent to that produced by 5.1.2, but will likely be different. 5) All builtin actions have been replaced with standard actions. In some cases. the standard action produces different but equivalent rules when compared to those produced by the corresponding builtin action. 6) The PROTO columns may now specify tcp:!syn (6:!syn) which matches TCP packets with the SYN flag reset or one or more of ACK, RST or FIN set. The dropNotSyn and rejNotSyn actions have been modified to use this feature. 7) During 'update', the settings of all _LEVEL and _DEFAULT options are now enclosed in quotes. This is done because these settings often contain parentheses and the .conf files are process by the shell. The sample configurations also have these settings enclosed in quotes. Update will continue to also enclose in quotes any settings that contains characters other than alphanumeric, '/', and '.'. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 2 ---------------------------------------------------------------------------- 1) Previously, when the 5.1 CLI program was run with no command given, a shell exception was raised. That has been corrected (Tuomo Soini). 2) A caution has been added in shorewall[6]-rtrules regarding similar rules at the same priority. 3) The 'dropBcasts' builtin action now works with Shorewall6. Previously, an attempt to use that action failed with a 'missing action file' error. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 2 ---------------------------------------------------------------------------- 1) Terminology change. What we've previously referred to as "default actions" are now called "policy actions" to better describe their purpose. 2) The DROP_DEFAULT, REJECT_DEFAULT, etc. options may now specify a comma-separated list of actions rather than just a single action. The actions are invoked in the order in which they are listed and each action may optionally be followed by a colon (":") and a log level. The POLICY column in shorewall[6]-policy can now specify a similar list of actions. In that file, the list may be preceded by a plus sign ("+"), in which case the listed actions will be in addition to those listed in the related _DEFAULT setting in shorewall[6].conf. 3) With the preceding change, the Drop and Reject policy actions are now deprecated in favor of a list of smaller actions. A warning is issued when these deprecated actions are used; the warning refers the reader to http://www.shorewall.net/Actions.html#Default. 4) A LOG_LEVEL option has been added to shorewall[6].conf with default value 'info'. The sample config files have been updated to use $LOG_LEVEL rather than 'info' so that changing this option's setting will change all default packet logging. Like with any option, $LOG_LEVEL can be used throughout the configuration (with the exception of shorewall[6]-params). 5) The LIMIT column in shorewall[6]-policy has been renamed RATE for consistency with shorewall[6]-rules. No change is required to existing configurations, including those that specify 'limit' in alternate input format. 6) Beginning with this release, the allowBcast, dropBcast, and Broadcast no longer handling multicast. Multicast is handeled separately in actions allowMcast, dropMcast and Multicast. The now-deprecated Drop and Reject actions have been modified so that ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 1 ---------------------------------------------------------------------------- 1) This release contains defect repair up through Shorewall 5.1.0.1. 2) Previously, expanded variables would be enclosed in single quotes in ?ERROR, ?WARNING and ?INFO directive output. That has been corrected. 3) The obsolete Drop and Reject macros have been removed (Drop and Reject are now actions rather than macros). 4) A typo has been corrected in the parameter descriptions in action.Drop and action.Reject. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 1 ---------------------------------------------------------------------------- 1) Previously, the compiler did not check for routefilter/provider issues. Now, a fatal compilation error is raised in the following cases: a) USE_DEFAULT_RT=Yes, ROUTE_FILTER=Yes in shorewall.conf and a regular provider (not tproxy) is defined in the providers file. b) USE_DEFAULT_RT=Yes and a provider interface specifies a non-zero value for the 'routefilter' option in the interfaces file. c) USE_DEFAULT_RT=No, ROUTE_FILTER=Yes in shorewall.conf, and a provider interface doesn't specify the 'balance' or 'primary' option in the providers file. d) USE_DEFAULT_RT=No, a provider interface specifies the non-zero value for the 'routefilter' option in the interfaces file but does not specify the 'balance' or 'primary' option in the providers file. 2) When 'routefilter' is specified by itself or with a non-zero value (e.g., routefilter=1), the 'logmartians' option is now also set implicitly when LOG_MARTIANS=No. If you actually want route filtering without logging, then you must also include 'logmartians=0'. 3) Since the creation of the USE_DEFAULT_RT option, when USE_DEFAULT_RT=Yes, 'balance=1' is assumed on all provider interfaces unless 'fallback', 'load', 'primary', 'loose' or 'tproxy' is specified. This makes it awkward to define a provider that does not generate a default route in either the 'balance' or 'default' routing tables; it is necessary to specify 'loose' then add the routing rules that are suppressed by that option. To address this issue, it is now possible to specify BALANCE_PROVIDERS=No. When BALANCE_PROVIDERS=No and none of the above-listed options is specified, the provider will generate no entry in the 'balance' or 'default routing tables irrespective of the setting of USE_DEFAULT_RT. All of the released shorewall[6].conf files now specify BALANCE_PROVIDERS=No. The default value is the effective setting of USE_DEFAULT_RT to provide backward compatibility with earlier releases. 4) When using ipset-based dynamic blacklisting, it is now possible to specify BLACKLIST in the POLICY column of policy files. When BLACKLIST is specified, the source IP address is automatically added to the dynamic blacklist ipset and then the packet is dropped. This new policy adds BLACKLIST_DEFAULT to shorewall[6].conf; the default setting is "Drop". 5) A BLACKLIST action has been added; the action adds the sender to the dynamic blacklist IPSET. BLACKLIST accepts two optional argument: 1 - Action to take after adding the sender to the ipset. Default is DROP. 2 - specifies the timeout for the added/updated entry. If no timeout is passed, the one specified in DYNAMIC_BLACKLIST, if any, is used. Otherwise, the one specified when the ipset was created, if any, is used. 6) Given that there was already a BLACKLIST macro which implemented the BLACKLIST action in blrules, the preceding change required that BLACKLIST behave differently when invoked from the blrules file and when invoked from the rules file. Because BLACKLIST invoked from the rules file normally generates two rules, an action (not inlined) is more appropriate there than is a macro. When it is invoked from the blrules file, it only generates a single rule so the optimizer will inline it anyway. For historical reasons, the compiler treats the blrules file as if it were the section BLACKLIST in the rules file. So, to implement this dual behavior in the BLACKLIST action, a new 'section' option has been added in the action file. When 'section' is specified, the name of the current section and a comma are prepended to the argument list passed when invoking the action. The action.BLACKLIST file then has the following structure: ?if @1 eq 'BLACKLIST' ?else ?endif 7) There is now a 'show action ' command for Shorewall and Shorewall6. The command displays the action file for the specified . ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 0 ---------------------------------------------------------------------------- 5.1.0.1 1) Shorewall6-lite 5.1.0 failed to start under systemd. That has been corrected. 2) Previously, the setting of PAGER in shorewall[6].conf was not propagated to a remote configuration during 'export', 'remote-start', 'remote-reload' and 'remote-restart'. That has been corrected. 5.1.0 1) This release includes defect repair through Shorewall 5.0.15.2. 2) A defect associated with CHAIN_SCRIPTS=Yes previously prevented some of the optimizations associated with optimize level 4 from being applied. Removal of the CHAIN_SCRIPT option (see below) has eliminated the defect. 3) The install.sh and uninstall.sh have had some minor cleanup (Matt Darfeuille). 4) Previously, when SAVE_IPSETS=Yes or SAVE_IPSETS=ipv4, the restore phase of a rejected safe-restart would fail. That has been corrected. 5) It is now possible to include compact IPv6 addresses (those with "::") in IP6TABLES() parameters. Previously, such addresses resulted in an "INVALID ACTION..." error. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 0 ---------------------------------------------------------------------------- 1) Shorewall 5.1 now has a single CLI program, ${SBINDIR}/shorewall (normally /sbin/shorewall). This program performs all of the same functions previously performed by /sbin/shorewall, /sbin/shorewall6, /sbin/shorewall-lite and /sbin/shorewall6-lite and is installed as part of the Shorewall-core package. It's default 'personality' is determined by the Shorewall packages installed: a) If the Shorewall package is installed, then by default, /sbin/shorewall behaves as in prior versions. b) If the Shorewall package is not installed, but the Shorewall-lite package is present, then /sbin/shorewall behaves as did /sbin/shorewall-lite in prior versions. c) If neither the Shorewall nor Shorewall-lite packages are installed, but the Shorewall6-lite package is installed, then /sbin/shorewall behaves as did /sbin/shorewall6-lite in prior versions. The program's personality can be altered through use of two new options. -6 When specified, changes the personality from Shorewall to Shorewall6 or from Shorewall-lite to Shorewall6-lite. -l When specified, changes the personality from Shorewall to Shorewall-lite or from Shorewall6 to Shorewall6-lite. This option is only required when both the standard package (Shorewall or Shorewall6) and the corresponding -lite package are installed on the system. The following is a comparison of Shorewall 5.0 and Shorewall 5.1 with respect to the CLI invocation: All four packages installed: Shorewall 5.0 Shorewall 5.1 shorewall shorewall shorewall6 shorewall -6 shorewall-lite shorewall -l shorewall6-lite shorewall -6l Only Shorewall-lite and Shorewall6-lite installed: Shorewall 5.0 Shorewall 5.1 shorewall-lite shorewall shorewall6-lite shorewall -6 A single shorewall(8) manpage now describes the CLI. The shorewall6(8), shorewall-lite(8) and shorewall6-lite(8) manpages are now minimal and refer the reader to shorewall(8). For backward compatibility, Shorewall6, Shorewall-lite and Shorewall6-lite install symlinks $SBINDIR/shorewall6, $SBINDIR/shorewall-lite and $SBINDIR/shorewall6-lite respectively. When the shorewall program is invoked through one of these symlinks, it adopts the appropriate personality. 2) Several settings in the default/sample .conf files have been modified: a) In Shorewall 5.1.0, the setting of LOGFORMAT in the default and sample .conf files was changed to "%s:%s " to enable 10-character zone names (up from 5 characters using the default "Shorewall:%s:%s:" setting). As part of this change, if a shorewall.conf file which did not set LOGFORMAT is updated using "shorewall update", LOGFORMAT is set to "Shorewall:%s:%s:" to preserve the existing behavior. This can have an effect on new installations, however in that scipts or log analyzers can no longer be configured to simply look for "Shorewall:" in log messages unless the setting of LOGFORMAT is changed. If you use the new "%s:%s " setting then Shorewall-generated Netfilter messages may be matched using this regular expression: 'IN=.* OUT=.* SRC=.*\..* DST=' Shorewall6-generated Netfilter messages may be matched using: 'IN=.* OUT=.* SRC=.*:.* DST=' And all Netfilter messages (IPv4 and IPv6) are matched using: 'IN=.* OUT=.* SRC=.* DST=' Shorewall6-generated Netfilter messages may be idd b) The LOGLIMIT setting has been changed from empty to "s:1/sec:10", to enable log trottling by default. c) The AUTOMAKE setting has been changed from "No" to "Yes", to avoid unnecessary recompilation. d) The IP_FORWARDING setting has been changed from "On" to "Keep" in shorewall.conf to accomodate cases where forwarding has been configured before installing Shorewall. e) The OPTIMIZE setting has been changed to "All", to create more compact rulesets by default. f) TC_CLEAR has been set to "No" in the shorewall6.conf files. 3) The allowed syntax in the SOURCE and DEST columns in the rules file has been extended to allow multiple comma-separated :[:][] tupples in a single rule. Where the lists mulitiple addresses separated by commas, the must be enclosed in parentheses. Example: net:(1.2.3.4,2.3.4.5),dmz:(5.6.7.8,6.7.8.9) See shorewall[6]-rules(5) for details. A similar change has been made to the conntrack and mangle files, where multiple : groups can be specified: Example: eth0:(1.2.3.4,2.3.4.5),eth1(5.6.7.8,6.7.8.9) See shorewall[6]-conntrack(5) and shorewall[6]-mangle(5) for details. 5) The CHAIN_SCRIPTS option in the .conf files has been eliminated, and the compiler no longer looks for script files with the same name as a chain or action. If you are using such files, you will need to convert them into equivalent ?begin perl .... ?end perl text or to use the IP[6]TABLES target and/or inline matches. See http://www.shorewall.org/Shorewall-5.html#idp41228128. 5) The --queue-cpu-fanout NFQUEUE option is now supported in NFQUEUE rules and policies. It is enabled by following the high queue number with the letter 'c' (e.g., NFQUEUE(0:3c)). This option requires 'NFQUEUE CPU Fanout' support in your kernel and ip[6]tables. 6) A SWITCH column has been added to the mangle files. See shorewall[6]-mangle(5) for details. 7) A 'show ipsec' command has been added. This command displays the contents of the IPSEC "Security Policy Database" (SPD) and "Security Association Database" (SAD). SAD keys are not shown. 8) The Netfilter team have removed support for the rawpost table, so Shorewall no longer supports features requiring that table (stateless netmapping in the netmap file). The good news is that, since kernel 3.7, Netfilter supports stateful IPv6 network mapping which is now also supported in Shorewall6 (see shorewall6-netmap(5)). 9) In the released tarballs, the action.* files now reside in a separate Actions/ directory. 10) The 'echo' builtin in recent versions of the dash shell does not support the -n option. To accomodate that version, Shorewall no longer uses either the -e or -n options. 11) When LOAD_HELPERS_ONLY=No, additional modules required for NAT are now loaded. 12) The (undocumented) Makefiles haven't been maintained for many releases and have been removed. 1