Shorewall 2.2.0-Beta3 ---------------------------------------------------------------------- Problems Corrected since 2.0.3 1) A non-empty DEST entry in /etc/shorewall/tcrules will generate an error and Shorewall fails to start. 2) A potential security vulnerablilty in the way that Shorewall handles temporary files and directories has been corrected. 3) Two problems with logging NAT rules (DNAT and REDIRECT) could cause startup failures. 4) Some users have reported the pkttype match option in iptables/ Netfilter failing to match certain broadcast packets. The result is that the firewall log shows a lot of broadcast packets. Users experiencing this problem can use PKTTYPE=No in shorewall.conf to cause Shorewall to use IP address filtering of broadcasts rather than packet type. Problems Corrected since 2.1.0 1) The "check" command fails with the following message: iptables: No chain/target/match by that name Problems Corrected since 2.1.4 1) Per-interface options like 'norfc1918' are not applied to requests that have been unencrypted as a result of an entry in the SPD. Problems corrected since 2.1.6 1) Dynamic zones marked as 'ipsec' in /etc/shorewall/ipsec now work correctly. Problems corrected since 2.1.7 1) Fix parsing of ACTION with ":" but no log level (Richard Musil). 2) Fix parsing of PROTO column in /etc/shorewall/tcrules. 3) Packets that will be encrypted or that have been decrypted by IPSEC are now exempted from the rules established by one-to-one NAT. This allows tunnel mode IPSEC to work for local networks where some of the systems use one-to-one NAT. 4) The shorewall.spec file now directs rpm to cause Shorewall to start automatically at boot. This feature was inadvertently removed in Shorewall 2.1.3. Problems corrected since 2.1.8 1) IP ranges in the routestopped and tunnels files now work. 2) Rules where an IP range appears in both the source and destination now work correctly. 3) With complex proxy arp configurations involving two or more ordered pairs of interfaces, the /proc/sys/net/ipv4/conf/*/proxy_arp flags were sometimes set incorrectly. This has been fixed. Problems corrected since 2.1.9 1) With DELAYBLACKLISTLOAD=No, the blacklist was previously not loaded. Problems corrected since 2.1.10 1) If TC_ENABLED=Yes but you have no /etc/shorewall/tcstart file then "shorewall restore" will no longer attempt to run the tcstart file. 2) Previously it was necessary to define ipsec zones (those with "Yes" in the IPSEC column in /etc/shorewall/ipsec or those having an entry in /etc/shorewall/hosts having the "ipsec" option) before other zones using the same interface. This has been corrected. 3) A typo has been corrected that prevented the 'logmartians' interface option from working correctly. 4) A typo has been corrected in and a clarification added to the /etc/shorewall/blacklist file. Problems corrected since 2.1.11 1) If a zone name appears more than once in /etc/shorewall/zones, Shorewall will now issue an error message and terminate during "shorewall [re]start" or "shorewall check". 2) If a configuration has two or more "complex" zones (zones having IPSEC hosts or zones having more than one subnet on an interface) then an incorrect ruleset is generated. This problem was introduced in 2.1.11. Problems corrected since 2.2.0 Beta 1. 1) The "shorewall check" command results in the (harmless) error message: /usr/share/shorewall/firewall: line 2753: check_dupliate_zones: command not found 2) The AllowNTP standard action now allows outgoing responses to broadcasts. 3) A clarification has been added to the hosts file's description of the 'ipsec' option pointing out that the option is redundent if the zone named in the ZONE column has been designated an IPSEC zone in the /etc/shorewall/ipsec file. Problems corrected since 2.2.0 Beta 2. 1) Missing '#' in the rfc1918 file. ----------------------------------------------------------------------- Issues when migrating from Shorewall 2.0 to Shorewall 2.1: 1) Shorewall configuration files except shorewall.conf are now empty (they contain only comments). If you wish to retain the defaults in any of the following files, you should copy these files before upgrading them then restore them after the upgrade: /etc/shorewall/zones /etc/shorewall/policy /etc/shorewall/tos 2) The following builtin actions have been removed and have been replaced by the new action logging implementation described in the new features below. logNotSyn rLogNotSyn dLogNotSyn 3) If shorewall.conf is upgraded to the latest version, it needs to be modified to set STARTUP_ENABLED=Yes 4) The Leaf/Bering version of Shorewall was previously named: shorwall-.lrp Beginning with 2.1, that file will now be named: shorewall-lrp-.tgz Simply rename that file to 'shorwall.lrp' when installing it on your LEAF/Bering system. 5) The ORIGINAL DEST column of the /etc/shorewall/rules file may no longer contain a second (SNAT) address. You must use an entry in /etc/shorewall/masq instead. Example from Shorewall FAQ #1: Prior to Shorewall 2.1: /etc/shorewall/interfaces loc eth1 detect routeback,... /etc/shorewall/rules DNAT loc loc:192.168.1.12 tcp 80 \ - 130.252.100.69:192.168.1.254 Shorewall 2.1 and Later: /etc/shorewall/interfaces loc eth1 detect routeback,... /etc/shorewall/masq: eth1 eth1 192.168.1.254 tcp 80 /etc/shorewall/rules: DNAT loc loc:192.168.1.12 tcp 80 \ - 130.252.100.69 6) The 'logunclean' and 'dropunclean' options that were deprecated in Shorewall 2.0 have now been removed completely. ----------------------------------------------------------------------- New Features: 1) ICMP packets that are in the INVALID state are now dropped by the Reject and Drop default actions. They do so using the new 'dropInvalid' builtin action. 2) The /etc/shorewall/masq file INTERFACE column now allows additional options. Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules defined in the /etc/shorewall/nat file. If you preceed the interface name with a plus sign ("+") then the rule will be evaluated before one-to-one NAT. Examples: +eth0 +eth1:192.0.2.32/27 Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by following the interface name by ":" but no digit. Examples: eth0: eth1::192.0.2.32/27 +eth3: 3) Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows you to override the setting of ADD_IP_ALIASES=Yes by following the interface name with ":" but no digit. 4) All configuration files in the Shorewall distribution with the exception of shorewall.conf are now empty. In particular, the /etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos files now have no active entries. Hopefully this will stop the questions on the support and development lists regarding why the default entries are the way they are. 5) Previously, including a log level (and optionally a log tag) on a rule that specified a user-defined (or Shorewall-defined) action would log all traffic passed to the action. Beginning with this release, specifying a log level in a rule that specifies a user- or Shorewall-defined action will cause each rule in the action to be logged with the specified level (and tag). The extent to which logging of action rules occurs is goverend by the following: a) When you invoke an action and specify a log level, only those rules in the action that have no log level will be changed to log at the level specified at the action invocation. Example: /etc/shorewall/action.foo: ACCEPT - - tcp 22 bar:info /etc/shorewall/rules: foo:debug fw net Logging in the invoked 'foo' action will be: ACCEPT:debug - - tcp 22 bar:info b) If you follow the log level with "!" then logging will be at that level for all rules recursively invoked by the action Example: /etc/shorewall/action.foo: ACCEPT - - tcp 22 bar:info /etc/shorewall/rules: foo:debug! fw net Logging in the invoke 'foo' action will be: ACCEPT:debug - - tcp 22 bar:debug! This change has an effect on extension scripts used with user-defined actions. If you define an action 'acton' and you have an /etc/shorewall/acton script then when that script is invoked, the following three variables will be set for use by the script: $CHAIN = the name of the chain where your rules are to be placed. When logging is used on an action invocation, Shorewall creates a chain with a slightly different name from the action itself. $LEVEL = Log level. If empty, no logging was specified. $TAG = Log Tag. Example: /etc/shorewall/rules: acton:info:test Your /etc/shorewall/acton file will be run with: $CHAIN="%acton1" $LEVEL="info" $TAG="test" 6) The /etc/shorewall/startup_disabled file is no longer created when Shorewall is first installed. Rather, the variable STARTUP_ENABLED is set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall to start, that variable's value must be set to 'Yes'. This change accomplishes two things: a) It prevents Shorewall from being started prematurely by the user's initialization scripts. b) It causes /etc/shorewall/shorewall.conf to be modified so that it won't be replaced by upgrades using RPM. 7) Some additional support has been added for the 2.6 Kernel IPSEC implementation. To use this support, you must have installed the IPSEC policy match patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The policy match patch affects both your kernel and iptables. There are two ways to specify that IPSEC is to be used when communicating with a set of hosts; both methods involve the new /etc/shorewall/ipsec file: a) If encrypted communication is used with all hosts in a zone, then you can designate the zone as an "ipsec" zone by placing 'Yes" in the IPSEC ONLY column in the /etc/shorewall/ipsec: #ZONE IPSEC OPTIONS ... # ONLY vpn Yes The hosts in the zone (if any) must be specified in /etc/shorewall/hosts but you do not need to specify the 'ipsec' option on the entries in that file (see below). Dynamic zones involving IPSEC must use that technique. Example: Under 2.4 Kernel FreeS/Wan: /etc/shorewall/zones: net Net The big bad Internet vpn VPN Remote Network /etc/shorewall/interfaces: net eth0 ... vpn ipsec0 ... Under 2.6 Kernel with this new support: /etc/shorewall/zones: net Net The big bad Internet vpn VPN Remote Network /etc/shorewall/interfaces: net eth0 ... /etc/shorewall/hosts: vpn eth0:0.0.0.0/0 /etc/shorewall/ipsec vpn Yes b) If only part of the hosts in a zone require encrypted communication, you may use of the new 'ipsec' option in /etc/shorewall/hosts to designate those hosts. Example: Under 2.4 Kernel FreeS/Wan: /etc/shorewall/zones: net Net The big bad Internet loc Local Extended local zone /etc/shorewall/interfaces: net eth0 ... loc eth1 ... loc ipsec0 ... Under 2.6 Kernel with this new support: /etc/shorewall/zones: net Net The big bad Internet vpn VPN Remote Network /etc/shorewall/interfaces: net eth0 ... loc eth1 ... /etc/shorewall/hosts: vpn eth0:0.0.0.0/0 ipsec,... Regardless of which technique you choose, you can specify additional SA options for the zone in the /etc/shorewall/ipsec entry. The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the input-output, input and output characteristics of the security policies to be used to decrypt (input) or encrypt (output) traffic to/from the zone. The available options are: reqid[!]= where is specified using setkey(8) using the 'unique:' option for the SPD level. spi[!]= where is the SPI of the SA. Since different SAs are used to encrypt and decrypt traffic, this option should only be listed in the IN OPTIONS and OUT OPTIONS columns. proto[!]=ah|esp|ipcomp mss= (sets the MSS value in TCP SYN packets and is not related to policy matching) mode[!]=transport|tunnel tunnel-src[!]=
[/] (only available with mode=tunnel) tunnel-dst[!]=
[/] (only available with mode=tunnel). Because tunnel source and destination are dependent on the direction of the traffic, these options should only appear in the IN OPTIONS and OUT OPTIONS columns. strict (if specified, packets must match all policies; policies are delimited by 'next'). next (only available with strict) Examples: #ZONE IPSEC OPTIONS IN OUT... # ONLY OPTIONS OPTIONS vpn Yes mode=tunnel,proto=esp spi=1000 spi=1001 loc No reqid=44,mode=transport The /etc/shorewall/masq file has a new IPSEC column added. If you specify Yes or yes in that column then the unencrypted packets will have their source address changed. Otherwise, the unencrypted packets will not have their source addresses changed. This column may also contain a comma-separated list of the options specified above in which case only those packets that will be encrypted by an SA matching the given options will have their source address changed. 8) To improve interoperability, tunnels of type 'ipsec' no longer enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no longer enforce use of the specified port as both the source and destination ports. 9) A new 'allowBcast' builtin action has been added -- it silently allows broadcasts and multicasts. 10) The -c option in /sbin/shorewall commands is now deprecated. The commands where -c was previously allowed now permit you to specify a configuration directory after the command: shorewall check [ ] shorewall restart [ ] shorewall start [ ] 11) Normally, when SNAT or MASQUERADE is applied to a tcp or udp connection, Netfilter attempts to retain the source port number. If it has to change to port number to avoid , conflicts, it tries to do so within port ranges ( < 512, 512-1023, and > 1023). You may now specify an explicit range of source ports to be used by following the address or address range (if any) in the ADDRESS column with ":" and a port range in the format -. You must specify either "tcp" or "udp" in the PROTO column. Examples 1 -- MASQUERADE with tcp source ports 4000-5000: #INTERFACE SUBNET ADDRESS PROTO eth0 192.168.1.0/24 :4000-5000 tcp Example 2 -- SNAT with udp source ports 7000-8000: #INTERFACE SUBNET ADDRESS PROTO eth0 10.0.0.0/8 192.0.2.44:7000-8000 udp 12) You may now account by user/group ID for outbound traffic from the firewall itself with entries in /etc/shorewall/accounting. Such accounting rules must be placed in the OUTPUT chain. See the comments at the top of /etc/shorewall/accounting for details. 13) Shorewall now verifies that your kernel and iptables have physdev match support if BRIDGING=Yes in shorewall.conf. 14) Beginning with this release, if your kernel and iptables have iprange match support (see the output from "shorewall check"), then with the exception of the /etc/shorewall/netmap file, anywhere that a network address may appear an IP address range of the form - may also appear. 15) Support has been added for the iptables CLASSIFY target. That target allows you to classify packets for traffic shaping directly rather than indirectly through fwmark. Simply enter the : classification in the first column of /etc/shorewall/tcrules: Example: #MARK/ SOURCE DEST PROTO PORT(S) #CLASSIFY 1:30 - - tcp 25 Marking using the CLASSIFY target always occurs in the POSTROUTING chain of the mangle table and is not affected by the setting of MARK_IN_FORWARD_CHAIN in shorewall.conf. 16) During "shorewall start", IP addresses to be added as a consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed then the are re-added later. This is done to help ensure that the addresses can be added with the specified labels but can have the undesirable side effect of causing routes to be quietly deleted. A new RETAIN_ALIASES option has been added to shorewall.conf; when this option is set to Yes, existing addresses will not be deleted. Regardless of the setting of RETAIN_ALIASES, addresses added during "shorewall start" are still deleted at a subsequent "shorewall stop" or "shorewall restart". 17) Users with a large black list (from /etc/shorewall/blacklist) may want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before loading the blacklist rules. While this may allow connections from blacklisted hosts to slip by during construction of the blacklist, it can substantially reduce the time that all new connections are disabled during "shorewall [re]start". 18) Using the default LOGFORMAT, chain names longer than 11 characters (such as in user-defined actions) may result in log prefix truncation. A new shorewall.conf action LOGTAGONLY has been added to deal with this problem. When LOGTAGONLY=Yes, logging rules that specify a log tag will substitute the tag for the chain name in the log prefix. Example -- file /etc/shorewall/action.thisisaverylogactionname: Rule: DROP:info:ftp 0.0.0.0/0 0.0.0.0/0 tcp 21 Log prefix with LOGTAGONLY=No: Shorewall:thisisaverylongacti Log prefix with LOGTAGONLY=Yes: Shorewall:ftp:DROP 19) Shorewall now resets the 'accept_source_route' flag for all interfaces. If you wish to accept source routing on an interface, you must specify the new 'sourceroute' interface option in /etc/shorewall/interfaces. 20) The default Drop and Reject actions now invoke the new standard action 'AllowICMPs'. This new action accepts critical ICMP types: Type 3 code 4 (fragmentation needed) Type 11 (TTL exceeded) 21) Explicit control over the kernel's Martian logging is now provided using the new 'logmartians' interface option. If you include 'logmartians' in the interface option list then logging of Martian packets on will be enabled on the specified interface. If you wish to globally enable martian logging, you can set LOG_MARTIANS=Yes in shorewall.conf. 22) You may now cause Shorewall to use the '--set-mss' option of the TCPMSS target. In other words, you can cause Shorewall to set the MSS field of SYN packets passing through the firewall to the value you specify. This feature extends the existing CLAMPMSS option in /etc/shorewall/shorewall.conf by allowing that option to have a numeric value as well as the values "Yes" and "No". Example: CLAMPMSS=1400 23) Shorewall now includes support for the ipp2p match facility. This is a departure from my usual policy in that the ipp2p match facility is included in Patch-O-Matic-NG and is unlikely to ever be included in the kernel.org source tree. Questions about how to install the patch or how to build your kernel and/or iptables should not be posted on the Shorewall mailing lists. In the following files, the "PROTO" or "PROTOCOL" column may contain "ipp2p": /etc/shorewall/rules /etc/shorewall/tcrules /etc/shorewall/accounting When the PROTO or PROTOCOL column contains "ipp2p" then the DEST PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a list of the options and their meaning, at a root prompt: iptables -m ipp2p --help You must not include the leading "--" on the option; Shorewall will supply those characters for you. If you do not include an option then "ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p"). 24) Shorewall now has support for the CONNMARK target from iptables. See the /etc/shorewall/tcrules file for details. 25) A new debugging option LOGALLNEW has been added to shorewall.conf. When set to a log level, this option causes Shorewall to generaate a logging rule as the first rule in each builtin chain. - The table name is used as the chain name in the log prefix. - The chain name is used as the target in the log prefix. Example: Using the default LOGFORMAT, the log prefix for logging from the nat table's PREROUTING chain is: Shorewall:nat:PREROUTING IMPORTANT: There is no rate limiting on these logging rules so use LOGALLNEW at your own risk; it may cause high CPU and disk utilization and you may not be able to control your firewall after you enable this option. DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE SENT TO ANOTHER SYSTEM. 26) The SUBNET column in /etc/shorewall/rfc1918 has been renamed SUBNETS and it is now possible to specify a list of addresses in that column.