Shorewall 2.0.0b ---------------------------------------------------------------------- Problems Corrected since 1.4.10 1) A blank USER/GROUP column in /etc/shorewall/tcrules no longer causes a [re]start error. 2) The 'fgrep' utility is no longer required (caused startup problems on LEAF/Bering). 3) The "shorewall add" command no longer inserts rules before checking of the blacklist. 4) The 'detectnets' and 'routeback' options may now be used together with the intended effect. 5) The following syntax previously produced an error: DNAT z1!z2,z3 z4... Problems Corrected since RC2 1) CONTINUE rules now work again. 2) A comment in the rules file has been corrected. Problems Corrected since 2.0.0 1) Using actions in the manner recommended in the documentation results in a Warning that the rule is a policy. 2) Thanks to Sean Mathews, a long-time problem with Proxy ARP and IPSEC has been corrected. ----------------------------------------------------------------------- Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0: 1) The 'dropunclean' and 'logunclean' interface options are no longer supported. If either option is specified in /etc/shorewall/interfaces, an threatening message will be generated. 2) The NAT_BEFORE_RULES option has been removed from shorewall.conf. The behavior of Shorewall is as if NAT_BEFORE_RULES=No had been specified. In other words, DNAT rules now always take precidence over one-to-one NAT specifications. 3) The default value for the ALL INTERFACES column in /etc/shorewall/nat has changed. In Shorewall 1.*, if the column was left empty, a value of "Yes" was assumed. This has been changed so that a value of "No" is now assumed. 4) The following files don't exist in Shorewall 2.0: /etc/shorewall/common.def /etc/shorewall/common /etc/shorewall/icmpdef /etc/shorewall/action.template (Moved to /usr/share/shorewall) /etc/shorewall/rfc1918 (Moved to /usr/share/shorewall). The /etc/shorewall/action file now allows an action to be designated as the "common" action for a particular policy type by following the action name with ":" and the policy (DROP, REJECT or ACCEPT). The file /usr/share/shorewall/actions.std has been added to define those actions that are released as part of Shorewall. In that file are two actions as follows: Drop:DROP Reject:REJECT The "Drop" action is the common action for DROP policies while the "Reject" action is the default action for "REJECT" policies. These actions will be performed on packets prior to applying the DROP or REJECT policy respectively. In the first release, the difference between "Reject" and "Drop" is that "Reject" REJECTs SMB traffic while "Drop" silently drops such traffic. As described above, Shorewall allows a common action for ACCEPT policies but does not specify such an action in the default configuration. If for some reason, you don't wish to have a common DROP or REJECT action, just include :DROP or :REJECT respectively in your /etc/shorewall/actions file. The file /usr/share/shorewall/actions.std catalogs the standard actions and is processed prior to /etc/shorewall/actions. This causes a large number of actions to be defined. The files which define these aactions are also located in /usr/share/shorewall as is the he action template file (action.template). In the initial release, the following actions are defined: dropBcast #Silently Drops Broadcast Traffic dropNonSyn #Silently Drop Non-syn TCP packets DropSMB #Silently Drops Microsoft SMB Traffic RejectSMB #Silently Reject Microsoft SMB Traffic DropUPnP #Silently Drop UPnP Probes RejectAuth #Silently Reject Auth DropPing #Silently Drop Ping DropDNSrep #Silently Drop DNS Replies AllowPing #Accept Ping AllowFTP #Accept FTP AllowDNS #Accept DNS AllowSSH #Accept SSH AllowWeb #Allow Web Browsing AllowSMB #Allow MS Networking AllowAuth #Allow Auth (identd) AllowSMTP #Allow SMTP (Email) AllowPOP3 #Allow reading mail via POP3 AllowIMAP #Allow reading mail via IMAP AllowTelnet #Allow Telnet Access (not recommended for use over the #Internet) AllowVNC #Allow VNC, Displays 0-9 AllowVNCL #Allow access to VNC viewer in listen mode AllowNTP #Allow Network Time Protocol (ntpd) AllowRdate #Allow remote time (rdate). AllowNNTP #Allow network news (Usenet). AllowTrcrt #Allows Traceroute (20 hops) AllowSNMP #Allows SNMP (including traps) AllowPCA #Allows PCAnywhere (tm). Drop:DROP #Common rules for DROP policy Reject:REJECT #Common Action for Reject policy These actions may be used in the ACTION column of the rules column. So for example, to allow FTP from your loc zone to your firewall, you would place this rule in /etc/shorewall/rules: #ACTION SOURCE DEST AllowFTP loc fw if you want to redefine any of the Shorewall-defined actions, simply copy the appropriate action file from /usr/share/shorewall to /etc/shorewall and modify the copy as desired. Your modified copy will be used rather than the original one in /usr/share/shorewall. Note: The 'dropBcast' and 'dropNonSyn' actions are built into Shorewall and may not be changed. Beginning with version 2.0.0-Beta2, Shorewall will only create a chain for those actions that are actually used. 5) The /etc/shorewall directory no longer contains a 'users' file or a 'usersets' file. Similar functionality is now available using user-defined actions. Now, action files created by copying /usr/share/shorewall/action.template may now specify a USER and or GROUP name/id in the final column just like in the rules file (see below). It is thus possible to create actions that control traffic from a list of users and/or groups. The last column in /etc/shorewall/rules is now labeled USER/GROUP and may contain: [!][:] [!][:] [!]: [!]: [!]: [!]: [!]: [!]: 6) It is no longer possible to specify rate limiting in the ACTION column of /etc/shorewall/rules -- you must use the RATE LIMIT column. 7) Depending on which method you use to upgrade, if you have your own version of /etc/shorewall/rfc1918, you may have to take special action to restore it after the upgrade. Look for /etc/shorewall/rfc1918*, locate the proper file and rename it back to /etc/shorewall/rfc1918. The contents of that file will supercede the contents of /usr/share/shorewall/rfc1918. New Features: 1) The INCLUDE directive now allows absolute file names. 2) A 'nosmurfs' interface option has been added to /etc/shorewall/interfaces. When specified for an interface, this option causes smurfs (packets with a broadcast address as their source) to be dropped and optionally logged (based on the setting of a new SMURF_LOG_LEVEL option in shorewall.conf). 3) fw->fw traffic may now be controlled by Shorewall. There is no need to define the loopback interface in /etc/shorewall/interfaces; you simply add a fw->fw policy and fw->fw rules. If you have neither a fw->fw policy nor fw->fw rules, all fw->fw traffic is allowed. 4) There is a new PERSISTENT column in the proxyarp file. A value of "Yes" in this column means that the route added by Shorewall for this host will remain after a "shorewall stop" or "shorewall clear". 5) "trace" is now a synonym for "debug" in /sbin/shorewall commands. So to trace the "start" command, you could enter: shorewall trace start 2> /tmp/trace The trace information would be written to the file /tmp/trace. 6) When defining an ipsec tunnel in /etc/shorewall/tunnels, if you follow the tunnel type ("ipsec" or "ipsecnet") with ":noah" (e.g., "ipsec:noah"), then Shorewall will only create rules for ESP (protocol 50) and will not create rules for AH (protocol 51). 7) A new DISABLE_IPV6 option has been added to shorewall.conf. When this option is set to "Yes", Shorewall will set the policy for the IPv6 INPUT, OUTPUT and FORWARD chains to DROP during "shorewall [re]start" and "shorewall stop". Regardless of the setting of this variable, "shorewall clear" will silently attempt to set these policies to ACCEPT. If this option is not set in your existing shorewall.conf then a setting of DISABLE_IPV6=No is assumed in which case, Shorewall will not touch any IPv6 settings except during "shorewall clear". 8) The CONTINUE target is now available in action definitions. CONTINUE terminates processing of the current action and returns to the point where that action was invoked.