mirror of
https://gitlab.com/shorewall/code.git
synced 2025-01-12 16:48:12 +01:00
Support alternative syntax for ipet lists
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
parent
0c6882c3a8
commit
25ca73ca54
@ -2588,14 +2588,14 @@ sub match_source_net( $;$ ) {
|
|||||||
} elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/ ) {
|
} elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/ ) {
|
||||||
require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , '' );
|
require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , '' );
|
||||||
join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'src' ) );
|
join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'src' ) );
|
||||||
} elsif ( $net =~ /^\[(\+.+)\]$/ ) {
|
} elsif ( $net =~ /^\+\[(.+)\]$/ ) {
|
||||||
my $result = '';
|
my $result = '';
|
||||||
my @sets = mysplit $1;
|
my @sets = mysplit $1;
|
||||||
|
|
||||||
require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1;
|
require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1;
|
||||||
|
|
||||||
for $net ( @sets ) {
|
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' ) );
|
$result .= join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'src' ) );
|
||||||
}
|
}
|
||||||
|
|
||||||
@ -2624,14 +2624,14 @@ sub match_dest_net( $ ) {
|
|||||||
} elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?$/ ) {
|
} elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?$/ ) {
|
||||||
require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , '');
|
require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , '');
|
||||||
join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'dst' ) );
|
join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'dst' ) );
|
||||||
} elsif ( $net =~ /^\[(\+.+)\]$/ ) {
|
} elsif ( $net =~ /^\+\[(.+)\]$/ ) {
|
||||||
my $result = '';
|
my $result = '';
|
||||||
my @sets = mysplit $1;
|
my @sets = mysplit $1;
|
||||||
|
|
||||||
require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1;
|
require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1;
|
||||||
|
|
||||||
for $net ( @sets ) {
|
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' ) );
|
$result .= join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'dst' ) );
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -1,3 +1,7 @@
|
|||||||
|
Changes in Shorewall 4.4.14
|
||||||
|
|
||||||
|
1) Support ipset lists.
|
||||||
|
|
||||||
Changes in Shorewall 4.4.13
|
Changes in Shorewall 4.4.13
|
||||||
|
|
||||||
1) Allow zone lists in rules SOURCE and DEST.
|
1) Allow zone lists in rules SOURCE and DEST.
|
||||||
|
@ -1,6 +1,6 @@
|
|||||||
----------------------------------------------------------------------------
|
----------------------------------------------------------------------------
|
||||||
S H O R E W A L L 4 . 4 . 1 3
|
S H O R E W A L L 4 . 4 . 1 4
|
||||||
R C 1
|
B E T A 1
|
||||||
----------------------------------------------------------------------------
|
----------------------------------------------------------------------------
|
||||||
|
|
||||||
I. PROBLEMS CORRECTED IN THIS RELEASE
|
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
|
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
|
None.
|
||||||
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 :<port> (e.g., :22) appeared.
|
|
||||||
|
|
||||||
----------------------------------------------------------------------------
|
----------------------------------------------------------------------------
|
||||||
I I. K N O W N P R O B L E M S R E M A I N I N G
|
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
|
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
|
1) Multiple source or destination ipset matches can be generated by
|
||||||
contain zone lists in the SOURCE and DEST column. A zone list is a
|
enclosing the ipset list in [...].
|
||||||
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
|
Example (/etc/shorewall/rules):
|
||||||
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
|
ACCEPT $FW net:+[dest-ip-map,dest-port-map]
|
||||||
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 <name>
|
|
||||||
|
|
||||||
The first reference to user-defined accounting chain <name> is
|
|
||||||
not a JUMP or COUNT from an already-defined chain.
|
|
||||||
|
|
||||||
- WARNING: Accounting chain <name> 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:
|
|
||||||
|
|
||||||
<rate>[:[<burst>][:[<latency>][:[<peak>][:[<minburst>]]]]]
|
|
||||||
|
|
||||||
These terms are described in tc-tbf(8). Shorewall supplies default
|
|
||||||
values as follows:
|
|
||||||
|
|
||||||
<burst> = 10kb
|
|
||||||
<latency> = 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.
|
|
||||||
|
|
||||||
<rate>[:<burst>]
|
|
||||||
|
|
||||||
The default <burst> is 10kb. A larger <burst> can help make the
|
|
||||||
<rate> more accurate; often for fast lines, the enforced rate is
|
|
||||||
well below the specified <rate>.
|
|
||||||
|
|
||||||
----------------------------------------------------------------------------
|
----------------------------------------------------------------------------
|
||||||
I V. R E L E A S E 4 . 4 H I G H L I G H T S
|
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
|
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
|
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 :<port> (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 <name>
|
||||||
|
|
||||||
|
The first reference to user-defined accounting chain <name> is
|
||||||
|
not a JUMP or COUNT from an already-defined chain.
|
||||||
|
|
||||||
|
- WARNING: Accounting chain <name> 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:
|
||||||
|
|
||||||
|
<rate>[:[<burst>][:[<latency>][:[<peak>][:[<minburst>]]]]]
|
||||||
|
|
||||||
|
These terms are described in tc-tbf(8). Shorewall supplies default
|
||||||
|
values as follows:
|
||||||
|
|
||||||
|
<burst> = 10kb
|
||||||
|
<latency> = 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.
|
||||||
|
|
||||||
|
<rate>[:<burst>]
|
||||||
|
|
||||||
|
The default <burst> is 10kb. A larger <burst> can help make the
|
||||||
|
<rate> more accurate; often for fast lines, the enforced rate is
|
||||||
|
well below the specified <rate>.
|
||||||
|
|
||||||
----------------------------------------------------------------------------
|
----------------------------------------------------------------------------
|
||||||
P R O B L E M S C O R R E C T E D I N 4 . 4 . 1 2
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 1 2
|
||||||
----------------------------------------------------------------------------
|
----------------------------------------------------------------------------
|
||||||
|
Loading…
Reference in New Issue
Block a user