diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index 17fbb5227..0254b5dd2 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -1,948 +1,767 @@ - - - - - - Shorewall News - - - -

Shorewall News and - Announcements
-

- Tom Eastep
+ + + + Shorewall News + + +

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-05-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. +
  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. +
  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. +
  4. Previously, not all of the mangle chains were flushed during +"shorewall restart".
    5. +
+09/12/2005 Shorewall 2.4.4
+
+Problems Corrected
+
    +
  1. An incorrect comment in the /etc/shorewall/proxyarp file has been +removed.
    2. +
  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. +
  3. Shorewall now clears the Netfilter "raw" table during "shorewall +[re]start", "shorewall stop" and "shorewall clear" processing.
    4. +
+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. +
  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.
    +
    3. +
+08/16/2005 Shorewall 2.4.3
+
+Problems Corrected:
+
    +
  1. Shorewall is no longer dependent on the 'which' utility.
    2. +
  2. The 'shorewall add' command failed if there existed a zone in the +configuration that specified the 'ipsec' option in /etc/shorewall/hosts.
    3. +
  3. Shorewall is no longer dependent on /bin/echo.
    4. +
  4. A CLASSIFY rule  with $FW in the SOURCE column (tcrules) no +longer results in a "shorewall start" error.
    5. +
  5. You may now use port lists in the DEST PORT and SOURCE PORT +columns of the /etc/shorewall/accounting file.
    6. +
  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. +
  7. Thanks to Tuomo Soini, all of the files have been siginificantly +cleaned up in terms of formatting and extra white-space.
    +
    8. +
+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. +
  2. The kernel version string is now included in the output of +"shorewall status".
    +
    3. +
+07/30/2005 Shorewall 2.2.6
+
+Problems Corrected:
+
    +
  1. MACLIST_TTL Vulnerability fix.
    2. +
  2. TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of iptables.
    3. +
  3. The bogons file has been updated to reflect recent IANA +allocations.
    4. +
+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. +
  2. A vulnerability involving MACLIST_TTL > 0 +or MACLIST_DISPOSITION=ACCEPT has been corrected.
    3. +
  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. +
  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.
    +
    5. +
+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).

    - 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-09-12
    -

    -
    - 09/12/2005 Shorewall 2.4.4
    -
    - Problems Corrected
    - -
      -
    1. An incorrect comment in the /etc/shorewall/proxyarp file - has been removed.
      2. - -
    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. - -
    3. Shorewall now clears the Netfilter "raw" table during - "shorewall [re]start", "shorewall stop" and "shorewall clear" - processing.
      4. -
    - 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. - -
    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.
      -
      3. -
    - 08/16/2005 Shorewall 2.4.3
    -
    - Problems Corrected:
    - -
      -
    1. Shorewall is no longer dependent on the 'which' - utility.
      2. - -
    2. The 'shorewall add' command failed if there existed a - zone in the configuration that specified the 'ipsec' option - in /etc/shorewall/hosts.
      3. - -
    3. Shorewall is no longer dependent on /bin/echo.
      4. - -
    4. A CLASSIFY rule  with $FW in the SOURCE column - (tcrules) no longer results in a "shorewall start" - error.
      5. - -
    5. You may now use port lists in the DEST PORT and SOURCE - PORT columns of the /etc/shorewall/accounting file.
      6. - -
    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. - -
    7. Thanks to Tuomo Soini, all of the files have been - siginificantly cleaned up in terms of formatting and extra - white-space.
      -
      8. -
    - 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. - -
    2. The kernel version string is now included in the output - of "shorewall status".
      -
      3. -
    - 07/30/2005 Shorewall 2.2.6
    -
    -     Problems Corrected:
    - -
      -
    1. MACLIST_TTL Vulnerability - fix.
      2. - -
    2. TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of - iptables.
      3. - -
    3. The bogons file has been updated to reflect recent IANA - allocations.
      4. -
    - 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. - -
    2. A vulnerability involving MACLIST_TTL - > 0 or MACLIST_DISPOSITION=ACCEPT has been - corrected.
      3. - -
    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. - -
    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.
      -
      5. -
    - 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
      
+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.
      
+    
      
+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. - -
    2. /sbin/shorewall now issues a warning each time that it - finds that startup is disabled.
      3. - -
    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.
      -
      4. -
    - -
    - -

    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. - -
    2. The /usr/share/shorewall/bogons file has been updated to - reflect recent IANA allocations.
      3. - -
    3. Shorewall now detects an error where multiple providers - specify the 'track' option on the same interface.
      4. - -
    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. - -
    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. - -
    6. A log level of "None!" is now allowed on builtin actions - such as ACCEPT and DROP.
      7. - -
    7. Previously, LIMIT:BURST parameters in - /etc/shorewall/policy were not correctly applied when the - policy was QUEUE.
      8. - -
    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. - -
    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.
      -
      10. -
    - 06/05/2005 Shorewall 2.4.0
    + +
    2. +
  2. /sbin/shorewall now issues a warning each time that it finds that +startup is disabled.
    3. +
  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.
    +
    4. +
+
+

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. +
  2. The /usr/share/shorewall/bogons file has been updated to reflect +recent IANA allocations.
    3. +
  3. Shorewall now detects an error where multiple providers specify +the 'track' option on the same interface.
    4. +
  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. +
  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. +
  6. A log level of "None!" is now allowed on builtin actions such as +ACCEPT and DROP.
    7. +
  7. Previously, LIMIT:BURST parameters in /etc/shorewall/policy were +not correctly applied when the policy was QUEUE.
    8. +
  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. +
  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.
    +
    10. +
+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.

    - 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.
    +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.

    - 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. - -
    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. - -
    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. - -
    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. - -
    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. - -
    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.
      -
      7. -
    -Old News here
     - +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. +
  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. +
  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. +
  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. +
  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. +
  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.
    +
    7. +
+Old News here
+ + -