Shorewall News and Announcements

Tom Eastep

Copyright © 2001-2005 Thomas M. Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

2005-10-05

10/05/2005 Shorewall 2.4.5
Problems Corrected in 2.4.5

  1. In previous versions, when the command is 'start', 'restart' or 'stop' then OUTPUT traffic to hosts listed in /etc/shorewall/routestopped is not enabled if ADMINISABSENTMINDED=Yes. That traffic is now enabled independent of the setting of ADMINISABSENTMINDED.
  2. Although it was documented that icmp types could be used in the tcrules file, the code did not support it. Thanks to Jorge Molina, that problem is now corrected.
  3. In a multi-ISP configuration, fwmark routing rules now have a higher priority than source IP rules. This allows entries in tcrules to be more effective in controlling routing.
  4. Previously, not all of the mangle chains were flushed during "shorewall restart".
09/12/2005 Shorewall 2.4.4

Problems Corrected
  1. An incorrect comment in the /etc/shorewall/proxyarp file has been removed.
  2. The message generated when a duplicate policy has been entered is now more informative. Previously, only the POLICY column contents appeared in the message. Now the SOURCE, DEST and POLICY column contents are shown.
  3. Shorewall now clears the Netfilter "raw" table during "shorewall [re]start", "shorewall stop" and "shorewall clear" processing.
New Features
  1. Tunnel types "openvpnserver" and "openvpnclient" have been added to reflect the introduction of client and server OpenVPN configurations in OpenVPN 2.0.
  2. The COMMAND variable is now set to 'restore' in restore scripts. The value of this variable is sometimes of interest to programmers providing custom /etc/shorewall/tcstart scripts.
08/16/2005 Shorewall 2.4.3

Problems Corrected:
  1. Shorewall is no longer dependent on the 'which' utility.
  2. The 'shorewall add' command failed if there existed a zone in the configuration that specified the 'ipsec' option in /etc/shorewall/hosts.
  3. Shorewall is no longer dependent on /bin/echo.
  4. A CLASSIFY rule  with $FW in the SOURCE column (tcrules) no longer results in a "shorewall start" error.
  5. You may now use port lists in the DEST PORT and SOURCE PORT columns of the /etc/shorewall/accounting file.
  6. The "shorewall show capabilities" command now accurately reports the availability of "Packet type match" independent of the setting of PKTTYPE in shorewall.conf.
  7. Thanks to Tuomo Soini, all of the files have been siginificantly cleaned up in terms of formatting and extra white-space.
New Features:
  1. New Allow.Submission and Allow.NTPbrd actions have been added. Users of the Allow.NTP action that use NTP broadcasting should switch to use of Allow.NTPbrd instead.
  2. The kernel version string is now included in the output of "shorewall status".
07/30/2005 Shorewall 2.2.6

Problems Corrected:
  1. MACLIST_TTL Vulnerability fix.
  2. TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of iptables.
  3. The bogons file has been updated to reflect recent IANA allocations.
07/21/2005 Shorewall 2.4.2

Problems Corrected:
  1. The /etc/shorewall/hosts file now includes information about defining a zone using one or more ipsets.
  2. A vulnerability involving MACLIST_TTL > 0 or MACLIST_DISPOSITION=ACCEPT has been corrected.
  3. It is now possible to specify !<address> in the SUBNET column of /etc/shorewall/masq. Previously, it was necessary to write 0.0.0.0/0!<address>.
  4. When <network1>!<network2> was specified in the SUBNET column of /etc/shorewall/masq, IPSEC policies were not correctly applied to the resulting rules. This usually resulted in IPSEC not working through the interface specified in the INTERFACES column.
New Features:
  1. A 'loose' provider option has been added. If you wish to be able to use marking to specify the gateway used by connections originating on the firewall itself, the specify 'loose' for each provider. It has bee reported that 'loose' may break the effect of 'track' so beware if you need 'track' functionality (you shouldn't be originating many connections from your firewall to the net anyway).

    To use 'loose', you also need to add two entries in /etc/shorewall/masq:
    #INTERFACE           SUBNET          ADDRESS
    
   $IF_ISP1             $IP_ISP2        $IP_ISP1
    
   $IF_ISP2             $IP_ISP1        $IP_ISP2
    where:
            $IF_ISP1        is the interface to ISP 1.
    
        $IF_ISP2        is the interface to ISP 2.
    
        $IP_ISP1        is the IP address of $IF_ISP1
    
        $IP_ISP2        is the IP address of $IF_ISP2
  2. /sbin/shorewall now issues a warning each time that it finds that startup is disabled.
  3. A new COPY column has been added to the /etc/shorewall/providers file. Normally, when a table name/number is given in the DUPLICATE column, the entire table (less default routes) is copied. The COPY column allows you to limit the routes copied to those that go through an interface listed in COPY. For example, if you enter eth0 in INTERFACE, "eth1,eth2" in COPY and 'main' in DUPLICATE then the new table created will contain those routes through the interfaces eth0, eth1 and eth2.

07/17/2005 Security vulnerability in MACLIST processing

Description

A security vulnerability has been discovered which affects all supported stable versions of Shorewall.  This vulnerability enables a client accepted by MAC address filtering to bypass any other rule.  If MACLIST_TTL is set to a value greater than 0 or MACLIST_DISPOSITION is set to "ACCEPT" in /etc/shorewall/shorewall.conf (default is MACLIST_TTL=0 and MACLIST_DISPOSITION=REJECT), and a client is positively identified through its MAC address, it bypasses all other policies/rules in place, thus gaining access to all open services on the firewall.

Fix

Workaround

For Shorewall 2.2.x or 2.4.x, set MACLIST_TTL=0 or MACLIST_DISPOSITION=REJECT in /etc/shorewall/shorewall.conf.  For Shorewall 2.0.x, set MACLIST_DISPOSITION=REJECT in /etc/shorewall/shorewall.conf.  MACLIST filtering is of limited value on Internet-connected hosts, and the Shorewall team recommends this approach to be used if possible.

Upgrade

For Shorewall 2.4.x, a fixed version of the 'firewall' script is available at: http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall and its mirrors, http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall and http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall.

For Shorewall 2.2.x, a fixed version of the 'firewall' script is available at: http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall and its mirrors, http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall and http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall.

For Shorewall 2.0.x, a fixed version of the 'firewall' script is available at: http://shorewall.net/pub/shorewall/errata/2.0.17/firewall and its mirrors, http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall and http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall.

Users of any version before 2.0.17 are urged to upgrade to a supported version of Shorewall (preferably 2.4.1) before using the fixed files.  Only the most recent version of the 2.0.x and 2.2.x streams will be supported by the development team, and the 1.x branches are no longer maintained at all.  Future releases of Shorewall will include this fix.

This information was based on Patrick Blitz's post to the Full Disclosure mailing list.  Thanks to Supernaut (supernaut at ns dot sympatico dot ca) for reporting this bug.

Version Upgrade

The vulnerability is corrected in Shorewall 2.4.2 and in Shorewall 2.2.6.

07/13/2005 Shorewall 2.4.1

Problems Corrected:
  1. Shell variables may now be used in the zones file.
  2. The /usr/share/shorewall/bogons file has been updated to reflect recent IANA allocations.
  3. Shorewall now detects an error where multiple providers specify the 'track' option on the same interface.
  4. The remnants of the GATEWAY column in /etc/shorewall/interfaces have been removed. This column appeared briefly in one of the Beta versions and was immediately removed but some vestiges remained.
  5. Shorewall now correctly restores a load-balancing default route during processing of the 'shorewall restore' and 'shorewall -f start' commands. The latter command is normally executed by the Shorewall init script during reboot.
  6. A log level of "None!" is now allowed on builtin actions such as ACCEPT and DROP.
  7. Previously, LIMIT:BURST parameters in /etc/shorewall/policy were not correctly applied when the policy was QUEUE.
  8. The 'chkconfig' command on FC4 and Mandriva previously created symbolic links with incorrect names ("S-1shorewall"). The init script has been changed to prevent this incorrect behavior.
  9. DHCP traffic forwarded through a bridge could, under some configurations, be filtered by the 'maclist' option even though the 'dhcp' option was specified. This has been corrected.
06/05/2005 Shorewall 2.4.0

Note: Because of the short time that has elapsed since the release of Shorewall 2.2.0, Shorewall 2.0 will be supported until 1 December 2005 or until the release of Shorewall 2.6.0, whichever occurs first.

New Features:
  1. Shorewall 2.4.0 includes support for multiple internet interfaces to different ISPs.

    The file /etc/shorewall/providers may be used to define the different providers. It can actually be used to define alternate routing tables so uses like transparent proxy can use the file as well.

    Columns are:

           NAME            The provider name.

           NUMBER          The provider number -- a number between 1 and 15

           MARK            A FWMARK value used in your /etc/shorewall/tcrules file to direct packets for this provider.

           DUPLICATE       The name of an existing table to duplicate. May be 'main' or the name of a previous provider.

           INTERFACE       The name of the network interface to the provider. Must be listed in/etc/shorewall/interfaces.

           GATEWAY         The IP address of the provider's gateway router. If you enter "detect" here then Shorewall
                           will     attempt to determine the gateway IP address automatically.

           OPTIONS         A comma-separated list selected from the following:

                   track   If specified, connections FROM this interface are to be tracked so that responses may be
                           routed     back out this same interface.

                           You want specify 'track' if internet hosts will be connecting to local servers through
                           this     provider.

                           Because of limitations in the 'ip' utility and policy routing, you may not use the SAVE or
                           RESTORE tcrules options or use connection    marking on any traffic to or from this
                           interface. For traffic control purposes, you must mark packets in the FORWARD chain (or
                           better yet, use the CLASSIFY target).

                   balance The providers that have 'balance' specified will get outbound traffic load-balanced among
                           them. By     default, all interfaces with 'balance' specified will have the same weight (1).
                           You can change the    weight of the route out of the interface by specifiying balance=<weight>
                           where <weight> is    the desired route weight.

           Example:  You run squid in your DMZ on IP address 192.168.2.99. Your DMZ interface is eth2

           #NAME   NUMBER  MARK DUPLICATE  INTERFACE GATEWAY       OPTIONS
           Squid   1       1    -          eth2      192.168.2.99  -

    Use of this feature requires that your kernel and iptabls support CONNMARK target and conntrack match support. It does NOT require the ROUTE target extension.

    WARNING: The current version of iptables (1.3.1) is broken with respect to CONNMARK and iptables-save/iptables-restore. This means that if you configure multiple ISPs, "shorewall restore" may fail. You must patch your iptables using the patch at http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff.

  2. Shorewall 2.3.0 supports the 'cmd-owner' option of the owner match facility in Netfilter. Like all owner match options, 'cmd-owner' may only be applied to traffic that originates on the firewall.

    The syntax of the USER/GROUP column in the following files has been extended:

            /etc/shorewall/accounting
            /etc/shorewall/rules
            /etc/shorewall/tcrules
            /usr/share/shorewall/action.template

    To specify a command, prefix the command name with "+".

       Examples:

            +mozilla-bin            #The program is named "mozilla-bin"
            joe+mozilla-bin         #The program is named "mozilla-bin" and
                                    #is being run by user "joe"
            joe:users+mozilla-bin   #The program is named "mozilla-bin" and
                                    #is being run by user "joe" with
                                    #effective group "users".

       Note that this is not a particularly robust feature and I would never advertise it as a "Personal Firewall" equivalent. Using symbolic links, it's easy to alias command names to be anything you want.

  3. Support has been added for ipsets (see http://people.netfilter.org/kadlec/ipset/).

    In most places where a host or network address may be used, you may also use the name of an ipset prefaced by "+".

            Example: "+Mirrors"

    The name of the set may be optionally followed by:

    a) a number from 1 to 6 enclosed in square brackets ([]) -- this number indicates the maximum number of ipset binding levels that are to be matched. Depending on the context where the ipset name is used, either all "src" or all "dst" matches will be used.

            Example: "+Mirrors[4]"

    b) a series of "src" and "dst" options separated by commas and inclosed in square brackets ([]). These will be passed directly to iptables in the generated --set clause. See the ipset documentation for details.

            Example: "+Mirrors[src,dst,src]"

    Note that "+Mirrors[4]" used in the SOURCE column of the rules file is equivalent to "+Mirrors[src,src,src,src]".

    To generate a negative match, prefix the "+" with "!" as in "!+Mirrors".

    Example 1: Blacklist all hosts in an ipset named "blacklist"

               /etc/shorewall/blacklist

               #ADDRESS/SUBNET         PROTOCOL        PORT
               +blacklist

    Example 2: Allow SSH from all hosts in an ipset named "sshok:

               /etc/shorewall/rules

               #ACTION      SOURCE      DEST     PROTO    DEST PORT(S)
               ACCEPT       +sshok      fw       tcp      22

    Shorewall can automatically capture the contents of your ipsets for you. If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf then "shorewall save" will save the contents of your ipsets. The file where the sets are saved is formed by taking the name where the Shorewall configuration is stored and appending "-ipsets". So if you enter the command "shorewall save standard" then your Shorewall configuration will be saved in var/lib/shorewall/standard and your ipset contents will be saved in /var/lib/shorewall/standard-ipsets. Assuming the default RESTOREFILE setting, if you just enter "shorewall save" then your Shorewall configuration will be saved in /var/lib/shorewall/restore and your ipset contents will be saved in /var/lib/shorewall/restore-ipsets.

    Regardless of the setting of SAVE_IPSETS, the "shorewall -f start" and "shorewall restore" commands will restore the ipset contents corresponding to the Shorewall configuration restored provided that the saved Shorewall configuration specified exists.

    For example, "shorewall restore standard" would restore the ipset contents from /var/lib/shorewall/standard-ipsets provided that /var/lib/shorewall/standard exists and is executable and that /var/lib/shorewall/standard-ipsets exists and is executable.

    Also regardless of the setting of SAVE_IPSETS, the "shorewall forget" command will purge the saved ipset information (if any) associated with the saved shorewall configuration being removed.

    You can also associate ipset contents with Shorewall configuration directories using the following command:

           ipset -S > <config directory>/ipsets

    Example:

           ipset -S > /etc/shorewall/ipsets

    When you start or restart Shorewall (including using the 'try' command) from the configuration directory, your ipsets will be configured from the saved ipsets file. Once again, this behavior is independent of the setting of SAVE_IPSETS.

    Ipsets are well suited for large blacklists. You can maintain your blacklist using the 'ipset' utility without ever having to restart or refresh Shorewall. If you use the SAVE_IPSETS=Yes feature just be sure to "shorewall save" after altering the blacklist ipset(s).

    Example /etc/shorewall/blacklist:

       #ADDRESS/SUBNET         PROTOCOL        PORT
       +Blacklist[src,dst]
       +Blacklistnets[src,dst]

    Create the blacklist ipsets using:

              ipset -N Blacklist iphash
              ipset -N Blacklistnets nethash

    Add entries

           ipset -A Blacklist 206.124.146.177
           ipset -A Blacklistnets 206.124.146.0/24

    To allow entries for individual ports

           ipset -N SMTP portmap --from 1 --to 31
           ipset -A SMTP 25

           ipset -A Blacklist 206.124.146.177
           ipset -B Blacklist 206.124.146.177 -b SMTP

    Now only port 25 will be blocked from 206.124.146.177.

  4. Shorewall 2.4.0 can now configure routing if your kernel and iptables support the ROUTE target extension. This extension is available in Patch-O-Matic-ng. This feature is *EXPERIMENTAL* since the Netfilter team have no intention of ever releasing the ROUTE target extension to kernel.org.

    Routing is configured using the /etc/shorewall/routes file. Columns in the file are as follows:

          SOURCE            Source of the packet. May be any of the following:


                            - A host or network address
                            - A network interface name.
                            - The name of an ipset prefaced with "+"
                            - $FW (for packets originating on the firewall)
                            - A MAC address in Shorewall format
                            - A range of IP addresses (assuming that your kernel and iptables support range match)
                            - A network interface name followed by ":" and an address or address range.

            DEST            Destination of the packet. May be any of the following:

                            - A host or network address
                            - A network interface name (determined from
                              routing table(s))
                            - The name of an ipset prefaced with "+"
                            - A network interface name followed by ":"
                              and an address or address range.

            PROTO           Protocol - Must be "tcp", "udp", "icmp", "ipp2p", a number, or "all". "ipp2p" requires
                            ipp2p match support in your kernel and    iptables.

            PORT(S)         Destination Ports. A comma-separated list of Port names (from /etc/services), port
                            numbers     or port ranges; if the protocol is "icmp", thiscolumn is interpreted as the
                            destination     icmp-type(s).

                            If the protocol is ipp2p, this column is interpreted as an ipp2p option without the
                            leading "--" (example "bit" for bit-torrent).     If no PORT is given, "ipp2p" is assumed.

                            This column is ignored if PROTOCOL = all but must be entered if any of the following
                            field     is supplied. In that case, it is suggested that this field contain "-"

            SOURCE PORT(S)  (Optional) Source port(s). If omitted, any source port is acceptable. Specified as a
                            comma-separated list of port names, port     numbers or port ranges.

            TEST            Defines a test on the existing packet or connection mark.

                            The rule will match only if the test returns true. Tests have the format
                            [!]<value>[/<mask>][:C]

                            Where:

                                    !       Inverts the test (not equal) <value> Value of the packet or
                                            connection mark.

                                    <mask>  A mask to be applied to the mark before testing
                                    :C      Designates a connection mark. If omitted, the packet mark's value
                                            is tested.

            INTERFACE       The interface that the packet is to be routed out of. If you do not specify this
                            field then     you must place "-" in this column and enter an IP address in the GATEWAY
                            column.

            GATEWAY         The gateway that the packet is to be forewarded through.

  5. Normally when Shorewall is stopped, starting or restarting then connections are allowed from hosts listed in /etc/shorewall/routestopped to the firewall and to other hosts listed in /etc/shorewall/routestopped.

    A new 'source' option is added for entries in that file which will cause Shorewall to allow traffic from the host listed in the entry to ANY other host. When 'source' is specified in an entry, it is unnecessary to also specify 'routeback'.

    Similarly, a new 'dest' option is added which will cause Shorewall to allow traffic to the host listed in the entry from ANY other host. When 'source' is specified in an entry, it is unnecessary to also specify 'routeback'.

  6. This change was implemented by Lorenzo Martignoni. It provides two new commands: "safe-start" and "safe-restart".

    safe-start starts Shorewall then prompts you to ask you if everything looks ok. If you answer "no" or if you don't answer within 60 seconds, a "shorewall clear" is executed.

    safe-restart saves your current configuration to /var/lib/shorewall/safe-restart then issues a "shorewall restart"; It then prompts you to ask if you if you want to accept the new configuration. If you answer "no" or if you don't answer within 60 seconds, the configuration is restored to its prior state.

    These new commands require either that your /bin/sh supports the "-t" option to the 'read' command or that you have /bin/bash installed.
Old News here