Shorewall 4.3.9 Shorewall 4.3 is the development thread for Shorewall 4.4 which will be released late in 2009. ---------------------------------------------------------------------------- R E L E A S E 4 . 3 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) The Shorewall documentation and man pages have been purged of information about earlier Shorewall releases. The documentation describes only the behavior of Shorewall 4.3 and later versions. 3) The interfaces file OPTIONs have been extended to largely remove the need for the hosts file. 4) 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. 5) Dynamic Zone support is once again available for IPv4; ipset support is required in your kernel and in iptables. 6) 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. 7) 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. ---------------------------------------------------------------------------- M I G R A T I O N I S S U E S ---------------------------------------------------------------------------- 1) The 'shorewall stop', 'shorewall clear', 'shorewall6 stop' and 'shorewall6 clear' commands no longer read the 'routestopped' file. The 'routestopped' file used is the one that was present at the last 'start', 'restart' or 'restore' command. 2) The old macro parameter syntax (e.g., SSH/ACCEPT) is now deprecated in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.3 documentation uses the new syntax exclusively, although the old syntax continues to be supported. 3) Support for the SAME target in /etc/shorewall/masq and /etc/shorewall/rules has been removed, following the removal of the underlying support in the Linux kernel. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 4 . 3 . 9 ---------------------------------------------------------------------------- 1) If an interface name was specified in a PREROUTING rule (tcrules or notrack) then an invalid iptables rule would be generated. 2) When a network address appeared in the SOURCE or DEST column of /etc/shorewall/tcfilters, an incorrect netmask was being generated in the resulting 'tc' rule. 3) Placing an IP address in the BROADCAST column of /etc/shorewall/interfaces caused Shorewall-perl to generate an erroneous 'Invalid BROADCAST address' error. ---------------------------------------------------------------------------- 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 . 3 . 9 ---------------------------------------------------------------------------- 1) Rules that specify a log level with a target other than LOG or NFLOG are now implemented through a separate chain. While this may increase the processing cost slightly for packets that match these rules, it is expected to reduce the overall cost of such rules because each packet that doesn't match the rules only has to be processed once per rule rather than twice. Example: /etc/shorewall/rules: REJECT:info loc net tcp 25 This previously generated these two rules (long rules folded): -A loc2net -p 6 --dport 25 -j LOG --log-level 6 --log-prefix "Shorewall:loc2net:reject:" -A loc2net -p 6 --dport 25 -j reject It now generates these rules: :log0 - [0:0] ... -A loc2net -p 6 --dport 25 -g log0 ... -A log0 -j LOG --log-level 6 --log-prefix "Shorewall:loc2net:REJECT:" -A log0 -p 6 --dport 25 -j reject Notice that now there is only a single rule generated in the 'loc2net' chain where before there were two. Packets for other than TCP port 25 had to be processed by both rules. Notice also that the new LOG rule reflects the original action ("REJECT") rather than what Shorewall maps that to ("reject"). 2) Shorewall6 has now been tested on kernel 2.6.24 (Ubuntu Hardy) and hence will now start successfully when running on that kernel. 3) Three new options (IP, TC and IPSET) have been added to shorewall.conf and shorwall6.conf. These options specify the name of the executable for the 'ip', 'tc' and 'ipset' utilities respectively. If not specified, the default values are: IP=ip TC=tc IPSET=ipset In other words, the utilities will be located via the current PATH setting. ---------------------------------------------------------------------------- N E W F E A T U R E S IN 4 . 3 ---------------------------------------------------------------------------- 1) The Shorewall packaging has been completely revamped in Shorewall 4.3. The new packages are: - Shorewall. Includes the former Shorewall-common and Shorewall-perl packages. Includes everything needed to create an IPv4 firewall. - Shorewall6. Requires Shorewall. Adds the components necessary to create an IPv6 firewall. - Shorewall-lite May be installed on a firewall system to run IPv4 firewall scripts generated by Shorewall. - Shorewall6-lite May be installed on a firewall system to run IPv6 firewall scripts generated by Shorewall6. 2) The interfaces file supports a new 'nets=' option. This option allows users to restrict a zone's definition to particular networks through an interface without having to use the hosts file. Example interfaces file: #ZONE INTERFACE BROADCAST OPTIONS loc eth3 detect dhcp,logmartians=1,routefilter=1,nets=172.20.1.0/24 dmz eth4 detect logmartians=1,routefilter=1,nets=206.124.146.177 net eth0 detect dhcp,blacklist,tcpflags,optional,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177) net eth2 detect dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177) loc tun+ detect nets=172.20.0.0/24 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Note that when more than one network address is listed, the list must be enclosed in parentheses. Notice also that exclusion may be used. The first entry in the above interfaces file is equivalent to the following: interfaces: #ZONE INTERFACE BROADCAST OPTIONS - eth0 detect dhcp,logmartians=1,routefilter=1 hosts: #ZONE HOST(S) OPTIONS loc $INT_IF:192.20.1.0/24 broadcast Note that the 'broadcast' option is automatically assumed and need not be explicitly specified. 3) Some websites run applications that require multiple connections from a client browser. Where multiple 'balanced' providers are configured, this can lead to problems when some of the connections are routed through one provider and some through another. To work around this issue, the SAME target has been added to /etc/shorewall/tcrules. SAME may be used in the PREROUTING and OUTPUT chains. When used in PREROUTING, it causes matching connections from an individual local system to all use the same provider. For example: SAME:P 192.168.1.0/24 - tcp 80,443 If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes then the new connection will use the same provider as the connection over which that last packet was sent. When used in the OUTPUT chain, it causes all matching connections to an individual remote system to all use the same provider. For example: SAME $FW - tcp 80,443 If the firewall attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes to the same remote system then the new connection will use the same provider as the connection over which that last packet was sent. Important note: SAME only works with providers that have the 'track' option specified in /etc/shorewall/providers. 4) The file /var/lib/shorewall/.restore has been renamed to /var/lib/shorewall/firewall. A similar change has been made in Shorewall6. When a successful start or restart is completed, the script that executed the command copies itself to to /var/lib/shorewall[6]/firewall. 5) Dynamic zone support is once again available for IPv4. This support is built on top of ipsets so you must have the xtables-addons installed on the firewall system. Dynamic zones are available when Shorewall-lite is used as well. Note that the dynamic zone support built into Shorewall provides no additional functionality over what is provided by simply defining a zone in terms of an ipset (see http://www1.shorewall.net/ipsets.html#Dynamic). You define a zone as having dynamic content in one of two ways: - By specifying nets=dynamic in the OPTIONS column of an entry for the zone in /etc/shorewall/interfaces; or - By specifying :dynamic in the HOST(S) column of an entry for the zone in /etc/shorewall/hosts. When there are any dynamic zones present in your configuration, Shorewall (Shorewall-lite) will: a) Execute the following commands during 'shorewall start' or 'shorewall-lite start'. ipset -U :all: :all: ipset -U :all: :default: ipset -F ipset -X ipset -R < ${VARDIR}/ipsets.save where $VARDIR normally contains /var/lib/shorewall (/var/lib/shorewall-lite) but may be modified by /etc/shorewall/vardir (/etc/shorewall-lite/vardir). b) During 'start', 'restart' and 'restore' processing, Shorewall will then attempt to create an ipset named _ for each zone/interface pair that has been specified as dynamic. The type of ipset created is 'iphash' so that only individual IPv4 addresses may be added to the set. c) Execute the following commands during 'shorewall stop' or 'shorewall-lite stop': if ipset -S > ${VARDIR}/ipsets.tmp; then mv -f ${VARDIR}/ipsets.tmp ${VARDIR}/ipsets.save fi The 'shorewall add' and 'shorewall delete' commands are supported with their original syntax: add [:] ... delete [:] ... In addition, the 'show dynamic' command is added that lists the dynamic content of a zone. show dynamic These commands are supported by shorewall-lite as well. 6) The generated program now attempts to detect all dynamic information when it first starts. If any of those steps fail, an error message is generated and the state of the firewall is not changed. 7) Shorewall will now attempt to detect a dynamic gateway by reading the dhclient lease file for the interface (/var/run/dhcp/dhclient-.lease). 8) To improve readability of the configuration files, Shorewall now allows leading white space in continuation lines when the continued line ends in ":" or ",". Example (/etc/shorewall/rules): #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net:\ 206.124.146.177,\ 206.124.146.178,\ 206.124.146.180\ dmz tcp 873 The leading white space on the lines that contain just an IP address is ignored so the SOURCE column effectively contains "net:206.124.146.177,206.124.147.178,206.124.146.180". 9) The generated script now uses iptables[6]-restore to instantiate the Netfilter ruleset during processing of the 'stop' command. As a consequence, the 'critical' option in /etc/shorewall/route_stopped is no longer needed and will result in a warning. 10) A new AUTOMAKE option has been added to shorewall.conf and shorewall6.conf. When set to 'Yes', this option causes new behavior during processing of the 'start' and 'restart' commands; if no files in /etc/shorewall/ (/etc/shorewall6) have changed since the last 'start' or 'restart', then the compilation step is skipped and the script used during the last 'start' or 'restart' is used to start/restart the firewall. Note that if a is specified in the start/restart command (e.g., "shorewall restart /etc/shorewall.new") then the setting of AUTOMAKE is ignored. Note that the 'make' utility must be installed on the firewall system in order for AUTOMAKE=Yes to work correctly. 11) The 'compile' command now allows you to omit the . When you do that, the defaults to /var/lib/shorewall/firewall (/var/lib/shorewall6/firewall) unless you have overridden VARDIR using /etc/shorewall/vardir (/etc/shorewall6/vardir). When combined with AUTOMAKE=Yes, it allows the following: gateway:~ # shorewall compile Compiling... Shorewall configuration compiled to /root/shorewall/firewall gateway:~ # ... gateway:~ # shorewall restart Restarting Shorewall.... done. gateway:~ # In other words, you can compile the current configuration then install it at a later time. 12) Thanks to I. Buijs, it is now possible to rate-limit connections by source IP or destination IP. The LIMIT:BURST column in /etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT column /etc/shorewall/rules (/etc/shorewall6/rules) have been extended as follows: [{s|d}:[[]:]]/{sec|min}[:] When s: is specified, the rate is per source IP address. When d: is specified, the rate is per destination IP address. The specifies the name of a hash table -- you get to choose the name. If you don't specify a name, the name 'shorewall' is assumed. Rules with the same name have their connection counts aggregated and the individual rates are applied to the aggregate. Example: ACCEPT net fw tcp 22 - - s:ssh:3/min This will limit SSH connections from net->fw to 3 per minute. ACCEPT net fw tcp 25 - - s:mail:3/min ACCEPT net fw tcp 587 - - s:mail:3/min Since the same hash table name is used in both rules, the above is equivalent to this single rule: ACCEPT net fw tcp 25,587 - - s:mail:3/min