diff --git a/Shorewall/Perl/Shorewall/Chains.pm b/Shorewall/Perl/Shorewall/Chains.pm index ee69ec4ab..2b0238e16 100644 --- a/Shorewall/Perl/Shorewall/Chains.pm +++ b/Shorewall/Perl/Shorewall/Chains.pm @@ -2588,14 +2588,14 @@ sub match_source_net( $;$ ) { } elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/ ) { require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , '' ); join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'src' ) ); - } elsif ( $net =~ /^\[(\+.+)\]$/ ) { + } elsif ( $net =~ /^\+\[(.+)\]$/ ) { my $result = ''; my @sets = mysplit $1; require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1; for $net ( @sets ) { - fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/; + fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)(\+?)[a-zA-Z][-\w]*(\[.*\])?/; $result .= join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'src' ) ); } @@ -2624,14 +2624,14 @@ sub match_dest_net( $ ) { } elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?$/ ) { require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , ''); join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'dst' ) ); - } elsif ( $net =~ /^\[(\+.+)\]$/ ) { + } elsif ( $net =~ /^\+\[(.+)\]$/ ) { my $result = ''; my @sets = mysplit $1; require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1; for $net ( @sets ) { - fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/; + fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)(\+?)[a-zA-Z][-\w]*(\[.*\])?/; $result .= join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'dst' ) ); } diff --git a/Shorewall/changelog.txt b/Shorewall/changelog.txt index 10f0f1454..2be631f3d 100644 --- a/Shorewall/changelog.txt +++ b/Shorewall/changelog.txt @@ -1,3 +1,7 @@ +Changes in Shorewall 4.4.14 + +1) Support ipset lists. + Changes in Shorewall 4.4.13 1) Allow zone lists in rules SOURCE and DEST. diff --git a/Shorewall/releasenotes.txt b/Shorewall/releasenotes.txt index ba55208ed..9ab639ebf 100644 --- a/Shorewall/releasenotes.txt +++ b/Shorewall/releasenotes.txt @@ -1,6 +1,6 @@ ---------------------------------------------------------------------------- - S H O R E W A L L 4 . 4 . 1 3 - R C 1 + S H O R E W A L L 4 . 4 . 1 4 + B E T A 1 ---------------------------------------------------------------------------- I. PROBLEMS CORRECTED IN THIS RELEASE @@ -14,107 +14,7 @@ VI. 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 ---------------------------------------------------------------------------- -1) Under rare circumstances where COMMENT is used to attach comments - to rules, OPTIMIZE 8 through 15 could result in invalid - iptables-restore (ip6tables-restore) input. - -2) Under rare circumstances involving exclusion, OPTIMIZE 8 through 15 - could result in invalid iptables-restore (ip6tables-restore) input. - -3) The change in 4.4.12 to detect and use the new ipset match syntax - broke the ability to detect the old ipset match capability. Now, - both versions of the capability can be correctly detected. - -4) Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail - if the last optional interface tested was not available. - -5) Exclusion in the blacklist file was correctly validated but was then - ignored when generating iptables (ip6tables) rules. - -6) Previously, non-trivial exclusion (more than one excluded - address/net) in CONTINUE, NONAT and ACCEPT+ rules generated - valid but incorrect iptables input. This has been corrected but - requires that your iptables/kernel support marking rules in any - Netfilter table (CONTINUE in the tcrules file does not require this - support). - - This fix implements a new 'Mark in any table' capability; those - who utilize a capabilities file should re-generate the file using - this release. - -7) Interface handling has been extensively modified in this release - to correct a number of problems with the earlier - implementation. Among those problems: - - - Invalid shell variable names could be generated in the firewall - script. The generated firewall script uses shell variables to - track the availability of optional and required interfaces and - to record detected gateways, detected addresses, etc. - - - The same shell variable name could be generated by two different - interface names. - - - Entries in the interfaces file with a wildcard physical name - (physical name ends with "+") and with the 'optional' option were - handled strangely. - - o If there were references to specific interfaces that matched - the wildcard, those entries were handled as if they had been - defined as optional in the interfaces file. - - o If there were no references matching the wildcard, then the - 'optional' option was effectively ignored. - - The new implementation: - - - Insures valid shell variable names. - - - Insures that shell variable names are unique. - - - Handles interface names appearing in the INTERFACE column of the - providers file as a special case for 'optional'. If the name - matches a wildcard entry in the interfaces file then the - usability of the specific interface is tracked individually. - - - Handles the availabilty of other interfaces matching a wildcard - as a group; if there is one useable interface in the group then - the wildcard itself is considered usable. - - The following example illustrates this use case: - - /etc/shorewall/interfaces - - net ppp+ - optional - - /etc/shorewall/shorewall.conf - - REQUIRE_INTERFACE=Yes - - If there is any usable PPP interface then the firewall will be - allowed to start. Previously, the firewall would never be allowed - to start. - -8) When a comma-separated list of 'src' and/or 'dst' was specified in - an ipset invocation (e.g., "+fooset[src,src]), all but the first 'src' - or 'dst' was previously ignored when generating the resulting - iptables rule. - -9) Beginning with Shorewall 4.4.9, the SAME target in tcrules has - generated invalid iptables (ip6tables) input. That target now - generates correct input. - -10) Ipsets associated with 'dynamic' zones were being created during - 'restart' but not during 'start'. - -11) To work around an issue in Netfilter/iptables, Shorewall now uses - state match rather than conntrack match for UNTRACKED state - matching. - -12) If the routestopped files contains NOTRACK rules, 'shorewall* clear' - did not clear the raw table. - -13) An error message was incorrectly generated if a port range of the - form : (e.g., :22) appeared. +None. ---------------------------------------------------------------------------- I I. K N O W N P R O B L E M S R E M A I N I N G @@ -127,136 +27,12 @@ VI. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES 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) Entries in the rules file (both Shorewall and Shorewall6) may now - contain zone lists in the SOURCE and DEST column. A zone list is a - comma-separated list of zone names where each name appears in the - zones file. A zone list may be optionally followed by a plus sign - ("+") to indicate that the rule should apply to intra-zone traffic - as well as to inter-zone traffic. +1) Multiple source or destination ipset matches can be generated by + enclosing the ipset list in [...]. - Zone lists behave like 'all' and 'any' with respect to Optimization - 1. If the rule matches the applicable policy for a given (source - zone, dest zone), then the rule will be suppessed for that pair of - zones unless overridden by the '!' suffix on the target in the - ACTION column (e.g., ACCEPT!, DROP!:info, etc.). + Example (/etc/shorewall/rules): - Additionally, 'any', 'all' and zone lists may be qualified in the - same way as a single zone. - - Examples: - - fw,dmz:90.90.191.120/29 - all:+blacklist - - The 'all' and 'any' keywords now support exclusion in the form of a - comma-separated list of excluded zones. - - Examples: - - all!fw (same as all-). - any+!dmz,loc (All zones except 'dmz' and 'loc' and - include intra-zone rules). - -2) An IPSEC column has been added to the accounting file, allowing you - to segregate IPSEC traffic from non-IPSEC traffic. See 'man - shorewall-accounting' (man shorewall6-accounting) for details. - - With this change, there are now three trees of accounting chains: - - - The one rooted in the 'accounting' chain. - - The one rooted in the 'accipsecin' chain. This tree handles - traffic that has been decrypted on the firewall. Rules in this - tree cannot specify an interface name in the DEST column. - - The one rooted in the 'accipsecout' chain. This tree handles - traffic that will be encrypted on the firewall. Rules in this - tree cannot specify an interface name in the SOURCE column. - - In reality, when there are bridges defined in the configuration, - there is a fourth tree rooted in the 'accountout' chain. That chain - handles traffic that originates on the firewall (both IPSEC and - non-IPSEC). - - This change also implements a couple of new warnings: - - - WARNING: Adding rule to unreferenced accounting chain - - The first reference to user-defined accounting chain is - not a JUMP or COUNT from an already-defined chain. - - - WARNING: Accounting chain has o references - - The named chain contains accounting rules but no JUMP or COUNT - specifies that chain as the target. - -3) Shorewall now supports the SECMARK and CONNSECMARK targets for - manipulating the SELinux context of packets. - - See the shorewall-secmarks and shorewall6-secmarks manpages for - details. - - As part of this change, the tcrules file now accepts $FW in the - DEST column for marking packets in the INPUT chain. - -4) Blacklisting has undergone considerable change in Shorewall 4.4.13. - - a) Blacklisting is now based on zones rather than on interfaces and - host groups. - - b) Near compatibility with earlier releases is maintained. - - c) The keywords 'src' and 'dst' are now preferred in the OPTIONS - column in /etc/shoreawll/blacklist, replacing 'from' and 'to' - respectively. The old keywords are still supported. - - d) The 'blacklist' keyword may now appear in the OPTIONS, - IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones. - - i) In the IN_OPTIONS column, it indicates that packets received - on the interface are checked against the 'src' entries in - /etc/shorewall/blacklist. - - ii) In the OUT_OPTIONS column, it indicates that packets being - sent to the interface are checked against the 'dst' entries. - - iii) Placing 'blacklist' in the OPTIONS column is equivalent to - placing in in both the IN_OPTIONS and OUT_OPTIONS columns. - - e) The 'blacklist' option in the OPTIONS column of - /etc/shorewall/interfaces or /etc/shorewall/hosts is now - equivalent to placing it in the IN_OPTIONS column of the - associates record in /etc/shorewall/zones. If no zone is given - in the ZONE column of /etc/shorewall/interfaces, the 'blacklist' - option is ignored with a warning (it was previously ignored - silently). - - f) The 'blacklist' option in the /etc/shorewall/interfaces and - /etc/shorewall/hosts files is now deprecated but will continue - to be supported for several releases. A warning will be added at - least one release before support is removed. - -5) There is now an OUT-BANDWIDTH column in - /etc/shorewall/tcinterfaces. - - The format of this column is: - - [:[][:[][:[][:[]]]]] - - These terms are described in tc-tbf(8). Shorewall supplies default - values as follows: - - = 10kb - = 200ms - - The remaining options are defaulted by tc. - -6) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and - /etc/shorewall/tcinterfaces now accepts an optional burst parameter. - - [:] - - The default is 10kb. A larger can help make the - more accurate; often for fast lines, the enforced rate is - well below the specified . + ACCEPT $FW net:+[dest-ip-map,dest-port-map] ---------------------------------------------------------------------------- I V. R E L E A S E 4 . 4 H I G H L I G H T S @@ -477,6 +253,247 @@ VI. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES ---------------------------------------------------------------------------- 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 . 1 3 +---------------------------------------------------------------------------- + +1) Under rare circumstances where COMMENT is used to attach comments + to rules, OPTIMIZE 8 through 15 could result in invalid + iptables-restore (ip6tables-restore) input. + +2) Under rare circumstances involving exclusion, OPTIMIZE 8 through 15 + could result in invalid iptables-restore (ip6tables-restore) input. + +3) The change in 4.4.12 to detect and use the new ipset match syntax + broke the ability to detect the old ipset match capability. Now, + both versions of the capability can be correctly detected. + +4) Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail + if the last optional interface tested was not available. + +5) Exclusion in the blacklist file was correctly validated but was then + ignored when generating iptables (ip6tables) rules. + +6) Previously, non-trivial exclusion (more than one excluded + address/net) in CONTINUE, NONAT and ACCEPT+ rules generated + valid but incorrect iptables input. This has been corrected but + requires that your iptables/kernel support marking rules in any + Netfilter table (CONTINUE in the tcrules file does not require this + support). + + This fix implements a new 'Mark in any table' capability; those + who utilize a capabilities file should re-generate the file using + this release. + +7) Interface handling has been extensively modified in this release + to correct a number of problems with the earlier + implementation. Among those problems: + + - Invalid shell variable names could be generated in the firewall + script. The generated firewall script uses shell variables to + track the availability of optional and required interfaces and + to record detected gateways, detected addresses, etc. + + - The same shell variable name could be generated by two different + interface names. + + - Entries in the interfaces file with a wildcard physical name + (physical name ends with "+") and with the 'optional' option were + handled strangely. + + o If there were references to specific interfaces that matched + the wildcard, those entries were handled as if they had been + defined as optional in the interfaces file. + + o If there were no references matching the wildcard, then the + 'optional' option was effectively ignored. + + The new implementation: + + - Insures valid shell variable names. + + - Insures that shell variable names are unique. + + - Handles interface names appearing in the INTERFACE column of the + providers file as a special case for 'optional'. If the name + matches a wildcard entry in the interfaces file then the + usability of the specific interface is tracked individually. + + - Handles the availabilty of other interfaces matching a wildcard + as a group; if there is one useable interface in the group then + the wildcard itself is considered usable. + + The following example illustrates this use case: + + /etc/shorewall/interfaces + + net ppp+ - optional + + /etc/shorewall/shorewall.conf + + REQUIRE_INTERFACE=Yes + + If there is any usable PPP interface then the firewall will be + allowed to start. Previously, the firewall would never be allowed + to start. + +8) When a comma-separated list of 'src' and/or 'dst' was specified in + an ipset invocation (e.g., "+fooset[src,src]), all but the first 'src' + or 'dst' was previously ignored when generating the resulting + iptables rule. + +9) Beginning with Shorewall 4.4.9, the SAME target in tcrules has + generated invalid iptables (ip6tables) input. That target now + generates correct input. + +10) Ipsets associated with 'dynamic' zones were being created during + 'restart' but not during 'start'. + +11) To work around an issue in Netfilter/iptables, Shorewall now uses + state match rather than conntrack match for UNTRACKED state + matching. + +12) If the routestopped files contains NOTRACK rules, 'shorewall* clear' + did not clear the raw table. + +13) An error message was incorrectly generated if a port range of the + form : (e.g., :22) appeared. + +---------------------------------------------------------------------------- + N E W F E A T U R E S I N 4 . 4 . 1 3 +---------------------------------------------------------------------------- + +1) Entries in the rules file (both Shorewall and Shorewall6) may now + contain zone lists in the SOURCE and DEST column. A zone list is a + comma-separated list of zone names where each name appears in the + zones file. A zone list may be optionally followed by a plus sign + ("+") to indicate that the rule should apply to intra-zone traffic + as well as to inter-zone traffic. + + Zone lists behave like 'all' and 'any' with respect to Optimization + 1. If the rule matches the applicable policy for a given (source + zone, dest zone), then the rule will be suppessed for that pair of + zones unless overridden by the '!' suffix on the target in the + ACTION column (e.g., ACCEPT!, DROP!:info, etc.). + + Additionally, 'any', 'all' and zone lists may be qualified in the + same way as a single zone. + + Examples: + + fw,dmz:90.90.191.120/29 + all:+blacklist + + The 'all' and 'any' keywords now support exclusion in the form of a + comma-separated list of excluded zones. + + Examples: + + all!fw (same as all-). + any+!dmz,loc (All zones except 'dmz' and 'loc' and + include intra-zone rules). + +2) An IPSEC column has been added to the accounting file, allowing you + to segregate IPSEC traffic from non-IPSEC traffic. See 'man + shorewall-accounting' (man shorewall6-accounting) for details. + + With this change, there are now three trees of accounting chains: + + - The one rooted in the 'accounting' chain. + - The one rooted in the 'accipsecin' chain. This tree handles + traffic that has been decrypted on the firewall. Rules in this + tree cannot specify an interface name in the DEST column. + - The one rooted in the 'accipsecout' chain. This tree handles + traffic that will be encrypted on the firewall. Rules in this + tree cannot specify an interface name in the SOURCE column. + + In reality, when there are bridges defined in the configuration, + there is a fourth tree rooted in the 'accountout' chain. That chain + handles traffic that originates on the firewall (both IPSEC and + non-IPSEC). + + This change also implements a couple of new warnings: + + - WARNING: Adding rule to unreferenced accounting chain + + The first reference to user-defined accounting chain is + not a JUMP or COUNT from an already-defined chain. + + - WARNING: Accounting chain has o references + + The named chain contains accounting rules but no JUMP or COUNT + specifies that chain as the target. + +3) Shorewall now supports the SECMARK and CONNSECMARK targets for + manipulating the SELinux context of packets. + + See the shorewall-secmarks and shorewall6-secmarks manpages for + details. + + As part of this change, the tcrules file now accepts $FW in the + DEST column for marking packets in the INPUT chain. + +4) Blacklisting has undergone considerable change in Shorewall 4.4.13. + + a) Blacklisting is now based on zones rather than on interfaces and + host groups. + + b) Near compatibility with earlier releases is maintained. + + c) The keywords 'src' and 'dst' are now preferred in the OPTIONS + column in /etc/shoreawll/blacklist, replacing 'from' and 'to' + respectively. The old keywords are still supported. + + d) The 'blacklist' keyword may now appear in the OPTIONS, + IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones. + + i) In the IN_OPTIONS column, it indicates that packets received + on the interface are checked against the 'src' entries in + /etc/shorewall/blacklist. + + ii) In the OUT_OPTIONS column, it indicates that packets being + sent to the interface are checked against the 'dst' entries. + + iii) Placing 'blacklist' in the OPTIONS column is equivalent to + placing in in both the IN_OPTIONS and OUT_OPTIONS columns. + + e) The 'blacklist' option in the OPTIONS column of + /etc/shorewall/interfaces or /etc/shorewall/hosts is now + equivalent to placing it in the IN_OPTIONS column of the + associates record in /etc/shorewall/zones. If no zone is given + in the ZONE column of /etc/shorewall/interfaces, the 'blacklist' + option is ignored with a warning (it was previously ignored + silently). + + f) The 'blacklist' option in the /etc/shorewall/interfaces and + /etc/shorewall/hosts files is now deprecated but will continue + to be supported for several releases. A warning will be added at + least one release before support is removed. + +5) There is now an OUT-BANDWIDTH column in + /etc/shorewall/tcinterfaces. + + The format of this column is: + + [:[][:[][:[][:[]]]]] + + These terms are described in tc-tbf(8). Shorewall supplies default + values as follows: + + = 10kb + = 200ms + + The remaining options are defaulted by tc. + +6) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and + /etc/shorewall/tcinterfaces now accepts an optional burst parameter. + + [:] + + The default is 10kb. A larger can help make the + more accurate; often for fast lines, the enforced rate is + well below the specified . + ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 4 . 4 . 1 2 ----------------------------------------------------------------------------