This is a minor release of Shorewall. Problems Corrected since version 1.4.6: 1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being tested before it was set. 2) Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command. 3) The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from shooting themselves in the foot prior to having configured Shorewall. 4) A change introduced in version 1.4.6 caused error messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP interface; the addresses were successfully added in spite of the messages. The firewall script has been modified to eliminate the error messages. Migration Issues: 1) Once you have installed this version of Shorewall, you must restart Shorewall before you may use the 'drop', 'reject', 'allow' or 'save' commands. 2) To maintain strict compatibility with previous versions, current uses of "shorewall drop" and "shorewall reject" should be replaced with "shorewall dropall" and "shorewall rejectall". New Features: 1) Shorewall now creates a dynamic blacklisting chain for each interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use the routing table to determine which of these chains is to be used for blacklisting the specified IP address(es). Two new commands ('dropall' and 'rejectall') have been introduced that do what 'drop' and 'reject' used to do; namely, when an address is blacklisted using these new commands, it will be blacklisted on all of your firewall's interfaces. 2) Thanks to Steve Herber, the help command can now give command-specific help. 3) A new option "ADMINISABSENTMINDED" has been added to /etc/shorewall/shorewall.conf. This option has a default value of "No" for existing Shorewall users who are upgrading to this release. With this setting, Shorewall's 'stopped' state continues as it has been; namely, in the stopped state only traffic to/from hosts listed in /etc/shorewall/routestopped is accepted. The default for new users installing Shorewall for the first time is ADMINISABSENTMINDED=Yes.With that setting, in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow: a) All traffic originating from the firewall itself; and b) All traffic that is part of or related to an already-existing connection. In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" entered through an ssh session will not kill the session. Note though that it is still possible for people to shoot themselves in the foot. Example: /etc/shorewall/nat: 206.124.146.178 eth0:0 192.168.1.5 /etc/shorewall/rules: ACCEPT net loc:192.168.1.5 tcp 22 ACCEPT loc fw tcp 22 I ssh into 206.124.146.178 which establishes an SSH connection with 192.168.1.5. I then create a second SSH connection from that computer to the firewall and confidently type "shorewall stop". As part of stopping, Shorewall removes eth0:0 which kills my SSH connection to 192.168.1.5!!! 4) Given the wide range of VPN software, I can never hope to add specific support for all of it. I have therefore decided to add "generic" tunnel support. Generic tunnels work pretty much like any of the other tunnel types. You usually add a zone to represent the systems at the other end of the tunnel and you add the appropriate rules/policies to implement your security policy regarding traffic to/from those systems. In the /etc/shorewall/tunnels file, you can have entries of the form: # TYPE ZONE GATEWAY GATEWAY ZONE generic:[:] where: is the protocol used by the tunnel if the protocol is 'udp' or 'tcp' then this is the destination port number used by the tunnel. is the zone of the remote tunnel gateway is the IP address of the remote tunnel gateway. Optional. A comma-separated list of zone names. If specified, the remote gateway is to be considered part of these zones. 5) An 'arp_filter' option has been added to the /etc/shorewall/interfaces file. This option causes /proc/sys/net/ipv4/conf//arp_filter to be set with the result that this interface will only answer ARP 'who-has' requests from hosts that are routed out of that interface. Setting this option facilitates testing of your firewall where multiple firewall interfaces are connected to the same HUB/Switch (all interfaces connected to the single HUB/Switch should have this option specified). Note that using such a configuration in a production environment is strongly recommended against. 6) The ADDRESS column in /etc/shorewall/masq may now include a comma-separated list of addresses and/or address ranges. Netfilter will use all listed addresses/ranges in round-robin fashion. 7) An /etc/shorewall/accounting file has been added to allow for traffic accounting. The file has two sections which will be described in reverse order. The second seciton of the file has the following columns: ACTION - What to do when a match is found. COUNT - Simply count the match and continue trying to match the packet with the following accounting rules DONE - Count the match and don't attempt to match any following accounting rules. - The name of a chain. Shorewall will create the chain automatically. If the name of the chain is followed by ":DONE" then after control returns from the named chain, the packet will not be matched against any of the following accounting rules. SOURCE - Packet Source The name of an interface, an address (host or net) or an interface name followed by ":" and a host or net address. DESTINATION - Packet Destination Format the same as the SOURCE column. PROTOCOL A protocol name (from /etc/protocols), a protocol number. DEST PORT Destination Port number Service name from /etc/services or port number. May only be specified if the protocol is TCP or UDP (6 or 17). SOURCE PORT Source Port number Service name from /etc/services or port number. May only be specified if the protocol is TCP or UDP (6 or 17). In all columns except the first, the values "-","any" and "all" are treated as wild-cards. The accounting rules are evaluated in the Netfilter 'filter' table. This is the same environment where the 'rules' file rules are evaluated and in this environment, DNAT has already occurred in inbound packets and SNAT has not yet occurred on outbound ones. The accounting rules are placed in a chain called "accounting" and can thus be displayed using "shorewall show accounting". It should be noted that where the ACTION is :DONE then the entry generates two rules in "accounting"; the first is a jump to the named chain and the second is a RETURN rule which causes the accounting chain to be exited. The first section of the file allows aggregation of counters in chains in other chains. It does this by allowing you to create an accounting chain hierarchy. This facility is described with an example at http://shorewall.net/Accounting.html.