The Shorewall team is pleased to announce the availability of Shorewall 4.5.14.
Please note that new capabilities are implemented in this release, so
your capabilities file(s) must be regenerated after installation of the
release.
----------------------------------------------------------------------------
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, a list of IPv6 host addresses where each address was
enclosed in square brackets generated a fatal compile-time error.
Such lists are now handled correctly.
2) The Shorewall 'load', 'reload' and 'export' commands have now been
modified to use a shorewallrc file in a remote system's export
directory. If the directory layout of the remote system differs
from that of the administrative system, then the remote system's
export directory should contains a copy of that system's
shorewallrc file.
3) A syntax error in the Shorewall uninstall.sh file has been
eliminated.
4) The contents of the various configpath files have been corrected.
5) The Shorewall uninstall.sh script previously failed to remove the
macro files from ${SHAREDIR}/shorewall. Those files are now
removed.
6) The 'version -a' command now prints the correct shorewall-core
version when it is run from shorewall6, shorewall-lite and
shorewall6-lite.
7) It is now possible to specify a port or port range along with an
address variable in the ADDRESSES column of /etc/shorewall/masq.
Example:
#INTERFACE SOURCE ADDRESS PROTO DEST
# PORT(S)
eth0 172.20.4.0/24 ð0:44 tcp 45
Previously, this usage generated a fatal compilation error.
8) Port numbers and service names may now be specified with the
UDPLITE protocol. As part of this change, two new capabilities have
been added.
- Enhanced Multi-port Match
Multi-port match ('-m multiport') can operate on SCTP and DCCP
- UDPLITE Port Redirection
Currently, neither DNAT nor REDIRECT support port redirection of
UDPLITE. This capability is added to detect that support in the
future.
9) The SUBSYSLOCK setting in the default shorewall6.conf file has been
changed from /var/lock/subsys/shorewall to
/var/lock/subsys/shorewall6.
10) 'blackhole' routes are now copied to provider tables when
USE_DEFAULT_RT=No. Previously, these routes were not copied with
the result that packets could be routed to blackholed addresses.
11) Duplicate interface names could previously appear in a case
statement in the generated script. These duplicates are now
suppressed.
12) Previously, a duplicate 'echo' command could appear in the
generated script. Now only a single command appears.
----------------------------------------------------------------------------
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) Previously, when compiling for export to a Shorewall lite system,
either /etc/shorewall/params was required to be readable by the
user or the remote host's configuration directory was required to
include a (possibly empty) params file.
Beginning with this release, when a directory name is specified in
a 'compile', 'check', 'load', 'reload' or 'export' command and the
user is not root (euid is not zero), then /sbin/shorewall and
/sbin/shorewall6 will only look in the specified directory for the
params and shorewall[6].conf files.
2) The BLACKLIST_LOGLEVEL option has been renamed BLACKLIST_LOG_LEVEL
to be consistent with the other log-level option
names. BLACKLIST_LOGLEVEL continues to be accepted as a synonym for
BLACKLIST_LOG_LEVEL, but a 'shorewall update' or 'shorewall6
update' command will replace BLACKLIST_LOGLEVEL with
BLACKLIST_LOG_LEVEL in the new .conf file.
3) Rules in the ESTABLISHED section are now placed in separate
chains. Rules for traffic from zone Za to zone Zb and placed in
^Za2Zb or ^Za-Zb, depending on the setting of
ZONE2ZONE. Previously, they were placed in Za2Zb (Za-Zb).
4) When the effective VERBOSITY is 2, the compiler now produces a
report as follows:
Configuration uses these capabilities ('*' denotes required):
ADDRTYPE
ARPTABLESJF
AUDIT_TARGET*
COMMENTS
CONNTRACK_MATCH
CT_TARGET
ENHANCED_REJECT
EXMARK
FTP_HELPER*
FWMARK_RT_MASK
GOTO_TARGET
IPSET_MATCH*
IRC_HELPER*
LOG_TARGET*
MANGLE_ENABLED
MANGLE_FORWARD
MARK*
MULTIPORT
NETBIOS_NS_HELPER
NEW_CONNTRACK_MATCH
NFACCT_MATCH*
NFLOG_TARGET*
RAW_TABLE*
RPFILTER_MATCH*
XMULTIPORT*
Shorewall configuration verified
5) While we understand the evils of NAT, it is required for proper
failover handling in IPv6 multi-ISP configurations. To accommodate
that limited use case, Shorewall6 now supports basic Masquerade,
SNAT and DNAT.
This feature requires a 3.7 or later kernel and iptables 1.4.17 or
later.
Note: The current Fedora 18 3.4.7 kernel does not support IPv6
MASQUERADE, so you must specify one or more addresses in the
ADDRESSES column. To approximate masquerade when running that
kernel, use an address variable in the ADDRESS column.
Example /etc/shorewall6/masq:
INTERFACE SOURCE ADDRESS
p3p1 2001:470:b:227::0/24 &p3p1
DNAT rules that specify a port number in the DEST column, must
enclose the server address (if any) in square brackets.
Example:
ACTION SOURCE DEST PROTO PORTS
DNAT net fw:[2001:470:b:227::2]:22 tcp 1022
As part of this change, a new 'MASQUERADE Target' capability as
been added.
6) 'blackhole' routes may now be defined in /etc/shorewall[6]/routes.
Simply place 'blackhole' in the GATEWAY column and leave the DEVICE
column empty.
7) The iptables/ip6tables 'multiport match' feature allows for
matching either the source or the destination port against a list
of port numbers. Up to this time, Shorewall did not allow users to
take advantage of that capability.
Beginning with this release, placing an equal sign in a SOURCE
PORT(S) column is interpreted as 'match the list specified in the
DEST PORT(S) column against both the packet source and destination
port in the packet. If there is any match, then the packet matches
the rule.
Example from the accounting file:
#ACTION CHAIN SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(S)
COUNT - br0 - tcp 80 =
This rule matches all TCP packets entering through br0 where either
the source port or the destination port is 80.
Thank you for using Shorewall,
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
