diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index 143f6ca4f..59fdce88b 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -18,9 +18,589 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

-

2004-06-23
+

2004-10-25

+


+9/23/2004 - +Shorewall 2.0.9
+
+Problems Corrected:
+

+
    +
  1. Previously, an empty PROTO column or a value of "all" in that +column would cause errors when processing the /etc/shorewall/tcrules +file.
    2. +
+New Features:
+
    +
  1. The "shorewall status" command now includes the output of "brctl +show" if the bridge tools are installed.
    +
    2. +
+

9/20/2004 – Change in Shorewall Support

+

Friends,

+

The demands that my job and my +personal life are currently placing on me are such that supporing +Shorewall to the extent that I have been doing is just not possible +any more.

+

I will continue to be active on the +development list and will continue to develop Shorewall if at all +possible.

+

I will also continue to read the +user's list and will help with problems that interest me. But I am no +longer going to hop on every problem as soon as I see it.

+

This change means that I'm going to +have to depend on you folks to help each other; I'm confident that we +can make this work.

+

8/22/2004 - +Shorewall 2.0.8
+
+Problems Corrected:

+
    +
  1. +

    Entries in the USER/GROUP column of an action file (made from +action.template) may be ignored or cause odd errors.

    +
    2. +
+

7/29/2004 - Shorewall 2.0.7
+
+Problems +Corrected:

+
    +
  1. +

    The PKTTYPE option introduced in +version 2.0.6 is now used when generating rules to REJECT packets. +Broadcast packets are silently dropped rather than being rejected with +an ICMP (which is a protocol violation) and users whose kernels have +broken packet type match support are likely to see messages reporting +this violation. Setting PKTTYPE=No should cause these messages to +cease.

    +
    2. +
  2. +

    Multiple interfaces with the +'blacklist' option no longer result in an error message at startup.

    +
    3. +
  3. +

    The following has been added to /etc/shorewall/bogons:
    +
    +       0.0.0.0   RETURN
    +
    +This prevents the 'nobogons' option from logging DHCP 'DISCOVER' +broadcasts.

    +
    4. +
+

New Features:

+
    +
  1. +

    To improve supportability, the "shorewall status" command now +includes IP and Route configuration information.
    +
    +   Example:
    +
    +   IP Configuration
    +
    +   1: lo: <LOOPBACK,UP> mtu +16436 qdisc noqueue
    +      link/loopback +00:00:00:00:00:00 brd 00:00:00:00:00:00
    +      inet 127.0.0.1/8 +brd 127.255.255.255 scope host lo
    +      inet6 ::1/128 +scope host
    +   2: eth0: +<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen +1000
    +      link/ether +00:a0:c9:15:39:78 brd ff:ff:ff:ff:ff:ff
    +      inet6 +fe80::2a0:c9ff:fe15:3978/64 scope link
    +   3: eth1: +<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen +1000
    +      link/ether +00:a0:c9:a7:d7:bf brd ff:ff:ff:ff:ff:ff
    +      inet6 +fe80::2a0:c9ff:fea7:d7bf/64 scope link
    +   5: sit0@NONE: <NOARP> mtu +1480 qdisc noop
    +      link/sit 0.0.0.0 +brd 0.0.0.0
    +   6: eth2: +<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen +1000
    +      link/ether +00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff
    +      inet6 +fe80::240:d0ff:fe07:3a1b/64 scope link
    +   7: br0: +<BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc noqueue
    +      link/ether +00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff
    +      inet +192.168.1.3/24 brd 192.168.1.255 scope global br0
    +      inet6 +fe80::240:d0ff:fe07:3a1b/64 scope link
    +
    +   Routing Rules
    +
    +   0:      +from all lookup local
    +   32765:  from all +fwmark       ca lookup www.out
    +   32766:  from all lookup main
    +   32767:  from all lookup +default
    +
    +   Table local:
    +
    +   broadcast 192.168.1.0 dev +br0  proto kernel  scope link  src 192.168.1.3
    +   broadcast 127.255.255.255 dev +lo  proto kernel  scope link  src 127.0.0.1
    +   local 192.168.1.3 dev br0  +proto kernel  scope host  src 192.168.1.3
    +   broadcast 192.168.1.255 dev +br0  proto kernel  scope link  src 192.168.1.3
    +   broadcast 127.0.0.0 dev lo  +proto kernel  scope link  src 127.0.0.1
    +   local 127.0.0.1 dev lo  proto +kernel  scope host  src 127.0.0.1
    +   local 127.0.0.0/8 dev lo  +proto kernel  scope host  src 127.0.0.1
    +
    +   Table www.out:
    +
    +   default via 192.168.1.3 dev br0
    +
    +   Table main:
    +
    +   192.168.1.0/24 dev br0  proto +kernel  scope link  src 192.168.1.3
    +   default via 192.168.1.254 dev br0
    +
    +   Table default:

    +
    2. +
+

7/16/2004 - Shorewall 2.0.6
+
+Problems +Corrected:

+ +

7/10/2004 - Shorewall 2.0.5
+
+Problems +Corrected:

+ +

7/06/2004 - Shorewall 2.0.4
+
+Problems +Corrected:

+ +

7/03/2004 - New Shorewall Release +Model
+
+Effective today, Shorewall is adopting a new release +model which takes ideas from the one used in the Linux Kernel and +from the release model for Postfix.

+
    +
  1. +

    Releases continue to have a +three-level identification x.y.z (e.g., 2.0.3).

    +
    2. +
  2. +

    The first two levels (x.y) +designate the Major Release Number (e.g., 2.0)

    +
    3. +
  3. +

    The third level (z) +designates the Minor Release Number.

    +
    4. +
  4. +

    Even numbered major releases (e.g., 1.4, +2.0, 2.2, ...) are Stable Releases. No new features are +added to stable releases and new minor releases of a stable release +will only contain bug fixes. Installing a new minor release for the +major release that you are currently running involves no migration +issues (for example, if you are running 1.4.10 and I release 1.4.11, +your current configuration is 100% compatible with the new release).

    +
    5. +
  5. +

    Support is available through the Mailing List for the two most +recent Stable Releases.

    +
    6. +
  6. +

    Odd numbered major releases (e.g., +2.1, 2.3, ...) are Development Releases. Development releases +are where new functionality is introduced. Documentation for new +features will be available but it may not be up to the standards of the +stable release documentation. Sites running Development Releases should +be prepared to play an active role in testing new features. Bug fixes +and problem resolution for the development release take a back seat to +support of the stable releases. Problem reports for the current +development release should be sent to the Shorewall +Development Mailing List.

    +
    7. +
  7. +

    When the level of functionality of +the current development release is judged adaquate, the Beta period for +a new Stable release will begin. Beta releases have identifications of +the form x.y.0-BetaN where x.y is the number of the +next Stable Release and N=1,2,3... . Betas are expected to +occur rougly once per year. Beta releases may contain new functionality +not present in the previous beta release (e.g., 2.2.0-Beta4 may contain +functionality not present in 2.2.0-Beta3). When I'm confident that the +current Beta release is stable, I will release the first Release +Candidate. Release candidates have identifications of the form x.y.0-RCn + where x.y is the number of the next Stable Release and + n=1,2,3... . Release candidates contain no new functionailty +-- they only contain bug fixes. When the stability of the current +release candidate is judged to be sufficient then that release +candidate will be released as the new stable release (e.g., 2.2.0). At +that time, the new stable release and the prior stable release are +those that are supported.

    +
    8. +
  8. +

    What does it mean for a major +release to be supported? It means that I will answer questions +about the release and that if a bug is found, I will fix the bug and +include the fix in the next minor release.

    +
    9. +
  9. +

    Between minor releases, bug fixes will continue to be made +available through the Errata page for each major release.

    +
    10. +
+

The immediate implications of this change are as follows:

+
    +
  1. +

    The functionality of the 2.0 major +release is frozen at the level of minor release 2.0.3.

    +
    2. +
  2. +

    The two major releases currently +supported are 1.4 and 2.0.

    +
    3. +
  3. +

    I will be opening the 2.1 +development release shortly with the release of 2.1.0.

    +
    4. +
  4. +

    Bug-fix releases with identifications of the form x.y.zX where +X=a,b,c,... (e.g., 2.0.3c) will not be seen in the future.

    +
    5. +
+

7/02/2004 - Shorewall 2.0.3c
+
+Problems +Corrected:

+
    +
  1. +

    Error messages regarding +$RESTOREBASE occur during shorewall stop

    +
    2. +
  2. +

    If CLEAR_TC=Yes in shorewall.conf, shorewall stop +fails without removing the lock file.

    +
    3. +
+


+6/30/2004 - Shorewall 2.0.3b and +Shorewall 1.4.10g
+
+Problems Corrected:

+
    +
  1. +

    The security vulnerability fix +released in Shorewall 2.0.3a failed under Slackware 9.1.

    +
    2. +
  2. +

    The security vulnerability fix released in Shorewall 2.0.3a +failed if mktemp was not installed.

    +
    3. +
+

6/28/2004 - Shorewall 2.0.3a and Shorewall +1.4.10f
+
+Problems Corrected:

+
    +
  1. +

    Javier Fernández-Sanguino Peña has +discovered an exploitable vulnerability in the way that Shorewall +handles temporary files and directories. The vulnerability can allow a +non-root user to cause arbitrary files on the system to be overwritten. +LEAF Bering and Bering uClibc users are generally not at risk due to +the fact that LEAF boxes do not typically allow logins by non-root +users.

    +
    2. +
  2. +

    (2.0.3a only) A non-empty DEST entry in /etc/shorewall/tcrules +will generate an error and Shorewall fails to start.

    +
    3. +
+

Note:: Slackware users may need the +'functions' file from CVS (STABLE/ project for 1.4.10f and STABLE2/ +project for 2.0.3a) to prevent startup errors with these versions +installed. These updatged files are also available from the Errata +(2.0, 1.4).

+

6/23/2004 - Shorewall 2.0.3
+
+Problems +Corrected:

+
    +
  1. +

    The 'firewall' script is not purging +temporary restore files in /var/lib/shorewall. These files have names +of the form "restore-nnnnn".

    +
    2. +
  2. +

    The /var/lib/shorewall/restore +script did not load the kernel modules specified in +/etc/shorewall/modules.

    +
    3. +
  3. +

    Specifying a null common action in +/etc/shorewall/actions (e.g., :REJECT) results in a startup error.

    +
    4. +
  4. +

    If /var/lib/shorewall does not +exist, shorewall start fails.

    +
    5. +
  5. +

    DNAT rules with a dynamic source +zone don't work properly. When used, these rules cause the rule to be +checked against ALL input, not just input from the designated zone.

    +
    6. +
  6. +

    The install.sh script reported +installing some files in /etc/shorewall when the files were actually +installed in /usr/share/shorewall.

    +
    7. +
  7. +

    Shorewall checks netfilter +capabilities before loading kernel modules. Hence if kernel module +autoloading isn't enabled, the capabilities will be misdetected.

    +
    8. +
  8. +

    The 'newnotsyn' option in +/etc/shorewall/hosts has no effect.

    +
    9. +
  9. +

    The file /etc/init.d/shorewall now +gets proper ownership when the RPM is built by a non-root user.

    +
    10. +
  10. +

    Rules that specify bridge ports in +both the SOURCE and DEST columns no longer cause "shorewall start" to +fail.

    +
    11. +
  11. +

    Comments in the rules file have been +added to advise users that "all" in the SOURCE or DEST column does not +affect intra-zone traffic.

    +
    12. +
  12. +

    With BLACKLISTNEWONLY=Yes, ICMP packets with state INVALID are +now passed through the blacklisting chains. Without this change, it is +not possible to blacklist hosts that are mounting certain types of +ICMP-based DOS attacks.

    +
    13. +
+

Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:

+
    +
  1. +

    The 'dropNonSyn' standard builtin action has been replaced with +the 'dropNotSyn' standard builtin action. The old name can still be +used but will generate a warning.

    +
    2. +
+

New Features:

+
    +
  1. +

    Shorewall now supports multiple +saved configurations.

    +
      +
    1. +

      The default saved configuration +(restore script) in /var/lib/shorewall is now specified using the +RESTOREFILE option in shorewall.conf. If this variable isn't set then +to maintain backward compatibility, 'restore' is assumed.
      +
      +The value of RESTOREFILE must be a simple file name; no slashes ("/") +may be included.

      +
      2. +
    2. +

      The "save" command has been +extended to be able to specify the name of a saved configuration.
      +
      +           shorewall +save [ <file name> ]
      +
      +The current state is saved to /var/lib/shorewall/<file name>. If +no <file name> is given, the configuration is saved to the file +determined by the RESTOREFILE setting.

      +
      3. +
    3. +

      The "restore" command has been +extended to be able to specify the name of a saved configuration:
      +
      +          shorewall +restore [ <file name> ]
      +
      +The firewall state is restored from /var/lib/shorewall/<file +name>. If no <file name> is given, the firewall state is +restored from the file determined by the RESTOREFILE setting.

      +
      4. +
    4. +

      The "forget" command has +changed. Previously, the command unconditionally removed the +/var/lib/shorewall/save file which records the current dynamic +blacklist. The "forget" command now leaves that file alone.
      +
      +Also, the "forget" command has been extended to be able to specify the +name of a saved configuration:
      +
      +              +shorewall forget [ <file name> ]
      +
      +The file /var/lib/shorewall/<file name> is removed. If no +<file name> is given, the file determined by the RESTOREFILE +setting is removed.

      +
      5. +
    5. +

      The "shorewall -f start" command +restores the state from the file determined by the RESTOREFILE setting. +

      +
      6. +
    +
    2. +
  2. +

    "!" is now allowed in accounting +rules.

    +
    3. +
  3. +

    Interface names appearing within the +configuration are now verified. Interface names must match the name of +an entry in /etc/shorewall/interfaces (or if bridging is enabled, they +must match the name of an entry in /etc/shorewall/interfaces or the +name of a bridge port appearing in /etc/shorewall/hosts).

    +
    4. +
  4. +

    A new 'rejNotSyn' built-in standard +action has been added. This action responds to "New not SYN" packets +with an RST.
    +
    +The 'dropNonSyn' action has been superceded by the new 'dropNotSyn' +action. The old name will be accepted until the next major release of +Shorewall but will generate a warning.
    +
    +Several new logging actions involving "New not SYN" packets have been +added:
    +
    +        logNewNotSyn  -- logs +the packet with disposition = LOG
    +        dLogNewNotSyn -- logs the +packet with disposition = DROP
    +        rLogNewNotSyn -- logs the +packet with disposition = REJECT
    +
    +The packets are logged at the log level specified in the LOGNEWNOTSYN +option in shorewall.conf. If than option is empty or not specified, +then 'info' is assumed.
    +
    +Examples (In all cases, set NEWNOTSYN=Yes in shorewall.conf):

    +
      +
    1. +

      To simulate the behavior of +NEWNOTSYN=No:

      +
        +
      1. +

        Add 'NoNewNotSyn' to +/etc/shorewall/actions.

        +
        2. +
      2. +

        Create /etc/shorewall/action.NoNewNotSyn containing:
        +
        +            +dLogNotSyn
        +            +dropNotSyn

        +
        3. +
      3. +

        Early in your rules file, place:
        +
        +         +NoNewNotSyn   all   all     tcp

        +
        4. +
      +
      2. +
    2. +

      Drop 'New not SYN' packets from +the net only. Don't log them:

      +
        +
      1. +

        Early in your rules file, place:
        +
        +         +dropNotSyn    +net        all   tcp

        +
        2. +
      +
      3. +
    +
    5. +
  5. +

    Slackware users no longer have to modify the install.sh script +before installation. Tuomo Soini has provided a change that allows the +INIT and FIREWALL variables to be specified outside the script as in:
    +
    +      DEST=/etc/rc.d INIT=rc.firewall +./install.sh

    +
    6. +

6/3/2004 - Shorewall 2.0.2f

Fixes one problem:
@@ -1447,7 +2027,7 @@ begin with a digit ([0-9]) and may contain embedded dashes

10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag awards Shorewall + src="images/j0233056.gif" title="" alt="" align="middle">Shorewall 1.4.7c released.

  1. The saga with "<zone>_frwd" chains continues. The 1.4.7c @@ -5079,7 +5659,7 @@ You may download the Beta from:

    12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux + alt="Powered by Mandrake Linux" border="0" height="21" width="140">

    Shorewall is at the center of MandrakeSoft's recently-announced @@ -5244,8 +5824,8 @@ to appease the LFS police at Debian.

    9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability Restored

    -Brown Paper Bag A couple of recent configuration changes +Brown Paper Bag A couple of recent configuration changes at www.shorewall.net broke the Search facility:
      @@ -5324,9 +5904,9 @@ Available

      are available at       http://security.dsi.unimi.it/~lorenzo/debian.html.

      8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for -its Author -- Shorewall 1.3.7a releasedBrown Paper Bag Graphic

      +its Author -- Shorewall 1.3.7a releasedBrown Paper Bag Graphic

      1.3.7a corrects problems occurring in rules file processing when starting Shorewall 1.3.7.

      8/22/2002 - Shorewall 1.3.7 Released 8/13/2002

      @@ -6232,8 +6812,8 @@ compatibility.

      4/8/2001 - Shorewall is now affiliated with the Leaf Project Leaf Logo

      + href="http://leaf.sourceforge.net">Leaf Logo

      4/5/2001 - The current version of Shorewall is 1.1.1. In this version:

        diff --git a/Shorewall-Website/shorewall_index.htm b/Shorewall-Website/shorewall_index.htm index d590cf5b1..22f026eae 100644 --- a/Shorewall-Website/shorewall_index.htm +++ b/Shorewall-Website/shorewall_index.htm @@ -28,12 +28,12 @@ to 2.0.x releases of Shorewall. For older versions:

        target="_top">here.

      -

      The current 2.0 Stable Release is 2.0.9 -- Here are the release +

      The current 2.0 Stable Release is 2.0.10 -- Here are the release notes.
      -The current 2.1 Developement Release is 2.1.11 -- Here +The current Developement Release is 2.2.0 Beta 1 -- Here are the release + href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1/releasenotes.txt">release notes.

      Copyright © 2001-2004 Thomas M. Eastep

      @@ -46,7 +46,7 @@ entitled “GNU Free Documentation License”.

      -

      2004-10-14

      +

      2004-10-25

      Table of Contents

      Introduction @@ -60,26 +60,10 @@ Shorewall
      Running Shorewall on Mandrake® with a two-interface setup?
      License

      -

      News

      -

      Shorewall -2.0.9
      -Change -in Shorewall Support
      -Shorewall -2.0.8
      -Shorewall 2.0.7
      -Shorewall -2.0.6
      -Shorewall 2.0.5
      -Shorewall -2.0.4
      -New Release Model
      -Shorewall -2.0.3c
      -Shorewall 2.0.3b
      -Shorewall -2.0.3a
      -Shorewall 2.0.3
      +

      News

      +

      Shorewall +2.0.10
      +Shorewall 2.2.0 Beta 1

      Leaf
      @@ -171,583 +155,88 @@ of the license is included in the section entitled "GNU Free Documentation License".

      News

      -9/23/2004 - -Shorewall 2.0.9
      +10/25/2004 - +Shorewall 2.0.10

      Problems Corrected:
        -
      1. Previously, an empty PROTO column or a value of "all" in that -column would cause errors when processing the /etc/shorewall/tcrules -file.
        2. +
      2. The GATEWAY column was previously ignored in 'pptpserver' entries +in /etc/shorewall/tunnels.
        3. +
      3. When log rule numbers are included in the LOGFORMAT, duplicate +rule numbers could previously be generated.
        4. +
      4. The /etc/shorewall/tcrules file now includes a note to the effect +that rule evaluation continues after a match.
        5. +
      5. The error message produced if Shorewall couldn't obtain the routes +through an interface named in the SUBNET column of /etc/shorewall/masq +was less than helpful since it didn't include the interface name.
        +
      New Features:
        -
      1. The "shorewall status" command now includes the output of "brctl -show" if the bridge tools are installed.
        +
      2. The "shorewall status" command has been enhanced to include the +values of key /proc settings:
        +
        +Example from a two-interface firewall:
        +
        +/proc
        +
        +   /proc/sys/net/ipv4/ip_forward = 1
        +   /proc/sys/net/ipv4/conf/all/proxy_arp = 0
        +   /proc/sys/net/ipv4/conf/all/arp_filter = 0
        +   /proc/sys/net/ipv4/conf/all/rp_filter = 0
        +   /proc/sys/net/ipv4/conf/default/proxy_arp = 0
        +   /proc/sys/net/ipv4/conf/default/arp_filter = 0
        +   /proc/sys/net/ipv4/conf/default/rp_filter = 0
        +   /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
        +   /proc/sys/net/ipv4/conf/eth0/arp_filter = 0
        +   /proc/sys/net/ipv4/conf/eth0/rp_filter = 0
        +   /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0
        +   /proc/sys/net/ipv4/conf/eth1/arp_filter = 0
        +   /proc/sys/net/ipv4/conf/eth1/rp_filter = 0
        +   /proc/sys/net/ipv4/conf/lo/proxy_arp = 0
        +   /proc/sys/net/ipv4/conf/lo/arp_filter = 0
        +   /proc/sys/net/ipv4/conf/lo/rp_filter = 0
      -

      9/20/2004 – Change in Shorewall Support

      -

      Friends,

      -

      The demands that my job and my -personal life are currently placing on me are such that supporing -Shorewall to the extent that I have been doing is just not possible -any more.

      -

      I will continue to be active on the -development list and will continue to develop Shorewall if at all -possible.

      -

      I will also continue to read the -user's list and will help with problems that interest me. But I am no -longer going to hop on every problem as soon as I see it.

      -

      This change means that I'm going to -have to depend on you folks to help each other; I'm confident that we -can make this work.

      -

      8/22/2004 - -Shorewall 2.0.8
      -
      -Problems Corrected:

      -
        -
      1. -

        Entries in the USER/GROUP column of an action file (made from -action.template) may be ignored or cause odd errors.

        -
        2. -
      -

      7/29/2004 - Shorewall 2.0.7

      -      Problems -Corrected:

      -
        -
      1. -

        The PKTTYPE option introduced in -version 2.0.6 is now used when generating rules to REJECT packets. -Broadcast packets are silently dropped rather than being rejected with -an ICMP (which is a protocol violation) and users whose kernels have -broken packet type match support are likely to see messages reporting -this violation. Setting PKTTYPE=No should cause these messages to -cease.

        -
        2. -
      2. -

        Multiple interfaces with the -'blacklist' option no longer result in an error message at startup.

        -
        3. -
      3. -

        The following has been added to /etc/shorewall/bogons:
        -
        -       0.0.0.0   RETURN
        -
        -This prevents the 'nobogons' option from logging DHCP 'DISCOVER' -broadcasts.

        -
        4. -
      -

      New Features:

      -
        -
      1. -

        To improve supportability, the "shorewall status" command now -includes IP and Route configuration information.
        -
        -   Example:
        -
        -   IP Configuration
        -
        -   1: lo: <LOOPBACK,UP> mtu -16436 qdisc noqueue
        -      link/loopback -00:00:00:00:00:00 brd 00:00:00:00:00:00
        -      inet 127.0.0.1/8 -brd 127.255.255.255 scope host lo
        -      inet6 ::1/128 -scope host
        -   2: eth0: -<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen -1000
        -      link/ether -00:a0:c9:15:39:78 brd ff:ff:ff:ff:ff:ff
        -      inet6 -fe80::2a0:c9ff:fe15:3978/64 scope link
        -   3: eth1: -<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen -1000
        -      link/ether -00:a0:c9:a7:d7:bf brd ff:ff:ff:ff:ff:ff
        -      inet6 -fe80::2a0:c9ff:fea7:d7bf/64 scope link
        -   5: sit0@NONE: <NOARP> mtu -1480 qdisc noop
        -      link/sit 0.0.0.0 -brd 0.0.0.0
        -   6: eth2: -<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen -1000
        -      link/ether -00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff
        -      inet6 -fe80::240:d0ff:fe07:3a1b/64 scope link
        -   7: br0: -<BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc noqueue
        -      link/ether -00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff
        -      inet -192.168.1.3/24 brd 192.168.1.255 scope global br0
        -      inet6 -fe80::240:d0ff:fe07:3a1b/64 scope link
        -
        -   Routing Rules
        -
        -   0:      -from all lookup local
        -   32765:  from all -fwmark       ca lookup www.out
        -   32766:  from all lookup main
        -   32767:  from all lookup -default
        -
        -   Table local:
        -
        -   broadcast 192.168.1.0 dev -br0  proto kernel  scope link  src 192.168.1.3
        -   broadcast 127.255.255.255 dev -lo  proto kernel  scope link  src 127.0.0.1
        -   local 192.168.1.3 dev br0  -proto kernel  scope host  src 192.168.1.3
        -   broadcast 192.168.1.255 dev -br0  proto kernel  scope link  src 192.168.1.3
        -   broadcast 127.0.0.0 dev lo  -proto kernel  scope link  src 127.0.0.1
        -   local 127.0.0.1 dev lo  proto -kernel  scope host  src 127.0.0.1
        -   local 127.0.0.0/8 dev lo  -proto kernel  scope host  src 127.0.0.1
        -
        -   Table www.out:
        -
        -   default via 192.168.1.3 dev br0
        -
        -   Table main:
        -
        -   192.168.1.0/24 dev br0  proto -kernel  scope link  src 192.168.1.3
        -   default via 192.168.1.254 dev br0
        -
        -   Table default:

        -
        2. -
      -

      7/16/2004 - Shorewall 2.0.6
      +10/24/2004 - +Shorewall 2.2.0 Beta1

      -      Problems -Corrected:

      -
        -
      • -

        Some users have reported the packet -type match option in iptables/Netfilter failing to match certain -broadcast packets. The result is that the firewall log shows a lot of -broadcast packets.
        -
        -Other users have complained of the following message when starting -Shorewall:
        -
        -            -modprobe: cant locate module ipt_pkttype
        -
        -Users experiencing either of these problems can use PKTTYPE=No in -shorewall.conf to cause Shorewall to use IP address filtering of -broadcasts rather than packet type.

        -
        • -
      • -

        The shorewall.conf and zones file -are no longer given execute permission by the installer script.

        -
        • -
      • -

        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.

        -
        • -
      -

      7/10/2004 - Shorewall 2.0.5
      -
      -Problems -Corrected:

      -
        -
      • -

        If DISABLE_IPV6=Yes in -shorewall.conf then harmless error messages referring to $RESTOREBASE -are generated during shorewall stop.

        -
        • -
      • -

        An anachronistic comment concerning a mangle option has been -removed from shorewall.conf.

        -
        • -
      -

      7/06/2004 - Shorewall 2.0.4
      -
      -Problems -Corrected:

      -
        -
      • -

        Rules with $FW as the source zone and that specify logging can -cause "shorewall start" to fail.

        -
        • -
      -

      7/03/2004 - New Shorewall Release -Model
      +The first beta in the 2.2 series is now available. Download +location is:

      -      Effective today, Shorewall is adopting a new release -model which takes ideas from the one used in the Linux Kernel and -from the release model for Postfix.

      + +

      The features available in this release and the migration +considerations are covered in the release +notes. Highlights include:
      +

        -
      1. -

        Releases continue to have a -three-level identification x.y.z (e.g., 2.0.3).

        -
        2. -
      2. -

        The first two levels (x.y) -designate the Major Release Number (e.g., 2.0)

        -
        3. -
      3. -

        The third level (z) -designates the Minor Release Number.

        -
        4. -
      4. -

        Even numbered major releases (e.g., 1.4, -2.0, 2.2, ...) are Stable Releases. No new features are -added to stable releases and new minor releases of a stable release -will only contain bug fixes. Installing a new minor release for the -major release that you are currently running involves no migration -issues (for example, if you are running 1.4.10 and I release 1.4.11, -your current configuration is 100% compatible with the new release).

        -
        5. -
      5. -

        Support is available through the Mailing List for the two most -recent Stable Releases.

        -
        6. -
      6. -

        Odd numbered major releases (e.g., -2.1, 2.3, ...) are Development Releases. Development releases -are where new functionality is introduced. Documentation for new -features will be available but it may not be up to the standards of the -stable release documentation. Sites running Development Releases should -be prepared to play an active role in testing new features. Bug fixes -and problem resolution for the development release take a back seat to -support of the stable releases. Problem reports for the current -development release should be sent to the Shorewall -Development Mailing List.

        -
        7. -
      7. -

        When the level of functionality of -the current development release is judged adaquate, the Beta period for -a new Stable release will begin. Beta releases have identifications of -the form x.y.0-BetaN where x.y is the number of the -next Stable Release and N=1,2,3... . Betas are expected to -occur rougly once per year. Beta releases may contain new functionality -not present in the previous beta release (e.g., 2.2.0-Beta4 may contain -functionality not present in 2.2.0-Beta3). When I'm confident that the -current Beta release is stable, I will release the first Release -Candidate. Release candidates have identifications of the form x.y.0-RCn - where x.y is the number of the next Stable Release and - n=1,2,3... . Release candidates contain no new functionailty --- they only contain bug fixes. When the stability of the current -release candidate is judged to be sufficient then that release -candidate will be released as the new stable release (e.g., 2.2.0). At -that time, the new stable release and the prior stable release are -those that are supported.

        -
        8. -
      8. -

        What does it mean for a major -release to be supported? It means that I will answer questions -about the release and that if a bug is found, I will fix the bug and -include the fix in the next minor release.

        -
        9. -
      9. -

        Between minor releases, bug fixes will continue to be made -available through the Errata page for each major release.

        -
        10. -
      -

      The immediate implications of this change are as follows:

      -
        -
      1. -

        The functionality of the 2.0 major -release is frozen at the level of minor release 2.0.3.

        -
        2. -
      2. -

        The two major releases currently -supported are 1.4 and 2.0.

        -
        3. -
      3. -

        I will be opening the 2.1 -development release shortly with the release of 2.1.0.

        -
        4. -
      4. -

        Bug-fix releases with identifications of the form x.y.zX where -X=a,b,c,... (e.g., 2.0.3c) will not be seen in the future.

        -
        5. -
      -

      7/02/2004 - Shorewall 2.0.3c
      -
      -      Problems -Corrected:

      -
        -
      1. -

        Error messages regarding -$RESTOREBASE occur during shorewall stop

        -
        2. -
      2. -

        If CLEAR_TC=Yes in shorewall.conf, shorewall stop -fails without removing the lock file.

        -
        3. -
      -


      -6/30/2004 - Shorewall 2.0.3b and -Shorewall 1.4.10g
      -
      -      Problems Corrected:

      -
        -
      1. -

        The security vulnerability fix -released in Shorewall 2.0.3a failed under Slackware 9.1.

        -
        2. -
      2. -

        The security vulnerability fix released in Shorewall 2.0.3a -failed if mktemp was not installed.

        -
        3. -
      -

      6/28/2004 - Shorewall 2.0.3a and Shorewall -1.4.10f
      -
      -      Problems Corrected:

      -
        -
      1. -

        Javier Fernández-Sanguino Peña has -discovered an exploitable vulnerability in the way that Shorewall -handles temporary files and directories. The vulnerability can allow a -non-root user to cause arbitrary files on the system to be overwritten. -LEAF Bering and Bering uClibc users are generally not at risk due to -the fact that LEAF boxes do not typically allow logins by non-root -users.

        -
        2. -
      2. -

        (2.0.3a only) A non-empty DEST entry in /etc/shorewall/tcrules -will generate an error and Shorewall fails to start.

        -
        3. -
      -

      Note:: Slackware users may need the -'functions' file from CVS (STABLE/ project for 1.4.10f and STABLE2/ -project for 2.0.3a) to prevent startup errors with these versions -installed. These updatged files are also available from the Errata -(2.0, 1.4).

      -

      6/23/2004 - Shorewall 2.0.3
      -
      -      Problems -Corrected:

      -
        -
      1. -

        The 'firewall' script is not purging -temporary restore files in /var/lib/shorewall. These files have names -of the form "restore-nnnnn".

        -
        2. -
      2. -

        The /var/lib/shorewall/restore -script did not load the kernel modules specified in -/etc/shorewall/modules.

        -
        3. -
      3. -

        Specifying a null common action in -/etc/shorewall/actions (e.g., :REJECT) results in a startup error.

        -
        4. -
      4. -

        If /var/lib/shorewall does not -exist, shorewall start fails.

        -
        5. -
      5. -

        DNAT rules with a dynamic source -zone don't work properly. When used, these rules cause the rule to be -checked against ALL input, not just input from the designated zone.

        -
        6. -
      6. -

        The install.sh script reported -installing some files in /etc/shorewall when the files were actually -installed in /usr/share/shorewall.

        -
        7. -
      7. -

        Shorewall checks netfilter -capabilities before loading kernel modules. Hence if kernel module -autoloading isn't enabled, the capabilities will be misdetected.

        -
        8. -
      8. -

        The 'newnotsyn' option in -/etc/shorewall/hosts has no effect.

        -
        9. -
      9. -

        The file /etc/init.d/shorewall now -gets proper ownership when the RPM is built by a non-root user.

        -
        10. -
      10. -

        Rules that specify bridge ports in -both the SOURCE and DEST columns no longer cause "shorewall start" to -fail.

        -
        11. -
      11. -

        Comments in the rules file have been -added to advise users that "all" in the SOURCE or DEST column does not -affect intra-zone traffic.

        -
        12. -
      12. -

        With BLACKLISTNEWONLY=Yes, ICMP packets with state INVALID are -now passed through the blacklisting chains. Without this change, it is -not possible to blacklist hosts that are mounting certain types of -ICMP-based DOS attacks.

        -
        13. -
      -

      Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:

      -
        -
      1. -

        The 'dropNonSyn' standard builtin action has been replaced with -the 'dropNotSyn' standard builtin action. The old name can still be -used but will generate a warning.

        -
        2. -
      -

      New Features:

      -
        -
      1. -

        Shorewall now supports multiple -saved configurations.

        -
          -
        1. -

          The default saved configuration -(restore script) in /var/lib/shorewall is now specified using the -RESTOREFILE option in shorewall.conf. If this variable isn't set then -to maintain backward compatibility, 'restore' is assumed.
          -
          -The value of RESTOREFILE must be a simple file name; no slashes ("/") -may be included.

          -
          2. -
        2. -

          The "save" command has been -extended to be able to specify the name of a saved configuration.
          -
          -           shorewall -save [ <file name> ]
          -
          -The current state is saved to /var/lib/shorewall/<file name>. If -no <file name> is given, the configuration is saved to the file -determined by the RESTOREFILE setting.

          -
          3. -
        3. -

          The "restore" command has been -extended to be able to specify the name of a saved configuration:
          -
          -          shorewall -restore [ <file name> ]
          -
          -The firewall state is restored from /var/lib/shorewall/<file -name>. If no <file name> is given, the firewall state is -restored from the file determined by the RESTOREFILE setting.

          -
          4. -
        4. -

          The "forget" command has -changed. Previously, the command unconditionally removed the -/var/lib/shorewall/save file which records the current dynamic -blacklist. The "forget" command now leaves that file alone.
          -
          -Also, the "forget" command has been extended to be able to specify the -name of a saved configuration:
          -
          -              -shorewall forget [ <file name> ]
          -
          -The file /var/lib/shorewall/<file name> is removed. If no -<file name> is given, the file determined by the RESTOREFILE -setting is removed.

          -
          5. -
        5. -

          The "shorewall -f start" command -restores the state from the file determined by the RESTOREFILE setting. -

          -
          6. -
        -
        2. -
      2. -

        "!" is now allowed in accounting -rules.

        -
        3. -
      3. -

        Interface names appearing within the -configuration are now verified. Interface names must match the name of -an entry in /etc/shorewall/interfaces (or if bridging is enabled, they -must match the name of an entry in /etc/shorewall/interfaces or the -name of a bridge port appearing in /etc/shorewall/hosts).

        -
        4. -
      4. -

        A new 'rejNotSyn' built-in standard -action has been added. This action responds to "New not SYN" packets -with an RST.
        -
        -The 'dropNonSyn' action has been superceded by the new 'dropNotSyn' -action. The old name will be accepted until the next major release of -Shorewall but will generate a warning.
        -
        -Several new logging actions involving "New not SYN" packets have been -added:
        -
        -        logNewNotSyn  -- logs -the packet with disposition = LOG
        -        dLogNewNotSyn -- logs the -packet with disposition = DROP
        -        rLogNewNotSyn -- logs the -packet with disposition = REJECT
        -
        -The packets are logged at the log level specified in the LOGNEWNOTSYN -option in shorewall.conf. If than option is empty or not specified, -then 'info' is assumed.
        -
        -Examples (In all cases, set NEWNOTSYN=Yes in shorewall.conf):

        -
          -
        1. -

          To simulate the behavior of -NEWNOTSYN=No:

          -
            -
          1. -

            Add 'NoNewNotSyn' to -/etc/shorewall/actions.

            -
            2. -
          2. -

            Create /etc/shorewall/action.NoNewNotSyn containing:
            -
            -            -dLogNotSyn
            -            -dropNotSyn

            -
            3. -
          3. -

            Early in your rules file, place:
            -
            -         -NoNewNotSyn   all   all     tcp

            -
            4. -
          -
          2. -
        2. -

          Drop 'New not SYN' packets from -the net only. Don't log them:

          -
            -
          1. -

            Early in your rules file, place:
            -
            -         -dropNotSyn    -net        all   tcp

            -
            2. -
          -
          3. -
        -
        5. -
      5. -

        Slackware users no longer have to modify the install.sh script -before installation. Tuomo Soini has provided a change that allows the -INIT and FIREWALL variables to be specified outside the script as in:
        -
        -      DEST=/etc/rc.d INIT=rc.firewall -./install.sh

        -
        6. +
      6. The behavior produced by specifying a log level in an action +invocation is now much more rational. Previously, all packets sent to +the action were logged; now each rule within the invoked action behaves +as if logging had been specified on it.
        7. +
      7. Support for the 2.6 Kernel's native IPSEC implementation is now +available.
        8. +
      8. Support for ipp2p is included.
        9. +
      9. Support for the iptables CONNMARK facility is now included in +Shorewall.
        10. +
      10. A new LOGALLNEW option facilitates problem analysis.
        11. +
      11. Users with a large static blacklist can now defer loading the +blacklist until after the rest of the ruleset has been enabled. Doing +so can decrease substantially the amount of time that connections are +disabled during shorewall [re]start.
        12. +
      12. Support for the iptables 'iprange match' feature has been +enabled. Users whose kernel and iptables contain this feature can use +ip address ranges in most places in their Shorewall configuration where +a CIDR netowrk can be used.
        13. +
      13. Accepting of source routing and martian logging may now be +enabled/disabled on each interface.
        14. +
      14. Shorewall now supports the CLASSIFY iptable target.

      More News