Copyright © 2001-2012 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
November 2, 2012
----------------------------------------------------------------------------
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) This release contains all defect repair from Shorewall 4.5.8.2.
2) A typo has been corrected in the shorewallrc.default file.
3) Beginning with Shorewall 4.5.7.2, Shorewall unconditionally
restores the provider mark as the first rule in the mangle table
OUTPUT and PREROUTING chains. Previously, the provider mark was
restored only if it was non-zero.
It has become clear that some users need it one way while others
need it the other way. To resolve this issue, a RESTORE_ROUTEMARKS
option has been added to shorewall.conf and shorewall6.conf. When
this option is set to Yes (the default), the 4.5.7.2 approach is
used (always restore the mark, even if it is zero); when it is set
to No, the pre-4.5.7.2 behavior is retained (only restore the mark
if it is non-zero).
4) Two error messages produced by the RST action have been
corrected. They previously referred to errors in the NotSyn action
rather than RST.
----------------------------------------------------------------------------
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) Prior to this release, if a dynamic zone was associated with more
than one interface, then Shorewall created a separate ipset for
each interface. This meant that multiple 'add' and 'delete'
commands might be required to change the zone composition.
This release introduces a 'dynamic_shared' zone option. When that
option is specified, a single ipset is generated regardless of the
number of entries the zone has in the hosts file.
The 'dynamic_shared' option may only be specified in the OPTIONS
column of the zones file.
The syntax of the 'add' and 'delete' commands is changed for zones
having the 'dynamic_shared' option:
add <zone> <address>[,<address> ... ]
delete <zone> <address>[,<address> ... ]
Example:
shorewall add direct 172.20.1.99
The syntax for 'add' and 'delete' for zones not having the
'dynamic_shared' option is unchanged.
2) Puppet and Teredo macros have been contributed by Paul Gear.
3) The 'show' command now supports a -b (brief) option that suppresses
listing of rules that have zero packet count and omits chains that
have no rules listed (Paul Gear).
4) A CHECKSUM action has been added to the tcrules files. This action
computes and fills in the checksum in a packet that lacks one.
This is particularly useful if you need to work around old
applications, such as dhcp clients, that do not work well with
checksum offloads, but you don't want to disable checksum offload
in your device.
As part of this change, a new 'Checksum Target' capability has been
added, so if you use a capabilities file, it needs to be
re-generated after you install this release.
5) The 'shorewall6 show routing' command now sorts the contents of
each routing table in the same way as 'shorewall show routing'.
6) It is now possible to specify a mark range in the ACTION column of
the tcrules file. This causes the generated ruleset to assign marks
in the range in round-robin fashion. As part of this change, a
STATE column is also added that allows marks to be assigned only to
packets that are in one of the specified states (NEW, RELATED,
ESTABLISHED, etc.). Specifying NEW in this column along with
a range in the ACTION column allows for load-balancing SNAT rules
over a number of different external addresses.
Example:
/etc/shorewall/tcrules
#ACTION SOURCE DEST ...
1-3:CF eth1 172.20.1.0/24 ; state=NEW
/etc/shorewall/masq
#INTERFACE SOURCE ADDRESS ...
eth0 192.168.1.0/24 1.1.1.1 ; mark=1:C
eth0 192.168.1.0/24 1.1.1.5 ; mark=2:C
eth0 192.168.1.0/24 1.1.1.9 ; mark=3:C
Specifying a mark range require the 'Statistics Match' capability
in your iptables and kernel.
----------------------------------------------------------------------------
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) This release includes the defect repair from Shorewall 4.5.7.1.
2) The restriction that TTL and HL tcrules could only be placed in the
FORWARD chain prevented these rules from being used to hide a router
from traceroute[6]. It is now allowed to place these rules in the
PREROUTING chain by following the specification with ':P' (e.g.,
'TTL(+1):P').
3) Previously, the macro.SNMP macro opened both UDP ports 161 and 162
from SOURCE to DEST. This is against the usual practice of opening
these ports in the opposite direction. Beginning with this release,
port 162 is opened in to SOURCE to DEST as before, while port 161
is opened from DEST to SOURCE.
4) Previously, when compiling for export, both
/etc/shorewall/shorewall[6].conf and the shorewall[6].conf in the
configuration directory were processed. Now, only the copy in the
configuration directory is processed.
5) The 'iptables_raw' module has been added to the modules.essential
file.
6) Several corrections have been made to the Fedora/Redhat SysV init
script for Shorewall-init.
7) The <directory> parameter to the 'try' command is now documented in
the shorewall(8) and shorewall6(8) manpages.
8) Some redundant interface-option rules have been removed in
configurations with multiple zones configured on a single
interface.
9) Previously, when compiling for export, the compilation would fail
if the setting of SHAREDIR in the firewall's shorewallrc was
different from the setting on the admin system. Such compilations
now succeed.
10) Earlier versions of the compiler accepted ":" as the sole contents
of a USER/GROUP column with the result that iptables-restore
failed. This incorrect usage now generates a compile-time error.
11) The 4.5.7 Shorewall compiler unconditionally probes for all
helpers, causing their corresponding modules to be loaded. Now,
this probing will only occur when LOAD_HELERS_ONLY=No.
12) The 'conntrack' files released in Shorewall 4.5.7 contained an
incorrect control port number for PPTP (1729 vs. 1723). The port
number has been corrected.
13) A typo in the PPtP macro has been corrected.
14) The compiler previously accepted TTL(-0) and HL(-0) in the ACTION
column of tcrules, leading to a failure of the generated script. +0
was also accepted with the same result. Now, this incorrect usage
is flagged as an error.
----------------------------------------------------------------------------
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) This release attempts to alleviate the confusion that results
from different usage of the VARDIR variable name.
Beginning with Shorewall 4.5.2, 'VARDIR' became a variable in the
shorewallrc file with the default value '/var/lib'. This was at
odds with the usage of VARDIR in /etc/$product/vardir, where the
variable VARDIR holds the state directory for a particular product
(e.g., /var/lib/shorewall). This latter usage is reflected in the
Shorewall code which has always used VARDIR to hold the individual
product's state directory.
To eliminate this issue going forward, a VARLIB variable has been
added to shorewallrc to assume the role previously filled by
VARDIR, while VARDIR now defaults to '${VARDIR}/${PRODUCT}'.
When a pre-4.5.8 shorewallrc file is present, VARLIB is set to
${VARDIR} and VARDIR is set to ${VARLIB}/${PRODUCT}. If VARLIB is
set in the shorewallrc file and VARDIR is not, then VARDIR also
defaults to ${VARDIR}/${PRODUCT}. When using the tarball installer,
the existing shorewallrc file (~/.shorewallrc or
${SHAREDIR}/shorewallrc) will be updated and the original will be
saved as shorewallrc.bak.
Note that since there is only a single shorewallrc file on a
system, the only means for overriding the ${VARLIB}/${PRODUCT}
default setting for VARDIR is still the /etc/$product/vardir file.
2) A new 'stoppedrules' file has been added and the 'routestopped'
file is now deprecated. The new file is processed when
'routestopped' does not exist or is empty.
See stoppedrules(5) for details about the new file.
3) When the -e option (compile for export) is specified in the 'check'
and 'compile' commands, the current working directory is now
automatically included in the CONFIG_PATH.
4) When the -e option is specified in a 'compile' command that
specifies no script name, the default is now 'firewall' in the
current working directory. In other words:
shorewall compile -e
creates 'firewall' and 'firewall.conf' in the current working
directory. This is consistent with the behavior of the 'load' and
'reload' commands.
5) Multiple UID/GIDs separated by commas may now be given in the
USER/GROUP column of the rules files.
6) A warning message is now issued if the 'blacklist' option is
specified for a zone (the 'blacklist' option has been deprecated
for several releases).
7) A PRIORITY column has been added to the tcfilter files. See
shorewall-tcfilters(5) and shorewall6-tcfilters(5) for details.
As part of this change, the method of assigning priorities to
filters where the PRIORITY is not specified has changed.
Previously, all ipv4 filters were assigned priority 10 while
all ipv6 filters were assigned priority 11. Now, for each device,
the compiler maintains a "high-water priority" that has an initial
value of 0. When a filter has no priority specified, the high-water
priority is incremented by 1 and assigned to the filter. When a
priority greater than the high-water priority is entered in the
PRIORITY column, the high-water priority is set to the specified
priority.
An attempt to assign a priority value greater than 65535
(explicitly or implicitly) raises an error.
8) It is now possible to explicitly assign priorities to
classification filters created by shorewall for the following:
- Filter that classifies packets based on their firewall mark
value.
- Filter that classifies ACK packets via the 'tcp-ack' class
option.
- Filter that classifies packets based on TOS value.
Example:
#DEVICE MARK RATE: CEIL PRIORITY OPTIONS
# DMAX:UMAX
eth0 1:50 5*full/10 full 1 tcp-ack:15,\
tos-minimize-delay:20
In this example, the classifier filters would be evaluated in this
order:
- tcp-ack (priority 15)
- tos-minimize-delay (priority 20)
- Mark value 1 (priority 50)
In other words, the filters are evaluated in ascending priority
order. If one filter doesn't match, the packet is passed to the
next filter.
See shorewall-tcclasses(5) and shorewall6-tcclasses(5) for
additional information.
9) The PRIORITY column in the tcclasses file is now optional for HFSC
classes. If that priority is omitted, then an explicit priority
must be specified for the MARK value and for the 'tcp-ack' and
'tos*' options if those are used.
----------------------------------------------------------------------------
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) This release includes the defect repair from Shorewall 4.5.6.2.
2) The command 'shorewall enable pppX' could fail with the ip diagnostic
Error: either "to" is duplicate, or "weight" is a garbage.
Shorewall now generates the correct ip command.
3) Optimize level 4 could previously combine two rules that each
specified the 'policy' match, leading to this iptables-restore
failure:
policy match: multiple elements but no --strict
The optimizer now avoids combining such rules.
While this is a long-standing defect in the optimizer, it was
exposed by changes in Shorewall 4.5.6.
4) There were several cases where hard-wired directory names appeared
in the tarball installers. These have been replaced with the
appropriate shorewallrc variables.
5) A defect in RHEL 6.3 and derivatives causes 'shorewall show
capabilities' to leave an empty ipset in the configuration. The
same defect can cause the Shorewall compiler to similarly leave an
empty ipset behind.
This Shorewall release has a workaround for this problem.
----------------------------------------------------------------------------
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 'rpfilter' interface option has been added. Setting this
option requires kernel 3.4.0 or later and iptables 1.4.14. This
option is similar to routefilter but without the disadvantages:
- Works with both IPv4 and IPv6
- Uses packet marks when doing reverse path lookup so works with
all Multi-ISP configurations.
- Uses standard Netfilter/Shorewall log messages controlled by the
- RPFILTER_LOG_LEVEL setting in shorewall.conf (5).
- Disposition and auditing may be controlled using the
- RPFILTER_DISPOSITION option in shorewall.conf (5).
This feature adds a new 'RPFilter Match' capability; if you use a
capabilities file, you should regenerate it using this release.
2) Beginning with the 3.3 kernels, Netfilter supports a form of
accounting (nfacct) that is triggered by iptables rules but that
survives purging and/or reloading the Netfilter ruleset. Shorewall
support for this form of accounting was added in Shorewall 4.5.7.
As of this writing, Fedora 17 has partial support for this feature
but not all. It is necessary to download and build the following:
- libnetfilter_acct
- nfacct
The following Fedora packages are also required:
- libnetlink and libnetlink-dev
- libmnl and libmnl-dev
The tarballs are available from the Netfilter download sites.
The nfacct utility can create, delete and display nfacct
objects. These named objects consist of a packet and byte
counter. Packets matching those netfilter rules that use the nfacct
match cause the packet and byte count in the object named in the
match to be incremented.
To use nfaccnt with Shorewall, use the NFACCT target. See
shorewall-accounting(5) for details.
The 'shorewall show nfacct' command is a thin wrapper around the
'nfacct list' command and displays all objects.
3) With the addition of the CT action to the /etc/shorewall[6]/notrack
file, the name of the file does not accurately reflect the file's
purpose. In this release, the name of the file has been changed to
'conntrack'.
The tarball installers will install 'conntrack' along side of an
existing 'notrack' file. If the 'notrack' file is non-empty, a
warning message is issued during compilation:
WARNING: Non-empty notrack file (...);
please move its contents to the conntrack file
This warning can be eliminated by removing the notrack file (if it
has no entries), or by moving its entries to the conntrack file and
removing the notrack file. Note that the conntrack file is always
populated with rules (see enhancement 5).
If the 'notrack' file exists and is empty, the first compilation
will remove it with the warning:
WARNING: Empty notrack file (...) removed
4) 'all' is now accepted as a zone name in the SOURCE column of
shorewall-conntrack(5). As in the rules file, it means all zones.
5) Because of the potential for attackers to subvert Netfilter helpers
like the one for FTP, the Netfilter team are in the process of
eliminating the automatic association of helpers to connections. In
the 3.5 kernel, it is possible to disable this automatic
association, and the team have announced that automatic association
will eventually be eliminated. While it is certainly more secure to
add explicit rules that create these associations, for Shorewall to
require users to add those rules would present a gross
inconvenience during a Shorewall upgrade.
To make Shorewall and kernel upgrades as smooth as possible,
several new features have been added in this release:
- Shorewall will automatically disable the kernel's automatic
association of helpers to connections on kernel 3.5 and later.
- An automatic association of helpers with connections that
performs the same function as in the pre-3.5 kernels has been
added. This automatic association is controlled by the new
AUTOHELPERS shorewall.conf option which is set to 'Yes' by
default.
- A HELPERS column has been added to the /etc/shorewall/rules
In the NEW section:
When the ACTION is ACCEPT, DNAT or REDIRECT, the specified
helper is automatically associated with the connection. HELPERS
may be specified in action files, macros and in the rules file
itself.
In the RELATED section:
The rule will only match related connections that have the
named helper attached.
- The standard Macros for applications requiring a helper (FTP,
IRC, etc) have been modified to automatically specify the correct
helper in the HELPER column.
- HELPER is now a valid action in /etc/shorewall/rules. This action
requires that a helper be present in the HELPER column and causes
the specified helper to be associated with connections matching
the rule. No destination zone should be specified in HELPER
rules. HELPER rules allow specification of a helper for
connections that are ACCEPTed by the applicable policy.
Example:
loc->net policy is ACCEPT.
In /etc/shorewall/rules:
FTP(HELPER) loc -
or equivalently
HELPER loc - tcp 21 ; helper=ftp
- The set of enabled helpers (either by AUTOHELPERS=Yes or by the
HELPERS column) can be taylored using the new HELPERS option in
shorewall.conf.
By making AUTOHELPERS=Yes the default, users can upgrade their
systems to a 3.5+ kernel without disrupting the operation of their
firewalls. Beyond such upgrades, we suggest setting AUTOHELPERS=No
and follow one of two strategies:
- Use the HELPERS column in the rules file to enable helpers as
needed (preferred); or
- Taylor the conntrack file to enable helpers on only those
connections that are required.
With either of these approaches, the list if available helpers can
be trimmed using the HELPERS option and rules can be added to the
RELATED section of the rules file to further restrict the effect of
helpers.
The implementation of these new function places conditional rules
in the /etc/shorewall[6]/conntrack file. These rules are included
conditionally based in the setting of AUTOHELPERS.
Example:
?if $AUTOHELPERS && __CT_TARGET
?if __FTP_HELPER
CT:helper:ftp all - tcp 21
?endif
...
?endif
__FTP_HELPER evaluates to false if the HELPERS setting is
non-empty and 'ftp' is not listed in that setting.
For example, if you only need FTP access from your 'loc' zone, then
add this rule outside of the outer-most ?if....?endif shown above.
CT:helper:ftp loc - tcp 21
For an overview of Netfilter Helpers and Shorewall's support for
dealing with them, see
http://www.shorewall.net/Helpers.html.
See
https://home.regit.org/netfilter-en/secure-use-of-helpers/
for additional information.
6) To make the spelling of the AUTO* shorewall[6].conf options
consistent, the AUTO_COMMENT option has been renamed
AUTOCOMMENT. AUTO_COMMENT is still accepted as an
alias. 'shorewall[6] update' will rename the option in the updated
.conf file.
7) The CT:helper action in the /etc/shorewall[6]/conntrack file
(formerly the notrack file) lacked flexibility. To allow different
options to be specified for each helper, the syntax of the
CT:helper action has been redesigned.
CT:helper:<helper>[(<option>=<value>[,...])]
where <option> is one of:
- ctevents
- expevents
Example:
CT:helper:ftp(expevents=new)
See shorewall-conntrack (5) for details.
8) The deprecated /etc/shorewall[6]/blacklist files are no longer
installed. Existing files are still processed by the compiler. Note
that blacklist files may be converted to equivalent blrules files
using 'shorewall[6] update -b'.
9) "?IF", "?ELSE", "?ELSEIF" and "?END" are now case-insensitive so,
for example, they can be entered as "?if", "?else", "elseif" AND
"?end".
10) Optimization level 4 now locates short chains (3 rules or less)
that have a single reference and replaces that single reference with
the rules themselves.
Optimization level 8 now eliminates duplicate rules in the raw
table.
----------------------------------------------------------------------------
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) This release includes the defect repairs from Shorewall 4.5.5.1 through
4.5.5.4.
2) Previously, the tcrules file was not processed when
TC_ENABLED=No. That meant that to use features like TPROXY, it was
necessary to set TC_ENABLED=Yes and create a dummy
/etc/shorewall/tcstart file. Now, only MANGLE_ENABLED=Yes is
required.
----------------------------------------------------------------------------
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) Support for size tables has been added in complex TC.
The OPTIONS column of /etc/shorewall/tcdevices now allows a
'linklayer' option whose value may be 'ethernet', 'atm' or 'adsl';
the last two are synonyms.
When 'linklayer' is specified, it may be followed by additional
options:
mtu=<mtu> - The device MTU; default 2048 (will be rounded up to a
power of two)
mpu=<mpubytes> - Minimum packet size used in
calculations. Smaller packets will be rounded up
to this size
tsize=<tablesize> - Size table entries; default is 512
overhead=<overheadbytes> - Number of overhead bytes per packet.
See tc-stab (8) for details about these options.
2) It is now possible to specify the LS (linksharing) rate for an HFSC
class in /etc/shorewall/tcclasses. See shorewall-tcclasses (5) for
details.
3) It is now possible to specify that a leaf class will use the RED
(Random Early Detection) queuing discipline rather than SFQ or
pfifo. A new class OPTION is defined:
red=(<red option>=<value>, ...)
When specified on a leaf class, causes the class to use the RED
(Random Early Detection) queuing discipline rather than
SFQ. See tc-red (8) for additional information.
Allowable <red option>s are:
min <min>
Average queue size in bytes at which marking becomes a
possibility.
max <max>
At this average queue size, the marking probability is
maximal. Must be at least twice <min> to prevent
synchronous retransmits, higher for low <min>.
probability <probability>
Maximum probability for marking, specified as a floating
point number from 0.0 to 1.0. Suggested values are 0.01 or
0.02 (1 or 2%, respectively).
limit <limit>
Hard limit on the real (not average) queue size in bytes.
Further packets are dropped. Should be set higher than
<max>+<burst>. It is advised to set this a few times higher
than <max>. Shorewall requires that <limit> be at least
twice <min>.
burst <burst>
Used for determining how fast the average queue size is
influenced by the real queue size. Larger values make the
calculation more sluggish, allowing longer bursts of
traffic before marking starts. Real life experiments
support the following guideâ€line:
(<min>+<min>+<max>)/(3*<avpkt>).
avpkt <avpkt>
Optional. Specified in bytes. Used with burst to determine
the time constant for average queue size calculations. 1000
is a good value and is the Shorewall default.
bandwidth <bandwidth>
Optional. This rate is used for calculating the average
queue size after some idle time. Should be set to the
bandwidth of your interface. Does not mean that RED will
shape for you!
ecn
RED can either 'mark' or 'drop'. Explicit Congestion
Notification (ECN) allows RED to notify remote hosts that
their rate exceeds the amount of bandwidth
available. Non-ECN capable hosts can only be notified by
dropping a packet. If this parameter is specified, packets
which indicate that their hosts honor ECN will only be
marked and not dropped, unless the queue size hits limit
bytes. Needs a tc binary with RED support compiled
in. Recommended.
4) The handling of the USER/GROUP column of the rules file has been
rewritten. As part of this rewrite:
a) The ability to specify a program name (e.g., +prog) has been
eliminated. The kernel feature which that ability depended on
was removed in kernel version 2.6.14.
b) It is now possible to specify UID and/or GID ranges of the form
'low-high' where 'low' and 'high' are integers and low <= high.
5) It is now possible to use Perl-compatible expressions in ?IF
directives. As before, variables must be environmental variables,
options from shorewall.conf, shell variables set in the params file
or capabilities. As previously, capabilities may be entered with
leading '__' rather than '$'.
Example:
?IF $BLACKLIST_LOGLEVEL && ! __LOG_OPTIONS
6) The ?ELSIF directive has been added allowing more convenient
expression of complex include scenarios.
Example (column headings abbreviated to fit release notes format):
#NAME NUM MARK DUP INTERFACE GWAY OPTIONS
?IF $FALLBACK
ComcastB 1 0x10000 - COMB_IF detect fallback
ComcastC 2 0x20000 - COMC_IF detect fallback
?ELSIF $STATISTICAL
ComcastB 1 0x10000 - COMB_IF detect load=0.66666667
ComcastC 2 0x20000 - COMC_IF detect load=0.33333333
?ELSE
ComcastB 1 0x10000 - COMB_IF detect balance=2
ComcastC 2 0x20000 - COMC_IF detect loose,balance
?ENDIF
7) And ORIGINAL DEST column has been added to the masq file, allowing
SNAT rules to match only DNAT traffic to a particular original source
address.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 5
----------------------------------------------------------------------------
1) This release includes all defect repair from Shorewall 4.5.4.1 and
4.5.4.2.
2) The Shorewall compiler sometimes must defer generating a rule until
runtime. This is done by placing shell commands in its internal
representation of a chain. These commands are then executed at run
time to create the final rule.
If all of the following were true, then an incorrect ruleset could
be generated:
a) Optimization level 4 was set.
b) A chain (chain A) containing shell commands had three or fewer
rules and commands.
c) The last rule in a second chain was a conditional jump to
chain A.
Under these conditions, the rules and commands in Chain A replaced
the conditional jump and the conditional part was lost.
Example (Lines are folded to fit the release note format):
Chain A:
if [ $SW_ETH0_ADDRESS != 0.0.0.0 ]; then
echo "-A net_dnat -d $SW_ETH0_ADDRESS\
-j DNAT --to-destination 1.2.3.4" >&3
fi
Chain B:
...
-A dnat -i eth0 -j
Result:
if [ $SW_ETH0_ADDRESS != 0.0.0.0 ]; then
echo "-A dnat -d $SW_ETH0_ADDRESS\
-j DNAT --to-destination 1.2.3.4" >&3
fi
Notice that the '-i eth0' match has been lost.
3) The Shorewall-core configure and configure.pl script were treating
SYSCONFDIR as a synonym for CONFDIR making it impossible to set
SYSCONFDIR.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 5
----------------------------------------------------------------------------
1) It is now possible to include additional information in netfilter
messages when using plain log levels (debug, info, ...). This is
done by following the level with a parenthesized comma-separated
list of "log options".
Valid log options are:
ip_options
Log messages will include the option settings from the IP
header.
macdecode
Decode the MAC address and protocol.
tcp_sequence
Include TCP sequence numbers.
tcp_options
Include options from the TCP header.
uid
Include the UID of the sending program; only effective for
packets originating on the firewall itself.
Example: info(tcp_options,tcp_sequence)
2) The Shorewall-init configuration file (/etc/default/shorewall-init
or /etc/sysconfig/shorewall-init) now contains a LOGFILE setting.
When specified, all messages generated by interface updown events
are logged there. The sample configuration file and the logrotate
file configure this log as /var/log/shorewall-ifupdown.log.
3) Previously, the 'ignore' interface option could only be specified
by itself and could not be specified unless the ZONE column was
empty (i.e, contained '-'). Now, it is allowed to specify
'ignore=1' without these restrictions.
With 'ignore=1', the generated script will still ignore
Shorewall-init 'up' and 'down' events but the interface will still
be subject to hairpin filtering unless it has the 'routefilter' or
'routeback' option.
4) Imbedded shell and Perl directives may now be optionally preceded
by a question mark ('?').
Example:
?BEGIN PERL
use strict;
...
?END PERL
5) To aid package maintainers for distributions that don't include the
Digest::SHA Perl module, the Shorewall install.sh script looks for
the DIGEST environmental variable and if the setting is not 'SHA',
then the Shorewall::Chains module is modified to use $DIGEST as the
module name.
To specify SHA1
DIGEST=SHA1 ./install.sh
----------------------------------------------------------------------------
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) This release includes all defect repairs from Shorewall 4.5.3.1.
2) When EXPORTMODULES=No in shorewall.conf, the following errors were
issued:
/usr/share/shorewall/modules: line 19: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 23: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 27: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 31: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 35: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 39: ?INCLUDE: command not found
These messages have been eliminated.
3) If the configuration settings in the PACKET MARK LAYOUT section of
shorewall.conf (shorewall6.conf) had empty settings, the 'update'
command would previously set them to their default settings. It now
leaves them empty.
4) Previously, Shorewall used 'unreachable' routes to null-route the
RFC1918 subnets. This approach has two drawbacks:
- It can cause problems for IPSEC in that it can cause packets to
be rejected rather than encrypted and forwarded.
- It can return 'host unreachable' ICMPs to other systems that
attempt to route RFC1918 addresses through the firewall.
To eliminate these problems, Shorewall now uses 'blackhole' routes.
Such routes don't interfere with IPSEC and silently drop packets
rather than return an ICMP.
5) The 'default' routing table is now cleared if there are no
'fallback' providers.
----------------------------------------------------------------------------
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) The TPROXY tcrules action introduced in Shorewall 4.4.7 was
incomplete and required additional rules to be added in the 'start'
or 'started' extension scripts.
In this release, the TPROXY implementation has been changed and an
additional DIVERT action has been created. Because the new TPROXY
has a different set of parameters than the prior one, the tcrules
file now supports two formats:
FORMAT 1 - (default, deprecated )
The TPROXY action allows three arguments, the first of which
('mark') is required.
FORMAT 2
The TPROXY action has two optional arguments; these are the
second and third arguments to the format-1 TPROXY:
port -- the port on which the proxy is listening. While
this argument is optional, it will normally be
supplied.
ip address -- The address on which the proxy is listening.
The file format is specified by a line like this:
FORMAT {1|2}
The Sample configurations have been updated to use FORMAT 2.
The format-2 tcrules file also supports the DIVERT action. The
DIVERT action directs matching packets to the local system if there
is a transparent socket in the local system that matches the
destination of the packet. DIVERT is used to redirect response
packets from remote web servers back to the proxy process
running on the firewall rather than being routed directly back to
the client.
Finally, the providers file supports a new 'tproxy' option. When
'tproxy' is specified:
- It must be the only OPTION given
- The MARK, DUPLICATE and GATEWAY columns must be empty.
- The loopback device (lo) should be specified as the INTERFACE.
The 'tproxy' option causes a reserved mark value to be associated
with the provider and for its associated routing rule to have
priority 1.
Here is the TPROXY configuration at shorewall.net:
interfaces:
FORMAT 2
#ZONE INTERFACE OPTIONS
net eth0 ...
net eth1 ...
loc eth2 ...
- lo ignore
tcrules:
FORMAT 2
#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(S)
DIVERT eth1 - tcp - 80
DIVERT eth0 - tcp - 80
TPROXY(3129,172.20.1.254) eth2 - tcp 80
providers:
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
...
Squid 3 - - lo - tproxy
/etc/squid3/squid.conf:
...
http_port 172.20.1.254:3129 tproxy
...
2) With some misgivings, this release adds support for the geoip match
feature available in xtables-addons. Geoip allows matching of the
source or destination IP address by ISO 3661 country codes. The
Shorewall support requires xtables-addons 1.33 or later.
The support is implemented in the form of extended syntax in the
SOURCE and DEST columns of the rules file.
To specify a single country code, add a caret prefix ('^').
Example: ^A1
To specify multiple country codes, enter them as a
comma-separated list enclosed in square brackets ('[...]') with a
caret prefix ('^').
Example: ^[A1,A2]
A listing of two-character country codes is available at
http://www.shorewall.net/ISO-3661.html.
Example rule - Drop email from Anonymous Proxies and Satellite
Providers:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
DROP:info net:^[A1,A2] dmz tcp 25
The compiler determines the set of valid country codes by examining
the geoip database which is normally installed in
/usr/share/xt_geoip/. There are two sub-directories at that
location:
BE - The big-endian database.
LE - The little-endian database.
To accomodate both big-endian and little-endian machines and
to allow the database to be installed elsewhere, a GEOIPDIR option
has been added in shorewall.conf and shorewall6.conf. The default
setting is "/usr/share/xt_geoip/LE" since Shorewall is normally
installed on little-endian machines.
3) OPTIMIZE level 4 now performs an additional optimization. If the
last rule in a chain is an unqualified jump to a simple target,
then all immediately preceding rules with the same simple target
are omitted.
For example, consider this chain:
-A fw-net -p udp --dport 67:68 -j ACCEPT
-A fw-net -p udp --sport 1194 -j ACCEPT
-A fw-net -p 41 -j ACCEPT
-A fw-net -j ACCEPT
Since all of the rules are jumps to the simple target ACCEPT, this
chain is totally optimized away and jumps to 'fw-net' are replaced
with jumps to ACCEPT.
As part of this enhancement, when both OPTIMIZE level 1 and level 4
are selected, the level 1 optimization step is skipped because it
is now a limited subset of level 4.
4) Tuomo Soini contributed a macro for MS SQL (macro.MSSQL).
----------------------------------------------------------------------------
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.5.3.1
1) Previously, nested conditionals did not work correctly in all
cases. In particular:
?IF $FALSE
?IF $FALSE
foo
bar
?ENDIF
baz
bop
?ENDIF
In this case, the lines 'baz' and 'bop' were incorrectly included
when they should have beeen omitted.
2) The 'balance' routing table is now cleared if there are no
'balance' providers.
3) Previously, the compiler generated an invalid 'ip add route'
command if an IPv6 provider had '-' in the GATEWAY column.
4) As noted in the Migration Considerations below, the generated
firewall script maintains the interface .status files used by LSM
and SWPING. Up to now, however, the 'disable' command did not
update the .status file. That has been corrected. As part of the
change, the 'isusable' script is no longer consulted by the
'enable' command.
5) The configure and configure.pl scripts have not been outputting the
setting of SPARSE, with the result that /etc/shorewall and
/etc/shorewall6 are fully-populated on Debian systems. This has
been corrected.
For Debian users that want to remove the extra files from
/etc/shorewall (/etc/shorewall6), the following script will
do the job (replace 'shorewall' by 'shorewall6' to clean
/etc/shorewall6):
#!/bin/sh
cd /etc/shorewall
for f in *; do
[ -f /usr/share/shorewall/configfiles/$f ] && \
diff -q $f /usr/share/shorewall/configfiles/$f > /dev/null \
&& rm $f;
done
Once you have done that, edit ~/.shorewallrc and add
SPARSE=Yes
to the settings in that file.
4.5.3
1) This version includes all defect repairs from Shorewall 4.5.2.1 -
4.5.2.4.
2) The LOCKFILE setting in shorewall.conf and shorewall6.conf had
inadvertently become undocumented. It is now documented again.
3) In an initial installation of Shorewall, Shorewall6, Shorewall Lite
or Shorewall6 Lite was done under Shorewall 4.5.2, then the
firewall would not start up at boot even though the installer
indicated that it would. That defect has been corrected.
4) Previously, when per-IP rate limiting was invoked, the compiler
would use the deprecated '--ratelimit' option, even if the
preferred '--ratelimit-upto' option was available. Now, the
compiler uses the preferred option if it is supported by the
installed version of iptables.
5) Prior to this release, using a manual chain in the ACTION column of
a macro body generated an error:
ERROR: Invalid Action (mychain) in macro, macro.FOO (line ...)
This now works correctly and generates a jump to the specified
manual chain.
6) If SHAREDIR was other than /usr/share and $CONFDIR/shorewall/init
did not exist, then an error message similar to this is emited:
Processing /usr/local/share/shorewall/init ...
Usage: /etc/init.d/shorewall
{start|stop|refresh|restart|force-reload|status}
7) Prevously, a line with the single word COMMENT in the tunnels file
would generate the following error:
ERROR: Zone must be specified
Now, such a line correctly resets the current rule comment.
8) In Shorewall 4.5.2, the MARK column in the tcrules file was renamed
to ACTION but only 'mark' was accepted in the alternate
specification format. Now both 'mark' and 'action' are accepted.
9) The alternative method of provider balancing using the statistic
match feature of iptables/Netfilter was missing some logic, with
the result that it was ineffective.
10) If a logical interface name was used by itself in the SOURCE column
of the rtrules file, the generated routing rule would contain the
logical name rather than the physical name.
----------------------------------------------------------------------------
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) Shorewall's TPROXY support is incomplete. A new and slightly
different implementation of TPROXY will be available in Shorewall
4.5.4.
----------------------------------------------------------------------------
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) The '-T' option is now supported in the Shorewall and Shorewall6
'load', 'reload', 'restart' and 'start' commands. As with the
'check' command, it causes a Perl stack trace to be printed along
with compiler WARNING and ERROR messages.
2) The debuggability of assertion failures has been improved.
- A Perl stack trace is now generated unconditionally on an
assertion failure.
- Relevant data is passed as additional arguments to assertion
checks so that setting a breakpoint in
Shorewall::Config::assert() can now allows examination of the
data structures surrounding the failure.
3) The GATEWAY column of the tunnels file has been renamed 'GATEWAYS'
and now accepts a list of host and network addresses as well as IP
ranges.
Exclusion is not permitted.
In the alternate specification format, both 'gateway' and
'gateways' are accepted as the column name.
4) The 'refresh' command now allows additional options:
-d - Run the rules compiler under the Perl debugger.
-n - Don't modify routing.
-T - Produce a Perl Stack trace on errors and warnings.
-D <directory> - Look in <directory> first for configuration files.
5) The interfaces file now supports two formats:
FORMAT 1 - (default, deprecated)
Includes the BROADCAST column (UNICAST in Shorewall6).
FORMAT 2
Does not include the BROADCAST (UNICAST) column.
The format is specified by a line line this:
FORMAT {1|2}
The Sample configurations have been updated to use FORMAT 2.
6) A change has been made in the packaging for Slackware. On
Slackware, there is an /etc/rc.d/firewall.rc script that looks for
/etc/rc.d/shorewall.rc and /etc/rc.d/shorewall6.rc and runs them,
passing it's own arguments.
The file installed as firewall.rc is named
init.slackware.firewall.sh and has traditionally been included in
the Shorewall package. Beginning with this release, it is moved to
the Shorewall-core package. This opens the door for releasing
Slackware versions of the -lite products in the future.
The init scripts for Slackware are now described in slackware.rc
as:
AUXINITSOURCE=init.slackware.firewall.sh
AUXINITFILE=rc.firewall
INITSOURCE=init.slackware.$PRODUCT.sh
INITFILE=rc.$PRODUCT
7) Previously, errors reported in macros were hard to analyze.
Example:
ERROR: Unknown destination zone (bar)
/usr/share/shorewall/macro.SSH (line 11),
In this case, we don't know where the SSH macro was invoked
incorrectly. Beginning with this release, the stack of
includes/opens will be included in ERROR and WARNING messages.
Example:
ERROR: Unknown destination zone (bar)
/usr/share/shorewall/macro.SSH (line 11)
from /etc/shorewall/rules (line 42)
This shows that the SSH macro was invoked on line 42 of the rules
file.
8) There is now a BLACKLIST macro that works as follows:
- If BLACKLIST_LOGLEVEL is set, then the macro invokes the
'blacklog' action.
- Otherwise, the macro invokes the BLACKLIST_DISPOSITION action.
9) An RST action has been added which matches tcp packets with the RST
flag set. The action accepts two optional parameters:
- Action (DEFAULT, ACCEPT or DROP). Default is DROP.
- Audit ('audit' or omitted). Default is omitted.
----------------------------------------------------------------------------
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) This release includes the defect repairs from Shorewall 4.5.1.1 and
4.5.1.2 (see below).
2) The generated firewall script includes code to automatically create
ipsets that are referenced but that don't exist. That code was
broken in releases 4.4.22 and later. This defect has been
corrected. As part of the fix, the generated script will now
issue a warning message when it creates an ipset.
----------------------------------------------------------------------------
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) The 'mss' option is now supported in the /etc/shorewall[6]/hosts
files. See the manpages for details.
2) It is now possible to conditionally include or omit configuration
entries based on the settings of shell variables. See
http://www.shorewall.net/configuration_file_basics.htm#Conditional
for details.
3) The MARK/CLASSIFY column in /etc/shorewall[6]/tcrules has been
renamed ACTION to reflect the expanded set of actions that can be
specified in the column.
4) Some users are finding these ipset warnings objectionable:
- Warning when a referenced ipset does not exist.
- Warning when using [src] in a destination column or [dst] in a
source column.
These warnings may now be suppressed by setting IPSET_WARNINGS=No
in shorewall.conf and/or shorewall6.conf.
5) The evolution of the Shorewall installation process
continues. Testers are invited to provide comments and suggestions
about the following.
Beginning with this release, the installers accept a configuration
file as a parameter. Options set in the configuration file are as
follows:
BUILD (optional) -- Platform on which the installation is being
performed. Possible values are:
apple - OS X
archlinux - ArchLinux
cygwin - Cygwin running under Windows
debian - Debian and derivatives
linux - Generic Linux system
redhat - Fedora, RHEL and derivatives
suse - SLES and OpenSuSE
If no value is assigned, then the installer
will detect the platform.
HOST (Optional) -- Allowed values are same as for BUILD. If not
specified, the BUILD setting is used.
CONFDIR (Req'd) -- Directory where product configuration
directory is installed. Normally /etc.
SHAREDIR (Req'd) -- Directory where architecture-independent
product files are installed. Normally
/usr/share.
LIBEXECDIR (Req'd) -- Directory where product executables are
installed. Normally /usr/share or
/usr/libexec.
PERLLIBDIR (Req'd) -- Directory where Shorewall Perl modules are
to be installed. Traditionally
/usr/share/shorewall.
SBINDIR (Req'd) -- Directory where product CLI programs are
installed. Normally /sbin
MANDIR (Req.d) -- Directory where manpages are
installed. Mornally /usr/share/man.
INITFILE (Optional)
-- Optional. If given, specifies the installed
filename of the initscript. Normally
set to $PRODUCT which the installers expand
to the name of the product being installed.
If not specified, no init script will be
installed.
INITSOURCE (Optional)
-- Must be specified if INITFILE is specified.
Gives the name of the file to be installed
as the INITFILE.
INITDIR (Optional) -- Directory where SysV init scripts are
installed. Must be specified if INITFILE is
specified.
ANNOTATED (Optional)
-- If non-empty, indicates that the
configuration files are to be annotated with
manpage information. Normally empty.
SYSTEMD (Optional) -- Name of the directory where .service files
are to be installed. Should only be specified
on systems running systemd.
SYSCONFDIR (Optional)
-- Name of the directory where subsystem
init configuration information is stored.
On Debian and derivates, this is
/etc/default. On other systems, it is
/etc/sysconfig.
SYSCONFFILE (Optional)
-- Name of the file to be installed in the
SYSCONFIGDIR. The installed name of the file
will always be the product name (shorewall,
shorewall-lite, etc.)
SPARSE (Optional) -- If non-empty, causes only the .conf file to
be installed in
${CONFDIR}/${PRODUCT}/. Otherwise, all of
the product's skeleton configuration files
will be installed.
TEMPDIR (Optional) -- If non-empty, the generated firewall script
will export the variable TMPDIR with
value $TEMPDIR.
VARDIR (Required) -- Directory where product state information
is stored. Normally /var/lib.
This setting was previously stored in the
optional vardir file in the product's
configuration directory.
Each of the product tarballs contains a set of configuration files
for the various HOSTS:
shorewallrc.apple
shorewallrc.archlinux
shorewallrc.cygwin
shorewallrc.debian
shorewallrc.default (for HOST 'linux')
shorewallrc.redhat
shorewallrc.suse
To aid distribution packagers, a configure script has been added.
The arguments to the script are the usual list of <option>=<value>
assignments. The supported options are the same as those above,
although they may be in lower case and may be optionally preceded
by '--'.
The configure script uses the setting of --host to select the
appropriate rc file. It reads that file to establish default
settings and then applies the values specified in the argument
list. To allow use with the %configure RPM macro, only the last
occurrence of a particular option setting is applied. The resulting
settings are written to a file named 'shorewallrc' in the current
working directory and are also written to standard out.
When Shorewall-core is installed on a system (with no DESTDIR), it
copies the specified configuration file into root's
~/.shorewallrc. The ~/.shorewallrc file is then used, by default,
when installing the other packages.
To further aid use with %configure, several aliases are supported:
alias option
----- ------
sharedstatedir vardir
datadir sharedir
sysconfdir confdir
The configuration file is also copied to
${SHAREDIR}/shorewall/shorewallrc where the CLI programs and init
scripts can find it. Those programs are modified by the installer
when ${SHAREDIR} is not /usr/share.
When using Shorewall-lite or Shorewall6-lite, if the remote
firewall's shorewallrc file differs from that on the firewall, then
a copy of the remote file should be placed in the firewall's
configuration directory on the administrative system.
Beginning with this release, using /etc/shorewall-lite/vardir
and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in
favor of the VARDIR setting in shorewallrc.
NOTE: While the name of the variable remains VARDIR, the
meaning is slightly different. When set in shorewallrc,
each product (shorewall-lite, and shorewall6-lite) will
create a directory under the specified path name to
hold state information.
Example:
VARDIR=/opt/var/lib/
The state directory for shorewall-lite will be
/opt/var/lib/shorewall-lite/ and the directory for
shorewall6-lite will be /opt/var/lib/shorewall6-lite.
When VARDIR is set in /etc/shorewall[6]-lite/vardir, the
product will save its state in the specified directory.
----------------------------------------------------------------------------
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.5.1.2
1) The Shorewall Lite and Shorewall6 Lite installers have been
installing the wrong SysV init script on Debian and derivatives.
The correct script is now installed.
2) Nested TC classes could result in Perl diagnostics like this one:
Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in
numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042,
<$currentfile> line 13.
These harmless messages have been eliminated.
3) It is once again possible to omit the minimum length in the LENGTH
column of the tcrules file.
4) Under the following conditions, a compiler internal error was
raised:
- Extended conntrack match support is available.
- Repeat Match is not available.
- A DNAT rule specifies a destination port, a server port and
an original destination.
5) Beginning with release 4.4.26, setting both 'nets=' and 'dhcp' on
an interface does not work correctly. That issue has been resolved
in this release.
4.5.1.1
1) When checking or compiling for export (-e option), /sbin/shorewall
would previously issue a warning message if the SHOREWALL_SHELL
specified in the remote firewall's shorewall.conf did not exist.
2) The changes to TOS handling in 4.5.1 are incompatible with older
releases such as RHEL5 and derivatives. That has been corrected.
3) The rules compiler now verifies that the protocol is TCP, UDP, SCTP
or DCCP when checking a port range (low:high or low-high).
4) Previously, start or restart using the init script would fail with
an error message referencing 'SHOREWALL_INIT_SCRIPT'. This defect
was not visible to users that set AUTOMAKE=Yes or that run
Shorewall-init.
4.5.1
1) This release includes all defect repair from versions
4.5.0.1-4.5.0.3.
2) The Shorewall-init installer now installs the proper init script on
Redhat and Fedora.
3) A typo has been corrected in the blrules man pages.
4) Previously, if the interface appearing in the HOSTS column of
/etc/shorewall6/hosts was not defined in
/etc/shorewall6/interfaces, then the compiler would terminate with
a Perl diagnostic:
Can't use an undefined value as a HASH reference at
/usr/share/shorewall/Shorewall/Zones.pm line 1817,
<$currentfile> line ...
5) The handling of the LIBEXEC and PERLLIB variables was broken in the
base 4.5.0 release. Simon Mater has supplied a fix which is
included in this release.
6) On systems running systemd, init scripts are no longer installed in
/etc/rc.d/init.d.
7) The Shorewall Init installer now correctly detects the use of
systemd.
8) On systems running systemd, the installer now installs
/sbin/shorewall-init. That file has not existed previously, even
though shorewall-init.service is trying to use it.
9) The compiler was previously failing to validate the contents of the
LENGTH and TOS columns in /etc/shorewall/tcrules. The contents of
those columns are now validated by the compiler and an appropriate
error message is issued if validation fails.
10) The column headings in the tos files are now in the proper
order. Previously, the SOURCE PORT and DEST PORT columns were
reversed.
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------
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) Support is now included for IMQ. This takes the form of of
IMQ(<number>) in the MARK/CLASSIFY column of
/etc/shorewall/tcrules.
2) It is no longer necessary to specify a MARK value for the default
class under a device that does not specify the 'classify'
option. Simple set the MARK column to '-' in the default class.
3) Previously, the install scripts included in the Shorewall packages
were very restrictive. They could either be run to install directly
onto the system in a distribution-dependent way, or they could
install into a directory in a distribution-independent way. This
limited their usefullness to packagers.
Beginning with this release, the install scripts handle the install
system and the target system independently. When running an
installer, the following environmental variables can be set:
a) BUILD - Describes the system where the installer is
running. Accepted values are:
cygwin - Cygwin running under a Microsoft OS
apple - OS X
debian - Debian,Ubuntu,etc.
redhat - Fedora,RHEL,Centos,Foobar,etc.
slackware - Slackware
archlinux - Arch Linux
linux - Generic Linux
If BUILD is not set, then the installer uses its existing
algorithm for detecting the current OS and distribution.
b) HOST - Describes the system where the installed package
will run.
- For Shorewall and Shorewall6, the possible values are
the same as for BUILD.
- If HOST is not set, the value of BUILD (through setting or
detection) is used.
- For Shorewall-lite and Shorewall6-lite, the possible choices
are debian, redhat, suse, slackware, archlinux and
linux.
- For Shorewall-init, the possible choices are debian,
redhat, and suse.
c) INITDIR - Gives the absolute path name of the directory
containing the init scripts.
The choice of HOST and TARGET follow the naming of similar macros
in rpm and autoconf.
As part of these changes, LIBEXEC and PERLLIB must now hold an
absolute pathname. So, for example, if you have been using
LIBEXEC=libexec
you will need to change to
LIBEXEC=/usr/libexec
Additionally, support has been added for sourcing a file containing
option settings. The file name is 'shorewall-pkg.config' in the
parent directory of the untar'ed package file.
5) The .spec files included with each package have undergone
considerable revision.
When running the package ./install.sh script:
a) The setting for LIBEXEC is taken from the standard '_libexecdir'
rpm macro.
b) The setting for PERLLIB is taken from the standard
'perl_privlib' rpm macro.
c) The setting for INITDIR is taken from the standard
'_initddir' rpm macro.
d) The setting of BUILD is detected by the install script.
e) The setting for TARGET is taken from the standard '_vendor' rpm
macro.
The rpms included with Shorewall are built with these settings of
the standard rpm-supplied macros:
%_libexecdir /usr/libexec
%perl_privlib /usr/share/shorewall
%_initddir /etc/init.d
%_vendor suse
The setting of %perl_sitelib is chosen for portability, since there
seems to be no common location for site-specific Perl modules among
the rpm-based distributions.
6) A SWITCH column has been added to /etc/shorewall/masq. This column
allows for enabling and disabling a rule based on a setting in
/proc/net/nf_condition. See shorewall-masq(5) for details.
7) The rules compiler now issues a warning when the 'src' ipset flag
is used in a destination column or the 'dst' ipset flag is used in
a source column.
8) Support has been added for matching and setting the "Differentiated
Services Code Point" (DSCP) field in the IP header. See
shorewall-tcrules(5) and shorewall6-tcrules(5) for details.
9) "Run-time gateway variables" are now supported. These variables
have names that are composed of a percent sign ('%') followed by
the logical name of an interface defined in
/etc/shorewall/interfaces. They are expanded to the IP address of
the default gateway out of the corresponding interface.
Example:
%eth0 expands to the IP address of the default gateway out of eth0.
See
http://www.shorewall.net/configuration_file_basics.htm#Variables
for details.
10) The 'update' command now omits non-default settings of
WIDE_TC_MARKS and HIGH_ROUTE_MARKS from the updated .conf file.
11) The 'isusable' extension script is no longer installed by
default. Users wishing to install it may simply copy it from
/usr/share/shorewall[6]/configfiles.
12) Support has been added for seting the "Type of Service" (TOS)
header field in shorewall-tcrules(5) and shorewall6-tcrules(5). See
the manpages for details. As part of this change, use of the
shorewall-tos(5) and shorewall6-tos(5) files is deprecated and a
warning is issued on the first rule in each file.
----------------------------------------------------------------------------
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) This release includes all defect repair included in
4.4.27.1-4.4.27.3.
2) The start and restart commands in Shorewall Lite and Shorewall6
Lite now correctly handle the 'trace' and 'debug'
keywords. Previously, those keywords were ignored.
3) The 'ip route list' command on recent Linux systems (Ubuntu 11.10,
for example) displays the IPv4 routing table in a seemingly random
order. In the 'show routing' and 'dump' commands, Shorewall and
Shorewall-lite now sort the output into the traditional
'Most-specific to most-general' order.
4) Previously, specifying 'No' in the HAVEROUTE column of
/etc/shorewall6/proxyndp resulted in a run-time error. The code has
been corrected so that no error occurs.
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------
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) The rules generated by the following interface options are now
traversed after those generated by the blrules file.
dhcp
maclist
nosmurfs
sfilter
tcpflags
As part of this change, the BLACKLIST section in the rules file has
been eliminated. If you have rules in that section, you must move
them to the blrules file prior to installing this Shorewall
version.
2) The timeout interval after which the previous state is restored
may now be specified in the safe-start and safe-restart commands.
3) The packing of the Shorewall products has been changed. Beginning
with this release, the packages are:
- Shorewall Core -- Core libraries installed in
/usr/share/shorewall/
- Shorewall -- Requires Shorewall Core. Together with
Shorewall Core, provides IPv4 firewalling.
- Shorewall6 -- Requires Shorewall. Provides IPv6 firewalling.
- Shorewall Lite -- Requires Shorewall Core. As before.
- Shorewall6 Lite -- Requires Shorewall Core. As before.
- Shorewall Init -- As before.
4) Shorewall and Shorewall6 now share a single install.sh file as do
Shorewall Lite and Shorewall6 Lite.
5) Functions common to both /usr/share/shorewall/prog.header and
/usr/share/shorewall/prog.header6 are now in a new library -
lib.core. The files /usr/share/shorewall/prog.footer is now used
for both IPv4 and IPv6.
6) Run-time address variables (e.g., ð0) may now be used in the
SOURCE column of the rtrules files.
7) The route_rules file has been renamed to 'rtrules'. The Shorewall
and Shorewall6 installers will perform the rename on an existing
file.
If both files exist, route_rules will be processed and rtrules
will be ignored with a warning.
8) A 'PROBABILITY' column has been added to the tcrules files. It
causes the rule to match randomly with the probability specified in
the column. See shorewall-tcrules(5) and shorewall6-tcrules(5) for
details.
9) An alternative to the balance=<weight> option in the providers file
is now available. This alternative works when there are multiple
links to the same ISP where both links use an ethernet interface (as
opposed to PPP0E) and have the same default gateway.
As part of this change, the generated firewall script now
automatically maintains the
/var/lib/shorewall[6][-lite]/interface.status files used by SWPING
and by LSM.
See http://www.shorewall.net/MultiISP.html#load for additional
information.
Example that sends 1/3 of the connections to the ComcastC provider
and the rest to ComcastB:
/etc/shorewall/shorewall.conf
MARK_IN_FORWARD_CHAIN=No
...
USE_DEFAULT_RT=Yes
/etc/shorewall/providers:
#NAME NUMBER MARK DUP INTERFACE GATEWAY OPTIONS
ComcastB 1 - - eth1 70.90.191.126 loose,balance,load=0.66666667
ComcastC 2 - - eth0 67.170.120.1 loose,fallback,load=0.33333333
Note: The 'loose' option is specified so that the compiler will not
generate and rules based on interface IP addresses. That way
we have complete control over the priority of such rules
through entries in the rtrules file.
/etc/shorewall/rtrules
#SOURCE DEST PROVIDER PRIORITY
70.90.191.120/29 - ComcastB 1000
ð0 - ComcastC 1000
Note: eth0 has a dynamic address, so ð0 is used in the SOURCE
column.
Note: Priority = 1000 means that these rules will come before rules
/etc/shorewall/shorewall.conf
MARK_IN_FORWARD_CHAIN=No
...
USE_DEFAULT_RT=Yes
/etc/shorewall/providers:
#NAME NUMBER MARK DUP INTERFACE GATEWAY OPTIONS
ComcastB 1 - - eth1 70.90.191.126 loose,balance,load=0.66666667
ComcastC 2 - - eth0 67.170.120.1 loose,fallback,load=0.33333333
Note: The 'loose' option is specified so that the compiler will not
generate and rules based on interface IP addresses. That way
we have complete control over the priority of such rules
through entries in the rtrules file.
/etc/shorewall/rtrules
#SOURCE DEST PROVIDER PRIORITY
70.90.191.120/29 - ComcastB 1000
ð0 - ComcastC 1000
Note: eth0 has a dynamic address, so ð0 is used in the SOURCE
column.
Note: Priority = 1000 means that these rules will come before rules
that select a provider based on marks.
10) The Shorewall files in /etc/default and /etc/sysconfig now support
two new options that affect how '/etc/init.d/shorewall start'
and '/etc/init.d/shorewall restart' behave:
STARTOPTIONS -- options to the start commmand.
RESTARTOPTIONS -- options to the restart command.
For example, if you always want 'start' to flush the conntrack
table, then you would have:
STARTOPTIONS="-p"
11) The Git repository has been reorganized to place the samples and
manpages under their corresponding product directories. For
example, trunk/manpage6 was moved to trunk/Shorewall6/manpages.
----------------------------------------------------------------------------
M I G R A T I O N I S S U E S
----------------------------------------------------------------------------
1) If you are migrating from Shorewall 4.2.x or earlier, please see
http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.27/releasenotes.txt
2) The BLACKLIST section of the rules file has been eliminated.
If you have entries in that file section, you must move them to the
blrules file.
3) This version of Shorewall requires the Digest::SHA1 Perl module.
Debian: libdigest-sha1-perl
Fedora: perl-Digest-SHA1
OpenSuSE: perl-Digest-SHA1
4) The generated firewall script now maintains the
/var/lib/shorewall[6][-lite]/interface.status files used by SWPING
and by LSM.
----------------------------------------------------------------------------
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) Shorewall 4.4.27 includes all defect corrections provider by
Shorewall 4.4.26.1.
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.
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:
32767: from all lookup default
One such entry would be added for each provider.
Now, one such an entry is added to the IPv6 routing rules, only if
that entry does not already exist.
4) The formatting of the manpage info in the annotated configuration
files has been improved dramatically.
5) A blrules file generated by 'update -b' would fail the compilation
step with
ERROR: Unknown ACTION (A_blacklog)
if all the following were true:
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.
----------------------------------------------------------------------------
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) Up to this point, Shorewall has had a lot of very similar files in
multiple products.
Beginning with this release, the following files are identical.
- /sbin/shorewall
- /sbin/shorewall6
- /sbin/shorewall-lite
- /sbin/shorewall6-lite
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.
Shorewall and Shorewall6 share use of /usr/share/shorewall/lib.base
/usr/share/shorewall/lib.cli, and /usr/share/shorewall/lib.common.
/usr/share/shorewall6/lib.base is a small file that sets variables
and then sources /usr/share/shorewall/lib.base.
As before, shorewall and shorewall-lite share the same libraries
as do shorewall6 and shorwall6-lite.
Shorewall includes a new library: /usr/share/shorewall/lib.cli-std.
/usr/share/shorewall[6]/lib.cli contains everything needed by the
Lite products.
2) Shorewall now supports the CT target in the Netfilter 'raw'
table. See 'man shorewall-notrack' for details.
The main use of this target is described in this paper:
http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf.
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:
iptables -A PREROUTING -t raw -p tcp --dport 2121 \
-d 1.2.3.4 -j CT --helper ftp
The equivalent entry in /etc/shorewall/notrack would be:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
CT:helper:ftp 1.2.3.4 - tcp 2121
As part of this change, Shorewall now verifies the helper name in
the HELPER column of the tcrules and tcpri files.
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:
- RELATED_DISPOSITION
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.
- RELATED_LOG_LEVEL
Specifies a level for logging related packets. Default is empty
which means that no logging occurs.
4) The options in shorewall.conf (shorewall6.conf) may now be used as
shell variables in other configuration files.
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'.
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.
----------------------------------------------------------------------------
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
----------------------------------------------------------------------------
4.4.25.2
1) Previously, if all the following were true:
- AUTOMAKE=Yes
- Current compiled script (/var/lib/shorewall/firewall or
/var/lib/shorewall6/firewall) up to date
- LEGACY_FASTSTART=No
- There was a saved configuration
then rather than start the current configuration, 'shorewall start
-f' or 'shorewall6 start -f' would incorrectly restore the saved
configuration.
2) The DropSmurfs and TCPFlags actions are now available in
Shorewall6. They were previously omitted from the IPv6 actions.std
file.
3) The 'rawpost' table was previously omitted from the output of the
'dump' command. It is now displayed.
4) Previously, if a configuration contained more than one wildcard
interface (physical name ending in '+'), then the generated script
might not work properly with Shorewall-init. This defect dates back
to the introduction of Shorewall-init.
Example:
ZONE INTERFACE BROADCAST OPTIONS
z1 eth+ - optional
z2 veth+ - optional
The script will contain a case statement of this form:
case $interface in
...
eth*|veth+)
...
4.4.25.1
1) A 'refresh' command with no chains or tables specified will now
reload chains created by entries in the BLACKLIST section of the
rules file.
2) The rules compiler previously failed to detect the 'Flow Filter'
capability. That capability is now correctly detected.
3) The IN_BANDWIDTH handling change in 4.4.25 was incompatible with
moribund distributions such as RHEL4. Restoring IN_BANDWIDTH
functionality on those releases required a new 'Basic Filter'
capability.
4.4.25
1) A defect in the optimizer that allowed incompatible rules to be
combined has been corrected.
Example:
Rule1: -i eth1 -j chainx
Rule in chainx: -i eth2 -j ACCEPT
Incorrect result: -i eth2 -j ACCEPT
With the change in this release, Rule1 will remain as it is.
2) Routes and rules added as a result of entries in
/etc/shorewall6/providers were previously not deleted by
'stop' or 'restart'. Repeated 'restart' commands could therefore
lead to an incorrect routing configuration.
3) Previously, capital letters were disallowed in IPv6 addresses. They
are now permitted.
4) If the COPY column in /etc/shorewall6/providers was non-empty,
previously a run-time error could occur when copying a table. The
diagnostic produced by ip was:
Either "to" is duplicate, or "cache" is garbage
5) When copying IPv6 routes, the generated script previously attempted
to copy 'cache' entries. Those entries are now omitted.
6) Previously, the use of large provider numbers could cause some
Shorewall-generated routing rules to be ineffective.
Example (provider numbers 110 and 120):
0: from all lookup local
10109: from all fwmark 0x6e/0xff lookup 110
10119: from all fwmark 0x78/0xff lookup 120
11000: from 2001:470:1f04:262::1/64 lookup 110
11001: from 2001:470:c:316::1/64 lookup 120
32766: from all lookup main
47904: from 2001:470:8388::1 lookup 110 <===========
50464: from 2001:470:f032::1 lookup 120 <===========
Now, all routing rules generated by provider interface IP (and IP6)
addresses are created at priority 20000.
0: from all lookup local
10109: from all fwmark 0x6e/0xff lookup 110
10119: from all fwmark 0x78/0xff lookup 120
11000: from 2001:470:1f04:262::1/64 lookup 110
11001: from 2001:470:c:316::1/64 lookup 120
20000: from 2001:470:8388::1 lookup 110 <===========
20000: from 2001:470:f032::1 lookup 120 <===========
32766: from all lookup main
7) In some contexts, IPv6 addresses of the form ::i.j.k.l were
incorrectly classified as invalid by the configuration compiler.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 2 5
----------------------------------------------------------------------------
1) The original static blacklisting implementation was
interface-oriented and only handled blacklisting by source
address. In Shorewall 4.4.12, the ability to blacklist by
destination address was added and blacklisting could be specified
as a ZONE option. This change, plus additional changes in
subsequent releases has lead to an implementation that is complex
and hard to extend.
In this release, a new static blacklisting facility has been
implemented. This facility is separate from the legacy facility, so
existing configurations will continue to work without change.
A BLACKLIST section has been added to the rules file. This section
is now the first section, having been added ahead of the ALL
section. The set of packets that are subject to blacklisting is
still governed by the setting of BLACKLISTNEWONLY in
shorewall.conf. The settings of BLACKLIST_LOGLEVEL and
BLACKLIST_DISPOSITION are not relevant to the new implementation.
Most of the actions available in other sections of the rules file
are available in the BLACKLIST section and logging is specified on
a rule-by-rule basis in the normal way.
In addition to the other actions available, a WHITELIST action has
been added which exempts matching packets from being passed to the
remaining rules in the section.
Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has
a companion blacklisting chain. The name of the blacklisting chain
is formed by appending "~" to the zone2zone chain. For example,
'net2fw' blacklist rules appear in the chain net2fw~.
There is a likelihood that multiple blacklisting chains will have
exactly the same rules. This is especially true when 'all' is used
as the zone name in the SOURCE and/or DEST columns. When
optimization level 8 is used, these identical chains are combined
into a single chain with the name ~blacklistN, where N is a number
(possibly with multiple digits).
The 'nosurfs' and 'tcpflags' interface options generate rules that
will be traversed prior to those in the BLACKLIST section. If you
want similar rules to be travered on packets that were not dropped
or rejected in the BLACKLIST chain, you can use the new
'DropSmurfs' and/or 'TCPFlags' standard actions.
The DropSmurfs action has a single parameter whose default value
is '-'. The action silently drops smurfs without auditing. If you
want to audit these drops, use DropSmurfs(audit). Logging can be
specified in the normal way (e.g., DropSmurfs:info).
The TCPFlags action has two parameters whose default values are
DROP and -. The first action determines what is to be done with
matching packets and can have the values DROP, REJECT or ACCEPT. If
you want the action to be audited, pass 'audit' in the second
parameter.
Example: TCPFlags(REJECT,audit)
Again, logging is specified in the normal way.
The 'maclist' interface option can also generate rules that are
traversed prior to those in the BLACKLIST section. If you want them
to come after the the blacklist rules, simply recode your maclist
rules in the NEW section of the rules file. The 'macipmap' ipset
type is ideally suited for this task.
Example: assumes the ipset name is macipmap and that the
zone to be verified is named wlan
/etc/shorewall/rules:
SECTION NEW
DROP:info wlan:!+macipmap all
2) '6in4' has been added as a synonum for '6to4' in the TYPE column of
the tunnels file.
3) The handling of IN_BANDWIDTH in both /etc/shorewall/tcdevices and
/etc/shorewall/tcinterfaces has been changed. Previously:
a) Simple rate/burst policing was applied using the value(s)
supplied.
b) IPv4 and IPv6 were policed separately.
Beginning with this release, you have the option of configuring a
rate estimated policing filter. This type of filter is discussed at
http://ace-host.stuart.id.au/russell/files/tc/doc/extimators.txt.
You specify an estimeting filter by preceding the IN-BANDWIDTH with
a tilde ('~').
Example: ~40mbit
This example limits incoming traffic to an *average* rate of 40mbit.
There are two other other parameters that can be specified, in
addition to the average rate - <interval> and
<decay_interval>. There is an excellent description of these
parameters in the document referenced above.
Example: ~40mbit:1sec:8sec
In that example, the <interval> is 1 second and the
<decay_interval> is 8 seconds. If not given, the default values are
250ms and 4 seconds. Both parameters must be supplied if either is
supplied.
Also in this release, the policing of IPv4 and IPv6 has been
combined so a single filter is applied to all traffic on a
configured interface.
4) Shorewall6 now supports the 'balance' and 'fallback' provider
options. These options are restricted to one interface per
configuration for each option.
5) The scripts generated by Shorewall6 now support the 'enable' and
'disable' commands.
6) A 'MARK' column has been added to the route_rules file. See
shorewall-route_rules (5) and shorewall6-route_rules (5) for
details.
----------------------------------------------------------------------------
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) This release includes all problem corrections from releases
4.4.23.1-4.4.23.3.
2) The 'fallback' option without =<weight> previously produced invalid
'ip' commands.
----------------------------------------------------------------------------
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) Stateless NAT is now available in Shorewall6. See
shorewall6-netmap(5) for details. Beta 2 added the ability to use
exclusion in the NET1 column.
2) /sbin/shorewall6 now supports the 'show rawpost' command.
3) This release includes support for 'Condition Match' which is
included in xtables-addons. Condition match allows rules to be
predicated on the setting of a named switch in
/proc/net/nf_condition/.
See
http://www.shorewall.net/configuration_file_basics.htm#Switches
for details.
4) With the preceding change, the rules file now has 14 columns. That
makes it awkward to specify the last column as you have to insert
the correct number of '-' to get the right column.
To make that easier, Shorewall now allows you to specify columns
using several (column-name,value) formats. See
http://www.shorewall.net/configuration_file_basics.htm#Pairs for
details.
5) The generated script will now use the iptables/ip6tables -S command
if available.
6) The implementation of USE_DEFAULT_RT=Yes has been changed
significantly. These changes include:
a) A new BALANCE routing table with number 250 has been added.
b) Routes to providers with the 'balance' option are added to the
BALANCE table rather than the default table.
c) This allows 'fallback' to work with USE_DEFAULT_RT.
d) For optional interfaces, the 'fallback' option without a value
now works the same as if 'fallback=1' had been specified.
This change also corrected several problems with 'fallback' and
enable/disable.
7) Support has been added for TTL manipulation (HL in Shorewall6).
See shorewall-tcrules(5) or shorewall6-tcrules(5) for details.
----------------------------------------------------------------------------
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) This release includes all problem corrections included in Shorewall
4.4.22.1 - 4.4.22.3.
2) Previously, the contents of the NET1 and NET2 columns in
/etc/shorewall/netmap were not validated by the rules compiler. As
a result, invalid entries in those columns could cause the compiled
script to fail while running iptables-restore.
3) The 'hits' command could issue an 'invalid number' diagnostic when
run under busybox ash. That diagnostic has been eliminated.
4) If a zone had multiple interfaces and neither 'routefilter' nor
'routeback' was specified on the interfaces, then traffic between
the interfaces could fail with a log message such as this one:
Sep 4 22:20:41 pilot kernel: [427181.381412]
Shorewall:sfilter1:DROP:IN=eth3 OUT=eth4
MAC=fe:ff:ff:ff:ff:ff:00:16:3e:7f:a0:b9:08:00 SRC=192.168.2.2
DST=192.168.2.3 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP
TYPE=8 CODE=0 ID=10893 SEQ=2
--------------------------------------------------------------------------
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) The leading '#!/bin/sh' line has been deleted from non-executable
shell modules.
2) When 'shorewall update' or 'shorewall6 update' results in no change
to the .conf file, a message is issued, the .bak file is removed
and the command terminates without error.
Note: This change was also included in Shorewall 4.4.22.3.
3) Support has been added for 'stateless NAT'. Stateless NAT is very
simmilar to NATMAP but differs from it in a couple of ways:
a. It does not rely on connection tracking, but is rather
implemented in the Netfilter raw table.
b. Both the source and destination address can be rewritten in all
three raw table chains: PREROUTING, OUTPUT and POSTROUTING.
When used together with stateful NAT, it allows a single router to
handle a duplicate network address situation.
Suppose that a VPN using interface tun0 is used to connect to
another organization, and that both intranets have network
192.168.1.0/24.
To allow the two organizations to communicate, they decide to use
172.20.1.0/24 to address the other's 192.168.1.0/24.
The following four entries are required in /etc/shorewall/netmap:
#TYPE NET1 INTERFACE NET2
SNAT 192.168.1.0/24 tun0 172.20.1.0/24
DNAT 172.20.1.0/24 tun0 192.168.1.0/24
DNAT:T 172.20.1.0/24 tun0 192.168.1.0.24
SNAT:P 192.168.1.0/24 tun0 172.20.1.0/24
Stateless NAT entries differ from NETMAP entries in the TYPE
column. For stateless entries, both the type of address
translation (DNAT or SNAT) and the chain (O for OUTPUT, P for
PREROUTING and T for POSTROUTING) are given.
4) A new section (ALL) has been added to /etc/shorewall/rules and to
/etc/shorwall6/rules. When present, the NEW section must be the
first section in the file and contains rules that are applied to
packets regardless of their connection tracking state.
5) The generated script now detects and removes stale lock files.
6) Jonathan Underwood has contributed Fedora/Redhat init script and
.service files. The .service files are used with systemd which
manages the startup sequence in Fedora 16.
When installing using the install scripts:
a) If /lib/systemd/system exists, the .service files are installed
there and are activated using /sbin/systemctl. When installing
into a directory, setting the SYSTEMD environmental variable to
a non-empty value will also trigger this behavior.
b) If /etc/redhat-release exists, the Fedora/Redhat init script
will be installed in /etc/init.d. When installing into a
directory, setting the FEDORA environmental variable to a
non-empty value will also trigger this behavior.
7) Previously, when a provider interface went 'soft down' (UP and
configured but not usable) or came back up from being 'soft down',
the firewall had to be reloaded ('/var/lib/shorewall/firewall
restart') to disable or enable the interface.
Beginning with this release, the compiled IPv4 script supports two
new commands:
- disable <interface>
- enable <interface>
The 'disable' command removes all policy routing added as a result
of the interface's entry in /etc/shorewall/providers and and any
traffic shaping configuration on the interface. The 'enable'
command restores policy routing and traffic shaping and refreshes the
interfaces's entries in /proc.
8) Shorewall now uses /sys/module/ to determine which modules are
loaded, thus speeding up start/restart
----------------------------------------------------------------------------
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.22.3
1) On older distributions where 'shorewall show capabilities'
indicates 'Connection Tracking Match: Not Available', harmless Perl
diagnostics like the following could be issued:
Use of uninitialized value $list in pattern match (m//)
at /usr/share/shorewall/Shorewall/Config.pm line 1273,
<$currentfile> line 14.
Use of uninitialized value $list in split
at /usr/share/shorewall/Shorewall/Config.pm line 1275,
<$currentfile> line 14.
2) On older distributions where 'shorewall show capabilities'
indicates 'Mangle FORWARD Chain: Not Available', entries in the ecn
file generated the following Perl Diagnostic:
Use of uninitialized value in hash element
at /usr/share/shorewall/Shorewall/Chains.pm line 1119.
3) Previously, if a provider interface was derived from an optional
wildcard entry in /etc/shorewall/providers, then the interface was
never considered to be usable.
Example:
/etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
net ppp+ - optionsl
/etc/shorewall/providers:
#PROVIDER NUMBER MARK INTERFACE ...
ISP1 1 1 ppp0 ...
4.4.22.2
1) On older distributions where 'shorewall show capabilities'
indicates 'Connection Tracking Match: Not Available', Shorewall
4.4.22 and 4.4.22.1 generated invalid iptables-restore input.
2) Previously, the compiler always placed '#!/bin/sh' on the first
line of the generated script. It now uses the setting of
SHOREWALL_SHELL on that line rather than '/bin/sh'. Note that
SHOREWALL_SHELL defaults to '/bin/sh' so this change only affects
those who specify a different shell.
4.4.22.1
1) Previously, if the name of a zone began with 'all', then entries
for that zone in /etc/shorewall/rules and /etc/shorewall6/rules
treated the name the same as 'all'.
This defect is present in Shorewall 4.4.13 through 4.4.22.
2) Previously, when LOAD_HELPERS_ONLY=No, harmless iptables-restore
warnings as follows could be generated:
...
Running /usr/local/sbin/iptables-restore...
--set option deprecated, please use --match-set
--set option deprecated, please use --match-set
IPv4 Forwarding Enabled
...
3) Potential SELinux issues have been corrected. From Orion Poplawski.
4.4.22
1) Under rare conditions, long port lists (>15 ports) could result in
the following failure when optimization level 4 was enabled.
Use of uninitialized value in numeric gt (>)
at /usr/share/shorewall/Shorewall/Chains.pm line 1264.
ERROR: Internal error in
Shorewall::Chains::decrement_reference_count at
/usr/share/shorewall/Shorewall/Chains.pm line 1264
2) All corrections included in Shorewall 4.4.21.1 (see below).
----------------------------------------------------------------------------
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
----------------------------------------------------------------------------
4.4.22.3
1) When 'shorewall update' or 'shorewall6 update' results in no change
to the .conf file, a message is issued, the .bak file is removed
and the command terminates without error.
4.4.22
1) Three new parameterized standard actions are included in this release.
Invalid - Packets in the INVALID connection tracking state
Broadcast - Broadcast and Multicast Packets
NotSyn - TCP packets that have the SYN flag set and all
other flags reset.
The standard default Drop and Reject actions have been modified to
use these new actions.
Each accepts two parameters:
a) Action to perform on matching packets. Must be ACCEPT, DROP or
REJECT. Default is DROP.
b) 'audit' flag. If 'audit', then the action will be audited.
The new actions deprecate the following built-in actions:
allowBcast - use Broadcast(ACCEPT)
allowInvalid - use Invalid(ACCEPT)
dropInvalid - use Invalid(DROP)
dropBroadcast - use Broadcast(DROP)
dropNotSyn - use NotSyn(DROP)
rejNotSyn - use NotSyn(REJECT)
2) Up to this point, the Perl-based compiler has stored rules
internally in iptables/ip6tables command strings. This has
made the optimizing the ruleset difficult and has made the
optimizer the most defect-dense part of the code.
This release marks to first step toward converting the compiler to
use an internal rule representation that is easier to optimize and
that is easy to convert to iptables/ip6tables commands effeciently.
The parser still generates iptables/ip6table rules which are then
converted into the internal form.
3) Optimize level 8 causes chains that are identical to another chain
to be deleted, and their references are replace by references to
the other chain. This can lead to confusion when looking at the
generated ruleset. For example, traffic going from the 'loc' zone
to the 'dmz' zone may now be passing through a chain named
'wan2dmz'!
To eliminate this confusion, the compiler now generates a
synthetic name for the combined chains, consisting of "~comb"
followed by an integer (e.g., "~comb1", "~comb2", etc.).
----------------------------------------------------------------------------
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) All problems corrections included in Shorewall 4.4.20.1 - 4.4.20.3
(see below).
2) The following error message
FOREWARD_CLEAR_MARK=Yes requires MARK Target in your kernel
and iptables
has been corrected to read
FORWARD_CLEAR_MARK=Yes requires MARK Target in your kernel
and iptables
3) The TPROXY target in the tcrules file could previously cause a
failure during iptables restore like this:
Running /usr/sbin/iptables-restore...
Bad argument `3128'
Error occurred at line: 110
Try `iptables-restore -h' or 'iptables-restore --help' for more
information.
ERROR: iptables-restore Failed. Input is in
/var/lib/shorewall/.iptables-restore-input
4) The 'balance' and 'fallback' options in /etc/shorewall/providers
have always been mutually exclusive but the compiler previously
didn't enforce that restriction. Now it does.
5) The Shorewall and Shorewall6 'load' and 'reload' commands
previously used the setting of RSH_COMMAND and RCP_COMMAND from
/etc/shorewall/shorewall.conf (/etc/shorewall6/shorewall6.conf).
These commands now use the .conf file in the current working
directory.
6) The ipset modules are now automatically loaded by Shorewall6 when
LOAD_HELPERS_ONLY=No is specified in shorewall6.conf. Additionally,
there is now a /usr/share/shorewall6/modules.ipset file that lists
all of the required modules.
7) TPROXY was previously not described in shorewall-tcrules(5) or
shorewall6-tcrules(5). These descriptions have been added.
In addition, Shorewall6 now correctly handles the third TPROXY
parameter (<ip address>). Previously, the following error was
generated:
ERROR: Invalid MARK (TPROXY(10,3128,::1)) :
/etc/shorewall6/tcrules (line 4)
----------------------------------------------------------------------------
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) AUTOMAKE=Yes now causes all directories on the CONFIG_PATH to be
searched for files newer than the script that last
started/restarted the firewall. Previously, only /etc/shorewall
(/etc/shorewall6) was searched.
2) FORMAT-2 actions may now specify default parameter values using the
DEFAULTS directive.
DEFAULTS <def1>,<def2>,...
Where <def1> is the default value for the first parameter, <def2>
is the default value for the second parameter and so on. To specify
an empty default, use '-'. Note that the corresponding parameter
variable ($n) will still expand to '-' but will be treated as empty
by the builtin actions such as dropInvalid.
The DEFAULTS directive also determines the maximum number of
parameters that an action may have. If more parameters are passed
than have default values, an error message is issued.
3) Parameterized macros may now specify a default parameter value
using the DEFAULT directive.
DEFAULT <default>
Example macro.Foo -- by default, accepts connections on ficticous
tcp port 'foo'.
DEFAULT ACCEPT
PARAM - - tcp foo
4) The standard Drop and Reject actions are now parameterized. Each
has 5 parameters:
1) Pass 'audit' if you want all ACCEPTs, DROPs and REJECTs audited.
Pass '-' otherwise.
2) The action to be applied to Auth requests:
FIRST PARAMETER DEFAULT
- REJECT
audit A_REJECT
3) The action to be applied to SMB traffic. The default depends on
the action and its first parameter:
ACTION FIRST PARAMETER DEFAULT
Reject - REJECT
Drop - DROP
Reject audit A_REJECT
Drop audit A_DROP
4) The action to be applied to accepted ICMP packets.
FIRST PARAMETER DEFAULT
- ACCEPT
audit A_ACCEPT
5) The action to be applied to UPnP (udp port 1900) and late DNS
replies (udp source port 53)
FIRST PARAMETER DEFAULT
- DROP
audit A_DROP
The parameters can be passed in the POLICY column of the policy
file.
Examples:
SOURCE DEST POLICY
net all DROP:Drop(audit):audit #Same as
#DROP:A_DROP:audit
SOURCE DEST POLICY
net all DROP:Drop(-,DROP) #DROP rather than REJECT Auth
The parameters can also be specified in shorewall.conf:
Example:
DROP_DEFAULT=Drop(-,DROP)
5) An 'update' command has been added to /sbin/shorewall and
/sbin/shorewall6. The command updates the shorewall.conf
(shorewall6.conf) file then validates the configuration. The
updated file will set any options not specified in the old file
with their default values, and will move any deprecated options
with non-default values to a 'deprecated options' section at the
end of the file. Each such deprecated option will generate a
warning message.
Your original shorewall.conf (shorewall6.conf) file will be saved as
shorewall.conf.bak (shorewall6.conf.bak).
The 'update' command accepts the same options as the 'check'
command plus a '-a' option that causes the updated file to be
annotated with manpage documentation.
6) Shorewall6 now supports ipsets.
Unlike iptables, which has separate configurations for IPv4 and
IPv6, ipset has a single configuration that handles both. This
means the SAVE_IPSETS=Yes in shorewall.conf or shorewall6.conf
won't work correctly. To work around this issue, Shorewall-init is
now capable restoring ipset contents during 'start' and saving them
during 'stop'.
To direct Shorewall-init to save/restore ipset contents, set the
SAVE_IPSETS option in /etc/sysconfig/shorewall-init
(/etc/default/shorewall-init on Debian and derivatives). The value
of the option is a file name where the contents of the ipsets will
be saved to and restored from. Shorewall-init will create any
parent directories during the first 'save' operation.
If you configure Shorewall-init to save/restore ipsets, be sure to
set SAVE_IPSETS=No in shorewall.conf and shorewall6.conf.
As part of this change, Shorewall and Shorewall6 will only restore
saved ipsets if SAVE_IPSETS=Yes in shorewall.conf
(shorewall6.conf).
7) Shorewall6 now supports dynamic zones:
1) The nets=dynamic option is allowed in /etc/shorewall6/interfaces
2) The HOSTS column of /etc/shorewall6/hosts may now contain
<interface>:dynamic.
3) /sbin/shorewall6 now supports the 'add' and 'delete' commands.
----------------------------------------------------------------------------
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) Previously, when a device number was explicitly specified in
/etc/shorewall/tcdevices, all unused numbers less than the one
specified were unavailable for allocation to following entries that
did not specify a number. Now, the compiler selects the lowest
unallocated number when no device number is explicitly allocated.
2) The obsolete PKTTYPE option has been removed from shorewall.conf
and the associated manpage.
3) The iptables 1.4.11 release produces an error when negative numbers
are specified for IPMARK mask values. Shorewall now converts such
numbers to their 32-bit hex equivalent.
4) Previously, before /etc/shorewall6/params was processed, the
IPv4 Shorewall libraries (/usr/share/shorewall/lib.*) were
loaded rather that the IPv6 versions (/usr/share/shorewall6/lib.*).
Now, the correct libraries are loaded.
5) Shorewall now sets /proc/sys/net/bridge/bridge_nf_call_iptables or
/proc/sys/net/bridge/bridge_nf_call_ip6tables when there are
interfaces with the 'bridge' option. This insures that netfilter
rules are invoked for bridged traffic. Previously, Shorewall was
not setting these flags with the possible result that a
bridge/firewall would not work properly.
6) Problem corrections released in 4.4.19.1-4.4.19.4 (see below)
are also included in this release.
----------------------------------------------------------------------------
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) The implementation of the environmental variables LIBEXEC and
PERLLIB that was introduced in 4.4.19 has been changed
slightly. The installers now allow absolute path names to be
supplied in these variables so that the executables and/or Perl
modules may be installed under a top-level directory other than
/usr. The change is compatible with 4.4.19 in that if a relative
path name is supplied, then '/usr/' is prepended to the supplied
name.
2) A new ACCOUNTING_TABLE option has been added to shorewall.conf and
shorewall6.conf. The setting determines the Netfilter table (filter
or mangle) where accounting rules are created.
When ACCOUNTING_TABLE=mangle, the allowable accounting file
sections are:
PREROUTING
INPUT
OUTPUT
FORWARD
POSTROUTING
Present sections must appear in that order.
3) An NFLOG 'ACTION' has been added to the accounting file to allow
sending matching packets (or the leading part of them) to backend
accounting daemons via a netlink socket.
4) A 'whitelist' option has been added to the blacklist file. When
'whitelist' is specified, packets/connections matching the entry
are not matched against the entries which follow. No logging of
whitelisted packets/connections is performed.
5) Support for the AUDIT target has been added. AUDIT is a feature of
the 2.6.39 kernel and iptables 1.4.10 that allows security auditing
of access decisions.
The support involves the following:
a) A new "AUDIT Target" capability is added and is required for
auditing support. To use AUDIT support with a capabilities
file, that file must be generated using this or a later
release.
Use 'shorewall show capabilities' after installing this release
to see if your kernel and iptables support the AUDIT target.
b) In /etc/shorewall/policy's POLICY column, the policy (and
default action, if any) may be followed by ':audit' to cause
applications of the policy to be audited. This means that any
NEW connection that does not match any rule in the rules file
or in the applicable 'default action' will be audited.
Only ACCEPT, DROP and REJECT policies may be audited.
Example:
#SOURCE DEST POLICY LOG
# LEVEL
net fw DROP:audit
It is allowed to also specify a log level on audited policies
resulting in both auditing and logging.
c) Three new builtin actions that may be used in the rules file,
in macros and in other actions.
A_ACCEPT - Audits and accepts the connection request
A_DROP - Audits and drops the connection request
A_REJECT - Audits and rejects
A log level may be supplied with these actions to
provide both auditing and logging.
Example:
A_ACCEPT:info loc net ...
d) The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION and
TCP_FLAGS_DISPOSITION options may be set as follows:
BLACKLIST_DISPOSITION A_DROP or A_REJECT
MACLIST_DISPOSITION A_DROP
A_REJECT, unless
MACLIST_TABLE=mangle
TCP_FLAGS_DISPOSITION A_DROP or A_REJECT
e) A SMURF_DISPOSITION option has been added to
shorewall.conf. The default value is DROP; if the option is set
to A_DROP, then dropped smurfs are audited.
f) An 'audit' option has been added to the
/etc/shorewall/blacklist file which causes the packets matching
the entry to be audited. 'audit' may not be specified together
with 'whitelist'.
g) The builtin actions (dropBroadcast, rejNonSyn, etc.) now support
an 'audit' parameter which causes all ACCEPT, DROP and REJECTs
performed by the action to be audited.
Note: The builtin actions are those actions listed in the
output of 'shorewall show actions' with names that begin with a
lower-case letter.
Example:
#ACTION SOURCE DEST
rejNonSyn(audit) net all
h) There are audited versions of the standard Default Actions
named A_Drop and A_Reject. Note that these audit everything
that they do so you will probably want to make your own copies
and modify them to only audit the packets that you care about.
6) Up to this release, the behaviors of 'start -f' and 'restart -f'
has been inconsistent. The 'start -f' command compares the
modification times of /etc/shorewall[6] with
/var/lib/shorewall[6]/restore while 'restart -f' compares with
/var/lib/shorewall[6]/firewall.
To make the two consistent, a new LEGACY_FASTSTART option has been
added. The default value when the option isn't specified is
LEGACY_FASTSTART=Yes which preserves the old behavior. When
LEGACY_FASTSTART=No, 'start -f' and 'restart -f' both compare with
/var/lib/shorewall[6]/firewall.
7) A '-c' (compile) option has been added to the 'start' and 'restart'
commands in both Shorewall and Shorewall6. It overrides the setting
of AUTOMAKE and unconditionally forces a recompilation of the
configuration.
When both -c and -f are specified, the result is determined by the
option that appears last.
8) Shorewall and Shorewall6 no longer depend on 'make'.
9) A '-T' (trace) option has been added to the 'check' and 'compile'
commands. When a warning or error message is generated, a Perl
stack trace is included to aid in isolating the source of the
message.
10) The Shorewall and Shorewall6 configuration files (including the
samples) may now be annotated with documentation from the associated
manpage.
The installers for these two packages support a -a (annotated)
option that installs annotated versions of the packages. Both
versions are available in the configfiles directory within the
tarball and in the Sample directories.
11) The STATE subcolumn of the secmarks file now allows the values 'I'
which will match packets in the INVALID state, and 'NI'
which will match packets in either NEW or INVALID state.
12) Certain attacks can be best defended through use of one of these
two measures.
a) rt_filter (Shorewall's routefilter). Only applicable to IPv4
and can't be used with some multi-ISP configurations.
b) Insert a DROP rule that prevents hairpinning (routeback). The
rule must be inserted before any ESTABLISHED,RELATED firewall
rules. This approach is not appropriate for bridges and other
cases, where the 'routeback' option is specified or implied.
For non-routeback interfaces, Shorewall and Shorewall6 will now
insert a hairpin rule, provided that the routefilter option is not
specified. The rule will dispose of hairpins according to the
setting of two new options in shorewall.conf and shorewall6.conf:
SFILTER_LOG_LEVEL
Specifies the logging level; default is 'info'. To omit
logging, specify FILTER_LOG_LEVEL=none.
SFILTER_DISPOSITION
Specifies the disposition. Default is DROP and the possible
values are DROP, A_DROP, REJECT and A_REJECT.
To deal with bridges and other routeback interfaces , there is now
an 'sfilter' option in /shorewall/interfaces and
/etc/shorewall6/interfaces.
The value of the 'sfilter' option is a list of network addresses
enclosed in in parentheses. Where only a single address is listed,
the parentheses may be omitted. When a packet from a
source-filtered address is received on the interface, it is
disposed of based on the new SFILTER_ options described above.
For a bridge or other routeback interface, you should list all of
your other local networks (those networks not attached to the
bridge) in the bridge's sfilter list.
Example:
My DMZ is 2001:470:b:227::40/124
My local interface (br1) is a bridge.
In /etc/shorewall6/interfaces, I have:
#ZONE INTERFACE BROADCAST OPTIONS
loc br1 - sfilter=2001:470:b:227::40/124
----------------------------------------------------------------------------
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) Corrected a problem in optimize level 4 that resulted in the
following compile-time failure.
Can't use an undefined value as an ARRAY reference at
/usr/share/shorewall/Shorewall/Chains.pm line 862.
2) If a DNAT or REDIRECT rule applied to a source zone with an
interface defined with 'physical=+', then the nat table 'dnat'
chain might have been created but not referenced. This prevented
the DNAT or REDIRECT rule from working correctly.
3) Previously, if a variable set in /etc/shorewall/params was given a
value containing shell metacharacters, then the compiled script
would contain syntax errors.
4) The pathname of the 'conntrack' binary was erroneously printed in
the output of 'shorewall6 show connections'.
5) Correct a problem whereby incorrect Netfilter rules were generated
when a bridge with ports was given a logical name.
6) If a bridge interface had subordinate ports defined in
/etc/shorewall/interface, then an ipsec entry (either ipsec zone or
the 'ipsec' option specified) in /etc/shorewall/hosts resulted in
the compiler generating an incorrect Netfilter configuration.
7) Previously /var/log/shorewall*-init.log was created in the wrong
Selinux context. The rpm's have been modified to correct that
issue.
8) An issue with params processing on RHEL6 has been corrected. The
problem manifested as the following type of warning:
WARNING: Param line (export OLDPWD) ignored at
/usr/share/shorewall/Shorewall/Config.pm line 2993.
9) A fatal error is now raised if '!0' appears in the PROTO column of
files that have that column. This avoids an iptables-restore
failure at run time.
----------------------------------------------------------------------------
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) When TC_ENABLED=Simple, ACK packets are now placed in the highest
priority class. An ACK packet is a TCP packet with the ACK flag set
and no data payload.
Rationale: Entries in /etc/shorewall[6]/tcpri affect both incoming
and outgoing connections. If a particular application, SMTP for
example, is placed in priority class 3, then outgoing ACK packets
for incoming email were previously placed in priority class 3 as
well. This could have the effect of slowing down incoming mail when
the goal was to give outgoing mail a lower priority. By
unconditionally placing ACK packets in priority class 1, this issue
is avoided.
2) Up to this point, the Perl-based rules compiler has not accepted
ICMP type lists. This is in contrast to the shell-based compiler
which did support such lists.
Support for ICMP (and ICMPv6) type lists has now been restored.
3) Distributions have different philosophies about the proper file
hierarchy. Two issures are particularly contentious:
- Executable files in /usr/share/shorewall*. These include;
getparams
compiler.pl
wait4ifup
shorecap
ifupdown
- Perl Modules in /usr/share/shorewall/Shorewall.
To allow distributions to designate alternate locations for these
files, the installers (install.sh) now support the following
environmental variables:
LIBEXEC -- determines where in /usr getparams, compiler.pl,
wait4ifup, shorecap and ifupdown are installed. Shorewall and
Shorewall6 must be installed with the same value of LIBEXEC. The
listed executables are installed in /usr/${LIBEXEC}/shorewall*. The
default value of LIBEXEC is 'share'. LIBEXEC is recognized by all
installers and uninstallers.
PERLLIB -- determines where in /usr the Shorewall perl modules are
installed. Shorewall and Shorewall6 must be installed with the same
value of PERLLIB. The modules are installed in
/usr/${PERLLIB}/Shorewall. The default value of PERLLIB is
'share/shorewall'. PERLLIB is only recognized by the Shorewall and
Shorewall6 installers and the same value must be passed to both
installers.
4) Bridge/ports handling has been significantly improved, resulting in
packets to/from bridges traversing fewer rules.
5) A list of protocols is now permitted in the PROTO column of the
rules file.
6) The contents of the Netfilter mangle table are now included in the
output from 'shorewall show tc'.
7) Simple traffic shaping can now have a common configuration between
IPv4 and IPv6. To do that:
- Set TC_ENABLED=Simple in both /etc/shorewall/shorewall.conf and
/etc/shorewall6/shorewall6.conf
- Configure /etc/shorewall/tcinterfaces.
- Leave /etc/shorewall6/tcinterfaces empty.
- Configure /etc/shorewall/tcpri (if desired)
- Configure /etc/shorewall6/tcpri (if desired)
It should be noted that when IPv6 packets are encapsulated for
transmission by 6to4/6in4, they retain their marks.
----------------------------------------------------------------------------
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.18 Final
1) Previously, if an IPv6 host address (no "/<vlsm>") was used in a
context where a network address is allowed, the compiler failed to
supply the default <vlsm> of 128. This could lead to startup errors
and/or Perl errors such as:
Use of uninitialized value $mask in concatenation (.) or
string at /usr/share/shorewall/Shorewall/Tc.pm line 979,
<$currentfile> line 11.
2) The <burst> option for the IN-BANDWIDTH column of tcdevices was
previously not recognized. That functionality has been restored.
3) If an interface mentioned in the tcfilters file was not up when
Shorewall was started or restarted, then the command would fail
at run-time with a 'tc' error message.
4.4.18 RC 1
1) None.
4.4.18 Beta 4
1) Edting of the MARK column has been tighened to catch errors at
compile time rather than at run time.
2) The MODULE_SUFFIX default has been changed to "ko ko.gz o o.gz gz"
to get the most common suffixes at the front of the list. It is
still recommended that you modify this setting to include only the
suffix(es) used on your system. Current distributions use 'ko'
almost exclusively.
4.4.18 Beta 2
1) Previously, the 'local' option in /etc/shorewall6/providers would
produce an 'ip route add' command containing an IPv4 address. It now
correctly uses the equivalent IPv6 address. Note that this option
is still undocumented for use with IPv6.
2) When optimize level 4 was set, the optimizer mis-handled rules of the
form:
-A <chain1> -j <chain2> -m comment ...
when such a rule was the only rule in a chain.
4.4.18 Beta 1
None.
----------------------------------------------------------------------------
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) The modules files are now just a driver that INCLUDEs several new
files and one old file:
- /usr/share/shorewall[6]/modules.essential # Essential modules
- /usr/share/shorewall[6]/modules.xtables # xt_ modules
- /usr/share/shorewall[6]/helpers # Existing file
- /usr/share/shorewall/ipset # ipset modules
- /usr/share/shorewall[6]/modules.tc # Traffic Shaping
- /usr/share/shorewall[6]/modules.extensions # Other extensions
This should make it easier to configure your own
/etc/shorewall[6]/modules file that won't be obsolete when you
upgrade your Shorewall/Shorewall6 installation.
For example, if you don't use traffic shaping or ipsets, you can
remove those from your copy of the modules file (copy in
/etc/shorewall/).
2) Traditionally, the root of the Shorewall accounting rules has been
the 'accounting' chain. Having a single root chain has drawbacks:
- Many rules are traversed needlessly (they could not possibly
match traffic).
- At any time, the Netfilter team could begin generating errors
when loading those same rules.
- MAC addresses may not be used in the accounting rules.
- The 'accounting' chain cannot be optimized when
OPTIMIZE_ACCOUNTING=Yes.
In addition, currently the rules may be defined in any order so the
rules compiler must post-process the ruleset to alert the user to
unreferenced chains.
Beginning with Shorewall 4.4.18, the accounting structure can be
created with three root chains:
- accountin: Rules that are valid in the INPUT chain (may not
specify an output interface).
- accountout: Rules that are valid in the OUTPUT chain (may not
specify an input interface or a MAC address).
- accountfwd: Other rules.
The new structure is enabled by sectioning the accounting file in a
manner similar to the rules file.
The sections are INPUT, OUTPUT and FORWARD and must appear in that
order (although any of them may be omitted). The first
non-commentary record in the accounting file must be a section
header when sectioning is used.
When sections are enabled:
- You must jump to a user-defined accounting chain before you can
add rules to that chain. This eliminates the possibility of
unreferenced chains.
- You may not specify an output interface in the INPUT section.
- In the OUTPUT section:
- You may not specify an input interface
- You may not jump to a chain defined in the INPUT section that
specifies an input interface
- You may not specify a MAC address
- You may not jump to a chain defined in the INPUT section that
specifies specifies a MAC address.
- The default value of the CHAIN column is:
- 'accountin' in the INPUT section
- 'accountout' in the OUTPUT section
- 'accountfwd' in the FORWARD section
- Traffic addressed to the firewall goes through the rules defined
in the INPUT section.
- Traffic originating on the firewall goes through the rules
defined in the OUTPUT section.
- Traffic being forwarded through the firewall goes through the
rules defined in the FORWARD section.
As part of this change, the USER/GROUP column must now be empty
except in the OUTPUT section. This is consistent with recent
Netfilter releases which disallow the owner match in rules
reachable from the INPUT and FORWARD hooks.
3) Internals Change: The Policy.pm module has been merged into the
Rules.pm module
----------------------------------------------------------------------------
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) Previously, Shorewall did not check the length of the names of
accounting chains and manual chains. This could result in
errors when loading the resulting ruleset. Now, the compiler issues
an error for chain names longer than 29 characters.
Additionally, the compiler now ensures that these chain names are
composed only of letters, digits, underscores ('_') and dashes
("-"). This eliminates Perl runtime errors or other failures when a
chain name is embedded within a regular expression.
2) Several issues with complex traffic shaping have been resolved:
a) Specifying IPv6 network addresses in the SOURCE or DEST columns
of /etc/shorewall6/tcfilters now works correctly. Previously,
Perl runtime warnings occurred and an invalid tc command was
generated.
b) Previously, if flow= was specified on a parent class, a perl
runtime warning occurred and an invalid tc command was
generated. This combination is now flagged as an error at
compile time.
c) There is now an ipv6 tcfilters skeleton included with
Shorewall6.
3) Several issues with accounting are corrected.
a) If an accounting rule of the form:
chain1 chain2
was configured and neither chain was referenced again in the
configuration, then an internal error was generated when
optimize level 4 was selected and OPTIMIZE_ACCOUNTING=Yes.
b) If there was only a single accounting rule and that rule
specified an interface in the SOURCE or DEST columns, then the
generated ruleset would fail to load when
OPTIMIZE_ACCOUNTING=Yes.
c) If a per-IP accounting table name appeared in more than one
rule and the specified network was not the same in all
occurrences, then the generated ruleset would fail to load.
This is now flagged as an error at compile time.
4) Two defects in compiler module loading have been corrected:
a) Previously, the kernel/net/ipv6/netfilter/ directory was not
searched.
b) A Perl diagnostic was issued when running on a monolithic kernel
when the modutils package was installed.
5) A line containing only 'INCLUDE' appearing in an extension script
now generates a compile-time diagnostic rather than a run-time
diagnostic.
6) Previously, the uninstall.sh scripts used insserv (if installed) on
Debian-based systems. These scripts now use the preferred tool
(updaterc.d).
7) Beginning with 4.4.16, compilation would fail if an empty shell
variable was referenced in a config file on a system where /bin/sh
is the Bourne Again Shell (bash).
8) In earlier versions. if OPTIMIZE=8 then the ruleset displayed by
'check -r' was the same as when OPTIMIZE=0
(unoptimized). Similarly, if OPTIMIZE=9 then the ruleset displayed
was the same as when OPTIMIZE=1.
9) Startup could previously fail on a system where kernel module
autoloading was not available and where TC_ENABLED=Simple was
specified in shorewall.conf or shorewall6.conf.
10) Previously, a 'done.' message could be printed at the end of
command processing even when the command had failed. Now, such a
message only appears if the command completed successfully.
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------
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) This release adds support for per-IP accounting using the ACCOUNT
target. That target is only available when xtables-addons is
installed. This support has been successfully tested with
xtables-addons 1.32 on:
- Fedora 14
- Debian Squeeze
- OpenSuSE 11.3
It has also been tested with xtables-addons 1.21 on:
- Debian Lenny
Information about xtables-addons installation may be found at
http://www.shorewall.net/Dynamic.html#xtables-addons
This feature required addition of the "ACCOUNT Target" capability
so if you use a capabilities file, you will want to refresh it
after installing this release.
Per-IP accounting is configured in /etc/shorewall/accounting (it is
not currently supported in IPv6). In the ACTION column, enter:
ACCOUNT(<table>,<network>)
where:
<table> is the name of an accounting table (you choose the
name). Rules specifying the same table will have their
per-IP counters accumulated in that table.
<network> is an IPv4 in CIDR format. May be as large as a /8.
Example: Suppose your WAN interface is eth0 and your LAN interface
is eth1 with network 172.20.1.0/24. To account for all
traffic between the WAN and LAN interfaces:
#ACTION TABLE SOURCE DEST ...
ACCOUNT(net-loc,172.20.1.0/24) - eth0 eth1
ACCOUNT(net-loc,172.20.1.0/24) - eth0 eth1
This will create a net-loc table for counting packets and
bytes for traffic between the two interfaces. The table is dumped
using the iptaccount utility:
iptaccount [-f] -l net-loc
Example (output folded):
gateway:~# iptaccount -l loc-net
libxt_ACCOUNT_cl userspace accounting tool v1.3
Showing table: loc-net
Run #0 - 3 items found
IP: 172.20.1.105 SRC packets: 115 bytes: 131107
DST packets: 68 bytes: 20045
IP: 172.20.1.131 SRC packets: 47 bytes: 12729
DST packets: 38 bytes: 25304
IP: 172.20.1.145 SRC packets: 20747 bytes: 2779676
DST packets: 27050 bytes: 32286071
Finished.
gateway:~#
For each local IP address with non-zero counters, the packet and
byte count for both incoming traffic (IP is DST) and outgoing
traffic (IP is SRC) are listed. The -f option causes the table to
be flushed (reset all counters to zero).
For a command synopsis, type:
iptaccount --help
One nice feature of per-IP accounting is that the counters survive
'shorewall restart'. This has a downside, however. If you change
the <network> associated with an accounting table, then you must
"shorewall stop; shorewall start" to have a successful restart
(counters will be cleared).
2) A 'show ipa' command has been added to /sbin/shorewall. It
displays each per-IP accounting table.
3) Traditionally, the -lite products have used the modules (or
helpers) file on the firewall system unless there is a modules (or
helpers) file in the configuration directory on the administrative
system. This release introduces the USE_LOCAL_MODULES option in
shorewall[6].conf.
When USE_LOCAL_MODULES=Yes, the modules (helpers) file on the
administrative system will be used to determine the set of modules
loaded. This also implies that the modules (helpers) file will be
read at compile time rather than at run-time when using Shorewall
and Shorewall6 directly on a firewall system.
As part of this change, the modules and helpers files are now
secured for read access by non-root users.
4) Given that shell variables are expanded at compile time, there was
previously no way to cause such variables to be expanded at run
time. This made it difficult (to impossible) to include dynamic IP
addresses in a Shorewall-lite configuration.
This release implements "Run-time address variables". In
configuration files, these variables are expressed using an
apersand ('&') followed by the name of an interface defined in
/etc/shorewall/interfaces. Wild-card interfaces (those whose names
end in '+') are not allowed to be used in this way.
Example:
ð0 would represent the primary IP address of eth0.
Run-time address variables may be used in the SOURCE and DEST
column of the following configuration files:
accounting
action files
blacklist
macro files
rules
tcrules
tos
They may also appear in the ORIGINAL DEST column of
action files
macro files
rules
They may also be used in the SOURCE and ADDRESS columns of the masq
file.
For optional interfaces, if the interface is not usable at the time
that the firewall starts, the resulting Netfilter rule(s)
containing the interface address are not added.
5) The shell variables set in /etc/shorewall/params
(/etc/shorewall6/params) are now available in the compiled script
at run-time with EXPORTPARAMS=No. The EXPORTPARAMS option is now
deprecated and the released /etc/shorewall/shorewall.conf and
/etc/shorewall/shorewall6.conf have been modified to specify
EXPORTPARAMS=No.
6) The INCLUDE directive may now be used in the following extension
scripts:
clear
findgw
init
isusable
refresh
refreshed
restored
start
started
stop
stopped
tcclear
The directive is executed during compilation so that the INCLUDEd
file(s) is(are) copied into the generated script. This same
technique is also now used for INCLUDE directives in the params
file when EXPORTPARAMS=Yes. Previously, INCLUDE directives in that
file were strongly discouraged with EXPORTPARAMS=Yes because the
INCLUDE was performed on the firewall system rather than on the
administrative system.
---------------------------------------------------------------------------
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) If the output of 'env' contained a multi-line value, then
compilation failed with an Internal Error. The code has been
changed so that the compiler now handles multi-line values
correctly.
2) In 4.4.15, output to Standard Out (FD 1) generated by
/etc/shorewall/params (/etc/shorewall6/params) was redirected to
/dev/null. It is now redirected to Standard Error (FD 2).
3) If a params file did not appear in the CONFIG_PATH, compilation
failed with the error:
.: 31: Can't open /etc/shorewall6/params
ERROR: Processing of /etc/shorewall6/params failed
4) Compilation no longer fails when /bin/sh is an older (e.g.,
RHEL5.x) bash.
5) Previously, proxy ARP with logical interface names did not
work. Symptoms included numerous Perl runtime error messages.
6) Previously, the root of a wildcard name erroneously matched that
name. For example 'eth' matched 'eth+'. Now there must be at least
one additional character (e.g., 'eth4').
7) Use of logical interface names in the notrack and ecn files
resulted in perl runtime warning messages.
8) The use of wildcard-matching names in certain contexts would result
in anomalous behavior. Among the symptoms were:
- Perl run-time messages similar to this one:
Use of uninitialized value in numeric comparison (<=>)
at /usr/share/shorewall/Shorewall/Zones.pm line 1334.
- Failure to treat the interface as optional or required.
9) Where two ISPs share the same interface, if one of the ISPs was not
reachable, an iptables-restore error such as this occurred:
iptables-restore v1.4.10: Bad mac address "-j"
10) Previously, under very rare circumstances, a chain would be
optimized away while there were still jumps to the chain. This caused
Shorewall start/restart to fail during iptables-restore.
11) Previously, the setting of BLACKLIST_DISPOSITION was not
validated. Now, an error is raised unless the value is DROP or REJECT.
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------
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) Shorewall-init now handles ppp devices.
2) To support proxy NDP in a manner similar to Proxy ARP, an
/etc/shorewall6/proxyndp file has been added. It should be noted
that IPv6 implements a "strong host model" whereas Linux IPv4
implements a "weak host model". In the strong model, IP addresses
are associated with interfaces; in the weak model, they are
associated with the host. This is relevant with respect to Proxy
NDP in that a multi-homed Linux IPv6 host will only respond to
neighbor discoverey requests for IPv6 addresses configured on the
interface receiving the request. So if eth0 has address
2001:470:b:227::44/128 and eth1 has address 2001:470:b:227::1/64
then in order for eth1 to respond to neighbor discovery requests
for 2001:470:b:227::44, the following entry in
/etc/shorewall6/proxyndp is required:
#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
2001:470:b:227::44 - eth1 Yes
As part of this change, the INTERFACE column in
/etc/shorewall/proxyarp is now optional and is only required when
HAVEROUTE=No (the default).
3) Shorewall 4.4.16 introduces format-2 Actions. Based on the similar
feature of macros, format-2 actions allow the same column layout
for macros, actions and rules.
In the action.xxx file, simply make the first non-commentary line:
FORMAT 2
This allows the lines which follow to have the same columns as
those in the rules file.
As part of this change, the earlier kludgy restrictions regarding
Macros and Actions have been eliminated. For example, DNAT, DNAT-,
REDIRECT, REDIRECT- and ACCEPT+ rules are now allowed in Actions
and in macros invoked from Actions. Additionally, Macros used in
Actions are now free to invoke other actions.
4) Action processing has been largely re-implemented in this release.
The prior implementation contained a lot of duplicated code which
made maintainance difficult. The old implementation pre-processed
all action files early in the compilation process and then
post-processed the ones that had been actionally used after the
rules file had been read. The new algorithm generates the chain for
each unique action invocation at the time that the invocation is
encountered in the rules file.
Consideration was given to eliminating the
/usr/share/shorewall/actions.std and /etc/shorewall/actions files,
since it is possible to discover actions "on the fly" in the same
way as macros are discovered. That change was ultimately rejected
because it could cause migration issues for users with macros and
actions with the same name (e.g., action.xxx and macro.xxx). If a
new major release of Shorewall (e.g., 4.6) is created, that change
will be reconsidered for inclusion at that time.
Action names are now verified to be composed of alphanumeric
characters, '_' and '-'.
There is now support for parameterized actions. The parameters are
a comma-separated list enclosed in parentheses following the
action name (e.g., ACT(REDIRECT,192.168.1.4)). Within the action
body, the parameter values are available in $1, $2, etc.
You can 'omit' a parameter in the list by using '-' (e,g,
REDIRECT,-.info) would omit the second parameter (within the action
body, $2 would expand to nothing). If you want to specify '-' as a
parameter value, use '--'.
Parameter values are also available to extensions scripts. See
http://www.shorewall.net/Actions.html#Extension for more
information.
----------------------------------------------------------------------------
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) Previously, if
a) syn flood protection was enabled in a policy that
specified 'all' for the SOURCE or DEST, and
b) there was only one pair of zones matching that policy, and
c) PROPAGATE_POLICIES=Yes in shorewall.conf, and
d) logging was specified on the policy
then the chain implementing the chain had "all" in its name while
the logging rule did not.
Example
On a simple standalone configuration, /etc/shorewall/policy
has:
#SOURCE DEST POLICY LOGGING
net all DROP info
then the chain implementing syn flood protection would be named
@net2all while the logging rule would indicate net2fw.
Now, the chain will be named @net2fw.
2) If the current environment exported the VERBOSE variable with a
non-zero value, then startup would fail.
3) If a route existed for an entire RFC1918 subnet (10.0.0.0/8,
172.20.0.0/12 or 192.168.0.0/16), then setting
NULL_ROUTE_RFC1918=Yes would cause the route to be replaced with an
'unreachable' one.
4) Shorewall6 failed to start correctly if all the following were true:
- Shorewall was installed using the tarball. It may have
subsequently been installed using a distribution-specific package
or the rpm from shorewall.net without first unstalling the
tarball components.
- Shorewall6 was installed using a distribution-specific package or
the rpm from shorewall.net.
- The file /etc/shorewall6/init was not created.
5) If an interface with physical='+' is given the 'optional' or
'required' option, then invalid shell variables names were
generated by the compiler.
6) The contributed macro macro.JAP generated a fatal error when used.
The root cause was a defect in parameter processing in nested
macros (if 'PARAM' was passed to an nested macro invocation, it was
not expanded to the current parameter value).
7) Previously, if find_first_interface_address() failed when running
shorewall-lite or shoreawll6-lite, the following unhelpful message
was issued:
/usr/share/shorewall-lite/lib.common: line 449: startup_error: command
not found
----------------------------------------------------------------------------
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) Munin and Squid macros have been contributed by Tuomo Soini.
2) The Shorewall6 accounting, tcrules and rules files now include a
HEADERS column which allows matching based on the IPv6 extension and
protocol headers included in a packet.
The contents of the column are:
[any:|exactly:]<header list>
where <header list> is a comma-separated list of headers from the
following:
Long Name Short Name Number
--------------------------------------
auth ah 51
esp esp 50
hop-by-hop hop 0
route ipv6-route 41
frag ipv6-frag 44
none ipv6-nonxt 59
protocol proto 255
If 'any:' is specified, the rule will match if any of the listed
headers are present. If 'exactly:' is specified, the will match
packets that exactly include all specified headers. If neither is
given, 'any:' is assumed.
This change adds a new capability (Header Match) so if you use a
capabilities file, you will need to regenerate using this release.
3) It is now possible to add explicit routes to individual provider
routing tables using the /etc/shorewall/routes (/etc/shorewall6/routes)
file.
See the shorewall-routes (5) and/or the shorewall6-routes (5) manpage.
4) Previously, /usr/share/shorewall/compiler.pl expected the contents
of the params file to be passed in the environment. Now, the
compiler invokes a small shell program
(/usr/share/shorewall/getparams) to process the file and to pass
the (variable,value) pairs back to the compiler.
Shell variable expansion uses the value from the params file if the
parameter was set in that file. Otherwise the current environment
is used. If the variable does not appear in either place, an error
message is generated.
5) Shared IPv4/IPv6 traffic shaping configuraiton is now
available. The device and class configuration can be included in
either the Shorewall or the Shorewall6 configuration. To place it
in the Shorewall configuration:
a) Set TC_ENABLED=Internal in shorewall.conf
b) Set TC_ENABLED=Shared in shorewall6.conf
c) Create symbolic link /etc/shorewall6/tcdevices pointing to
/etc/shorewall/tcdevices.
d) Create symbolic link /etc/shorewall6/tcclasses pointing to
/etc/shorewall/tcclasses.
e) Entries for both IPv4 and IPv6 can be included in
/etc/shorewall/tcfilters. This file has been extended to allow
both IPv4 and IPv6 entries to be included in a single file.
f) Packet marking rules are included in both configurations'
tcrules file as needed. CLASSIFY rules in
/etc/shorewall6/tcrules are validated against the Shorewall TC
configuration.
In this setup, the tcdevices and tcclasses will only be updated
when Shorewall is restarted. The IPv6 marking rules are updated
when Shorewall6 is restarted.
The above configuration may be reversed to allow Shorewall6 to
control the TC configuration.
----------------------------------------------------------------------------
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) Previously, messages to the STARTUP_LOG had inconsistent date formats.
2) The blacklisting change in 4.4.13 was broken in some simple
configurations with the effect that blacklisting was not enabled.
3) Previously, Shorewall6 produced an untidy sequence of error
messages when an attempt was made to start it on a system running a
kernel older than 2.6.24:
[root@localhost shorewall6]# shorewall6 start
Compiling...
Processing /etc/shorewall6/shorewall6.conf...
Loading Modules...
Compiling /etc/shorewall6/zones...
...
Shorewall configuration compiled to /var/lib/shorewall6/.start
ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
/usr/share/shorewall6/lib.common: line 73:
[: -lt: unary operator expected
ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
[root@localhost shorewall6]#
This has been corrected so that a single ERROR message is
generated.
4) Previously, an ipset name appearing in the /etc/shorewall/hosts
file could be qualified with a list of 'src' and/or 'dst' enclosed
in quotes. This was virtually guaranteed not to work since the set
must match when used to verify both a packet source and a
packet destination. Now, the following error is raised:
ERROR: ipset name qualification is disallowed in this file
As part of this change, the ipset name is now verified to begin
with a letter and be composed of letters, digits, underscores ("_")
and hyphens ("-").
5) The Shorewall-lite and Shorewall6-lite Debian init scripts contained a
syntax error.
6) If the -v or -q options were used in /sbin/shorewall-lite or
/sbin/shorewall6-lite commands that involve the compiled firewall
script and the resulting effective VERBOSITY was > 2 or < -1, then
the command would fail.
7) The log reading commands (show log, logwatch, and dump) returned no
log records when run on one of the -lite products.
8) To avoid future confusion, the following obsolete options have been
deleted from the sample shorewall.conf files:
BRIDGING
DELAYBLACKLISTLOAD
PKTTYPE
They will still be recognized by the rules compiler.
9) All sample .conf files have been changed to specify
FORWARD_CLEAR_MARK=
rather than
FORWARD_CLEAR_MARK=Yes
That way, systems without MARK support will still be able to
install the sample configurations and FORWARD_CLEAR_MARK will
default to Yes on systems with MARK support.
10) The install scripts in the tarballs now correctly create init
symlinks on recent Ubuntu releases.
11) Previously, this entry in the OPTIONS column of
/etc/shorewall/interfaces incorrectly generated a syntax error.
nets=(1.2.3.0/24)
The error was:
ERROR: Invalid VLSM (24))
12) Previously, if 10 or more interfaces were configured in Complex
Traffic Shaping (/etc/shorewall/tcdevices), the following
compilation diagnostic was generated:
Argument "a" isn't numeric in sprintf at
/usr/share/shorewall/Shorewall/Config.pm line 893.
and an invalid TC configuration was generated.
13) If the current environment exported the VERBOSITY variable with a
non-zero value, startup would fail.
----------------------------------------------------------------------------
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) Multiple source or destination ipset matches can be generated by
enclosing the ipset list in +[...].
Example (/etc/shorewall/rules):
ACCEPT $FW net:+[dest-ip-map,dest-port-map]
2) Shorewall now uses the 'conntrack' utility for 'show connections'
if that utility is installed. Going forward, the Netfilter team
will be enhancing this interface rather than the /proc interface.
3) The CPU time required for optimization has been reduced by 2/3.
4) An 'scfilter' extension script has been added. This extension
script differs from other such scripts in that it is invoked by the
command line tools (/sbin/shorewall, /sbin/shorewall6,
/sbin/shorewall-lite and /sbin/shorewall6-lite).
The script acts as a filter for the output of the 'show
connections' command. Each connection is piped through the filter
which can modify and/or drop information as desired.
Example:
#!/bin/sh
sed 's/secmark=0 //'
That script will remove 'secmark=0 ' from each line.
The default script is:
#!/bin/sh
cat -
which passes the output through unmodified.
If you are using Shorewall-lite and/or Shorewall6-lite, the
scfilter file is kept on the administrative system. The compiler
encapsulates the script into a shell function that is copied
into the generated auxillary configuration file
(firewall.conf). That function is then invoked by the 'show
connections' command.
----------------------------------------------------------------------------
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 :<port> (e.g., :22) appeared.
14) An error is now generated if '*' appears in an interface name.
----------------------------------------------------------------------------
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 start 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) 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 T H I S R E L E A S E
----------------------------------------------------------------------------
1) Previously, the Shorewall6-lite version of shorecap was using
iptables rather than ip6tables, with the result that many capabilities
that are only available in IPv4 were being reported as available.
2) In a number of cases, Shorewall6 generated incorrect rules
involving the IPv6 multicast network. The rules specified
ff00::/10 where they should have specified ff00::/8. Also, rules
instantiated when the firewall was stopped used ff80::/10 rather
than fe80::/10 (IPv6 Link Local network).
3) Previously, using a destination port-range with :random produced a
fatal compilation error in REDIRECT rules.
4) A number of problems associated with Shorewall-init and Upstart
have been corrected.
If you use Shorewall-init, then when upgrading to this version, be
sure to recompile all firewall scripts before you take interfaces
down or reboot.
5) Previously, the Shorewall installer (install.sh) failed to install
/usr/share/shorewall/configfiles/Makefile and rather issued the
following message:
install-file: command not found
This caused the Makefile to be omitted from RPMs as well.
6) When 'any' was used in the SOURCE column, a duplicate rule was
generated in all "fw2*" ("fw-* if ZONE2ZONE="-"). If 'any' was used
in the DEST column, then a duplicate rule appeared in all "*2fw"
(*-fw) chains.
7) A port range that omitted the first port number (e.g., ":80") was
rejected with the following error:
ERROR: Invalid/Unknown tcp port/service (0) : ......
8) AUTOMAKE=Yes has been broken for some time. It is now working
correctly.
----------------------------------------------------------------------------
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) Support has been added for ADD and DEL rules in
/etc/shorewall/rules. ADD allows either the SOURCE or DESTINATION
IP address to be added to an ipset; DEL deletes an address
previously added.
2) Per-ip log rate limiting has been added in the form of the LOGLIMIT
option in shorewall.conf. When LOGLIMIT is specified, LOGRATE and
LOGBURST are ignored.
LOGRATE and LOGBURST are now deprecated.
LOGLIMIT value format is [{s|d}:]<rate>[/<unit>][:<burst>]
If the value starts with 's:' then logging is limited per source
IP. If the value starts with 'd:', then logging is limited per
destination IP. Otherwise, the overall logging rate is limited.
<unit> is one of sec, min, hour, day.
If <burst> is not specified, then a value of 5 is assumed.
3) The sample configurations now include a 'Universal' configuration
that will start on any system and protect that system while
allowing the system to forward traffic.
As part of this change, several additional features were added:
- You may now specify "physical=+" in the interfaces file.
- A 'COMPLETE' option is added to shorewall.conf and
shorewall6.conf. When you set this option to Yes, you are
asserting that the configuration is complete so that your set of
zones encompasses any hosts that can send or receive traffic
to/from/through the firewall. This causes Shorewall to omit the
rules that catch packets in which the source or destination IP
address is outside of any of your zones. Default is No. It is
recommended that this option only be set to Yes if:
o You have defined an interface whose effective physical setting
is '+'
o That interface is assigned to a zone.
o You have no CONTINUE policies or rules.
4) 'icmp' is now accepted as a synonym for 'ipv6-icmp' in IPv6
compilations.
5) Shorewall now detects the presence of a recent ipset iptables
module and uses its new syntax. This avoids a warning on iptables
1.4.9. This change involves a new capabilities file version so if
you use a capabilities file, be sure to regenerate it with 4.4.12
shorewall-lite or shorewall6-lite.
6) Blacklisting can now be done by destination IP address as well as
by source address.
The /etc/shorewall/blacklist and /etc/shorewall6/blacklist files
now have an optional OPTIONS column. Initially, this column can
contain either 'from' (the default) or 'to'; the latter causes the
address(es) in the ADDRESS/SUBNET column to be interpreted as a
DESTINATION address rather than a source address.
Note that static blacklisting is still restricted to traffic
ARRIVING on an interface that has the 'blacklist' option set. So to
block traffic from your local network to an internet host, you must
specify 'blacklist' on your internal interface.
Similarly, dynamic blacklisting has been enhanced to recognize the
'from' and 'to' keywords.
Example:
shorewall drop to 1.2.3.4
This command will silently drop connection requests to1.2.3.4.
The reciprocal of that command would be:
shorewall allow to 1.2.3.4
7) The status command now displays the directory containing the .conf
file (shorewall.conf or shorewall6.conf) when the running
configuration was compiled.
Example:
gateway:/etc/shorewall# shorewall status
Shorewall-4.4.12-RC1 Status at gateway - Thu Aug 12 19:41:51 PDT 2010
Shorewall is running
State:Started (Thu Aug 12 19:41:48 PDT 2010) from /etc/shorewall/
gateway:/etc/shorewall#
----------------------------------------------------------------------------
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) The IPv6 allowBcast action generated an invalid rule.
2) If IPSET=<pathname> was specified in shorewall.conf, then when an
ipset was used in a configuration file entry, the following
fatal compilation error occurred:
ERROR: ipset names in Shorewall configuration files require Ipset
Match in your kernel and iptables : /etc/shorewall/rules (line nn)
If you applied the workaround given in the "Known Problems", then
you should remove /etc/shorewall/capabilities after installing
this fix.
3) The start priority of shorewall-init on Debian and Debian-based
distributions was previously too low, making it start too late.
4) The log output from IPv6 logs was almost unreadable due to display
of IPv6 addresses in uncompressed format. A similar problem
occurred with 'shorewall6 show connections'. This update makes the
displays much clearer at the expense of opening the slight
possibility of two '::' sequences being incorrectly shown in the
same address.
5) The new REQUIRE_INTERFACE was inadvertently omitted from
shorewall.conf and shorewall6.conf. It has been added.
6) Under some versions of Perl, a Perl run-time diagnostic was produced
when options were omitted from shorewall.conf or shorewall6.conf.
7) If the following options were specified in /etc/shorewall/interfaces
for an interface with '-' in the ZONE column, then these options
would be ignored if there was an entry in the hosts file for the
interface with an explicit or implicit 0.0.0.0/0 (0.0.0.0/0 is
implied when the host list begins with '!').
blacklist
maclist
nosmurfs
tcpflags
Note: for IPv6, the network is ::/0 rather than 0.0.0.0/0.
8) The generated script was missing a closing quote when
REQUIRE_INTERFACE=Yes.
9) Previously, if nets= was specified under Shorewall6, this error
would result:
ERROR: Invalid IPv6 address (224.0.0.0) :
/etc/shorewall6/interfaces (line 16)
----------------------------------------------------------------------------
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) Beginning with this release, Shorewall supports a 'vserver'
zone type. This zone type is used with Shorewall running on a
Linux-vserver host system and allows you to define zones that
represent a set of Linux-vserver hosts.
See http://www.shorewall.net/Vserver.html for details.
2) A new FORWARD_CLEAR_MARK option has been added to shorewall.conf
and shorewall6.conf.
Traditionally, Shorewall has cleared the packet mark in the first
rule in the mangle FORWARD chain. This behavior is maintained with
the default setting (FORWARD_CLEAR_MARK=Yes). If the new option is
set to No, packet marks set in the PREROUTING chain are retained in
the FORWARD chains.
As part of this change, a new "fwmark route mask" capability has
been added. If your version of iproute2 supports this capability,
fwmark routing rules may specify a mask to be applied to the mark
prior to comparison with the mark value in the rule. The presence
of this capability allows Shorewall to relax the restriction that
small mark values may not be set in the PREROUTING chain when
HIGH_ROUTE_MARKS is in effect. If you take advantage of this
capability, be sure that you logically OR mark values in PREROUTING
makring rules rather then simply setting them unless you are able
to set both the high and low bits in the mark in a single rule.
As always when a new capability has been introduced, be sure to
regenerate your capabilities file(s) after installing this release.
3) A new column (NET3) has been added to the /etc/shorewall/netmap
file. This new column can qualify the INTERFACE column by
specifying a SOURCE network (DNAT rule) or DEST network (SNAT rule)
associated with the interface.
4) To accomodate systems with more than one version of Perl installed,
the shorewall.conf and shorewall6.conf files now support a PERL
option. If the program specified by that option does not exist or
is not executable, Shorewall (and Shorewall6) fall back to
/usr/bin/perl.
----------------------------------------------------------------------------
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) Startup Errors (those that are detected before the state of the
system has been altered), were previously not sent to the
STARTUP_LOG.
2) A regression of sorts occurred in Shorewall 4.4.9. Previously, a
Perl extension script could end with a call to add_rule(). Such a
script fails under Shorewall 4.4.9 unless the 'trace' option is
specified on the run line.
While this issue has been corrected, users are advised to always
end their Perl extension scripts with the following line to insure
that the script returns a 'true' value:
1;
3) Under rare circumstances involving a complex configuration,
OPTIMIZE=13 and OPTIMIZE=15 could cause invalid iptables-restore
input to be generated.
Sample error message:
iptables-restore v1.4.8: Couldn't load target
`sys2sys':/usr/local/libexec/xtables/libipt_sys2sys.so:
cannot open shared object file: No such file or directory
4) Previously, if the 'optional' option was given to an interface with
a wildcard physical name, specific instances of the interface were
never considered usable.
Example:
/etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
net ppp+ - optional
/etc/shorewall/providers:
#PROVIDER NUMBER MARK DUPLICATE INTERFACE ...
XYZTEL 1 - main ppp0
The XYZTEL provider was never usable.
This configuration now works correctly.
5) The 'forget' command now correctly removes saved ipsets.
----------------------------------------------------------------------------
V. 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) Shorewall 4.4.10 includes a new 'Shorewall Init' package. This new
package provides two related features:
a) It allows the firewall to be closed prior to bringing up
network devices. This insures that unwanted connections are not
allowed between the time that the network comes up and when the
firewall is started.
b) It integrates with NetworkManager and distribution ifup/ifdown
systems to allow for 'event-driven' startup and shutdown.
The two facilities can be enabled separately.
When Shorewall-init is first installed, it does nothing until you
configure it.
The configuration file is /etc/default/shorewall-init on
Debian-based systems and /etc/sysconfig/shorewall-init otherwise.
There are two settings in the file:
PRODUCTS - lists the Shorewall packages that you want to
integrate with Shorewall-init. Example:
PRODUCTS="shorewall shorewall6"
IFUPDOWN When set to 1, enables integration with
NetworkManager and the ifup/ifdown scripts.
To close your firewall before networking starts:
a) in the Shorewall-init configuration file, set PRODUCTS to the
firewall products installed on your system.
b) be sure that your current firewall script(s) (normally in
/var/lib/<product>/firewall) is(are) compiled with the 4.4.10
compiler.
Shorewall and Shorewall6 users can execute these commands:
shorewall compile
shorewall6 compile
Shorewall-lite and Shorewall6-lite users can execute these
commands on the administrative system.
shorewall export <firewall-name-or-ip-address>
shorewall6 export <firewall-name-or-ip-address>
That's all that is required.
To integrate with NetworkManager and ifup/ifdown, additional steps
are required. You probably don't want to enable this feature if you
run a link status monitor like swping or LSM.
a) In the Shorewall-init configuration file, set IFUPDOWN=1.
b) In your Shorewall interfaces file(s), set the 'required' option
on any interfaces that must be up in order for the firewall to
start. At least one interface must have the 'required' or
'optional' option if you perform the next optional step. If
'required' is specified on an interface with a wildcard name
(the physical name ends with '+'), then at least one interface
that matches the name must be in a usable state for the
firewall to start successfully.
c) (Optional) -- If you have specified at least one 'required'
or 'optional interface, you can then disable automatic firewall
startup at boot time.
On Debian-based systems, set startup=0 in /etc/default/<product>.
On other systems, use your service startup configuration tool
(chkconfig, insserv, ...) to disable startup.
The following actions occur when an interface comes up:
FIREWALL INTERFACE ACTION
STATE
----------------------------------
Any Required start
stopped Optional start
started - restart
The following actions occur when an interface goes down:
In the INTERFACE column, '-' indicates neither required nor
optional
FIREWALL INTERFACE ACTION
STATE
----------------------------------
Any Required stop
stopped Optional start
started - restart
For optional interfaces, the /var/lib/<product>/<interface>.state
files are maintained to reflect the state of the interface.
Please note that the action is carried out using the current
compiled script; the configuration is not recompiled.
A new option has been added to shorewall.conf and
shorewall6.conf. The REQUIRE_INTERFACE option determines the
outcome when an attempt to start/restart/restore/refresh the
firewall is made and none of the optional interfaces are available.
With REQUIRE_INTERFACE=No (the default), the operation is
performed. If REQUIRE_INTERFACE=Yes, then the operation fails and
the firewall is placed in the stopped state. This option is
suitable for a laptop with both ethernet and wireless
interfaces. If either come up, the firewall starts. If neither
comes up, the firewall remains in the stopped state. Similarly, if
an optional interface goes down and there are no optional
interfaces remaining in the up state, then the firewall is stopped.
Shorewall-init may be installed on Debian-based systems, SuSE-based
systems and RedHat-based systems.
On Debian-based systems, during system shutdown the firewall is
opened prior to network shutdown (/etc/init.d/shorewall stop
performs a 'clear' operation rather than a 'stop'). This is
required by Debian standards. You can change this default behavior
by setting SAFESTOP=1 in /etc/default/shorewall
(/etc/default/shorewall6, ...).
2) All of the CLIs now support the -a option of the 'version' command.
Example:
gateway:~# shorewall6 version -a
4.4.10-RC1
shorewall: 4.4.10-RC1
shorewall-lite: 4.4.10-RC1
shorewall6-lite: 4.4.10-RC1
shorewall-init: 4.4.10-RC1
gateway:~#
3) Beginning with this release, the 'restart' and 'refresh' commands
now retain the contents of the dynamic blacklist as well as the
current UPnP rules. The dynamic blacklist is also preserved over
stop/start.
----------------------------------------------------------------------------
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) Logical interface names in the EXTERNAL column of
/etc/shorewall/proxyarp were previously not mapped to their
corresponding physical interface names. This could cause 'start' or
'restart' to fail.
2) If find_first_interface_address() was unable to detect an address,
then Shorewall 4.4.8 would issue an obscure message
(startup_error: command not found) and continue.
Now, a meaningful error message is produced and the calling process
stops.
3) If LOG_VERBOSITY=0 in shorewall.conf, then when the compiled script
was executed, messages such as the following would be issued:
/var/lib/shorewall6/.restart: line 65: [: -gt: unary operator
expected
4) With optimize 4, if an unnecessary NONAT rule was included in
/etc/shorewall/rules (there was no DNAT or REDIRECT rule with the
same source zone), then 'shorewall start' and/or 'shorewall restart'
could fail with invalid iptables-restore input.
5) The tarball installers now check for the presence of the CLI
program (/sbin/shorewall, /sbin/shorewall6, etc) to determine if a
fresh install or an upgrade should be performed. Previously, the
installers used the presense of the configuration directory
(/etc/shorewall, /etc/shorewall6, etc.) which led to incomplete
installations where there was an existing configuration directory.
6) The fallback.sh scripts have been removed from Shorewall-lite,
Shorewall6, and Shorewall6-lite. These scripts no longer work and
should have been removed in 4.4.0.
7) The -lite products previously were inconsistent in how they
referred to their startup log. Some references included '-lite'
where some did not. This was particularly bad in the case of the
Shorewall-lite logrotate file which duplicated the name used by the
Shorewall package. This inconsistency could cause logrotate to
fail if both packages were installed.
8) Two additional problems with optimize 4 have been corrected. One
manifested as invalid iptables-restore input involving the 'tcpre'
mangle chain. The other involved wildcard interface names (those
ending in '+') and would likely also result in invalid
iptables-restore input.
9) Previously, Shorewall would set up infrastructure to handle traffic
from the firewall to bport zones. Such infrastructure could never
be used. Now, Shorewall avoids setting up these unneeded chains
and/or rules.
10) If optimization level 2 and there were no OUTPUT rules and the only
effective output policy was $FW->all ACCEPT, then the OUTPUT chain
was empty and no packets could be sent.
11) If find_first_interface_address() was called in the params file, a
fatal error occured on start/restart.
12) The following valid configuration produced invalid
iptables-restore input with optimization level 4.
/etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
vpn tun+ -
/etc/shorewall/masq:
#INTERFACE SOURCE ADDRESS PROTO PORT
tun0 192.168.1.0/24
Use of tunN in the nat and netmap files also produced invalid
iptables-restore input.
----------------------------------------------------------------------------
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) The compiler now auto-detects bridges for the purpose of setting
the 'routeback' option. Auto-detection is disabled when compiling
for export (-e option); note that -e is implicit in the 'load' and
'reload' commands.
2) When 'trace' is specified on a command that involves the compiler
(e.g., shorewall trace check), the compiler now creates a trace to
standard output.
Trace entries are of three types:
Input --- begin with IN===>. Input read from configuration
files. Comments have been
stripped, continuation lines
combined and shell variables
expanded.
Output --- begin with GS----->. Text written to the generated
script.
Netfilter -- begin with NF-(x)->. Updates to the compiler's chain
table, where 'x' is one of the
following:
N - Create a chain.
A - Append a rule to a chain.
R - Replace a rule in a chain.
I - Inserted a rule into a chain.
T - Shell source text appended/inserted into a chain --
converted into rules at run-time.
D - Deleted Rule from a chain; note that this causes the
following rules to be renumbered.
X - Deleted a chain
P - Change a built-in chains policy. Chains in the filter table
are created with a DROP policy. All other builtin chains
have policy ACCEPT.
! Followed by one or more of the following to indicate that
the operation is not allowed on the chain.
O - Optimize
D - Delete
M - Move rules
Netfilter trace records indicate the table and chain being
changed. If the change involves a particular rule, then the rule
number is also included.
Example (append the first rule to the filter FORWARD chain):
NF-(A)-> filter:FORWARD:1 ...
If the trace record involves the chain itself, then no rule number
is present.
Example (Delete the mangle tcpost chain):
NF-(X)-> mangle:tcpost
3) Thanks to Vincent Smeets, there is now an IPv6 mDNS macro.
4) Optimize 8 has been added. This optimization level eliminates
duplicate chains. So to set all possible optimizations, specify
OPTIMIZE=15.
5) The command-line tools now support 'show log <regex>' where <regex>
is a regular expression to search for in the LOGFILE. The command
searches the current LOGFILE for Netfilter messages matching the
supplied regex.
6) There are some instances where a bridge with no IP address is
configured. Prior to Shorewall 4.4.9, this required the following:
/etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
dummy br0 - routeback
/etc/shorewall/policy:
#SOURCE DEST POLICY
dummy all DROP
all dummy DROP
Beginning in this release, a single entry will suffice:
/etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
- br0 - bridge
7) The generated ruleset now uses conntrack match for state matching,
if it is available.
8) In /etc/shorewall/routestopped, the 'routeback' option is assumed
if the interface has 'routeback' specified (either explicitly or
detected).
9) Apple Macs running OS X may now be used as a Shorewall
administrative system. Simply install using the tarball installer.
2010-03-24 Shorewall 4.4.8
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 8
----------------------------------------------------------------------------
1) A CONTINUE rule specifying a log level would cause the compiler to
generate an incorrect rule sequence. The packet would be logged
but the CONTINUE action would not occur.
2) If multiple entries were present in /etc/shorewall/tcdevices and
globally unique class numbers were not explicitly specified in
/etc/shorewall/tcclasses, then 'shorewall start' would fail with a
diagnostic such as:
Setting up Traffic Control...
RTNETLINK answers: File exists
ERROR: Command "tc qdisc add dev eth1 parent 2:2 handle 2: sfq quantum
1500 limit 127 perturb 10" Failed
Processing /etc/shorewall/stop ...
3) Previously, when a low per-IP rate limit (such as 1/hour) was
specified, the effective enforced rate was much higher
(approximately 6/min). The Shorewall compiler now configures the
hashlimit table idle timeout based on the rate units (min, hour,
...) so that the rate is more accurately enforced.
As part of this change, a unique hash table name is assigned to
each per-IP rate limiting rule that does not specify a table name
in the rule. The assigned names are of the form 'shorewallN' where
N is an integer. Previously, all such rules shared a single
'shorewall' table which lead to unexpected results.
4) All versions of Shorewall-perl mishandle per-IP rate limiting in
REDIRECT, DNAT and ACCEPT+ rules. The effective rate and burst are
1/2 of the values given in the rule.
5) Detection of the 'Old hashlimit match' capability was broken in
/sbin/shorewall, /sbin/shorewall-lite and in the IPv4 version of
shorecap.
6) On older distributions such as RHEL5 and derivatives, Shorewall
would fail to start if a TYPE was specified in
/etc/shorewall/tcinterfaces and LOAD_HELPERS_ONLY had been
specified in /etc/shorewall/shorewall.conf.
7) The Debian init scripts are modified to include $remote_fs in the
Required-start and Required-stop specifications.
8) Previously, when a supported command failed, the Debian Shorewall
init script would still return a success (zero) exit status. It now
returns a failure status (1) when the command fails.
9) Previously, if a queue number was specified in an NFQUEUE policy
(e.g., NFQUEUE(0)), invalid iptables-restore input would be
generated.
10) Previously, with optimization 4, users of ipsec on older releases
such as RHEL5 and CentOS, could encounter an error similar to this
one:
Running /sbin/iptables-restore...
iptables-restore v1.3.5: Unknown arg `out'
Error occurred at line: 93
Try `iptables-restore -h' or 'iptables-restore --help' for more
information.
ERROR: iptables-restore Failed. Input is in
/var/lib/shorewall/.iptables-restore-input
11) Previously, with optimization 4, the 'blacklst' chain could be
optimized away. If the blacklist file was then changed and a
'shorewall refresh' executed, those new changes would not be included
in the active ruleset.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 8
----------------------------------------------------------------------------
1) To avoid variable name collisions, a number of shell variable names
that Shorewall uses and that are in all capital letters have been
changed. The following variables are now safe to use in your
/etc/shorewall/params file and in your extension scripts:
DEBUG
ECHO_E
ECHO_N
EXPORT
FAST
HOSTNAME
IPT_OPTIONS
NOROUTES
PREVIEW
PRODUCT
PROFILE
PURGE
RECOVERING
RESTOREPATH
RING_BELL
STOPPING
TEST
TIMESTAMP
USE_VERBOSITY
VERBOSE
VERBOSE_OFFSET
VERSION
See Migration Issue 14 above for additional information.
2) The Shorewall and Shorewall6 installers now accept a '-s' (sparse)
option. That option causes only shorewall.conf to be installed in
/etc/shorewall/.
3) An OpenPGP HTTP Keyserver Protocol (HKP) macro (macro.HKP) has been
contributed.
4) In an attempt to help those who don't read the documentation, the
compiler now flags apparent use of '-' as a port range separator
with an error message.
Example:
/etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT net fw tcp 21-22
Resulting error message
ERROR: The separator for a port range is ':', not '-' (21-22) :
/etc/shorewall/rules (line 3)
5) Support has been added for UDPLITE (proto 136) in that DEST PORT(S)
and SOURCE PORT(S) may now be specified for that protocol.
6) If a runtime error occurs during a 'start' or 'restart' operation
but a saved configuration is successfully restored, a subsequent
'status' command now gives the detailed status as 'Restored from
<filename>' rather than 'Started'; <filename> is the saved script
used to restore the configuration.
2010-02-14 Shorewall 4.4.7
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 7
----------------------------------------------------------------------------
1) The tcinterfaces and tcpri files are now installed by the
installer and are included in the rpm.
2) An invalid octal number (e.g., 080) appearing in a port list
resulted in a perl error message.
As part of this fix, both hex and octal numbers are now accepted
for protocol and port numbers.
3) In 4.4.6, if a system:
a) Had mangle table support.
b) Had a FORWARD chain in the mangle table.
c) Did not have MARK Target support.
then 'shorewall start' would fail.
4) Previously, the 'nosmurfs' option was ignored in IPv6
compilations. As part of this fix, 'nosmurfs' handling when
SMURF_LOG_LEVEL is specified has been improved for both IPv4 and
IPv6.
5) Previously, specifying a TYPE in /etc/shorewall/tcinterfaces would
cause start/restart to fail on systems lacking 'flow' classifier
support. In Shorewall 4.4.7, we detect the ability of the 'tc'
utility to support that classifier.
There are two caveats:
- 'tc' may support 'flow' but the kernel does not. In that case,
start/restart will still fail.
- If you use a capabilities file, you will need to regenerate the
file using shorewall-lite 4.4.7 in order for 'flow' to be
accurately detected. If you do not regenerate the file, the
compiler will use other hints to try to determine if 'flow' is
available.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 7
----------------------------------------------------------------------------
1) The OPTIMIZE option value is now a bit-map with each bit
controlling a separate set of optimizations.
- The low-order bit (value 1) controls optimizations available in
earlier releases. We refer to this optimization as "optimization
1".
- The next bit (value 2) suppresses superfluous ACCEPT rules in a
policy chain that implements an ACCEPT policy. Any ACCEPT rules
that immediately preceed the final blanket ACCEPT rule in the
chain are now omitted. We refer to this optimization as
"optimization 2".
- The next bit (value 4 or "optimization 4") enables the following
additional optimizations:
a) Empty chains are optimized away.
b) Chains with one rule are optimized away.
c) If a built-in chain has a single rule that branches to a
second chain, then the rules from the second chain are moved
to the built-in chain and the target chain is omitted.
d) Chains with no references are deleted.
e) Accounting chains are subject to optimization if the new
OPTIMIZE_ACCOUNTING option is set to 'Yes' (default is 'No').
f) If a chain ends with an unconditional branch to a second chain
(other than to 'reject'), then the branch is deleted from the
first chain and the rules from the second chain are appended
to it.
The following chains are exempted from optimization 4:
action chains (user-created).
accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
dynamic
forwardUPnP
logdrop
logreject
rules chains (those of the form zonea2zoneb or zonea-zoneb).
UPnP (nat table).
To enable all possible optimizations, set OPTIMIZE to 7 (1 + 2 +
4).
2) Shorewall now combines identical logging chains. Previously, a
separate chain was created for each logging rule.
3) Beginning with Shorewall 4.4.7, accounting can be disabled by
setting ACCOUNTING=No in shorewall.conf. This allows you to keep a
set of accounting rules configured in /etc/shorewall/accounting and
to then enable and disable them by simply toggling the setting of
ACCOUNTING.
Similarly, dynamic blacklisting can be disabled by setting
DYNAMIC_BLACKLIST=No. This saves a jump rule in the INPUT
and FORWARD filter chains..
4) Shorewall can now automatically assign mark values to providers in
cases where 'track' is specified (or TRACK_PROVIDERS=Yes) but
packet marking is otherwise not used for directing connections to a
particular provider. Simply specify '-' in the MARK column and
Shorewall will automatically assign a mark value.
5) Support for TPROXY has been added. See
http://www.shorewall.net/Shorewall_Squid_Usage.html#TPROXY.
6) Traditionally, Shorewall has loaded all modules that could possibly
be needed twice; once in the compiler, and once when the generated
script is initialized. The latter can be a time-consuming process
on slow hardware.
Beginning with 4.4.7, there is a LOAD_HELPERS_ONLY option in
shorewall.conf. For existing users, LOAD_HELPERS_ONLY=No is the
default.
For new users that employ the sample configurations,
LOAD_HELPERS_ONLY=Yes will be the default. That setting causes only
a small subset of modules to be loaded; it is assumed that the
remaining modules will be autoloaded. Additionally, capability
detection in the compiler is deferred until each capability is
actually used. As a consequence, no modules are autoloaded
unnecessarily.
Modules loaded when LOAD_HELPERS_ONLY=Yes are the protocol
helpers. These cannot be autoloaded.
In addition, the nf_conntrack_sip module is loaded with
sip_direct_media=0. This setting is slightly less secure than
sip_direct_media=1, but it solves many VOIP problems that users
routinely encounter.
2010-01-16 Shorewall 4.4.6
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 6
----------------------------------------------------------------------------
1) A 'feature' of xtables-addons when applied to Debian Lenny causes
extra /31 networks to appear for nethash sets in the output of
"ipset -L" and "ipset -S". A hack has been added to prevent these
from being saved when Shorewall is saving IPSETS during 'stop'.
As part of this change, the generated script is more careful about
verifying the existence of the correct ipset utility before using
it to save the contents of the sets.
2) The mDNS macro previously did not include IGMP (protocol 2) and it
did not specify the mDNS multicast address (224.0.0.251). These
omissions have been corrected.
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
None.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 6
----------------------------------------------------------------------------
1) In kernel 2.6.31, the handling of the rp_filter interface option was
changed incompatibly. Previously, the effective value was determined
by the setting of net.ipv4.config.dev.rp_filter logically ANDed with
the setting of net.ipv4.config.all.rp_filter.
Beginning with kernel 2.6.31, the value is the arithmetic MAX of
those two values.
Given that Shorewall sets net.ipv4.config.all.rp_filter to 1 if
there are any interfaces specifying 'routefilter', specifying
'routefilter' on any interface has the effect of setting the option
on all interfaces.
To allow Shorewall to handle this issue, a number of changes were
necessary:
a) There is no way to safely determine if a kernel supports the
new semantics or the old so the Shorewall compiler uses the
kernel version reported by uname.
b) This means that the kernel version is now recorded in
the capabilities file. So if you use capabilities files, you
need to regenerate the files with Shorewall[-lite] 4.4.6 or
later.
c) If the capabilities file does not contain a kernel version,
the compiler assumes version 2.6.30 (the old rp_filter
behavior).
d) The ROUTE_FILTER option in shorewall.conf now accepts the
following values:
0 or No - Shorewall sets net.ipv4.config.all.rp_filter to 0.
1 or Yes - Shorewall sets net.ipv4.config.all.rp_filter to 1.
2 - Shorewall sets net.ipv4.config.all.rp_filter to 2.
Keep - Shorewall does not change the setting of
net.ipv4.config.all.rp_filter if the kernel version
is 2.6.31 or later.
The default remains Keep.
e) The 'routefilter' interface option can have values 0,1 or 2. If
'routefilter' is specified without a value, the value 1 is
assumed.
2) SAVE_IPSETS=Yes has been resurrected but in a different form. With
this setting, the contents of your ipsets are saved during 'shorewall
stop' and 'shorewall save' and they are restored during 'shorewall
start' and 'shorewall restore'. Note that the contents may only be
restored during 'restore' if the firewall is currently in the
stopped state and there are no ipsets currently in use. In
particular, when 'restore' is being executed to recover from a
failed start/restart, the contents of the ipsets are not changed.
When SAVE_IPSETS=Yes, you may not include ipsets in your
/etc/shorewall/routestopped configuration.
3) IPv6 addresses following a colon (":") may either be surrounded by
<..> or by the more standard [..].
4) A DHCPfwd macro has been added that allows unicast DHCP traffic to
be forwarded through the firewall. Courtesy of Tuomo Soini.
5) Shorewall (/sbin/shorewall) now supports a 'show macro' command:
shorewall show macro <macro>
Example:
shorewall show macro LDAP
The command displays the contents of the macro.<macro> file.
6) You may now preview the generated ruleset by using the '-r' option
to the 'check' command (e.g., "shorewall check -r").
The output is a shell script fragment, similar to the way it
appears in the generated script.
7) It is now possible to enable a simplified traffic shaping
facility by setting TC_ENABLED=Simple in shorewall.conf.
See http://www.shorewall.net/simple_traffic_shaping.html for
details.
8) Previously, when TC_EXPERT=No, packets arriving through 'tracked'
provider interfaces were unconditionally passed to the PREROUTING
tcrules. This was done so that tcrules could reset the packet mark
to zero, thus allowing the packet to be routed using the 'main'
routing table. Using the main table allowed dynamic routes (such as
those added for VPNs) to be effective.
The route_rules file was created to provide a better alternative
to clearing the packet mark. As a consequence, passing these
packets to PREROUTING complicates things without providing any real
benefit.
Beginning with this release, when TRACK_PROVIDERS=Yes and TC_EXPERT=No,
packets arriving through 'tracked' interfaces will not be passed to
the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in
4.4.3, this change should be transparent to most, if not all, users.
2009-12-19 Shorewall 4.4.5
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 5
----------------------------------------------------------------------------
1) The change which removed the 15 port limitation on
/etc/shorewall/routestopped was incomplete. The result was that if
more than 15 ports were listed, an error was generated.
2) If any interfaces had the 'bridge' option specified, compilation
failed with the error:
Undefined subroutine &Shorewall::Rules::match_source_interface called
at /usr/share/shorewall/Shorewall/Rules.pm line 2319.
3) The compiler now flags port number 0 as an error in all
contexts. Previously, port 0 was allowed with the result that
invalid iptables-restore input could be generated in some cases.
4) The 'show policies' command now works in Shorewall6 and
Shorewall6-lite.
5) Traffic shaping modules from /lib/modules/<version>/net/sched/ are
now correctly loaded. Previously, that directory was not
searched. Additionally, Shorewall6 now tries to load the cls_flow
module; previously, only Shorewall attempts to load that module.
6) The Shorewall6-lite shorecap program was previously including the
IPv4 base library rather than the IPv6 version. Also, Shorewall6
capability detection was determing the availablity of the mangle
capability before it had determined if ip6tables was installed.
7) The setting of MODULE_SUFFIX was previously ignored except when
compiling for export.
8) Detection of the Enhanced Reject capability in the compiler was
broken for IPv4 compilations.
9) The 'reload -c' command would ignore the setting of DONT_LOAD in
shorewall.conf. The 'reload' command without '-c' worked as
expected.
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
None.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 5
----------------------------------------------------------------------------
1) Shorewall now allows DNAT rules that change only the destination
port.
Example:
DNAT loc net::456 udp 234
That rule will modify the destination port in UDP packets received
from the 'loc' zone from 456 to 234. Note that if the destination
is the firewall itself, then the destination port will be rewritten
but that no ACCEPT rule from the loc zone to the $FW zone will have
been created to handle the request. So such rules should probably
exclude the firewall's IP addresses in the ORIGINAL DEST column.
2) Systems that do not log Netfilter messages locally can now set
LOGFILE=/dev/null in shorewall.conf.
3) The 'shorewall show connections' and 'shorewall dump' commands now
display the current number of connections and the max supported
connections.
Example:
shorewall show connections
Shorewall 4.5.0 Connections (62 out of 65536) at gateway - Sat ...
In that case, there were 62 current connections out of a maximum
number supported of 65536.
2009-11-21 Shorewall 4.4.4
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 4
----------------------------------------------------------------------------
1) In some simple one-interface configurations, the following Perl
run-time error messages were issued:
Generating Rule Matrix...
Use of uninitialized value in concatenation (.) or string at
/usr/share/shorewall/Shorewall/Chains.pm line 649.
Use of uninitialized value in concatenation (.) or string at
/usr/share/shorewall/Shorewall/Chains.pm line 649.
Creating iptables-restore input...
2) The Shorewall operations log (specified by STARTUP_LOG) is now
secured 0600.
3) Previously, the compiler generated an incorrect test for interface
availability in the generated code for adding route rules. The
result was that the rules were always added, regardless of the
state of the provider's interface. Now, the rules are only added
when the interface is available.
4) When TC_WIDE_MARKS=Yes and class numbers are not explicitly
specified in /etc/shorewall/tcclasses, duplicate class numbers
result. A typical error message is:
ERROR: Command "tc class add dev eth3 parent 1:1 classid
1:1 htb rate 1024kbit ceil 100000kbit prio 1 quantum 1500"
Failed
Note that the class ID of the class being added is a duplicate of
the parent's class ID.
Also, when TC_WIDE_MARKS=Yes, values > 255 in the MARK column of
/etc/shorewall/tcclasses were rejected.
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
None.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 4
----------------------------------------------------------------------------
1) The Shorewall packages now include a logrotate configuration file.
2) The limit of 15 entries in a port list has been relaxed in
/etc/shorewall/routestopped.
3) The following seemingly valid configuration produces a fatal
error reporting "Duplicate interface name (p+)"
/etc/shorewall/zones:
#ZONE TYPE
fw firewall
world ipv4
z1:world bport4
z2:world bport4
/etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
world br0 - bridge
world br1 - bridge
z1 br0:p+
z2 br1:p+
This error occurs because the Shorewall implementation requires
that each bridge port must have a unique name.
To work around this problem, a new 'physical' interface option has
been created. The above configuration may be defined using the
following in /etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
world br0 - bridge
world br1 - bridge
z1 br0:x+ - physical=p+
z2 br1:y+ - physical=p+
In this configuration, 'x+' is the logical name for ports p+ on
bridge br0 while 'y+' is the logical name for ports p+ on bridge
br1.
If you need to refer to a particular port on br1 (for example
p1023), you write it as y1023; Shorewall will translate that name
to p1023 when needed.
It is allowed to have a physical name ending in '+' with a logical
name that does not end with '+'. The reverse is not allowed; if the
logical name ends in '+' then the physical name must also end in
'+'.
This feature is not restricted to bridge ports. Beginning with this
release, the interface name in the INTERFACE column can be
considered a logical name for the interface, and the actual
interface name is specified using the 'physical' option. If no
'physical' option is present, then the physical name is assumed to
be the same as the logical name. As before, the logical interface
name is used throughout the rest of the configuration to refer to
the interface.
4) Previously, Shorewall has used the character '2' to form the name
of chains involving zones and/or the word 'all' (e.g., fw2net,
all2all). When zones names are given numeric suffixes, these
generated names are hard to read (e.g., foo1232bar). To make these
names clearer, a ZONE2ZONE option has been added.
ZONE2ZONE has a default value of "2" but can also be given the
value "-" (e.g., ZONE2ZONE="-") which causes Shorewall to separate
the two parts of the name with a hyphen (e.g., foo123-bar).
5) Only one instance of the following warning is now generated;
previously, one instance of a similar warning was generated for
each COMMENT encountered.
COMMENTs ignored -- require comment support in iptables/Netfilter
6) The shorewall and shorewall6 utilities now support a 'show
policies' command. Once Shorewall or Shorewall6 has been restarted
using a script generated by this version, the 'show policies'
command will list each pair of zones and give the applicable
policy. If the policy is enforced in a chain, the name of the chain
is given.
Example:
net => loc DROP using chain net2all
Note that implicit intrazone ACCEPT policies are not displayed for
zones associated with a single network where that network
doesn't specify 'routeback'.
7) The 'show' and 'dump' commands now support an '-l' option which
causes chain displays to include the rule number of each rule.
(Type 'iptables -h' and look for '--line-number')
2009-11-01 Shorewall 4.4.3
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 3
----------------------------------------------------------------------------
1. Previously, if 'routeback' was specified in /etc/shorewall/routestopped:
a) 'shorewall check' produced an internal error
b) The 'routeback' option didn't work
2) If an alias IP address was added and RETAIN_ALIASES=No in
shorewall.conf, then a compiler internal error resulted.
3) Previously, the generated script would try to detect the values
for all run-time variables (such as IP addresses), regardless of
what command was being executed. Now, this information is only
detected when it is needed.
4) Nested zones where the parent zone was defined by a wildcard
interface (name ends with +) in /etc/shorewall/interfaces did
not work correctly in some cases.
5) IPv4 addresses embedded in IPv6 (e.g., ::192.168.1.5) were
incorrectly reported as invalid.
6) Under certain circumstances, optional providers were not detected
as being usable.
Additionally, the messages issued when an optional provider was not
usable were confusing; the message intended to be issued when the
provider shared an interface ("WARNING: Gateway <gateway> is not
reachable -- Provider <name> (<number>) not Added") was being
issued when the provider did not share an interface. Similarly, the
message intended to be issued when the provider did not share an
interface ("WARNING: Interface <interface> is not usable --
Provider <name> (<number>) not Added") was being issued when the
provider did share an interface.
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
None.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 3
----------------------------------------------------------------------------
1) On Debian systems, a default installation will now set
INITLOG=/dev/null in /etc/default/shorewall. In all configurations,
the default values for the log variables are changed to:
STARTUP_LOG=/var/log/shorewall-init.log
LOG_VERBOSITY=2
The effect is much the same as the old defaults, with the exception
that:
a) Start, stop, etc. commands issued through /sbin/shorewall
will be logged.
b) Logging will occur at maximum verbosity.
c) Log entries will be date/time stamped.
On non-Debian systems, new installs will now log all Shorewall
commands to /var/log/shorewall-init.log.
2) A new TRACK_PROVIDERS option has been added in shorewall.conf.
The value of this option becomes the default for the 'track'
provider option in /etc/shorewall/providers.
3) A new 'limit' option has been added to
/etc/shorewall/tcclasses. This option specifies the number of
packets that are allowed to be queued within the class. Packets
exceeding this limit are dropped. The default value is 127 which is
the value that earlier versions of Shorewall used. The option is
ignored with a warning if the 'pfifo' option has been specified.
2009-10-02 Shorewall 4.4.2
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 2
----------------------------------------------------------------------------
1) Detection of Persistent SNAT was broken in the rules compiler.
2) Initialization of the compiler's chain table was occurring before
shorewall.conf had been read and before the capabilities had been
determined. This could lead to incorrect rules and Perl runtime
errors.
3) The 'shorewall check' command previously did not detect errors in
/etc/shorewall/routestopped.
4) In earlier versions, if a file with the same name as a built-in
action were present in the CONFIG_PATH, then the compiler would
process that file like it was an extension script.
The compiler now ignores the presence of such files.
5) Several configuration issues which previously produced an error or
warning are now handled differently.
a) MAPOLDACTIONS=Yes and MAPOLDACTIOSN= in shorewall.conf are now
handled as they were by the old shell-based compiler. That is,
they cause pre-3.0 built-in actions to be mapped automatically
to the corresponding macro invocation.
b) SAVE_IPSETS=Yes no longer produces a fatal error -- it is now a
warning.
c) DYNAMIC_ZONES=Yes no longer produces a fatal error -- it is now
a warning.
d) RFC1918_STRICT=Yes no loger produces a fatal error -- it is now
a warning.
6) Previously, it was not possible to specify an IP address range in
ADDRESS column of /etc/shorewall/masq. Thanks go to Jessee Shrieve
for the patch.
7) The 'wait4ifup' script included for Debian compatibility now runs
correctly with no PATH.
8) The new per-IP LIMIT feature now works with ancient iptables
releases (e.g., 1.3.5 as found on RHEL 5). This change required
testing for an additional capability which means that those who use
a capabilities file should regenerate that file after installing
4.4.2.
9) One unintended difference between Shorewall-shell and
Shorewall-perl was that Shorewall-perl did not support the MARK
column in action bodies. This has been corrected.
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
None.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 2
----------------------------------------------------------------------------
1) Prior to this release, line continuation has taken precedence over
#-style comments. This prevented us from doing the following:
ACCEPT net:206.124.146.176,\ #Gateway
206.124.146.177,\ #Mail
206.124.146.178\ #Server
...
Now, unless a line ends with '\', any trailing comment is stripped
off (including any white-space preceding the '#'). Then if the line
ends with '\', it is treated as a continuation line as normal.
2) Three new columns have been added to FORMAT-2 macro bodies.
MARK
CONNLIMIT
TIME
These three columns correspond to the similar columns in
/etc/shorewall/rules and must be empty in macros invoked from an
action.
3) Accounting chains may now have extension scripts. Simply place your
Perl script in the file /etc/shorewall/<chain> and when the
accounting chain named <chain> is created, your script will be
invoked.
As usual, the variable $chainref will contain a reference to the
chain's table entry.
2009-09-03 Shorewall 4.4.1
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 4 . 1
----------------------------------------------------------------------------
1) If ULOG was specified as the LOG LEVEL in the all->all policy, the
rules at the end of the INPUT and OUTPUT chains would still use the
LOG target rather than ULOG.
2) Using CONTINUE policies with a nested IPSEC zone was still broken
in some cases.
3) The setting of IP_FORWARDING has been change to Off in the
one-interface sample configuration since forwarding is typically
not required with only a single interface.
4) If MULTICAST=Yes in shorewall.conf, multicast traffic was
incorrectly exempted from ACCEPT policies.
5) Previously, the definition of a zone that specified "nets=" in
/etc/shorewall/interfaces could not be extended by entries in
/etc/shorewall/hosts.
6) Previously, "nets=" could be specified in a multi-zone interface
definition ("-" in the ZONES column) in /etc/shorewall/zones. This
now raises a fatal compilation error.
7) MULTICAST=Yes generates an incorrect rule that limits its
effectiveness to a small part of the multicast address space.
8) Checking for zone membership has been tighened up. Previously,
a zone could contain <interface>:0.0.0.0/0 along with other hosts;
now, if the zone has <interface>:0.0.0.0/0 (even with exclusions),
then it may have no additional members in /etc/shorewall/hosts.
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
None.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 4 . 1
----------------------------------------------------------------------------
1) To replace the SAME keyword in /etc/shorewall/masq, support has
been added for 'persistent' SNAT. Persistent SNAT is required when
an address range is specified in the ADDRESS column and when you
want a client to always receive the same source/destination IP
pair. It replaces SAME: which was removed in Shorewall 4.4.0.
To specify persistence, follow the address range with
":persistent".
Example:
#INTERFACE SOURCE ADDRESS
eth0 0.0.0.0/0 206.124.146.177-206.124.146.179:persistent
This feature requires Persistent SNAT support in your kernel and
iptables.
If you use a capabilities file, you will need to create a new one
as a result of this feature.
WARNING: Linux kernels beginning with 2.6.29 include persistent
SNAT support. If your iptables supports persistent SNAT but your
kernel does not, there is no way for Shorewall to determine that
persistent SNAT isn't going to work. The kernel SNAT code blindly
accepts all SNAT flags without verifying them and returns them to
iptables when asked.
2) A 'clean' target has been added to the Makefiles. It removes backup
files (*~ and .*~).
3) The meaning of 'full' has been redefined when used in the context
of a traffic shaping sub-class. Previously, 'full' always meant the
OUT-BANDWIDTH of the device. In the case of a sub-class, however,
that definition is awkward to use because the sub-class is limited
by the parent class.
Beginning with this release, 'full' in a sub-class definition
refers to the specified rate defined for the parent class. So
'full' used in the RATE column refers to the parent class's RATE;
when used in the CEIL column, 'full' refers to the parent class's
CEIL.
As part of this change, the compiler now issues a warning if the
sum of the top-level classes' RATEs exceeds the OUT-BANDWIDTH of
the device. Similarly, a warning is issued if the sum of the RATEs
of a class's sub-classes exceeds the rate of the CLASS.
4) When 'nets=<network>' or 'nets=(<net1>,<net2>,...) is specified in
/etc/shorewall/interfaces, multicast traffic will now be sent to
the zone along with limited broadcasts.
5) A flaw in the parsing logic for the zones file allowed most zone
types containing the character string 'ip' to be accepted as a
synonym for 'ipv4' (or ipv6 if compiling an IPv6 configuration).
2009-08-14 Shorewall 4.4.0
----------------------------------------------------------------------------
R E L E A S E 4 . 4 H I G H L I G H T S
----------------------------------------------------------------------------
1) Support for Shorewall-shell has been discontinued. Shorewall-perl
has been combined with Shorewall-common to produce a single
Shorewall package.
2) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing
discipline has been added. HFSC is superior to the "Hierarchical
Token Bucket" queuing discipline where realtime traffic such as
VOIP is being used.
3) Support for the "flow" traffic classifier has been added. This
classifier can help prevent multi-connection applications such as
BitTorrent from using an unfair amount of bandwidth.
4) The Shorewall documentation and man pages have been purged of
information about earlier Shorewall releases. The documentation
describes only the behavior of Shorewall 4.4 and later versions.
5) The interfaces file OPTIONs have been extended to largely remove the
need for the hosts file.
6) It is now possible to define PREROUTING and OUTPUT marking rules
that cause new connections to use the same provider as an existing
connection of the same kind.
7) Dynamic Zone support is once again available for IPv4; ipset support is
required in your kernel and in iptables.
8) A new AUTOMAKE option has been added to shorewall.conf and
shorewall6.conf. Setting this option will allow Shorewall to skip
the compilation phase during start/restart if no configuration
changes have occurred since the last start/restart.
9) The LIMIT:BURST column in /etc/shorewall/policy
(/etc/shorewall6/policy) and the RATE LIMIT column in
/etc/shorewall/rules (/etc/shorewall6/rules) may now be used to
limit on a per source IP or per destination IP basis.
10) Support for per-IP traffic shaping classes has been added.
11) Support for netfilter's TRACE facility has been added. TRACE allows
you to trace selected packets through Netfilter, including marking
by tcrules.
2009-08-02 Shorewall 4.4.0 RC 2
Read the details at http://www1.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.0-RC2/releasenotes.txt
2009-07-26 Shorewall 4.4.0 RC 1
Read the details at http://www1.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.0-RC1/releasenotes.txt
2009-07-12 Shorewall 4.4.0 Beta 4
Read the details at http://www1.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.0-Beta4/releasenotes.txt
2009-06-29 Shorewall 4.4.0 Beta 3
Read the details at http://www1.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.0-Beta3/releasenotes.txt
2009-06-21 Shorewall 4.4.0 Beta 2
Read the details at http://www1.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.0-Beta2/releasenotes.txt
2009-06-18 Shorewall 4.2.10
Problems corrected in Shorewall 4.2.10
1) A 'large quantum' warning log message during restart has been
eliminated. The log message occurred when an interface with a large
OUT-BANDWIDTH was defined in /etc/shorewall/tcdevices.
2) When a REJECT rule included a log entry, the disposition in the log
message was incorrectly shown as 'reject' rather than 'REJECT'.
3) When 'forward' was specified on one or more interfaces in
/etc/shorewall6/interfaces, the progress message "Compiling
Interface forwarding..." was issued multiple times. Now, only one
instance of the message is generated.
4) A typing error in the IPv6 two-interface sample shorewall6.conf
file has been corrected. This error prevented the compiler from
being able to find macros in /usr/share/shorewall/.
Known Problems Remaining:
1) When exclusion is used in an entry in /etc/shorewall/hosts, then
Shorewall-shell produces an invalid iptables rule if any of the
following OPTIONS are also specified in the entry:
blacklist
maclist
norfc1918
tcpflags
2) Shorewall-shell generates inversion rules which produce
warnings with iptables 1.4.3.
Example:
iptables -A lan2fw -p 6 --dport 999 -s ! 192.168.20.1 -j ACCEPT
with iptables 1.4.3.1 the following information message is produced:
Using intrapositioned negation (`--option ! this`) is deprecated in
favor of extrapositioned (`! --option this`).
We don't intend to fix this. It's time to migrate to Shorewall-perl
anyway.
New Features in Shorewall 4.2.10
1) Shorewall's suppport for dynamic gateways on interfaces managed by
dhclient works on OpenSuSE systems but not on some other
distributions.
In order to generalize support for learning the gateway for dynamic
interfaces, a new 'findgw' extension script (user exit) has been
added.
The exit will be invoked in a function that has a single argument:
$1 = <name of an interface>
If the function can determine the gateway for the passed interface,
it should write the gateway to standard out. Here is a sample
/etc/shorewall/findgw that works with dhclient (dhcp3) in Debian
Lenny:
if [ -f /var/lib/dhcp3/dhclient.${1}.leases ]; then
grep 'option routers' /var/lib/dhcp3/dhclient.${1}.leases |\
tail -n 1 |\
while read j1 j2 gateway; do\
echo $gateway | sed 's/;//';\
done
fi
The same code works on Ubuntu Jaunty if you replace the first '.'
with '-' and replace '.leases' with '.lease' (don't you just love
the consistency between distributions?).
That code also works on CentOS if you replace 'dhcp3' by
'dhclient'.
'findgw' files that have been customized for various distributions
may be found at
http://www.shorewall.net/pub/shorewall/contrib/findgw.
2009-06-13 Shorewall 4.4.0 Beta 1
Read the details at http://www1.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.0-Beta1/releasenotes.txt
2009-05-14 Shorewall 4.2.9
Problems corrected in Shorewall 4.2.9
1) The Shorweall-perl 4.2.8 compiler did not rename the output script
file with the result that:
a) Shorewall would not start for the first time after
installation.
b) Configuration changes were apparently ignored.
2) Placing a broadcast address in the BROADCAST column of
/etc/shorewall/interfaces caused Shorewall-perl to generate an
error:
ERROR: Invalid BROADCAST address : /etc/shorewall/interfaces\
(line 225)
3) When Shorewall could not determine the MAC address of of a gateway
router where multiple providers are configured through the same
interface, invalid iptables-restore input was generated. This
resulted in an error message similar to the following:
iptables-restore v1.3.5: Bad mac address `-j'
4) Shorewall-perl was not processing the tcrules file when
TC_ENABLED=No.
5) When 'all' appeared in the SOURCE column of a DNAT rule, no rule to
redirect output from the firewall itself was generated.
6) The 'shorewall iprange' command failed to produce a minimal list of
networks.
New Features in Shorewall 4.2.9
1) Shorewall6 has now been validated on Ubuntu Hardy running kernel
2.6.24. Shorewall6 is now supported on that kernel version.
2009-04-16 Shorewall 4.2.8
Problems Corrected in Shorewall 4.2.8
1) The 'start -f' command would previously skip the compilation step
unconditionally when the 'make' utility was not installed. Now, the
compilation step is run unconditionally in this case.
2) When ADD_IP_ALIASES=Yes in shorewall.conf, entries in
/etc/shorewall/nat produce this failure at compile time when
using Shorewall-perl:
ERROR: Internal Error in emit : /etc/shorewall/nat (line 12)
3) When LOG_MARTIANS=Yes with Shorewall-perl, setting logmartians=0 in
an entry in /etc/shorewall/interface failed to suppress martian
logging on the interface.
4) Shorewall-perl now generates rules with inversion that are
compatible with iptables 1.4.3.
5) When a network address was specified in the SOURCE or DEST column of
/etc/shorewall/tcfilters, Shorewall-perl was generating an incorrect
netmask.
New Features in 4.2.8
1) The /usr/share/shorewall/modules and /usr/share/shorewall6/modules
files have been updated for iptables 1.4.3/kernel 2.6.29.
2009-03-19 Shorewall 4.2.7
Problems corrected in 4.2.7
1) Previously, the 'start' command set the permission flags on
/var/lib/shorewall*/state so that it could be read by
non-root users while the 'stop' command set the permissions such
that the file could not be read by those users.
Beginning with 4.2.7, both commands will secure the file for
root-only access. If you want the file to be world-readable, then
add
chmod 744 <file name>
To your /etc/shorewall/started, /etc/shorewall/stopped and
/etc/shorewall/restored files.
2) The 'shorewall6 dump' command now correctly displays the installed
version of Shorewall-perl. It also displays the IPv6 neighbor table
contents rather than the ARP table contents.
3) Under some circumstances, interface options like nosmurfs and
tcpflags would not be applied to forwarded traffic when using
Shorewall-perl.
4) The following rule was badly mis-handled:
DNAT- loc net:1.2.3.4:2525 tcp 25
The result:
WARNING: Destination zone (1.2.3.4) ignored : /etc/shorewall/rules (line 459)
Can't call method "inet_htoa" without a package or object reference at
/usr/share/shorewall-perl/Shorewall/IPAddrs.pm line 150,
<$currentfile> line 459.
5) Previously, OPTIONS were not allowed with a bridge port in
/etc/shorewall/interfaces. That oversight has been corrected and
now the following OPTIONS are allowed:
blacklist
maclist
norfc1918
nosmurfs
routeback
tcpflags
6) Tuomo Soini provided a workaround patch for a problem seen in some
kernel's (see FAQ 82) that caused 'shorewall start' to fail when
USE_DEFAULT_RT=Yes .
New Features in Shorewall 4.2.7
1) Prior to Shorewall version 3.0.0, rules generated by
/etc/shorewall/tunnels were traversed before those generated by
/etc/shorewall/rules. When SECTIONs were added to the rules file in
3.0.0, traversal of the tunnel rules was deferred until after those
generated by the NEW section of the rules file.
Beginning with Shorewall-perl 4.2.7, the tunnel rules are back
where they started -- right before the first rule generated by the
NEW section of /etc/shorewall/rules.
2) To allow bypassing of connection tracking for certain traffic,
/etc/shorewall/notrack and /etc/shorewall6/notrack files have been
added.
Columns in the file are:
SOURCE - <zone>[:<interface>][:<address list>]
DEST - [<address list>]
PROTO - <protocol name or number>
DEST PORT(S) - <port number list>
SOURCE PORT(S) - <port number list>
USER/GROUP - [<user>][:<group>]
May only be specified if the SOURCE <zone> is $FW.
Traffic that matches all given criteria will not be subject to
connection tracking. For such traffic, your policies and/or rules
must deal with ALL of the packets involved, in both the original
and the opposite directions. All untracked traffic is passed
through the relevant rules in the NEW section of the rules
file. Untracked encapsulated tunnel traffic can be handled by
entries in /etc/shorewall/tunnels just like tracked traffic
is. Because every packet of an untracked connection must pass
through the NEW section rules, it is suggested that rules that deal
with untracked traffic should appear at the top of the file.
Example:
/etc/shorewall/tunnels:
#TYPE ZONE GATEWAY
6to4 net
/etc/shorewall/notrack
#SOURCE DEST PROTO DEST SOURCE USER/
# PORT(S) PORT(S) GROUP
net:!192.88.99.1 - 41
Given that 192.88.99.1 is an anycast address, many hosts can
respond to outward traffic to that address. The entry in
/etc/shorewall/tunnels allows protocol 41 net<->fw. The entry in
/etc/shorewall/notrack prevents the inbound traffic from creating
additional useless conntrack entries.
As part of this change, the 'show' command is enhanced to support a
'show raw' command that is an alias for 'show -t raw'. The raw
table is where NOTRACK rules are created. The dump command is also
enhanced to display the contents of the raw table.
3) Shorewall-perl supports three additional columns in the
/etc/shorewall/routestopped file:
PROTO -- Protocol name or number
DEST PORT(S) -- comma-separated list of service names and/or port
numbers
SOURCE PORT(S) -- comma-separated list of service names and/or port
numbers.
These columns are only meaningful when the "-f" option to
'shorewall stop' is used.
As part of this change, the "-f" option to the 'stop' and 'clear'
commands is now the default when FAST_STOP=Yes in shorewall.conf.
To override this default, use the "-s" option:
shorewall stop -s
Note that if you have entries with one or more of the new columns,
the -s option will result in warning messages.
gateway:~ # shorewall stop -s
Stopping Shorewall...
WARNING: Unknown routestopped option ignored: notrack
WARNING: Unknown routestopped option ignored: 41
WARNING: Unknown routestopped option ignored: notrack
WARNING: Unknown routestopped option ignored: 41
done.
gateway:~ #
4) Shorewall-perl now handles SOURCE PORT lists of more than 15
entries by breaking the containing rule into multiple rules.
2009-02-15 Shorewall 4.2.6
Problems corrected in 4.2.6
1) The CONFIG_PATH in the two- and three-interface Shorewall6 sample
configurations was incorrect with the result that this error
occurred on 'shorewall6 check' or 'shorewall6 start'.
ERROR: No IP zones defined
2) Setting TCP_FLAGS_DISPOSITION=REJECT caused both Shorewall-shell
and Shorewall-perl to create invalid iptables commands. This has
been corrected but we still strongly recommend against that
setting; TCP_FLAGS_DISPOSITION=DROP is preferred.
3) Shorewall-perl was generating code that checked for state match
before kernel modules were loaded. This caused start/restart to
fail on systems without kernel module loading.
4) The Shorewall6 and Shorewall6-lite Makefiles were incorrect.
5) If a service name is used in a port-mapping rule (a DNAT or
REDIRECT rule that changes the destination port), and if the
kernel and iptables include Extended Connection Match support, then
invalid iptables-restore input is produced by Shorewall-perl.
6) If iptables 1.4.1 or later was installed, Shorewall-perl generated
incorrect iptables-restore input if exclusion was used in the
ORIGINAL DEST field of a DNAT or REDIRECT rule.
7) On kernels earlier than 2.6.20, the 'shorewall show connections'
command fails.
New Feature in Shorewall 4.2.6
1) A BitTorrent32 macro has been added. This macro matches the
extended TCP port range used by BitTorrent 3.2 and later.
2) A new COUNT action has been added to Shorewall-perl. This action
creates an iptables (ip6tables) rule with no target. Connections
matching such a rule are simply counted and the packet is passed on
to the next rule.
Shorewall-shell ignores COUNT in actions and macros, thus allowing
the standard actions (action.Drop and action.Reject) to have a
COUNT rule as their first entry.
3) A new RESTORE_DEFAULT_ROUTE option has been added to
shorewall.conf. It is used to determine whether to restore the
default route saved when there are 'balance' providers defined but
all of them are down.
The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
pre-4.2.6 behavior.
RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
default route in the main table (USE_DEFAULT_RT=No) or in the
default table (USE_DEFAULT_RT=Yes) when there are no balance
providers available. In that case, RESTORE_DEFAULT_ROUTE=No
will cause any default route in the relevant table to be deleted.
4) IPv4 firewall scripts produced by Shorewall-perl now use dhcpcd's
database when trying to detect the gateway for an interface
("detect" in the GATEAWAY column in /etc/shorewall/interfaces).
As part of this change, it is now permitted to specify 'detect'
when USE_DEFAULT_RT=Yes; in that case, the script will only detect
gateways for point-to-point devices and for devices configured by
dhcpcd.
5) Shorewall-perl now supports port inversion. A port number or list
of port numbers may be preceded by '!" which will cause the rule to
match all ports EXCEPT those listed:
Example: To blacklist 206.124.146.176 for all tcp ports except 80:
ADDRESS/SUBNET PROTO PORT(S)
206.124.146.177 tcp !80
6) Shorewall-perl now supports protocol inversion. A protocol name or
number may be preceded by '!' to specify all protocols except the
one following '!'.
Example: To blacklist 206.124.146.176 for all protocols except
UDP:
ADDRESS/SUBNET PROTO PORT(S)
206.124.146.177 !udp
Note that ports may not be specified when protocol inversion
is used.
7) When using Shorewall-perl, neither the 'start' nor 'started'
extension script is run during processing of the 'restore'
command. To allow extension of that command, we have added a
'restored' extension script that runs at the successful completion
of 'restore'. This script is only available with Shorewall-perl.
With Shorewall-shell, both scripts are run during 'restore' but in
that case, the run_iptables() function does nothing. So any
run_iptables() calls in the 'start' script are effectively ignored.
8) Shorewall-perl now correctly handles 'here documents' quoting
(<<EOF .... EOF) in run-time extension scripts.
2009-01-22 Shorewall 4.2.5
Problems corrected in 4.2.5
1) If exclusion is used to define a zone in /etc/shorewall/hosts and
that zone is used as the SOURCE zone in a DNAT or REDIRECT rule,
then Shorewall-perl can generate invalid iptables-restore input.
2) A bug in the Perl Cwd module (see
http://rt.cpan.org/Public/Bug/Display.html?id=13851) causes the
Shorewall-perl compiler to fail if it doesn't have at least read
access to its current working directory. 4.2.5 contains a
workaround.
3) If 'critical' was specified on an entry in
/etc/shorewall6/routestopped, Shorewall6 (Shorewall-perl) would
generate an error.
4) In certain cases where exclusion occurred in /etc/shorewall/hosts,
Shorewall-perl would generate incorrect iptables-restore input.
5) In certain cases where exclusion occurred in /etc/shorewall/hosts,
Shorewall-perl would generate invalid iptables-restore input.
6) The 'shorewall6 refresh' command runs iptables_restore rather than
ip6tables_restore.
7) The commands 'shorewall6 save-start', 'shorewall6-save-restart' and
'shorewall6 restore' were previously broken.
8) The Debian init script was checking $startup in
/etc/default/shorewall rather than in /etc/default/shorweall6
9) The Archlinux init scripts for Shorewall6 and Shorewall6 Lite were
unconverted Shorewall scripts.
10) When 'detect' is used in the GATEWAY column of
/etc/shorewall/providers, Shorewall-perl now ensures that the
gateway was successfully detected. If the gateway cannot be
detected, action is taken depending on whether the provider is
'optional' or not. If the provider is optional, it's configuration
is skipped; if the provider is not optional, the current operation
is aborted.
11) The command 'shorewall6 debug start' would previously fail with
ERROR: Command "/sbin/ip6tables -t nat -F" Failed
12) Both ipv4 and ipv6 compiled programs attempt to run the tcclear
script itself at run time rather than running the copy of the
file in the compiled script. This usually isn't noticable unless
you are running Shorewall Lite or Shorewall6 Lite in which case,
the script doesn't get run (since it is on the administrative
system and not the firewall system).
13) If your iptables/kernel included "Extended Connection Tracking
Match support" (see the output of "shorewall show capabilities"),
then a REDIRECT rule that specified a port list or range would
cause Shorewall-perl to create invalid iptables-restore input:
Running /usr/sbin/iptables-restore...
iptables-restore v1.4.2-rc1: conntrack: Bad value for
"--ctorigdstport" option: "1025:65535"
Error occurred at line: 191
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input
Known Problems Remaiining:
1) When exclusion is used in an entry in /etc/shorewall/hosts, then
Shorewall-shell produces an invalid iptables rule if any of the
following OPTIONS are also specified in the entry:
blacklist
maclist
norfc1918
tcpflags
New Feature in Shorewall 4.2.5
1) A new 'fallback' option is added in
/etc/shorewall/providers. The option works similar to 'balance'
except that the default route is added in the default routing table
(253) rather than in the main table (254).
The option can be used by itself or followed by =<number> (e.g,
fallback=2).
When the option is used by itself, a separate (not balanced)
default route is added with a metric equal to the provider's NUMBER.
When the option is used with a number, a balanced route is added
with the weight set to the specified number.
'fallback' is ignored if USE_DEFAULT_RT=Yes in shorewall.conf and
is only available with Shorewall-perl.
'fallback' is useful in situations where:
- You want all traffic to be sent via one primary provider unless
there is a compelling reason to use a different provider
- If the primary provider is down, then you want to balance the
outgoing traffic among a set of other providers or to a
ordered list of providers.
In this case:
- Do not specify 'balance' on any of the providers.
- Disable route filtering ('ROUTE_FILTER=No' in shorewall.conf).
- Specify 'fallback' on those providers that you want to use if
the primary is down.
- Only the primary provider should have a default route in the main
routing table.
See http://www.shorewall.net/MultiISP.html#Complete for an example
of this option's use.
2) Shorewall-perl now transparently handles the xtables-addon version
of ipp2p. Shorewall detects whether the installed ipp2p is from
patch-o-matic-ng or from xtables-addon and proceeds accordingly.
If the patch-o-matic-ng version is installed:
a) If no DEST PORT is supplied, the default is "--ipp2p".
b) If "ipp2p" is supplied as the DEST PORT, it will be passed to
iptables-restore as "--ipp2p".
If the xtables-addons version is installed:
a) If no DEST PORT is supplied, the default is "--edk --gnu --dc
--kazaa".
b) If "ipp2p" is supplied as the DEST PORT, it will be passed to
iptables-restore as "--edk --gnu --dc --kazaa".
Shorewall-perl now also accepts a comma-separated list of options
(e.g., "edk,gnu,dc,kazaa).
Additionally, Shorewall now looks for modules in /lib/modules/$(uname
-r)/extra and in /lib/modules/$(uname -r)/extra/ipset
This change introduced a new capability ("Old IPP2P Match Syntax")
so if you use a capabilities file, be sure to re-generate the
file(s) after you have installed 4.2.5.
3) There is now a macro.Git, which opens git-daemon's port (9418/tcp).
4) There is also a macro.IRC which open's the Internet Relay Chat port
(6667/tcp).
2009-01-06 Winner of the Shorewall Logo Design Competition Announced
The Shorewall developers are pleased to announce that after deliberatingSee
http://trac.shorewall.net/wiki/LogoDesignCompetition for
details.
2008-12-31 Shorewall 4.2.4
1) In 4.2.4, two new packages are included:
a) Shorewall6 - analagous to Shorewall-common but handles IPv6
rather than IPv4.
b) Shorewall6-lite - analagous to Shorewall-lite but handles IPv6
rather than IPv4.
The packages store their configurations in /etc/shorewall6/ and
/etc/shorewall6-lite/ respectively.
The fact that the packages are separate from their IPv4 counterparts
means that you control IPv4 and IPv6 traffic separately (the same
way that Netfilter does). Starting/Stopping the firewall for one
address family has no effect on the other address family.
For additional information, see
http://www.shorewall.net/IPV6Support.html.
Other features of Shorewall6 are:
a) There is no NAT of any kind (most people see this as a giant step
forward). When an ISP assigns you a public IPv6 address, you are
actually assigned an IPv6 'prefix' which is like an IPv4
subnet. A 64-bit prefix allows 4 billion squared individual hosts
(the size of the current IPv4 address space squared).
b) The default zone type is ipv6.
c) The currently-supported interface options in Shorewall6 are:
blacklist
bridge
dhcp
nosmurfs (traps multicast and Subnet-router anycast addresses
used as the packet source address).
optional
routeback
sourceroute
tcpflags
mss
forward (setting it to 0 makes the router behave like a host
on that interface rather than like a router).
d) The currently-supported host options in Shorewall6 are:
blacklist
routeback
tcpflags
e) Traffic Shaping is disabled by default. The tcdevices and
tcclasses files are address-family independent so
to use the Shorewall builtin Traffic Shaper, TC_ENABLED=Internal
should be specified in Shorewall or in Shorewall6 but not in
both. In the configuration where the internal traffic shaper is
not enabled, CLEAR_TC=No should be specified.
tcfilters are not available in Shorewall6.
f) When both an interface and an address or address list need to
be specified in a rule, the address or list must be enclosed in
angle brackets. Example:
#ACTION SOURCE DEST
ACCEPT net:eth0:<2001:19f0:feee::dead:beef:cafe> dmz
Note that this includes MAC addresses as well as IPv6 addresses.
The HOSTS column in /etc/shorewall6/hosts also uses this
convention:
#ZONE HOSTS OPTIONS
chat6 eth0:<2001:19f0:feee::dead:beef:cafe>
Even when an interface is not specified, it is permitted to
enclose addresses in <> to improve readability. Example:
#ACTION SOURCE DEST
ACCEPT net:<2001:1::1> $FW
g) The options available in shorewall6.conf are a subset of those
available in shorewall.conf.
h) The Socket6.pm Perl module is required if you include DNS names
in your Shorewall6 configuration. Note that it is loaded the
first time that a DNS name is encountered so if it is missing,
you get a message similar to this one:
...
Checking /etc/shorewall6/rules...
Can't locate Socket6.pm in @INC (@INC contains: /root ...
teastep@ursa:~/Configs/standalone6$
2008-12-16 Shorewall 4.2.3
Problems corrected in Shorewall 4.2.3
1) Previously, Shorewall would allow compilation for export of a
script named 'shorewall' with the unfortunate side effect that
the 'shorewall.conf' file was overwritten. Scripts named
'shorewall' now cause a fatal error to be raised.
2) Previously, Shorewall-perl attempted to do Shell variable
substitution on the first line in /etc/shorewall/compile.
3) Following the Netfilter tradition, the IPP2P maintainer has made an
incompatible syntax change (the --ipp2p option has been
removed). Shorewall has always used "-m ipp2p --ipp2p" when
detecting the presence of IPP2P support.
Shorewall-common and Shorewall-perl have been modified to use
"-m ipp2p --edk" instead.
4) When Extended Conntrack Match support was available, Shorewall-perl
would create invalid iptables-restore input for certain DNAT rules.
5) An optimization in all Shorewall-perl 4.2 versions could cause
undesirable side effects. The optimization deleted the
<interface>_in and <interface>_fwd chains and moved their rules
to the appropriate rules chain (a <zone>2<xxx> chain).
This worked badly in cases where a zone was associated with more
than one interface. Rules could be duplicated or, worse, a rule
that was intended for only input from one of the interfaces would
be applied to input from all of the zone's interfaces.
This problem has been corrected so that an interface-related
chains is only deleted if:
a) the chain has no rules in it; or
b) the interface is associated with only one zone and that zone is
associated with only that interface in which case it is safe to
move the rules.
Other changes in Shorewall 4.2.3
1) Except with the -e option is specified, the Shorewall-perl compiler
now verifies user/group names appearing in the USER/GROUP column of
the rules file.
2) The output of 'shorewall dump' now includes the output from
'netstat -tunap'.
3) Shorewall-perl now accepts '+' as an interface name in
/etc/shorewall/interfaces. That name matches any interface and is
useful for defining a zone that will match any interface that might
be added after Shorewall is started.
A couple of words of caution are in order.
a) Because '+' matches any interface name, Shorewall cannot
verify interface names appearing in other files when '+' is
defined in /etc/shorewall/interfaces.
b) The zone assigned to '+' must be the last one defined in
/etc/shorewall/zones.
4) Shorewall-perl now uses the iptables --goto parameter in obvious
cases.
5) The 'reset' command now allows you to reset the packet and byte
counter on individual chains:
shorewall reset chain1 chain2 ...
shorewall-lite reset chain1 chain2 ...
2008-11-20 Shorewall 4.2.2
Problems corrected in Shorewall 4.2.2
1) Shorewall-perl now insures that each line copied from a
configuration file or user exit is terminated with a newline
character.
2) When ipranges were used to define zones, Shorewall-perl could
generate invalid iptables-restore input if 'Repeat Match' was not
available. Repeat Match is not a true match -- it rather is a
feature of recent iptables releases that allows a match to be
repeated within a rule.
3) With Shorewall-perl, if a destination port list had exactly 16
ports, where a port-range counts as two ports, then Shorewall-perl
would fail to split the rule into multiple rules and an
iptables-restore error would result.
4) The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1
compatibility contained a typo that prevented it from working
correctly.
5) If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP
address and no zone name in the DEST column, Shorewall-perl would
reject the rule. If a zone name was specified, Shorewall-perl
would issue a Warning message.
6) Previously, if Extended conntrack match support was available, a
DNAT rule that specified a server port but no destination port
would generate invalid iptables-restore input.
Other changes in Shorewall 4.2.2
1) A macro supporting JAP (anonymization protocol) has been added.
It can be used as any other macro (e.g., JAP/ACCEPT) in the rules
file.
2) A macro supporting DAAP (Digital Audio Access Protocol) has been added.
It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules
file.
3) A macro supporting DCC (Distributed Checksum Clearinghouse) has been
added. It can be used as any other macro (e.g., DCCP/ACCEPT) in the
rules file.
4) A macro supporting GNUnet (secure peer-to-peer networking) has been
added. It can be used as any other macro (e.g., GNUnet/ACCEPT) in the
rules file.
5) In 4.2.1, a single capability ("Extended conntrack match support")
was used both to control the use of --ctorigport and to trigger use
of the new syntax for inversion of --ctorigdst (e.g., "!
--ctorigdst ..."). In 4.2.2, these are controlled by two separate
capabilities. If you use a capabilities file when compiling your
configuration, be sure to generate a new one after installing
4.2.2.
2008-10-25 Shorewall 4.2.1
Problems corrected in Shorewall 4.2.1
1) A description of the CONNBYTES column has been added to
shorewall-tcrules(5).
2) Previously, Shorewall-perl would accept zero as the <max> value in
the CONNBYTES column of tcrules even when the <min> field was
non-zero. A value of zero for <max> was equivalent to omitting
<max>.
3) iptables 1.4.1 discontinued support of syntax generated by
shorewall in some cases. Shorewall now detects when the new syntax
is required and uses it instead.
4) The Shorewall-perl implementation of the LENGTH column in
/etc/shorewall/tcrules was incomplete with the result that
all LENGTH rules matched. Thanks to Lennart Sorensen for the patch.
5) The 'export' command no longer fails with the error:
/sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi")
Other changes in Shorewall 4.2.1
1) With the recent renewed interest in DOS attacks, it seems
appropriate to have connection limiting support in Shorewall. To
that end, a CONNLIMIT column has been added to both the policy and
rules files.
The content of these columns is of the format
[!] <limit>[:<mask>]
where
<limit> is the limit on simultaneous TCP connections.
<mask> specifies the size of the network to which
the limit applies and is specified as a
CIDR mask length. The default value for
<mask> is 32 which means that each remote
IP address can have <limit> TCP connections
active at once.
! Not allowed in the policy file. In the rules file, it
causes connections to match when the number of
current connections exceeds <limit>.
When specified in the policy file, the limit is enforced on all
connections that are subject to the given policy (just like
LIMIT:BURST). The limit is checked on new connections before the
connection is passed through the rules in the NEW section of the
rules file.
It is important to note that while the limit is only checked for
those destinations specified in the DEST column, the number of
current connections is calculated over all destinations and not
just the destination specified in the DEST column.
Use of this feature requires the connlimit match capability in your
kernel and iptables. If you use a capabilities file when compiling
your Shorewall configuration(s), then you need to regenerate the
file using Shorewall or Shorewall-lite 4.2.1.
2) Shorewall now supports time/date restrictions on entries in the
rules file via a new TIME column.
The contents of this column is a series of one or more "time
elements" separated by apersands ("&"). Possible time elements are:
utc Times are expressed in Greenwich Mean Time.
localtz Times are expressed in local civil time (default)
timestart=hh:mm[:ss]
timestop=hh:mm[:ss] Start and stop time of day for rule
weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or
Sun
monthdays=dd[,dd]... where dd is an ordinal day of the month.
datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
where yyyy = Year
first mm = Month
dd = Day
hh = Hour
2nd mm = Minute
ss = Second
Examples:
1) utc×tart=10:00×top=12:00
Between 10am and 12 noon each day, GMT
2) datestart=2008-11-01T12:00
Beginning November 1, 2008 at noon LCT.
Use of this feature requires the time match capability in your
kernel and iptables. If you use a capabilities file when compiling
your Shorewall configuration(s), then you need to regenerate the
file using Shorewall or Shorewall-lite 4.2.1.
2006-10-05 Shorewall 4.2.0
Release Highlights.
1) Support is included for multiple internet providers through the same
ethernet interface.
2) Support for NFLOG has been added.
3) Enhanced operational logging.
4) The tarball installers now work under Cygwin.
5) Shorewall-perl now supports IFB devices which allow traffic shaping of
incoming traffic.
6) Shorewall-perl supports definition of u32 traffic classification
filters.
2008-03-29 Shorewall 4.0.10
Problems corrected in Shorewall-perl 4.0.10.
1) Shorewall-perl 4.0.9 erroneously reported an error message when a
bridge port was defined in /etc/shorewall/interfaces:
ERROR: Your iptables is not recent enough to support bridge ports
2) Under Shorewall-perl, if an empty action was invoked or was named
in one of the DEFAULT_xxx options in shorewall.conf, an
iptables-restore error occured.
3) If $ADMIN was empty, then the rule:
ACCEPT loc:$ADMIN all
became
ACCEPT loc net
It is now flagged as an error.
4) Previously, Shorewall-perl would reject an IP address range in the
ecn and routestopped files.
5) A POLICY of ":" in /etc/shorewall/policy would produce Perl
run-time errors.
6) An INTERFACE of ":" in /etc/shorewall/interfaces would produce Perl
run-time errors.
7) A MARK of ":" in /etc/shorewall/tcrules would produce Perl
run-time errors.
Problems corrected in Shorewall-shell 4.0.10.
1) Specifying a value for ACCEPT_DEFAULT or QUEUE_DEFAULT resulted in
a fatal error at compile time.
Known Problems Remaining.
1) The 'refresh' command doesn't refresh the mangle table. So changes
made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
not be reflected in the running ruleset.
Other changes in 4.0.10.
1) The Sample configurations have been updated to set
LOG_MARTIANS=keep. In 4.2, this will be changed to
LOG_MARTIANS=Yes.
2) Shorewall-perl now generates a fatal error if a non-existant shell
variable is used in any configuration file (except
/etc/shorewall/params).
3) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP
port 1701 in both directions and assumes that the source port will
also be 1701. Some implementations (particularly OS X) use a
different source port. In that case, you should use
'generic:udp:1701' rather than 'l2tp'.
2008-03-01 Shorewall 3.4.8
1) Shorewall now removes any default bindings of ipsets before
attempting to reload them. Previously, default bindins were not
removed with the result that the ipsets could not be destroyed.
2) When HIGH_ROUTE_MARKS=Yes, unpredictable results could occur when
marking in the PREROUTING or OUTPUT chains. When a rule specified a
mark value > 255, the compiler was using the '--or-mark' operator
rather than the '--set-mark' operator with the result that when a
packet matched more than one rule, the resulting routing mark was
the logical product of the mark values in the rules.
Example:
0x100 192.168.1.44 0.0.0.0/0
0x200 0.0.0.0/0 0.0.0.0/0 tcp 25
A TCP packet from 192.168.1.44 with destination port 25 would end
up with a mark value of 0x300.
3) Shorewall now properly parses comma separated SOURCE (formerly
SUBNET) values in the masq configuration file. Previously, the comma
separated list was not split up into its components, resulting in an
invalid address being passed to the iptables command.
Example:
# /etc/shorewall/masq
#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
eth0 192.168.2.1,192.168.2.3
4) Previously, specifying both an interface and a MAC address in the
SOURCE column of the tcrules file caused a failure at runtime.
Thanks to Justin Joseph for the patch.
5) Previously, specifying both an interface and an address in the
tcrules DEST column would cause an incomplete rule to be generated.
Example:
1 192.168.1.4 eth2:206.124.146.177 tcp 22
The resulting tcrule would be as if this had been specified:
1 0.0.0.0/0 eth2:206.124.146.177 tcp 22
6) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match
fwmarks to routing tables overflowed the designated range for such
marks (10000 - 11000).
2008-02-23 Shorewall 4.0.9
Problems corrected in Shorewall-perl 4.0.9.1
1) In 4.0.9, Shorewall-perl incorrectly generated the following error
message:
ERROR: Your iptables is not recent enough to support bridge ports
Problems corrected in Shorewall-perl 4.0.9
1) If a zone was defined with exclusion in /etc/shorewall/hosts, then
the rules generated for directing outgoing connections to the zone
were incorrect.
Example:
/etc/shorewall/zones:
z ipv4
/etc/shorewall/interfaces:
- eth2
/etc/shorewall/hosts:
z eth2:192.168.1.0/24!192.168.1.5
Traffic from the firewall to 192.168.1.5 was incorrectly classified
as $FW->z.
2) Qualifying 'SOURCE' and 'DEST' with an IP address in a macro file
caused 'SOURCE' or 'DEST' to be interpreted incorrectly as the name
of an interface.
Example:
PARAM DEST SOURCE:224.0.0.22
3) Specifying '!<user>' in the USER/GROUP column of the files that
support it resulted in an invalid iptables rule under
Shorewall-perl.
4) Previously, Shorewall would accept both an interface and an IP
address in tcrules POSTROUTING entries (such as CLASSIFY).
Example:
1:11 eth1:192.168.4.9 - tcp 22
It also allowed both a destination interface and address.
Example:
1:P - eth1:192.168.4.9 tcp 22
Because Netfilter does not allow an input interface to be specified
in POSTROUTING or an output interface to be specified in
PREROUTING, Shorewall must use the routing table to generate a list
of networks accessed through any interface specified in these
cases. Given that a specific address (or set of addresses) has
already been specified, it makes no sense qualify it (them) by
another list of addresses.
5) Shorewall-perl incorrectly generated a fatal error when ':C',
':T' or ':CT' was used in a tcrules entry that gave $FW as the
SOURCE.
6) Users have been confused about this error message:
ERROR: Bridge Ports require Repeat match in your kernel and iptables
The message has been replaced with:
ERROR: Your iptables is not recent enough to support bridge ports
The minimum version required is 1.3.8.
Problems corrected in Shorewall-shell 4.0.9.
1) An optimization added to Shorewall-shell in 4.0.0 has been backed
out to work around a limitation of Busybox 'sed'.
2) Previously, specifying both an interface and an address in the
tcrules DEST column would cause an incomplete rule to be generated.
Example:
1 192.168.1.4 eth2:206.124.146.177 tcp 22
The resulting tcrule would be as if this had been specified:
1 0.0.0.0/0 eth2:206.124.146.177 tcp 22
3) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match
fwmarks to routing tables previously overflowed the designated
range defined for such marks (10000 - 11000).
Known Problems Remaining.
1) The 'refresh' command doesn't refresh the mangle table. So changes
made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
not be reflected in the running ruleset.
Other changes in 4.0.9.
1) The Shorewall-perl now flags unprintable garbage characters in
configuration files with the message:
ERROR: Non-ASCII gunk in file
2) The /usr/share/shorewall/modules file has been updated to reflect
module renaming in kernel 2.6.25.
3) The 'ip route replace' command is broken in kernel 2.6.24. To work
around this problem, the undocumented option BROKEN_ROUTING has
been added to shorewall.conf. The default is BROKEN_ROUTING=No.
If you are experiencing 'File Exists' errors from 'ip route
replace' commands, then add the following line to your
shorewall.conf:
BROKEN_ROUTING=Yes
Note: This workaround is only available in Shorewall-perl.
2008-01-25 Shorewall 4.0.8
Problems corrected in Shorewall-perl 4.0.8.
1) Mark tests (such as in the TEST column of tcrules or the MARK
column of the rules file) were ignoring the value 0. As part of
this fix, the default mask generated by entries in these columns
has been changed from 0xFF to 0xFFFF for compatibility with
Shorewall-shell.
2) The compilation date recorded in the firewall.conf file produced by
Shorewall-perl was previously mangled.
3) The ability to specify a DEST IP range (round-robin) in a DNAT rule
has been restored. In versions 4.0.5 - 4.0.7, an IP range was
incorrectly flagged as an error.
Problems corrected in Shorewall-shell 4.0.8.
1) Shorewall-shell now properly parses comma separated SOURCE (formerly
SUBNET) values in the masq configuration file. Previously, the comma
separated list was not split up into its components, resulting in an
invalid address being passed to the iptables command.
Example:
# /etc/shorewall/masq
#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
eth0 192.168.2.1,192.168.2.3
Known Problems Remaining.
1) The 'refresh' command doesn't refresh the mangle table. So changes
made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
not be reflected in the running ruleset.
Other changes in 4.0.8.
None.
Problems corrected in Shorewall-perl 4.0.7
1) If any of the following files was missing, a harmless Perl warning
was issued:
accounting
maclist
masq
nat
netmap
rfc1918
routestopped
tunnels
This problem was experienced mostly by Debian users and users of
Debian derivatives such as Ubuntu.
2) The iptables utility doesn't retry operations that fail due to
resource shortage. Beginning with this release, Shorewall reruns
iptables when such a failure occurs.
3) Previously, Shorewall-perl did not accept log levels in upper case
(e.g., INFO). Beginning with 4.0.7, log levels are treated in a
case-insensitive manner by Shorewall-perl.
4) The column headers in macro files were not aligned. This has been
corrected, along with some inaccuracies in the macro.template file.
5) The shorewall.conf files in the Samples did not contain some
recently-defined options. They are now up to date.
6) The names of the Jabber macros were shuffled. They are now named
correctly.
7) If ADD_IP_ALIASES=Yes, an alias was incorrectly added when the
specified INTERFACE ended with ":" (e.g., eth0:).
8) Shorewall-shell generated an incorrect iptables rule from the
following:
/etc/shorewall/rules:
ACCEPT loc:eth0:~00-02-02-02-02-02 ...
/etc/shorewall/tcrules:
xxxx eth0:~00-02-02-02-02-02 ...
Known Problems Remaining.
1) The 'refresh' command doesn't refresh the mangle table. So changes
made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
not be reflected in the running ruleset.
Other changes in 4.0.7
1) If the program named in SHOREWALL_SHELL doesn't exist or is not
executable, Shorewall and Shorewall-lite now both fall back to
/bin/sh after issuing a warning message. Previously, both
terminated with a fatal error.
2) The error message has been improved when a non-root user attempts
"shorewall show capabilities".
3) Shorewall-perl now generates fatal error conditions when there are
no IPv4 zones defined and when there are no interfaces defined.
2007-12-26 Shorewall 4.1.3
Problems corrected in Shorewall 4.1.3.
1) If NFLOG or ULOG was specified with parameters, the resulting
iptables-restore input contained elements that were incorrectly
up-cased.
2) If STARTUP_LOG is specified without LOG_VERBOSITY, /sbin/shorewall
produces an error.
3) If LOG_VERBOSITY is specified without STARTUP_LOG, run-time error
messages are produced.
4) Shorewall-shell was mishandling the entries in /etc/shorewall/rules
and in /etc/shorewall/tcrules where both a SOURCE interface and MAC
address were specified.
Example:
ACCEPT net:eth0:~01-02-03-04-05-06 $FW tcp 22
Other changes in Shorewall 4.1.3.
1) If the program named in SHOREWALL_SHELL doesn't exist or is not
executable, Shorewall and Shorewall-lite now both fall back to
/bin/sh after issuing a warning message. Previously, both
terminated with a fatal error.
2) The error message has been improved when a non-root user attempts
"shorewall show capabilities".
3) Shorewall-perl now generates fatal error conditions when there are
no IPv4 zones defined and when there are no interfaces defined.
4) Shorewall now unconditionally uses tc filter rules to classify
traffic by MARK value. Previously, Shorewall used the CLASSIFY
target in the POSTROUTING chain if it was available.
5) The Shorewall-common installer (install.sh) now works on Windows
under Cygwin.
To install Shorewall-perl under Cygwin:
$ tar -xf shorewall-perl-4.1.3.tar.bz2
$ tar -xf shorewall-common-4.1.3.tar.bz2
$ cd shorewall-perl-4.1.3
$ ./install.sh
$ cd ../shorewall-common-4.1.3
$ USER=<your user id> GROUP=None ./install.sh
The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).
2007-11-23 Shorewall 4.0.6
Problems corrected in Shorewall-perl 4.0.6.
1) In a DNAT or REDIRECT rule, if no serverport was given and the DEST
PORT(S) list contained a service name containing a hyphen ("-") then
an ERROR was generated.
Example -- Rules file:
DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125
Results in:
ERROR: Invalid port range (ms:wbt:server) : rules (line 49)
Problem was introduced in Shorewall 4.0.5 and does not occur in
earlier releases.
2) If a long destination port list needed to be broken at a port pair,
the generated rule contained an extra comma which resulted in an
iptables-restore failure.
3) Several problems involving port ranges and port lists in REDIRECT
rules have been corrected.
4) Shorewall-perl no longer requires an address in the GATEWAY column
of /etc/shorewall/tunnels. If the column is left empty (or contains
'-') then 0.0.0.0/0 is assumed.
5) Previously with Shorewall-perl, redirecting both STDOUT and STDERR
to the same file descriptor resulted in scrambled output between
the two. The error messages were often in the middle of the
regular output far ahead of the point where the error occurred.
This problem was possible in the Debian Shorewall init script
(/etc/init.d/shorewall) which redirects output to the
Debian-specific /var/log/shorewall-init.log file in this way:
$SRWL $SRWL_OPTS start >> $INITLOG 2>&1 && ...
6) With both compilers, when HIGH_ROUTE_MARKS=Yes, unpredictable
results could occur when marking in the PREROUTING or OUTPUT
chains. When a rule specified a mark value > 255, the compilers
were using the '--or-mark' operator rather than the '--set-mark'
operator. Consequently, when a packet matched more than one
rule, the resulting routing mark was the logical product of the
mark values in the matching rules rather than the mark value from
the last matching rule.
Example:
0x100 192.168.1.44 0.0.0.0/0
0x200 0.0.0.0/0 0.0.0.0/0 tcp 25
A TCP packet from 192.168.1.44 with destination port 25 would have
a mark value of 0x300 rather than the expected value of 0x200.
7) Previously, a 'start -f' on Shorewall Lite would produce the
following distressing output before starting the firewall:
make: *** No rule to make target `/firewall', needed by
`/var/lib/shorewall-lite/restore'. Stop.
Furthermore, the Makefile for both Shorewall and Shorewall Lite
failed to take into account the /etc/shorewall/vardir file.
This has been corrected. As part of the fix, both /sbin/shorewall
and /sbin/shorewall-lite support a "show vardir" command that
displays the VARDIR setting.
8) Shorewall-perl was previously ignoring the USER/GROUP column of the
tcrules file.
9) Supplying the name of a built-in chain in the 'refresh' command
caused entries in the chain to be duplicated. Since this is a
feature of iptables-restore with the '-n' option, built-in chains
in the 'refresh' list will now be rejected.
Known Problems Remaining.
1) The 'refresh' command doesn't refresh the mangle table. So changes
made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
not be reflected in the running ruleset.
Other changes in Shorewall 4.0.6.
1) Shorewall-perl now uses the '--physdev-is-bridged' option when it
is available. This option will suppress messages like the following:
kernel: physdev match: using --physdev-out in the OUTPUT, FORWARD and
POSTROUTING chains for non-bridged traffic is not supported
anymore.
This change only affects users who use bport/bport4 zones in a
briged configuration and requires that capabilities files be
regenerated using Shorewall-common or Shorewall-lite 4.0.6.
2) Shorewall-perl now allows you to embed Shell or Perl scripts in
all configuration files except /etc/shorewall/params and
/etc/shorewall/shorewall.conf (As always, you can continue to
include arbitrary shell code in /etc/shorewall/params).
To embed a one-line script, use one of the following:
SHELL <shell script>
PERL <perl script>
For multi-line scripts, use:
BEGIN SHELL
<shell script>
END SHELL
BEGIN PERL
<perl script>
END PERL
For SHELL scripts, the output from the script is processed as if it
were part of the file.
Example 1 (Shell): To generate SMTP/ACCEPT rules from zones a b c d
and e to the firewall:
Either:
BEGIN SHELL
for z in a b c d e; do
echo SMTP/ACCEPT $z fw tcp 25
done
END SHELL
or
SHELL for z in a b c d e; do echo SMTP/ACCEPT $z fw tcp 25; done
Either is equivalent to:
SMTP/ACCEPT a fw tcp 25
SMTP/ACCEPT b fw tcp 25
SMTP/ACCEPT c fw tcp 25
SMTP/ACCEPT d fw tcp 25
SMTP/ACCEPT e fw tcp 25
With a Perl script, if you want to output text to be processed as
if it were part of the file, then pass the text to the shorewall()
function.
Example 2 (Perl): To generate SMTP/ACCEPT rules from zones a b c d
and e to the firewall:
BEGIN PERL
for ( qw/a b c d e/ ) {
shorewall "SMTP/ACCEPT $_ fw tcp 25";
}
END PERL
PERL scripts have access to any context accumulated in earlier PERL
scripts. All such embedded Perl, as well as conventional Perl
extension scripts are placed in the Shorewall::User package. That
way, your global variables and functions won't conflict with any of
Shorewall's.
To allow you to load Perl modules and initialize any global state,
a new 'compile' compile-time extension script has been added. It is
called early in the compilation process.
For additional information, see
- http://www.shorewall.net/configuration_file_basics.html#Embedded
3) To complement Embedded Perl scripts, Shorewall 4.0.6 allows Perl
scripts to create filter chains using
Shorewall::Chains::new_manual_chain() and then use the chain as a
target in subsequent entries in /etc/shorewall/rules.
See http://www.shorewall.net/ManualChains.html for information.
4) The 'hits' command now accepts a -t option which limits the report
to those log records generated today.
5) A DONT_LOAD option has been added to shorewall.conf. If there are
kernel modules that you don't wish to have loaded, you can list
them in this entry as a comma-separated list.
Example:
DONT_LOAD=nf_conntrack_sip,nf_nat_sip
6) Shorewall-perl now supports the --random option of the iptables
SNAT, MASQUERADE, DNAT and REDIRECT targets. Please note that
iptables support for this option is currently broken for the DNAT
and REDIRECT targets; I've sent a patch to the Netfilter team.
For MASQUERADE, simply place the word 'random' in the ADDRESS
column. This causes Netfilter to randomize the source port seen by
the remote host.
Example:
#INTERFACE SOURCE ADDRESS
eth0 eth1 random
For SNAT, follow the port list by ":random".
Example:
#INTERFACE SOURCE ADDRESS
eth0 eth1 206.124.146.179:10000-10999:random
For DNAT, follow the port list by ":random".
Example:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
DNAT net loc:192.168.1.4:40-50:random tcp 22
For REDIRECT, you must use the fully-qualified form of the DEST:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
REDIRECT net $FW::40-50:random tcp 22
Note that ':random' is only effective with SNAT, DNAT and REDIRECT
when a port range is specified in the ADDRESS/DEST column. It is
ignored by iptables/iptables-restore otherwise.
2007-10-22 Shorewall 4.0.5
Problems corrected in Shorewall 4.0.5.
1) Previously, Shorewall-perl misprocessed $FW::<port> in the DEST
column of a REDIRECT rule, generating an error. '$FW::<port>' now
produces the same effect as '<port>'.
2) If the PROTOCOL (PROTO) column contained 'TCP' or 'UDP' and SOURCE
PORT(S) or DEST PORT(S) were given, then Shorewall-perl rejected
the entry with the error:
ERROR: SOURCE/DEST PORT(S) not allowed with PROTO TCP : /etc/shorewall/rules
The rule was accepted if 'tcp' or 'udp' was used instead.
3) Shorewall-shell now removes any default bindings of ipsets before
attempting to reload them. Previously, default bindings were not
removed with the result that the ipsets could not be destroyed.
Other changes in Shorewall 4.0.5.
1) Two new options have been added to /etc/shorewall/hosts
(Shorewall-perl only).
broadcast: Permits limited broadcast (destination 255.255.255.255)
to the zone.
destonly: Normally used with the Multi-cast range. Specifies that
traffic will be sent to the specified net(s) but that
no traffic will be received from the net(s).
Example:
wifi eth1:192.168.3.0/24 broadcast
wifi eth1:224.0.0.0/4 destonly
In that example, limited broadcasts from the firewall with a source
IP in the 192.168.3.0/24 range will be acccepted as will multicasts
(with any source address).
2) A MULTICAST option has been added to shorewall.conf. This option
will normally be set to 'No' (the default). It should be set to
'Yes' under the following circumstances:
a) You have an interface that has parallel zones defined via
/etc/shorewall/hosts.
b) You want to forward multicast packets to two or more of those
parallel zones.
In such cases, you will configure a 'destonly' network on each
zone receiving multicasts.
The MULTICAST option is only recognized by Shorewall-perl and is
ignored by Shorewall-shell.
3) As announced in the Shorewall 4.0.4 release notes, Shorewall-perl
no longer supports the 'detectnets' option. Specifying that option
now results in the following message:
WARNING: Support for the 'detectnets' option has been removed
It is suggested that 'detectnets' be replaced by
'routefilter,logmartians'. That will produce the same filtering
effect as 'detectnets' while eliminating 1-2 rules per connection.
One user has asked how to retain the output of 'shorewall show
zones' if the 'detectnets' option is removed. While I don't advise
doing so, you can reproduce the current 'shorewall show' behavior
as follows.
Suppose that you have a zone named 'wifi' that produces the
following output with 'detectnets':
wifi (ipv4)
eth1:192.168.3.0/24
You can reproduce this behavior as follows:
/etc/shorewall/interfaces:
- eth1 detect ...
/etc/shorewall/hosts:
wifi eth1:192.168.3.0/24 broadcast
If you send multicast to the 'wifi' zone, you also need this entry
in your hosts file:
wifi eth1:224.0.0.0/4 destonly
4) (Shorewall-perl only) The server port in a DNAT or REDIRECT rule
may now be specified as a service name from
/etc/services. Additionally:
a) A port-range may be specified as the service port expressed in
the format <low port>-<high port>. Connections are assigned to
server ports in round-robin fashion.
b) The compiler only permits a server port to be specified if the
protocol is tcp or udp.
c) The compiler ensures that the server IP address is valid (note
that it is still not permitted to specify the server address as a
DNS name).
5) (Shorewall-perl only) Users are complaining that when they migrate
to Shorewall-perl, they have to restrict their port lists to 15
ports. In this release, we relax that restriction on destination
port lists. Since the SOURCE PORT(s) column in the configuration
files is rarely used, we have no plans to relax the restriction in
that column.
6) There have been several cases where iptables-restore has failed
while executing a COMMIT command in the .iptables_restore_input
file. This gives neither the user nor Shorewall support much to go
on when analyzing the problem. As a new debugging aid, the meaning
of 'trace' and 'debug' have been changed.
Traditionally, /sbin/shorewall and /sbin/shorewall-lite have
allowed either 'trace' or 'debug' as the first run-line
parameter. Prior to 4.0.5, the two words produced the same effect.
Beginning with Shorewall 4.0.5, the two words have different
effects when Shorewall-perl is used.
trace - Like the previous behavior.
In the Shorewall-perl compiler, generate a stack trace
on WARNING and ERROR messages.
In the generated script, sets the shell's -x option to
trace execution of the script.
debug - Ignored by the Shorewall-perl compiler.
In the generated script, causes the commands in
.iptables_restore_input to be executed as discrete iptables
commands. The failing command can thus be identified and a
diagnosis of the cause can be made.
Users of Shorewall-lite will see the following change when using a
script that was compiled with Shorewall-perl 4.0.5 or later.
trace - In the generated script, sets the shell's -x option to
trace execution of the script.
debug - In the generated script, causes the commands in
.iptables_restore_input to be executed as discrete iptables
commands. The failing command can thus be identified and a
diagnosis of the cause can be made.
In all other cases, 'debug' and 'trace' remain synonymous. In
particular, users of Shorewall-shell will see no change in
behavior.
WARNING: The 'debug' feature in Shorewall-perl is strictly for
problem analysis. When 'debug' is used:
a) The firewall is made 'wide open' before the rules are applied.
b) The routestopped file is not consulted and the rules are applied
in the canonical iptables-restore order (ASCIIbetical by chain).
So if you need critical hosts to be always available during
start/restart, you may not be able to use 'debug'.
7) /usr/share/shorewall-perl/buildports.pl,
/usr/share/shorewall-perl/FallbackPorts.pm and
/usr/share/shorewall-perl/Shorewall/Ports.pm have been removed.
Shorewall now resolves protocol and port names as using Perl's
interface to the the standard C library APIs getprotobyname() and
getservbyname().
Note 1:
The protocol names 'tcp', 'TCP', 'udp', 'UDP', 'all', 'ALL',
'icmp' and 'ICMP' are still resolved by Shorewall-perl
itself.
Note 2:
Those of you running Shorewall-perl under Cygwin may wish to
install "real" /etc/protocols and /etc/services files
in place of the symbolic links installed by Cygwin.
8) The contents of the Shorewall::*::$VERSION variables are now a
only of interest for Perl programs that are using the modules and
specifying a minimum version (e.g., "use Shorewall::Config
4.0.5;"). Each module continues to carry a separate version which
indicates the release of Shorewall-perl when the module was last
modified
2007-10-02 Shorewall 3.4.7
Problems Corrected in Shorewall 3.4.7
1) A bug prevented proper handling of PREROUTING marks when
HIGH_ROUTE_MARKS=No and the track option was specified in
/etc/shorewall/providers.
2) Previously, if the following sequence of routing rules was
specified, then the first rule would always be omitted.
#SOURCE DEST PROVIDER PRIORITY
$SRC_A $DESTIP1 ISP1 1000
$SRC_A $DESTIP2 SOMEISP 1000
$SRC_A - ISP2 1000
The reason for this omission was that Shorewall uses a
delete-before-add approach and attempting to delete the third rule
resulted in the deletion of the first one instead.
This problem occurred with both compilers.
3) When using Shorewall-shell, provider numbers were not recognized in
the PROVIDER column of /etc/shorewall/route_rules.
2007-09-28 Shorewall 4.0.4
Problems Corrected in Shorewall 4.0.4
1) If no interface had the 'blacklist' option, then when using
Shorewall-perl, the 'start' and 'restart' command failed:
ERROR: No filter chain found with name blacklst
New Shorewall-perl 4.0.3 packages were released that corrected this
problem; it is included here for completeness.
2) If no interface had the 'blacklist' option, then when using
Shorewall-perl, the generated script would issue this harmless
message during 'shorewall refresh':
chainlist_reload: Not found
3) If /bin/sh was a light-weight shell such as ash or dash, then
'shorewall refresh' failed.
4) During start/restart, the script generated by Shorewall-perl was
clearing the proxy_arp flag on all interfaces; that is not the
documented behavior.
5) If the module-init-tools package was not installed and
/etc/shorewall/modules did not exist or was non-empty, then
Shorewall-perl would fail with the message:
ERROR: Can't run lsmod : /etc/shorewall/modules (line 0)
6) Shorewall-perl now makes a compile-time check to insure that
iptables-restore exists and is executable. This check is made when
the compiler is being run by root and the -e option is not
given.
Note that iptables-restore must reside in the same directory as the
iptables executable specified by IPTABLES in shorewall.conf or
located by the PATH in the event that IPTABLES is not specified.
7) When using Shorewall-perl, if an action was invoked with more than
10 different combinations of log-levels/tags, some of those
invocations would have incorrect logging.
8) Previously, when 'shorewall restore' was executed, the
iptables-restore utility was always located using the PATH setting
rather than the IPTABLES setting.
With Shorewall-perl, the IPTABLES setting is now used to locate
this utility during 'restore' as it is during the processing of
other commands.
9) Although the shorewall.conf manpage indicates that the value
'internal' is allowed for TC_ENABLED, that value was previously
rejected ('Internal' was accepted).
10) The meaning of the 'loose' provider option was accidentally reversed
in Shorewall-perl. Rather than causing certain routing rules to be
omitted when specified, it actually caused them to be added (these
rules were omitted when the option was NOT specified).
11) If the 'bridge' option was specified on an interface but there were
no bport zones, then traffic originating on the firewall was not
passed through the accounting chain.
12) In commands such as:
shorewall compile <directory>
shorewall restart <directory>
shorewall check <directory>
if the name of the <directory> contained a period ("."), then
Shorewall-perl would incorrectly substitute the current working
directory for the name.
13) Previously, if the following sequence of routing rules was
specified, then the first rule would always be omitted.
#SOURCE DEST PROVIDER PRIORITY
$SRC_A $DESTIP1 ISP1 1000
$SRC_A $DESTIP2 SOMEISP 1000
$SRC_A - ISP2 1000
The reason for this omission was that Shorewall uses a
delete-before-add approach and attempting to delete the third rule
resulted in the deletion of the first one instead.
This problem occurred with both compilers.
14) When using Shorewall-shell, provider numbers were not recognized in
the PROVIDER column of /etc/shorewall/route_rules.
15) An off-by-one problem in Shorewall-perl caused the value 255 to be
rejected in the MARK column of /etc/shorewall/tcclasses.
16) When HIGH_ROUTE_MARKS=Yes, marks with values > 255 must be a
multiple of 256. That restriction was being enforced by
Shorewall-shell but not by Shorewall-perl. Shorewall-perl now also
enforces this restriction.
17) Using REDIRECT with a parameterized macro (e.g., DNS/REDIRECT)
failed with an "Unknown interface" error when using Shorewall-perl.
Other Changes in Shorewall 4.0.4
1) The detection of 'Repeat Match' has been improved. 'Repeat Match'
is not a match at all but rather is a feature of recent versions of
iptables that allows a particular match to be used multiple times
within a single rule.
Example:
-A foo -m physdev --physdev-in eth0 -m physdev --physdev-out ...
When using Shorewall-shell, the availability of 'Repeat Match' can
speed up compilation very slightly.
2) Apparently recent Fedora releases are broken. The
following sequence of commands demonstrates the problem:
ip rule add from 1.1.1.1 to 10.0.0.0/8 priority 1000 table 5
ip rule add from 1.1.1.1 to 0.0.0.0/0 priority 1000 table main
ip rule del from 1.1.1.1 to 0.0.0.0/0 priority 1000
The third command should fail but doesn't; instead, it incorrectly
removes the rule added by the first command.
To work around this issue, you can set DELETE_THEN_ADD=No in
shorewall.conf which prevents Shorewall from deleting ip rules
before attempting to add a similar rule.
3) When using Shorewall-perl, the following message is now issued if
the 'detectnets' option is specified in /etc/shorewall/interfaces:
WARNING: Support for the 'detectnets' option will be removed from
Shorewall-perl in version 4.0.5; better to use 'routefilter' and
'logmartians
The 'detect' options has always been rather silly. On input, it
duplicates the function of 'routefilter'. On output, it is a no-op
since traffic that doesn't match a route out of an interface won't
be sent through that interface (duh!).
Beginning with Shorewall 4.0.5, the warning message will read:
WARNING: Support for the 'detectnets' option has been removed
2007-09-01 Shorewall 4.0.3
Problems Corrected in 4.0.3
1) Using the LOG target in the rules file could result in two LOG
rules being generated by Shorewall-shell. Additionally, using an IP
address range in a rule that performed logging could result in an
invalid iptables command.
2) Shorewall now loads the act_police kernel module needed by traffic
shaping.
3) Previously, "shorewall show -f capabilities" and "shorecap" omitted
the "TCPMSS Match" capability. This made it appear to a compiler
using a capabilities file that the TCPMSS Match capability was not
available.
4) Previously, Shorewall would truncate long log prefixes to 29
characters. This resulted in there being no space between the log
prefix and the IN= part of the message.
Example: fw2net:LOG:HTTPSoutIN= OUT=eth0
Beginning with this release, Shorewall will truncate the prefix to
28 bytes and add a trailing space.
Example: fw2net:LOG:HTTPSou IN= OUT=eth0
5) Previously, if:
- FASTACCEPT=No
- The policy from Z1 to Z2 was CONTINUE
- Neither Z1 nor Z2 had parent zones
- There were no Z1->Z2 rules
then connections from Z2->Z1 would fail even if there were
rules/policies allowing them. This has been
corrected.
6) The 'shorewall add' and 'shorewall delete' command would fail when:
- The running configuration was compiled with Shorewall-perl.
- The name of the interface specified in the command contained an
embedded special character such as '.' or '-'.
This problem was the result of the change in Shorewall 4.0.2 that
removed the legacy mapping of interface names when embedding such
names in a Netfilter chain name. To correct the problem, the
pre-4.0.2 name mapping is restored when DYNAMIC_ZONES=Yes.
5) A bug in Shorewall-shell prevented proper handling of PREROUTING
marks when HIGH_ROUTE_MARKS=No and the track option was specified
in /etc/shorewall/providers.
6) With Shorewall-perl, if EXPORTPARAMS=Yes then INCLUDE directives in
the params file would fail at script execution time with "INCLUDE:
not found". This has been corrected.
7) Shorewall-perl was mis-sorting the zone list when zones were nested
more than one deep.
8) Stale references to http://www.shorewall.net/Documentation.htm have
been removed from the config files (including samples). That URL
has been replaced by the online manpages.
Other Changes in 4.0.3
1) A script generated by Shorewall-perl now tries to modify/restore
/etc/iproute2/rt_tables only if the file is writable. This prevents
run-time errors when /etc is mounted read-only.
A new KEEP_RT_TABLES option has been added to shorewall.conf. When
set to Yes, this option prevents Shorewall from altering the
/etc/iproute2/rt_tables database. The KEEP_RT_TABLES option is only
recognized by Shorewall-perl and is ignored by Shorewall-shell.
2) Shorewall-perl now requires the FindBin Perl module.
3) When an optional provider is not available, a script generated by
Shorewall-perl will no longer add the corresponding
routing rules.
4) A new 'isusable' extension script has been added. This script
allows you to extend the availability test that Shorewall performs
on optional providers.
Here's an example that uses ping to ensure that the default
gateways through eth0 and eth1 are reachable:
case $1 in
eth0)
ping -c 4 -I eth0 206.124.146.254 > /dev/null 2>&1
return
;;
eth1)
ping -c 4 -I eth1 192.168.12.254 > /dev/null 2>&1
return
;;
*)
# Assume we don't need to do any additional testing
# for this interface beyond Shorewall's
return 0
;;
esac
Additional information is available at
http://www.shorewall.net/shorewall_extension_scripts.htm.
5) Processing of the message log in the 'show log', 'logwatch' and
'dump' commands has been speeded up thanks to a suggestion by
Andrew Suffield.
6) Beginning with Shorewall 4.0, the shorewall 'stop', and 'clear'
commands were processed by the generated script from the
last successful 'start', 'restart' or 'refresh' command. This had
the side effect that updates to the /etc/shorewall/routestopped
file did not take effect until one of those three commands was
successfully processed.
Beginning with Shorewall 4.0.3, the old 3.x behavior is restored as
the default and the 4.0 behavior is enabled using the '-f' command
option.
Example: shorewall stop -f
is only recognized by Shorewall-perl and causes Shorewall to set
the MSS field in forwarded TCP SYN packets going in or out the
interface to the value that you specify.
Example:
#ZONE INTERFACE BROADCAST OPTIONS
vpn ppp0 - mss=1400
The mss option only affects incoming traffic that has not been
decrypted by IPSEC and outgoing traffic that will not subsequently
be encrypted by IPSEC. The MSS for IPSEC traffic is managed by the
'mss' option in /etc/shorewall/zones.
8) Shorewall now detects the presence of the 'hashlimit match'
capability. There is no builtin support yet for hashlimit but
detection allows extension scripts for user-supplied actions to
determine if the capability exists.
With Shorewall-shell, $HASHLIMIT_MATCH will be non-empty if the
capability exists.
With Shorewall-perl, $capabilities{HASHLIMIT_MATCH} will be true in
a boolean context if the capability exists. Shorewall-perl users
may also code the following in their extension script:
use Shorewall::Config;
require_capability( 'HASHLIMIT_MATCH', #Capability
'My hashlimit action' , #Feature requiring
#capability
's' ); #Feature is singular
#(if plural, pass the
empty string)
That call would procduce the following fatal error if the
capability isn't available:
ERROR: My hashlimit action requires the Hashlimit match capability
in your kernel and iptables
9) NFQUEUE support has been added to Shorewall-perl.
NFQUEUE may appear in actions, macros, rules and as a policy.
When NFQUEUE is used by itself, queue number zero is assumed. To
specify a queue number, follow NFQUEUE by a slash ("/") and the
queue number.
Examples (/etc/shorewall/rules):
NFQUEUE loc net tcp #Queue number 0
NFQUEUE/22 loc net udp #Queue number 22
NFQUEUE/22:info loc net gre #With logging
An NFQUEUE_DEFAULT option has been added to shorewall.conf for
specifying the default action to use with NFQUEUE policies.
Use of NFQUEUE requires the NFQUEUE Target capability in your
kernel/iptables. If you intend to use NFQUEUE with Shorewall-lite,
then you must install Shorewall-lite 4.0.3 in order to build a
capabilities file that includes NFQUEUE Target. If your
capabilities file was generated by a Shorewall/Shorewall-lite
version earlier that 4.0.3, you will receive a warning during
compilation.
10) The 'refresh' command can now refresh chains other than 'blacklst'.
The syntax of the command is now:
shorewall refresh [ <chain> ... ]
If no <chain> is given then 'blacklst' is assumed. Otherwise, the
Shorewall-perl compiler compiles a script whose 'refresh' command
refreshes the listed <chain>(s).
The listed chains are assumed to be in the filter table. You can
refresh chains in other tables by prefixing the chain name with the
table name followed by ":" (e.g., nat:net_dnat). Chain names which
follow are assumed to be in that table until the end of the list or
until an entry in the list names another table.
This feature requires Shorewall-perl 4.0.3 as well as
Shorewall-common 4.0.3.
2007-08-19 Shorewall 3.4.6
Problems Corrected in 3.4.6.
1) If the "Mangle FORWARD Chain" capability was supported, entries in
the /etc/shorewall/ecn file would cause invalid iptables
commands to be generated.
2) Certain errors occurring during
start/restart/safe-start/safe-restart/try processing could cause
the lockfile to be left behind. This resulted in a 60-second delay
the next time one of these commands was run.
3) It was not previously possible to define traffic shaping on a
bridge port; the generated script complained that the
interface was not up and configured.
4) Previously, using a port list in the DEST PORT(S) column of the
rules file or in an action file caused an invalid iptables command
to be generated.
5) Using the LOG target in the rules file could result in two LOG
rules being generated. Additionally, using an IP address range in a
rule that performed logging could result in an invalid iptables
command.
6) Shorewall now loads the act_police kernel module needed by traffic
shaping.
7) Previously, "shorewall show -f capabilities" and "shorecap" omitted
the "TCPMSS Match" capability. This made it appear to a compiler
using a capabilities file that the TCPMSS Match capability was not
available.
8) Previously, Shorewall would truncate long log prefixes to 29
characters. This resulted in there being no space between the log
prefix and the IN= part of the message.
Example: fw2net:LOG:HTTPSoutIN= OUT=eth0
Beginning with this release, Shorewall will truncate the prefix to
28 bytes and add a trailing space.
Example: fw2net:LOG:HTTPSou IN= OUT=eth0
9) Previously, if:
- FASTACCEPT=No
- The policy from Z1 to Z2 was CONTINUE
- Z1 and Z2 were orphans (neither had parent zones)
- There were no Z1->Z2 rules
then connections from Z2->Z1 would fail even if there were
rules/policies allowing them. This has been
corrected.
Other changes in 3.4.6.
1) Processing of the message log in the 'show log', 'logwatch' and
'dump' commands has been speeded up thanks to a suggestion by
Andrew Suffield.
2007-08-10 Shorewall 4.0.2
Problems corrected in 4.0.2
1) The Shorewall-perl compiler was still generating invalid
iptables-restore input from entries in /etc/shorewall/ecn.
2) When using Shorewall-perl, unless an interface was specified as
'optional' in the interfaces file, the 'restore' command would
fail if the routes through the interface or the addresses on the
interface could not be detected.
Route detection occurs when the interface is named in the SOURCE
column of the masq file. Address detection occurs when
DETECT_DNAT_IPADDRS=Yes and the interface is the SOURCE for a DNAT
or REDIRECT rule or when 'maclist' is specified for the interface.
Since the 'restore' command doesn't use the detected information,
detection is now skipped if the command is 'restore'.
3) It was not previously possible to define traffic shaping on a
bridge port; the generated script complained that the
interface was not up and configured.
4) When Shorewall-shell was not installed, certain options in
/etc/shorewall/interfaces and /etc/shorewall/hosts would cause the
'add' and 'delete' commands to fail with a missing library error.
OPTION FILE
maclist interfaces,hosts
proxyarp interfaces
5) The /var/lib/shorewall/zones file was being overwritten during
processing of the 'refresh' command by a script generated with
Shorewall-perl. The result was that hosts previously added to
dynamic zones could not be deleted after the 'refresh'.
6) If the file named as the output file in a Shorewall-perl 'compile'
command was a symbolic link, the generated error message
erroneously stated that the file's parent directory was a symbolic
link.
As part of this change, cosmetic changes were made to a number of
other error messages.
7) Some intra-zone rules were missing when a zone involved multiple
interfaces or when a zone included both IPSEC and non-IPSEC
networks.
8) Shorewall was not previously loading the xt_multiport kernel
module.
9) The Russian and French translations no longer have English headings
on notes, cautions, etc..
10) Previously, using a port list in the DEST PORT(S) column of the
rules file or in an action file could cause an invalid iptables
command to be generated by Shorewall-shell.
11) If there were no bridges in a configuration, Shorewall-perl would
ignore the CHAIN column in /etc/shorewall/accounting.
Other changes in 4.0.2
1) Shorewall-perl now detects when a port range is included in a list
of ports and iptables/kernel support for Extended Multi-port Match
is not available. This avoids an iptables-restore failure at
run-time.
2) Most chains created by Shorewall-shell have names that can be
embedded within shell variable names. This is a workaround for
limitations in the shell programming language which has no
equivalent to Perl hashes. Often chain names must have the name of
a network interface encoded in them. Given that interface names can
contain characters that are invalid in a shell variable name,
Shorewall-shell performs a name mapping which was carried forward to
Shorewall-perl:
- Trailing '+' is dropped.
- The characters ".", "-", "%' and "@" are translated to "_".
This mapping has been elminated in the 4.0.2 release of Shorewall-
perl. So where before you would see chain "eth0_0_in", you may now
see the same chain named "eth0.0_in". Similarly, a chain previously
named "ppp_fwd" may now be called "ppp+_fwd".
3) Shorewall-perl now uses the contents of the BROADCAST column in
/etc/shorewall/interfaces when the Address Type match capability is
not available.
2007-07-30 Shorewall 4.0.1
Problems corrected in 4.0.1.
1) The Shorewall Lite installer was producing an empty shorewall-lite
manpage. Since the installer runs as part of creating the RPM, the
RPM also suffered from this problem. The 4.0.0 Shorewall-lite
packages were re-uploaded with this problem corrected.
2) The Shorewall Lite uninstaller incorrectly removed /sbin/shorewall
rather than /sbin/shorewall-lite.
3) Both the Shorewall and Shorewall Lite uninstallers did a "shorewall
clear" if Shorewall [Lite] was running. Now, the Shorewall Lite
uninstaller correctly does "shorewall-lite clear" and both
uninstallers only perform the 'clear' operation if the other
product is not installed. This prevents the removal of one of the
two products from clearing the firewall configuration established
by the other one.
4) The 'ipsec' OPTION in /etc/shorewall/hosts was mis-handled by
Shorewall-perl. If the zone type was changed to 'ipsec' or
'ipsec4' and the 'ipsec' option removed from the hosts file entry,
the configuration worked properly.
5) If a CLASSID was specified in a tcrule and TC_ENABLED=No, then
Shorewall-perl produced the following:
Compiling...
Use of uninitialized value in string ne at /usr/share/shorewall-perl/Shorewall/Tc.pm line 285, <$currentfile> line 18.
ERROR: Class Id n:m is not associated with device eth0 : /etc/shorewall/tcrules (line 18)
6) If IPTABLES was not specified in shorewall.conf, Shorewall-perl was
locating the binary using the PATH environmental variable rather
than the PATH setting in shorewall.conf. If no PATH was available
when Shorewall-perl was run and IPTABLES was not set in
shorewall.conf, the following messages were issued:
Use of uninitialized value in split at /usr/share/shorewall-perl/Shorewall/Config.pm line 1054.
ERROR: Can't find iptables executable
ERROR: Shorewall restart failed
7) If the "Mangle FORWARD Chain" capability was supported, entries in
the /etc/shorewall/ecn file would cause invalid iptables commands
to be generated. This problem occurred with both compilers.
8) Shorewall now starts at reboot after an upgrade from shorewall <
4.0.0. Previously, Shorewall was not started automatically at
reboot after an upgrade using the RPMs.
9) Shorewall-perl was generating invalid iptables-restore input when a
log level was specified with the dropBcast and allowBcast builtin
actions and when a log level followed by '!' was used with any
builtin actions.
10) Shorewall-perl was incorrectly rejecting 'min' as a valid unit of
time in rate-limiting specifications.
11) Certain errors occurring during
start/restart/safe-start/safe-restart/try processing could cause
the lockfile to be left behind. This resulted in a 60-second delay
the next time one of these commands was run.
Other changes in Shorewall 4.0.1.
1) A new EXPAND_POLICIES option is added to shorewall.conf. The
option is recognized by Shorewall-perl and is ignored by
Shorewall-shell.
Normally, when the SOURCE or DEST columns in shorewall-policy(5)
contains 'all', a single policy chain is created and the policy is
enforced in that chain. For example, if the policy entry is
#SOURCE DEST POLICY LOG
# LEVEL
net all DROP info
then the chain name is 'net2all' which is also the chain named in
Shorewall log messages generated as a result of the policy. If
EXPAND_POLICIES=Yes, then Shorewall-perl will create a separate
chain for each pair of zones covered by the policy. This makes the
resulting log messages easier to interpret since the chain in the
messages will have a name of the form 'a2b' where 'a' is the SOURCE
zone and 'b' is the DEST zone. See
http://linuxman.wikispaces.com/PPPPPPS for more information.
2) The Shorewall-perl dependency on the "Address Type Match"
capability has been relaxed. This allows Shorewall 4.0.1 to be used
on releases like RHEL4 that don't support that capability.
3) Shorewall-perl now detects dead policy file entries that result
when an entry is masked by an earlier entry. Example:
all all REJECT info
loc net ACCEPT
4) Recent kernels are apparently hard to configure and we have been
seeing a lot of problem reports where the root cause is the lack of
state match support in the kernel. This problem is difficult to
diagnose when using Shorewall-perl so the generated shell program
now checks specifically for this problem and terminates with an
error if the capability doesn't exist.
2007-07-20 Shorewall 4.0.0
----------------------------------------------------------------------------
R E L E A S E H I G H L I G H T S
----------------------------------------------------------------------------
1) This is the first Shorewall release that fully integrates the new
Shorewall-perl compiler. See the "New Features" section below.
2) You are now offered a choice as to which compiler(s) you install. In
4.0.0, there are the following packages:
- Shorewall-common ( common files )
- Shorewall-shell ( the shell-based compiler )
- Shorewall-perl (the Perl-based compiler )
You must install at least one of the compiler packages (you may
install them both) along with Shorewall-common.
YOU DO NOT NEED TO UNINSTALL ANY OF YOUR CURRENT PACKAGES.
See the Migration Considerations below for further information.
3) The facilities for supporting bridge/firewalls under earlier
releases are deprecated and their documentation is omitted from the
4.0 distribution. New bridge support is implemented in the
Shorewall-perl compiler. This support utilizes the reduced-function
physdev match support available in Linux kernel 2.6.20 and later.
Problems corrected in 4.0.0 Final.
1) The shorewall-lite install.sh may now be run multiple times from
the same directory. Previously, the manpages were gzipped in-place
which made it impossible to rerun the script.
2) If shorewall.conf contained SHOREWALL_COMPILER=shell (which it can
on Shorewall 3.4.2-4 systems) and the shorewall-shell RPM was
removed, subsequent "shorewall [re]start" operations failed. When
shorewall-shell is removed, the shorewall.conf file is modified to
specify SHOREWALL_COMPILER= and the original is saved in
shorewall.conf.rpmsave.
3) The contents of the LOG LEVEL column in /etc/shorewall/policy are
now validated at compile time by Shorewall-perl.
Other changes in Shorewall 4.0.0 Final.
1) The Perl modules in /usr/share/shorewall-perl/Shorewall/ have been
consolidated somewhat, leading to slightly faster compilation.
Migration Considerations:
1) Beginning with Shorewall 4.0.0, there is no single 'shorewall'
package. Rather there are two compiler packages (shorewall-shell
and shorewall-perl) and a set of base files (shorewall-common)
which are required by either compiler package.
Although the names of the packages are changing, you can upgrade
without having to uninstall/reinstall.
To repeat: YOU DO NOT NEED TO UNINSTALL ANY EXISTING PACKAGE.
If you attempt to upgrade using the shorewall-common RPM, you get
this result:
gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm
error: Failed dependencies:
shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch
gateway:~ #
You must either:
rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \
shorewall-common-4.0.0.noarch.rpm
or
rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \
shorewall-perl-4.0.0.noarch.rpm \
shorewall-common-4.0.0.noarch.rpm
If you don't want to use shorewall-perl exclusively then use the
second command above then
rpm -e shorewall-shell
If you are upgrading using the tarball, you must install
shorewall-shell and/or shorewall-perl before you upgrade
using shorewall-common. Otherwise, the install.sh script fails with:
ERROR: No Shorewall compiler is installed
The shorewall-shell and shorewall-perl packages are installed from
the tarball in the expected way; untar the package, and run the
install.sh script.
Example 1: You have 'shorewall' installed and you want to continue
to use the shorewall-shell compiler.
tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-shell-4.0.0.tar.bz2
cd shorewall-shell-4.0.0
./install.sh
cd ../shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restart
Example 2: You have shorewall 3.4.4 and shorewall-perl 4.0.0-Beta7
installed and you want to upgrade to 4.0. You do not need the
shell-based compiler.
tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-perl-4.0.0.tar.bz2
cd shorewall-perl-4.0.0
./install.sh
cd ../shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restart
Be sure to modify shorewall.conf if it still has
SHOREWALL_COMPILER=shell.
2) The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work
slightly differently in Shorewall 4.0.0. In prior releases, leaving
these options empty was equivalent to setting them to 'No' which
caused the corresponding flag in /proc to be reset for all
interfaces. Beginning in Shorewall 4.0.0, leaving these options
empty causes Shorewall to leave the flags in /proc as they are. You
must set the option to 'No' in order to obtain the old behavior.
3) The -f option is no longer the default when Shorewall is started at
boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
"shorewall start" is nearly as fast as "shorewall restore" and
"shorewall start" uses the current configuration which avoids
confusion.
If you plan on continuing to use Shorewall-shell and you want to
use the "-f" option at boot time, then you must add the following
to /etc/sysconfig/shorewall or /etc/default/shorewall:
OPTIONS="-f"
If you currently have neither of those files, you will need to
create one of them.
4) This issue will only affect you if you use Shorewall Lite and have
modified /usr/share/configpath to specify a different LITEDIR.
The implementation of LITEDIR has always been
unsatisfactory. Furthermore, there have been other cases where
people have asked to be able to designate the state directory
(default /var/lib/shorewall[-lite]).
To meet these objectives:
a) The LITEDIR variable has been eliminated in
/usr/share/shorewall[-lite]/configpath.
b) A new file /etc/shorewall[-lite]/vardir has been added. This
file is not created by default but may be added as needed. It
is expected to contain a single variable assignment:
VARDIR=<directory>
Example:
VARDIR=/root/shorewall
To change VARDIR, copy the old directory to the new one before you
restart Shorewall[-lite].
To use this feature with Shorewall-lite, all packages involved
(compiler, shorewall-common and shorewall-lite) must be version
4.0.0-RC2 or later.
----------------------------------------------------------------------------
N E W F E A T U R E S
----------------------------------------------------------------------------
1) Shorewall-perl
This Shorewall package includes a complete rewrite of the compiler
in Perl.
I decided to make Shorewall-perl a separate package for several reasons:
a) Embedded applications are unlikely to adopt Shorewall-perl; even
Mini-Perl has a substantial disk and RAM footprint.
b) Because of the gross incompatibilities between the new compiler and the
old (see below), migration to the new compiler must be voluntary.
------------------------------------------------------------------------
T H E G O O D N E W S:
------------------------------------------------------------------------
a) The compiler has a small disk footprint.
b) The compiler is very fast.
c) The compiler generates a firewall script that uses iptables-restore;
so the script is very fast.
d) The new compiler does a much better job of validating the
configuration and catches many errors that resulted in run-time
failures with the old compiler.
e) Use of the Shorewall-perl is optional! The old slow clunky
Bourne-shell compiler is still available.
------------------------------------------------------------------------
T H E B A D N E W S:
------------------------------------------------------------------------
There are a number of incompatibilities between the Perl-based compiler
and the Bourne-shell one.
a) The Perl-based compiler requires the following capabilities in your
kernel and iptables.
- addrtype match
- multiport match
These capabilities are in current distributions.
b) Now that Netfilter has features to deal reasonably with port lists,
I see no reason to duplicate those features in Shorewall. The
Bourne-shell compiler goes to great pain (in some cases) to
break very long port lists ( > 15 where port ranges in lists
count as two ports) into individual rules. In the new compiler, I'm
avoiding the ugliness required to do that. The new compiler just
generates an error if your list is too long. It will also produce
an error if you insert a port range into a port list and you don't
have extended multiport support.
c) The old BRIDGING=Yes support has been replaced by new bridge
support that uses the reduced 'physdev match' capabilities found
in kernel 2.6.20 and later. This new implementation may be used
where it is desired to control traffic through a bridge.
The new implementation includes the following features:
a) A new "Bridge Port" zone type is defined. Specify 'bport' or
'bport4' in the TYPE column of /etc/shorewall/zones.
Bridge Port zones should be a sub-zone of a regular ipv4 zone
that represents all hosts attached to the bridge.
b) A new 'bridge' option is defined for entries in
/etc/shorewall/interfaces. Bridges should have this option
specified, even if you don't want to filter traffic going
through the bridge.
c) Bridge ports must now be defined in
/etc/shorewall/interfaces. The INTERFACE column contains
both the bridge name and the port name separated by a colon
(e.g., "br0:eth1"). No OPTIONS are allowed for bridge
ports. The bridge must be defined before its ports and must
have the 'bridge' option.
Bridge Port (BP) zones have a number of limitations:
a) Each BP zone may only be associated with ports on a single
bridge.
b) BP zones may not be associated with interfaces that are not
bridge ports.
c) You may not have policies or rules where the DEST is a BP
zone but the source is not a BP zone. If you need such
rules, you must use the BP zone's parent zone as the DEST
zone.
Example (Bridge br0 with ports eth1 and tap0):
/etc/shorewall/zones:
fw firewall
net ipv4
loc ipv4
lan:loc bport
vpn:loc bport
/etc/shorewall/interfaces:
net eth0 - ...
loc br0 - ...
lan eth1
vpn tap0
When using the /etc/shorewall/hosts file to define a bport4
zone, you specify only the port name:
Example:
/etc/shorewall/zones:
fw firewall
net ipv4
loc ipv4
lan:loc bport
vpn:loc bport
/etc/shorewall/hosts
lan eth1:192.168.2.0/24 ...
The structure of the accounting rules changes slightly when
there are bridges defined in the Shorewall
configuration. Because of the restrictions imposed by Netfilter
in kernel 2.6.21 and later, output accounting rules must be
segregated from forwarding and input rules.
To accomplish this separation, Shorewall-perl creates two
accounting chains:
- accounting - for input and forwarded traffic.
- accountout - for output traffic.
If the CHAIN column contains '-', then:
- If the SOURCE column in a rule includes the name of the
firewall zone (e.g., $FW), then the rule is add only
to the accountout chain.
- Otherwise, if the DEST in the rule is any or all or 0.0.0.0/0,
then the rule is added to both accounting and accountout.
- Otherwise, the rule is added to accounting only.
See http://www.shorewall.net/bridge-Shorewall-perl.html for
additional information about the new bridge support.
d) The BROADCAST column in the interfaces file is essentially unused;
if you enter anything in this column but '-' or 'detect', you will
receive a warning.
e) Because the compiler is written in Perl, some of your extension
scripts from earlier versions will no longer work because
Shorewall-perl runs those extension scripts at compile-time rather
than at run-time.
Compile-time scripts are:
initdone
maclog
All per-chain scripts including those associated with actions.
Compile-time extension scripts are executed using the Perl 'eval
`cat <file>`' mechanism. Be sure that each script returns a
'true' value; otherwise, the compiler will assume that the
script failed and will abort the compilation.
All scripts will need to begin with the following line:
use Shorewall::Chains;
For more complex scripts, you may need to 'use' other Shorewall
Perl modules -- browse /usr/share/shorewall-perl/Shorewall/ to
see what's available.
When a script is invoked, the $chainref scalar variable will hold a
reference to a chain table entry.
$chainref->{name} contains the name of the chain
$chainref->{table} holds the table name
To add a rule to the chain:
add_rule( $chainref, <the rule> );
Where
<the rule> is a scalar argument holding the rule text. Do
not include "-A <chain name>"
Example:
add_rule( $chainref, '-j ACCEPT' );
To insert a rule into the chain:
insert_rule( $chainref, <rulenum>, <the rule> );
The log_rule_limit function works like it does in the shell
compiler with two exceptions:
- You pass the chain reference rather than the name of
the chain.
- The commands are 'add' and 'insert' rather than '-A'
and '-I'.
- There is only a single "pass as-is to iptables"
argument (so you must quote that part).
Example:
log_rule_limit(
'info' ,
$chainref ,
$chainref->{name},
'DROP' ,
'', #Limit
'' , #Log tag
'add', #Command
'-p tcp' #Pass as-is
);
Note that in the 'initdone' script, there is no default chain
($chainref). You can objtain a reference to a standard chain by:
my $chainref = $chain_table{<table>}{<chain name>};
Example:
my $chainref = $chain_table{'filter'}{'INPUT'};
The continue script is eliminated. That script was designed to
allow you to add special rules during [re]start. Shorewall-perl
doesn't need such rules.
See http://www.shorewall.net/shorewall_extension_scripts.htm
for further information about extension scripts under
Shorewall-perl.
f) The 'refresh' command now works like 'restart' with the
following exceptions:
- The refresh command is rejected if Shorewall is not running.
- The refresh command only rebuilds the 'blacklst' chain.
- A directory name may not be specified in the refresh command.
g) The /etc/shorewall/tos file now has zone-independent SOURCE and
DEST columns as do all other files except the rules and policy
files.
The SOURCE column may be one of the following:
[all:]<address>[,...]
[all:]<interface>[:<address>[,...]]
$FW[:<address>[,...]]
The DEST column may be one of the following:
[all:]<address>[,...]
[all:]<interface>[:<address>[,...]]
This is a permanent change. The old zone-based rules have never
worked right and this is a good time to replace them. I've tried
to make the new syntax cover the most common cases without
requiring change to existing files. In particular, it will
handle the tos file released with Shorewall 1.4 and earlier.
h) Shorewall is now out of the ipset load/reload business. With
scripts generated by the Perl-based Compiler, the Netfilter
ruleset is never cleared. That means that there is no
opportunity for Shorewall to load/reload your ipsets since that
cannot be done while there are any current rules using ipsets.
So:
i) Your ipsets must be loaded before Shorewall starts. You
are free to try to do that with the following code in
/etc/shorewall/start:
if [ "$COMMAND" = start ]; then
ipset -U :all: :all:
ipset -F
ipset -X
ipset -R < /my/ipset/contents
fi
The file '/my/ipset/contents' (not its real name of
course) will normally be produced using the ipset -S
command.
The above will work most of the time but will fail in a
'shorewall stop' - 'shorewall start' sequence if you
use ipsets in your routestopped file (see below).
ii) Your ipsets may not be reloaded until Shorewall is stopped
or cleared.
iii) If you specify ipsets in your routestopped file then
Shorewall must be cleared in order to reload your ipsets.
As a consequence, scripts generated by the Perl-based compiler
will ignore /etc/shorewall/ipsets and will issue a warning if
you set SAVE_IPSETS=Yes in shorewall.conf.
i) Because the configuration files (with the exception of
/etc/shorewall/params) are now processed by the Perl-based
compiler rather than by the shell, only the basic forms of Shell
expansion ($variable and ${variable}) are supported. The more
exotic forms such as ${variable:=default} are not
supported. Both variables defined in /etc/shorewall/params and
environmental variables (exported by the shell) can be used in
configuration files.
j) USE_ACTIONS=No is not supported. That option is intended to
minimize Shorewall's footprint in embedded applications. As a
consequence, Default Macros are not supported.
k) DELAYBLACKLISTLOAD=Yes is not supported. The entire ruleset is
atomically loaded with one execution of iptables-restore.
l) MAPOLDACTIONS=Yes is not supported. People should have converted
to using macros by now.
m) The pre Shorewall-3.0 format of the zones file is not supported;
neither is the /etc/shorewall/ipsec file.
n) BLACKLISTNEWONLY=No is not permitted with FASTACCEPT=Yes. This
combination doesn't work in previous versions of Shorewall so
the Perl-based compiler simply rejects it.
o) Shorewall-perl has a single rule generator that is used for all
rule-oriented files. So it is important that the syntax is
consistent between files.
With shorewall-shell, there is a special syntax in the SOURCE
column of /etc/shorewall/masq to designate "all traffic entering
the firewall on this interface except...".
Example:
#INTERFACE SOURCE ADDRESSES
eth0 eth1!192.168.4.9 ...
Shorewall-perl uses syntax that is consistent with the rest of
Shorewall:
#INTERFACE SOURCE ADDRESSES
eth0 eth1:!192.168.4.9 ...
p) The 'allowoutUPnP' built-in action is no longer supported. The
Netfilter team have removed support for '-m owner --owner-cmd'
which that action depended on.
q) The treatment of the following interface options has changed under
Shorewall-perl.
- arp_filter
- routefilter
- logmartians
- proxy_arp
- sourceroute
With the Shorewall-shell compiler, Shorewall resets these options
on all interfaces then sets the option on those interfaces
for which the option is defined in /etc/shorewall/interfaces.
Under Shorewall-perl, these options can be specified with the value
0 or 1 (e.g., proxy_arp=0). If no value is specified, the value 1
is assumed. Shorewall will modify only the setting of those
interfaces for which the option is specified and will set the
option to the given value.
A fatal compilation error is also generated if you specify one of
these options with a wildcard interface (one ending with '+').
r) The LOG_MARTIANS and ROUTE_FILTER options are now tri-valued in
Shorewall-perl.
Yes - Same as before
No - Same as before except that it applies regardless of
whether any interfaces have the logmartians/routefilter
option
Keep - Shorewall ignores the option entirely (which is the
default).
s) Shorewall-perl support nn 'optional' option has been added to
/etc/shorewall/interfaces. This option is recognized by
Shorewall-perl but not by Shorewall-shell. When 'optional' is
specified for an interface, Shorewall will be silent when:
- a /proc/sys/net/ipv4/conf/ entry for the interface cannot be
modified (including for proxy ARP).
- The first address of the interface cannot be obtained.
I specify 'optional' on interfaces to Xen virtual machines that
may or may not be running when Shorewall is [re]started.
CAUTION: Use 'optional' at your own risk. If you [re]start
Shorewall when an 'optional' interface is not available and then
do a 'shorewall save', subsequent 'shorewall restore' and
'shorewall -f start' operations will instantiate a ruleset that
does not support that interface, even if it is available at the
time of the restore/start.
t) Shorewall-perl validates all IP addresses and addresses ranges
in rules. DNS names are resolved and an error is issued for any
name that cannot be resolved.
u) Shorewall-perl checks configuration files for the presense of
characters that can cause problems if they are allowed into the
generated firewall script:
- Double Quotes. These are prohibited except in the
shorewall.conf and params files.
- Single Quotes. These are prohibited except in the
shorewall.conf and params files and in COMMENT lines.
- Single back quotes. These are prohibited except in the
shorewall.conf and params files.
- Backslash. Probibited except as the last character on a line
to denote line continuation.
v) Under Shorewall-perl, macros may invoke other macros with the
restriction that such macros may not be invoked within an action
body.
When marcros are invoked recursively, the parameter passed to an
invocation are automatically propagated to lower level macros.
Macro invocations may be nested to a maximum level of 5.
------------------------------------------------------------------------
P R E R E Q U I S I T E S
------------------------------------------------------------------------
- Perl (I use Perl 5.8.8 but other versions should work fine)
- Perl Cwd Module
- Perl File::Basename Module
- Perl File::Temp Module
- Perl Getopt::Long Module
------------------------------------------------------------------------
U S I N G T H E N E W C O M P I L E R
If you only install one compiler, then that compiler will be used.
If you install both compilers, then the compiler actually used depends
on the SHOREWALL_COMPILER setting in shorewall.conf.
The value of this new option can be either 'perl' or 'shell'.
If you add 'SHOREWALL_COMPILER=perl' to /etc/shorewall/shorewall.conf
then by default, the new compiler will be used on the system. If you
add it to shorewall.conf in a separate directory (such as a
Shorewall-lite export directory) then the new compiler will only be
used when you compile from that directory.
If you only install one compiler, it is suggested that you do not set
SHOREWALL_COMPILER.
You can also select the compiler to use on the command line using the
'C option:
'-C shell' means use the shell compiler
'-C perl' means use the perl compiler
The -C option overrides the setting in shorewall.conf.
Example:
shorewall restart -C perl
2) Thanks to Paul Gear, an IPPServer macro has been added. Be sure to
read the comments in the macro file before trying to use this
macro.
3) Eariler generations of Shorewall Lite required that remote root
login via ssh be enabled in order to use the 'load' and 'reload'
commands.
Beginning with this release, you may define an alternative means
for accessing the remote firewall system.
Two new options have been added to shorewall.conf:
RSH_COMMAND
RCP_COMMAND
The default values for these are as follows:
RSH_COMMAND: ssh ${root}@${system} ${command}
RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
Shell variables that will be set when the commands are envoked are
as follows:
root - root user. Normally 'root' but may be overridden using
the '-r' option.
system - The name/IP address of the remote firewall system.
command - For RSH_COMMAND, the command to be executed on the
firewall system.
files - For RCP_COMMAND, a space-separated list of files to
be copied to the remote firewall system.
destination - The directory on the remote system that the files
are to be copied into.
4) The accounting, masq, rules and tos files now have a 'MARK' column
similar to the column of the same name in the tcrules file. This
column allows filtering by MARK and CONNMARK value (CONNMARK is
only accepted under Shorewall Perl).
5) SOURCE and DEST are now reserved zone names to avoid problems with
bi-directional macro definitions which use these as names as key
words.
6) The "shorewall show zones" command now flags zone members that have
been added using "shorewall add" by preceding them with a plus sign
("+").
Example:
Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007
fw (firewall)
net (ipv4)
eth0:0.0.0.0/0
loc (ipv4)
br0:0.0.0.0/0
eth4:0.0.0.0/0
eth5:0.0.0.0/0
+eth1:0.0.0.0/0
dmz (ipv4)
eth3:0.0.0.0/0
vpn (ipv4)
tun+:0.0.0.0/0
In the above output, "eth1:0.0.0.0/0" was dynamically added to the
'loc' zone. As part of this change, "shorewall delete" will only
delete entries that have been added dynamically. In earlier
versions, any entry could be deleted although the ruleset was only
changed by deleting entries that had been added dynamically.
7) The 'shorewall version' command now lists the version of the
installed compiler(s) if the -a option is used:
gateway:/bulk/backup # shorewall version -a
4.0.0-Beta1
Shorewall-shell 4.0.0-Beta1
Shorewall-perl 4.0.0-Beta1
gateway:/bulk/backup #
8) The Perl compiler is externalized. Both the compiler.pl program
and the Perl Module interface are documented.
The compiler program is /usr/share/shorewall-perl/compiler.pl:
compiler.pl [ <option> ... ] [ <filename> ]
If a <filename> is given, then the configuration will be compiled
output placed in the named file. If <filename> is not given, then
the configuration will simply be syntax checked.
Options are:
-v <verbosity>
--verbosity=<verbosity>
The <verbosity> is a number between 0 and 2 and corresponds to
the VERBOSITY setting in shorewall.conf. This setting controls
the verbosity of the compiler itself.
-e
--export
If given, the configuration will be compiled for export to
another system.
-d <directory>
--directory=<directory>
If this option is omitted, the configuration in /etc/shorewall
is compiled/checked. Otherwise, the configuration in the named
directory will be compiled/checked.
-t
--timestamp
If given, each progress message issued by the compiler and by
the compiled program will be timestamped.
--debug
If given, when a warning or error message is issued, it is
supplimented with a stack trace. Requires the Carp Perl
module.
Example (compiles the configuration in the current directory
generating a script named 'firewall' and using VERBOSITY
2).
/usr/share/shorewall-perl/compiler.pl -v 2 -d . firewall
Note: For compatibility with the Shorewall 3.4.2 and 3.4.3
releases, options not passed on the run-line get their values from
environmental variables:
Option Variable
--verbosity VERBOSE
--export EXPORT
--directory SHOREWALL_DIR
--timestamp TIMESTAMP
The Perl Module is externalized as follows:
use lib '/usr/share/shorewall-perl';
use Shorewall::Compiler;
compiler $filename, $directory, $verbose, $options
The arguments to the compiler function are as follows:
$filename - Name of the compiled script to be created.
If the arguments evaluates to false, the
configuration is syntax checked
$directory - The directory containing the configuration.
If passed as '', then /etc/shorewall/ is assumed.
$verbose - The verbosity level (0-2).
$options - A bitmap of options. Shorewall::Compiler
exports two constants to help building this
argument:
EXPORT = 0x01
TIMESTAMP = 0x02
The compiler raises an exception with 'die' if it encounters an
error; $@ contains the 'ERROR' messages describing the problem.
The compiler function can be called repeatedly with different
inputs.
9) When TC_ENABLED=Internal, Shorewall-perl now validates classids in
the MARK/CLASSIFY column of /etc/shorewall/tcrules against the
classes generated by /etc/shorewall/tcclasses.
10) During installation, Shorewall generates the Perl module
/usr/share/shorewall-perl/Shorewall/Ports.pm, using your
/etc/protocols and /etc/services as input.
To re-generate the module from those two files:
1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm
file.
2. /usr/share/shorewall-perl/buildports.pl > \
/usr/share/shorewall-perl/Shorewall/Ports.pm
Note: If the buildports.pl program fails to run to a successful
completion during installation, a fallback version of
module will be installed. That fallback module was generated from
the /etc/protocols and /etc/services shipped with Ubuntu Feisty
Fawn.
Even if the buildports.pl program runs successfully, the fallback
module is also installed as
/usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you
encounter problems with the generated module, simply copy the
fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.
11) Tuomo Soini has contributed bi-directional macros for various
tunnel types:
IPsecah
GRE
IPsec
IPIP
IPsecnat
L2TP
12) The -f option is no longer the default when Shorewall is started at
boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
"shorewall start" is nearly as fast as "shorewall restore" and
"shorewall start" uses the current configuration which avoids
confusion.
To re-generate the module from those two files:
1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm
file.
2. /usr/share/shorewall-perl/buildports.pl > \
/usr/share/shorewall-perl/Shorewall/Ports.pm
Note: If the buildports.pl program fails to run to a successful
completion during installation, a fallback version of
module will be installed. That fallback module was generated from
the /etc/protocols and /etc/services shipped with Ubuntu Feisty
Fawn.
Even if the buildports.pl program runs successfully, the fallback
module is also installed as
/usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you
encounter problems with the generated module, simply copy the
fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.
11) Tuomo Soini has contributed bi-directional macros for various
tunnel types:
IPsecah
GRE
IPsec
IPIP
IPsecnat
L2TP
12) The -f option is no longer the default when Shorewall is started at
boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
"shorewall start" is nearly as fast as "shorewall restore" and
"shorewall start" uses the current configuration which avoids
confusion.
13) The implementation of LITEDIR has always been
unsatisfactory. Furthermore, there have been other cases where
people have asked to be able to designate the state directory
(default /var/lib/shorewall[-lite]).
To meet these objectives:
a) The LITEDIR variable has been eliminated in
/usr/share/shorewall[-lite]/configpath.
b) A new file /etc/shorewall[-lite]/vardir has been added. This
file is not created by default but may be added as needed. It
is expected to contain a single variable assignment:
VARDIR=<directory>
Example:
VARDIR=/root/shorewall
To change VARDIR, copy the old directory to the new one before you
restart Shorewall[-lite].
To use this feature with Shorewall-lite, all packages involved
(compiler, shorewall-common and shorewall-lite) must be version
4.0.0-RC2 or later.
2007-07-15 Shorewall 3.4.5
Problems Corrected in 3.4.5.
1) DYNAMIC_ZONES=Yes can now coexist with Shorewall-perl's 'bport'
zones. Those zones themselves may not be dynamically modified but
the presence of bport zones no longer causes the 'shorewall add'
command to fail.
2) Shorewall's internal traffic shaper once again works when the 'sed'
utility is provided by the Busybox package.
3) Version 3.4.4 erroneously accepted the values On, Off, on, off, ON
and OFF for the IP_FORWARDING option. These values were treated
like 'Keep'. The listed values are now once again flagged as an
error.
4) If 'routeback' and 'detectnets' were specified on an interface,
limited broadcasts (to 255.255.255.255) and multicasts were dropped
when forwarded through the interface. This could cause
broadcast-based and multicast applications to fail when running
through a bridge with 'detectnets'.
5) The 'hits' command works once again.
6) IPSECFILE=ipsec (either explicitly or defaulted) works
now. Previously, processing of the ipsec file was bypassed; often
with a confusing "missing file" message.
7) If DETECT_DNAT_IPADDRS=Yes in shorewall.conf but you did't have conntrack
match support, then the generated script was missing 'done's.
Other changes in 3.4.5.
1) When a Shorewall release includes detection of an additional
capability, existing capabilities files become out of
date. Previously, this condition was not detected.
Beginning with this release, each generated capabilities file
contains a CAPVERSION specification which defines the capabilities
version of the file. If the CAPVERSION in a capabilities file is
less than the current CAPVERSION, then Shorewall will issue the
following message:
WARNING: <file> is out of date -- it does not contain all of
the capabilities defined by Shorewall version <version>
where
<file> is the name of the capabilities file.
<version> is the current Shorewall version.
Existing capabilities files contain no CAPVERSION. When such a file
is read, Shorewall will issue this message:
WARNING: <file> may be not contain all of the capabilities defined
by Shorewall version <version>
2) When a directory is specified in a command such as 'start' or
'compile', Shorewall now reads the shorewall.conf file (if any) in
that directory before deciding which compiler to use. So if
SHOREWALL_COMPILER is not specified in
/etc/shorewall/shorewall.conf and the -C option was not specified
on the run-line, then if Shorewall-perl is installed, the additional
shorewall.conf file is read to see if it specifies a
SHOREWALL_COMPILER.
3) The 'save' command now uses iptables-save from the same directory
containing iptables. Previously, iptables-save was located via the
PATH setting.
2007-06-17 Shorewall 3.4.4
Problems corrected in 3.4.4:
1) The commands "shorewall add <interface> <zone>" and "shorewall
delete <interface> <zone>" no longer produce spurious error
messages.
2) The command "shorewall delete <interface> <zone>" now actually deletes
entries when it successfully completes. Previously, it would appear
to remove an entry, even when removing that entry should fail.
3) Setting HIGH_ROUTE_MARKS=No no longer causes TC_EXPERT flagging.
4) When run as root, the 'shorewall load' and 'shorewall reload'
commands would fail if the LOGFILE setting in
/etc/shorewall/shorewall.conf specified a non-existant file.
5) Entries in /etc/shorewall/tcrules that specify both a source and
destination port fail with the following diagnostic:
iptables v1.3.3: multiport can only have one option
6) Previously, Shorewall-lite did not allow DHCP traffic through an
interface when the interface was a bridge with 'dhcp' specified
unless there was a bridge on the administrative system with the
same name.
7) SOURCE and DEST are now flagged as invalid zone name to avoid
problems with macros that use those names as keywords.
8) Previously, Shorewall could *increase* the MSS under some
circumstances. This possibility is now eliminated, provided that
the system has TCPMSS match support (be sure to update your
capabilities files!).
9) Firewall zone names other than 'fw' no longer cause a error when
IPSECFILE is not set or is set to 'ipsec'.
10) The 'proxyarp' option on an interface was previously ignored when
the /etc/shorewall/proxyarp file was empty.
11) Previously, if action 'a' was defined then the following
rule generated an error:
a: z1 z2 ...
The trailing ":" is now ignored.
12) Previously, if a RATE/LIMIT was specified on a REJECT rule, the
generated error messages referred to the rule as a DROP rule.
13) The 'nolock' keyword was previously ignored on several
/sbin/shorewall[-lite] commands.
Other changes in 3.4.4:
1) The accounting, masq, rules and tos files now have a 'MARK' column
similar to the column of the same name in the tcrules file. This
column allows filtering by MARK value.
2) The "shorewall show zones" command now flags zone members that have
been added using "shorewall add" by preceding them with a plus sign
("+").
Example:
Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007
fw (firewall)
net (ipv4)
eth0:0.0.0.0/0
loc (ipv4)
br0:0.0.0.0/0
eth4:0.0.0.0/0
eth5:0.0.0.0/0
+eth1:0.0.0.0/0
dmz (ipv4)
eth3:0.0.0.0/0
vpn (ipv4)
tun+:0.0.0.0/0
In the above output, "eth1:0.0.0.0/0" was dynamically added to the
'loc' zone. As part of this change, "shorewall delete" will only
delete entries that have been added dynamically. In earlier
versions, any entry could be deleted although the ruleset was only
changed by deleting entries that had been added dynamically.
3) Eariler generations of Shorewall Lite required that remote root
login via ssh be enabled in order to use the 'load' and 'reload'
commands.
Beginning with this release, you may define an alternative means
for accessing the remote firewall system.
Two new options have been added to shorewall.conf:
RSH_COMMAND
RCP_COMMAND
The default values for these are as follows:
RSH_COMMAND: ssh ${root}@${system} ${command}
RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
Shell variables that will be set when the commands are envoked are
as follows:
root - root user. Normally 'root' but may be overridden using
the '-r' option.
system - The name/IP address of the remote firewall system.
command - For RSH_COMMAND, the command to be executed on the
firewall system.
files - For RCP_COMMAND, a space-separated list of files to
be copied to the remote firewall system.
destination - The directory on the remote system that the files
are to be copied into.
4) You may now select the compiler to use on the command line using
the '-C' option. This option is available on the following
commands:
check
compile
export
load
reload
restart
start
try
safe-start
save-restart
Example:
shorewall try -C perl .
2007-06-12 New Host for www.shorewall.net and ftp.shorewall.net
I'm pleased to announce that Ty Christiansen and the folks at Master Mind
Productions (http://mastermindpro.com) have volunteered to host
www.shorewall.net and ftp.shorewall.net.
The new site is up and running and I've just changed DNS to point to the new
server. Let me know if you experience any problems.
Please join me in thanking Ty and Master Mind for their support of the
Shorewall project.
2007-04-30 Shorewall 3.4.3
Problems corrected in Shorewall 3.4.3
1) The shorecap program was not loading modules correctly.2) The CHAIN variable is now set correctly before the 'maclog' script is invoked.3) The 'shorewall load' and 'shorewall reload' commands redundently re-generated the capabilities file when it resided in the export directory.4) Setting LOGFILE to the value of a shell variable from the params file now works.5) The 'shorewall-lite restore' command can fail with a 'startup not enabled' error.6) When ROUTE_FILTER=Yes in shorewall.conf, Shorewall no longer clears the rp_filter flag for all interfaces.7) When LOG_MARTIANS=Yes in shorewall.conf, Shorewall no longer clears the log_martians flag for all interfaces.8) The 'shorewall add' and 'shorewall delete' commands no longer fail with the message 'ERROR: Only one firewall zone may be defined'.9) It was previously impossible to disable martian logging.10) IP addresses (aliases) added by ADD_IP_ALIASES and ADD_SNAT_ALIASES are now correctly deleted when Shorewall stops.11) The 'shorewall add' and 'shorewall delete' commands no longer fail with the error 'Only one firewall zone may be defined'.12) The special 'detect' value now works correctly in the ADDRESSES column of /etc/shorewall/masq.Other changes in Shorewall 3.4.31) A LOCKFILE option has been added to shorewall.conf. This file is used to serialize updates to the active firewall configuration. If not specified, the defaults are:
Shorewall - /var/lib/shorewall/lock
Shorewall Lite - /var/lib/shorewall-lite/lock
2007-04-08 Shorewall 3.2.10
Problems Corrected in 3.2.10
1) Previously, if a 'start' or 'restart' command failed during the
compilation step, /sbin/shorewall erroneously returned an exit
status of zero.
2) If IMPLICIT_CONTINUE=Yes was in effect, then sub-zones received the
implicit CONTINUE policy for their intra-zone traffic (rather than
the implicit ACCEPT policy for such traffic). This could cause
intra-zone traffic to be rejected by rules in one of the parent
zones.
3) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. With this
change, shorewall will only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
4) The /usr/share/shorewall[-lite]/modules file has been updated for
kernel 2.6.20.
5) The /proc/net/ip_conntrack pseudo-file has been inexplicably
renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
library has been updated to look for both files.
6) Tunnels of type 'ipsecnat' failed to work properly due to a missing
rule.
7) The 'shorecap' program was not loading modules correctly.
Problems corrected in Shorewall 3.4.2
1) The /usr/share/shorewall[-lite]/modules file has been updated for
kernel 2.6.20.
2) The /proc/net/ip_conntrack pseudo-file has been inexplicably
renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
library has been updated to look for both files.
3) Shoreall 3.4 was not consistent with respect to its treatment of
log level 'none' and 'none!' and built-in actions. In particular,
specifying 'none' with the Limit action produced a run-time error.
Shorewall now correctly suppresses generation of log messages when
a log level of 'none' or 'none!' is given to a built-in action.
4) Tunnels of type 'ipsecnat' would sometimes fail to work because of
a missing rule.
Problems Corrected in 3.4.1
1) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. There was a
partial fix included in 3.4.0; unfortunately, it did not correct the
problem completely. Shorewall 3.4.1 includes the rest of the change
necessarey to only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
2) If the log-prefix in a log message exceeded 29 characters,
'shorewall restart' fails with 'truncate: command not found' and a
possible segmentation fault in iptables.
3) Log messages specifying a log tag had two spaces appended to the
log prefix. This could cause mysterious "log-prefix truncated"
messages.
4) When nested zones were defined in the /etc/shorewall/zones file and
IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,
shell error messages ( usually '<zone>: not found' ) during
compilation resulted.
5) Use of CONTINUE policies lead to startup errors with a message
such as the following:
Applying Policies...
iptables v1.3.7: Couldn't load target
`CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open
shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"
Failed
6) If there were hosts defined as 'critical' in
/etc/shorewall/routestopped then problems occured in two cases:
i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall
clear' was issued.
ii) On Shorewall or Shorewall lite system when 'start' or 'restart'
failed during execution of the compiled script and there was no saved
configuration ('shorewall[-lite] save' has not been issued).
The symptoms were that the following shell messages were issued and
the 'critical' hosts were not enabled:
/var/lib/shorewall/.start: line nnn: source_ip_range: command not found
/var/lib/shorewall/.start: line nnm: dest_ip_range: command not found
Other changes in 3.4.1
1) Several changes are included which allow testing of experimental
versions of Shorewall on systems with 3.4.1 and later 3.4 releases
installed. Among these changes is the detection and reporting of
"Address Type Match" which may be used in future 3.4 releases.
These changes have no effect on normal Shorewall operation.
Shorewall 3.4.0
Release Highlights
1) Shorewall can now be tailored to reduce its footprint on embedded
systems. As part of this change, actions are now completely
optional.
See http://www.shorewall.net/Modularization.html for details.
2) Exclusion is now possible in /etc/shorewall/hosts. This is required
for bridge/firewalls under kernel 2.6.20 and later.
See http://www.shorewall.net/NewBridge.html.
3) Shorewall and Shorewall Lite now include man pages. There is a
man page for shorewall(8), one for shorewall-lite(8) and one for
each configuration file. As part of this change, all documentation
has been removed from Shorewall configuration files. This should
make it easier from users to upgrade from one release to the next
since the configuration files will only change when column is added
or renamed.
See http://www.shorewall.net/manpages/Manpages.html
4) Shorewall now remembers the changes that it has made to routing as
a result of entries in /etc/shorewall/providers and
/etc/shorewall/route_rules and reverses those changes when
appropriate.
Problems Corrected in 3.4.0 Final.
1) In the rules file, following the action with "!" is supposed to
exempt the rule from being suppressed by OPTIMIZE=1. That feature
was not working.
2) If both a macro body and a macro invocation contained an entry in the
SOURCE or DEST column, then compilation failed with the error:
merge_macro_source_dest: command not found
3) An obscure bug in rule activation having to do with the new
exclusion feature in /etc/shorewall/hosts has been corrected.
4) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. With this
change, shorewall will only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
New Features in Shorewall 3.4:
1) In order to accomodate small embedded applications, Shorewall 3.4
is now modularized. In addition to the base files, there are
loadable "libraries" that may be included or omitted from an
embedded system as required.
Loadable Shorewall libraries reside in /usr/share/shorewall/ and
have names that begin with "lib.". The following libraries are
included in Shorewall 3.4:
- lib.accounting. Must be available if you include entries in
/etc/shorewall/accounting.
- lib.actions. Must be available if you do not specify
USE_ACTIONS=No in /etc/shorewall/shorewall.conf.
- lib.base. The base Shorewall library required by all programs,
including compiled firewall scripts. This library is also
released as part of Shorewall Lite and is installed in
/usr/share/shorewall-lite/.
- lib.cli. Library containing the code common to /sbin/shorewall,
/sbin/shorewall-lite. This library is also released as part of
Shorewall Lite and is installed in /usr/share/shorewall-lite/.
- lib.config. Library containing the code that is common to
/usr/share/shorewall/compiler and /usr/share/shorewall/firewall.
- lib.dynamiczones. Must be available if you specify
DYNAMIC_ZONES=Yes in shorewall.conf.
- lib.maclist. Must be available if you specify the 'maclist'
option in /etc/shorewall/interfaces or /etc/shorewall/hosts.
- lib.nat. Must be available if you have entries in
/etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap
or if you use DNAT or REDIRECT rules.
- lib.providers. Must be available if you have entries in
/etc/shorewall/providers.
- lib.proxyarp. Must be available if you have entries in
/etc/shorewall/proxyarp or if you specify the 'proxyarp' option
in /etc/shorewall/interfaces.
- lib.tc. Must be available if you have entries in
/etc/shorewall/tcdevices and /etc/shorewall/tcclasses.
- lib.tcrules. Must be available if you have entries in
/etc/shorewall/tcrules.
- lib.tunnels. Must be available if you have entries in
/etc/shorewall/tunnels.
Embedded applications can further decrease the size of the Shorewall
footprint by:
- Omitting the macro files.
- Omitting all unused extension scripts.
See http://www.shorewall.net/Modularization.html for additional
details.
2) As hinted in the previous bullet, there is a new USE_ACTIONS option
in /etc/shorewall/shorewall.conf. Shorewall actions can be very
powerful but they also require a lot of code to implement. Embedded
applications can omit that code by setting
USE_ACTIONS=No. Shorewall will ignore all action-related files
including /usr/share/shorewall/actions.std and
/etc/shorewall/actions. Builtin actions will still be available for
use in rules and macros.
The 'Limit' action has been converted to a builtin so that Limit is
available even when USE_ACTIONS=No.
See the next item for more information.
3) Prior to Shorewall 3.4, default actions were specified in
/usr/share/shorewall/actions.std or in /etc/shorewall/actions.
This approach has two drawbacks:
a) All DROP policies must use the same default action and all
REJECT policies must use the same default action.
b) Now that we have modularized action processing (see the New
Features section below), we need a way to define default rules
for a policy that does not involve actions.
The solution is two-fold:
- Four new options have been added to the
/etc/shorewall/shorewall.conf file that allow specifying the
default action for DROP, REJECT, ACCEPT and QUEUE.
The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and
QUEUE_DEFAULT.
DROP_DEFAULT describes the rules to be applied before a
connection request is dropped by a DROP policy; REJECT_DEFAULT
describes the rules to be applied if a connection request is
rejected by a REJECT policy. The other two are similar for
ACCEPT and QUEUE policies.
The value assigned to these may be:
a) The name of an action.
b) The name of a macro
c) 'None' or 'none'
The default values are:
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT=none
QUEUE_DEFAULT=none
If USE_ACTIONS=Yes, then these values refer to action.Drop and
action.Reject respectively. If USE_ACTIONS=No, then these values
refer to macro.Drop and macro.Reject.
If you set the value of either option to "None" then no default
action will be used and the default action or macro (if any)
must be specified in /etc/shorewall/policy
- The POLICY column in /etc/shorewall/policy has been extended.
In /etc/shorewall/policy, when the POLICY is DROP, REJECT,
ACCEPT or QUEUE then the policy may be followed by ":" and one
of the following:
a) The word "None" or "none". This causes any default
action defined in /etc/shorewall/shorewall.conf
to be omitted for this policy.
b) The name of an action (requires that USE_ACTIONS=Yes
in shorewall.conf). That action will be invoked
before the policy is enforced.
c) The name of a macro. The rules in that macro will
be applied before the policy is enforced. This
does not require USE_ACTIONS=Yes.<
br>
Example:
#SOURCE DEST POLICY LOG
# LEVEL
loc net ACCEPT
net all DROP:MyDrop info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT:MyReject info
4) For users whose kernel and iptables have Extended MARK Target
support, it is now possible to logically AND or OR a value into the
current packet mark by preceding the mark value (and optional mask)
with an ampersand ("&") or vertical bar ("|") respectively.
Example: To logically OR the value 4 into the mark value for
packets from 192.168.1.1:
#MARK SOURCE
|4 192.168.1.1
5) Previously, zone names were restricted to five characters in
length. That limit derives from the --log-prefix in Netfilter log
messages which must be 29 bytes or less in length. With the
standard Shorewall LOGFORMAT, that leaves 11 characters for the
chain name; given that many chain names are of the form
<zone1>2<zone2>, that gives a maximum zone name length of 5.
Beginning with this release, the maximum length of a zone name is
dependent on the LOGFORMAT (the maximum length may never be less
than 5 but it may be greater than 5). For example, setting
LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters.
6) Netfilter provides support for attachment of comments to Netfilter
rules. Comments can be up to 255 bytes in length and are visible
using the "shorewall show <chain>", "shorewall show nat",
"shorewall show mangle" and "shorewall dump" commands. Comments are
delimited by '/* ... */" in the output.
Beginning with Shorewall 3.4, you may place COMMENT lines in the
/etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat
and /etc/shorewall/masq files and in action files. The remainder of
the line is treated as a comment and it will be attached as a
Netfilter comment to the rule(s) generated by succeding entries
in the file.
Note: Do not prefix the comment with "#". Shorewall's two-pass
compiler strips off "#" comments in the first pass and processes
COMMENT lines in the second pass. Hence, by the time that COMMENT
is processed, the "#" and everything following it has been removed
(see example below).
To stop the current comment from being attached to further
rules, simply include COMMENT on a line by itself (so that the
following rules will have no comment) or specify a new COMMENT.
If you do not have Comment support in your iptables/kernel (see the
output of "shorewall[-lite] show capabilities") then COMMENTS are
ignored with this warning:
COMMENT ignored -- requires comment support in iptables/Netfilter
Example from my rules file:
#SOURCE SOURCE DEST PROTO DEST PORT(S)
COMMENT Stop Microsoft Noise
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
COMMENT # Stop comment from being attached to rules below
The output of "shorewall show loc2net" includes (folded):
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 137,445 /* Stop Microsoft Noise */
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139 /* Stop Microsoft Noise */
7) A new macro (macro.RDP) has been added for Microsoft Remote
Desktop. This macro was contributed by Tuomo Soini.
8) A new 'maclog' extension file has been added. This file is
processed just before logging based on the setting of
MACLIST_LOG_LEVEL is done. When the extension is invoked, the CHAIN
variable will contain the name of the chain where rules should be
inserted. Remember that if you have specified MACLIST_TABLE=mangle,
then your run_iptables commands should include "-t mangle".
9) The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to
more accurately describe the contents of the column.
10) Previously, it was not possible to use exclusion in
/etc/shorewall/hosts. Beginning with this release, you may now use
exclusion lists in entries in this file. Exclusion lists are
discussed at:
http://www.shorewall.net/configuration_file_basics.htm#Exclusion.
Example:
loc eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28
In that example, the 'loc' zone is defined to be the subnet
192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4
and hosts in the sub-network 192.168.1.16/28.
11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing"
commands have been added. The first produces the same output as "ip
addr ls". The second produces a report about your routing rules and
tables.
12) Beginning with this release, Shorewall and Shorewall Lite will
share common change logs and release notes.
13) In Shorewall versions prior to 3.4, multiple jumps to a '2all'
chain could be generated in succession.
Example from an earlier shorewall version:
gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006
Counters reset Thu Oct 19 08:34:47 PDT 2006
Chain eth2_fwd (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
0 0 wifi2all all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * br0 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * eth3 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * tun+ 0.0.0.0/0 0.0.0.0/0
gateway:~ #
This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.
gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006
Counters reset Thu Oct 19 09:15:19 PDT 2006
Chain eth2_fwd (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
0 0 wifi2all all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~ #
Note that with OPTIMIZE=1, traffic destined for an
interface/Address that falls outside of all defined zones may now
be logged out of a '2all' chain rather than out of the FORWARD
chain.
The OPTIMIZE setting also controls the suppression of redundant
wildcard rules (those specifying "all" in the SOURCE or DEST
column). A wildcard rule is considered to be redundant when it
has the same ACTION and Log Level as the applicable policy.
Example:
/etc/shorewall/policy
#SOURCE DEST POLICY LEVEL
loc net ACCEPT
/etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
...
ACCEPT all all icmp 8
OPTIMIZE=0
gateway:~ # shorewall show loc2net
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006
Counters reset Thu Oct 26 07:54:58 PDT 2006<
br>
Chain loc2net (1 references)
pkts bytes target prot opt in out source destination
...
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~
OPTIMIZE=1
gateway:~ # shorewall show loc2net
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006
Counters reset Thu Oct 26 07:56:38 PDT 2006
Chain loc2net (1 references)
pkts bytes target prot opt in out source destination
...
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~
If you really want a rule that duplicates the policy, follow the
action with "!":
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
...
ACCEPT! all all icmp 8
14) IP Address ranges are now allowed in the drop, reject, allow and
logdrop shorewall[-lite] commands.
15) Previously, Shorewall has not attempted to undo the changes it has
made to the firewall's routing as a result of entries in
/etc/shorewall/providers and /etc/shorewall/routes. Beginning with
this release, Shorewall will attempt to undo these changes.
When Shorewall starts or is restarted and there are entries in
/etc/shorewall/providers, Shorewall will capture the contents
of /etc/shorewall/rt_tables and will restore that database when
Shorewall is stopped or restarted. Similarly, the default route
will be captured the first time that you [re]start Shorewall using
this version and will be restored under the following conditions:
a) shorewall stop
b) shorewall clear
c) shorewall restart or restore and there are no entries in
/etc/shorewall/providers.
Once the default route has been restored, Shorewall will delete
the saved copy so that it will once again be captured at the next
shorewall start or shorewall restore.
16) Shorewall no longer includes policy matches in its generated
ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC
networks are defined using the 'ipsec' option in
/etc/shorewall/hosts).
17) The Makefile installed in /usr/share/shorewall/configfiles/ is now
the same one mentioned at
http://www.shorewall.net/CompiledPrograms.html.
Once the file is copied into an export directory, you modify the
setting of the HOST variable to match the name of the remote
firewall.
The default target is the "firewall" script so "make" compiles the
firewall script if any of the configuration files have
changed. "make install" builds "firewall" if necessary then
installs it on the remote firewall. "make capabilities" will
generate the "capabilities" file. "make save" will save the running
configuration on the remote firewall.
18) Shorewall and Shorewall Lite now include the following manpages.
shorewall-accounting(5)
shorewall-actions(5)
shorewall-blacklist(5)
shorewall.conf(5)
shorewall-ecn(5)
shorewall-exclusion(5)
shorewall-hosts(5)
shorewall-interfaces(5)
shorewall-lite.conf(5)
shorewall-lite(8)
shorewall-maclist(5)
shorewall-masq(5)
shorewall-nat(5)
shorewall-nesting(5)
shorewall-netmap(5)
shorewall-params(5)
shorewall-policy(5)
shorewall-providers(5)
shorewall-proxyarp(5)
shorewall-rfc1918(5)
shorewall-route_rules(5)
shorewall-routestopped(5)
shorewall-rules(5)
shorewall-tcclasses(5)
shorewall-tcdevices(5)
shorewall-tcrules(5)
shorewall-template(5)
shorewall-tos(5)
shorewall-tunnels(5)
shorewall(8)
shorewall-zones(5)
Now that the manpages are in place, command-specific help has been
removed since it duplicates information in the man pages.
19) From the beginning, the Shorewall configuration files in
/etc/shorewall/ have contained documentary comments. While these
comments are useful, they present an upgrade problem. Beginning
with this release, these comments are removed from the
configuration files themselves and are replaced by the manpages
described in the preceding release note entry.
20) Shorewall now uses tc fwmark filters to classify packets for
traffic shaping when the DEVICE isn't an interface described in
/etc/shorewall/interfaces. This is in preparation for the upcoming
change to the way that --physdev-out works in iptables/Netfilter;
that change is now scheduled for kernel 2.6.20.
21) If your kernel and iptables have extended multiport support, then
Shorewall will use that support for the destination port when
generating rules from entries in the /etc/shorewall/tcrules file.
22) The 'safe-start' and 'safe-restart' command have been
improved. Both now accept an optional directory name; if supplied,
Shorewall will look first in that directory for configuration
files.
The commands have also been enhanced to only restore the
configuration once in the event of a failure. Previously, if there
was a current 'save' command in effect, then that configuration
would be restored on a failure and then the last-running
configuration would be restored.
23) The 'try' command has been reimplemented with new semantics.
If Shorewall is started then the firewall state is saved to a
temporary saved configuration (/var/lib/shorewall/.try). Next, if
Shorewall is currently started then a restart command is issued;
otherwise, a start command is performed. if an error occurs during
the compliation phase of the restart or start, the command
terminates without changing the Shorewall state. If an error occurs
during the restart phase, then a 'shorewall restore' is performed
using the saved configuration. If an error occurs during the start
phase, then Shorewall is cleared. If the start/restart succeeds
and a timeout is specified then a 'clear' or 'restore' is performed
after timeout seconds.
24) The syntax of the 'export' command has been made slightly
friendlier.
The old syntax:
export <directory1> [user@]system:[<directory2>]
It is now:
export <directory1> [user@]system[:<directory2>]
In other words, if you don't need to specify <directory2>, you may
omit the colon (":") following the system name.
The old syntax is still accepted -- that is, you can still
type:
export firewall2:
which is equivalent to
export firewall2
25) Shorewall commands may be speeded up slightly by using a
'capabilities' file. The 'capabilities' file was originally
designed for use with Shorewall Lite and records the
iptables/Netfilter features available on the target system.
To generate a capabilities file, execute the following command as
root:
shorewall show -f capabilities > /etc/shorewall/capabil
ities
When you install a new kernel and/or iptables, be sure to generate
a new capabilities file.
26) When syslogd is run with the -C option (which in some
implementations causes syslogd to log to an in-memory circular
buffer), /sbin/shorewall will now use the 'logread' command to read
the log from that buffer. This is for combatibility with OpenWRT.
27) There is now a ":T" qualifier in /etc/shorewall/tcrules which
causes the resulting rule to be inserted into the POSTROUTING
chain.
28) The program /usr/share/shorewall/wait4ifup can be used to wait for
a network device (such as a ppp device) to reach the UP state.
/usr/share/shorewall/wait4ifup <interface> [ <seconds> ]
The program will wait for up to <seconds> seconds for the
named <interface> to reach the UP state. If <seconds> is not given,
60 seconds is assumed.
The exit status is zero if <interface> comes up within <seconds>
seconds and non-zero otherwise.
29) Previously, 'ipsecnat' tunnels allowed AH traffic by default
(unless 'isecnat:noah' was given). Given that AH is incompatible
with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.
30) Shorewall now generates half as many rules as previously in the
'blacklst' chain when BLACKLIST_LOGLEVEL is specified.
31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in
shorewall.conf then Shorewall will not process
/etc/shorewall/params when the compiled script is run. With
EXPORTPARAMS=No, any shell variables needed at run-time must be set
in /etc/shorewall/init.
In a Shorewall/Shorewall Lite environment, this allows
/etc/shorewall/params to be written to run exclusively
on the administrative system while /etc/shorewall/init runs
exclusively on the firewall system.
So shell variables required at compile time may be set in
/etc/shorewall/params and those required at run-time may be set in
/etc/shorewall/init.
Note 1: If you need shell variables values in your
/etc/shorewall/stop or /etc/shorewall/stopped script, then you need
to set their values in /etc/shorewall/stop. /etc/shorewall/init is
not invoked during processing of the 'stop' and 'clear' commands.
Note 2: EXPORTPARAMS was actually introduced in Shorewall version
3.2.9. It is described here for the benefit of those who did not
install that version.