From 70d8190878194c91c7a73e8a00abd8a9a600f9d9 Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 23 Sep 2004 22:58:32 +0000 Subject: [PATCH] Update for Shorewall 2.0.9 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1643 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-Website/download.htm | 7 +- Shorewall-Website/mailing_list.htm | 5 +- Shorewall-Website/shorewall_index.htm | 1144 +++++++++++++------------ 3 files changed, 624 insertions(+), 532 deletions(-) diff --git a/Shorewall-Website/download.htm b/Shorewall-Website/download.htm index f42d134f3..9d11187ec 100644 --- a/Shorewall-Website/download.htm +++ b/Shorewall-Website/download.htm @@ -22,7 +22,7 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

-

2004-07-06
+

2004-09-21

I strongly urge you to read and print a copy of the

+

If you are new to Shorewall, please do not download the Development +version.
+

Download Sites:

- +
diff --git a/Shorewall-Website/mailing_list.htm b/Shorewall-Website/mailing_list.htm index fd8c22890..f9f076e57 100755 --- a/Shorewall-Website/mailing_list.htm +++ b/Shorewall-Website/mailing_list.htm @@ -27,10 +27,13 @@ Documentation License
-

2004-09-04
+

2004-09-23

+

See the Shorewall Website for +Shorewall information and documentation.
+

Mailing Lists are Moderated for Non-Member Posts

Given the recent problems associated with the MyDoom virus (and the more annoying diff --git a/Shorewall-Website/shorewall_index.htm b/Shorewall-Website/shorewall_index.htm index a2c7da660..5216ed181 100644 --- a/Shorewall-Website/shorewall_index.htm +++ b/Shorewall-Website/shorewall_index.htm @@ -1,333 +1,345 @@ - + - - + Shoreline Firewall (Shorewall) 2.0 + + + - -
+

Shorewall 2.0

-Tom Eastep
+

Tom Eastep

-The information on this site -applies only to 2.0.x releases of -Shorewall. For older versions:
+The information on this site applies only +to 2.0.x releases of Shorewall. For older versions:

    -
  • The 1.4 site is here.
    -
    • -
  • The 1.3 site is here.
    • -
  • The 1.2 site is here.
    • +
  • +

    The 1.4 site is here.

    +
    • +
  • +

    The 1.3 site is here.

    +
    • +
  • +

    The 1.2 site is here.

    +
-The current 2.0 Stable Release is 2.0.8 -- Here are the The current 2.0 Stable Release is 2.0.8 -- Here are the release notes.
-The current 2.1 Developement Release is 2.1.8 -- Here are the release +The current 2.1 Developement Release is 2.1.9 -- Here +are the release notes.

-Copyright © 2001-2004 Thomas M. Eastep
-
-
+Copyright © 2001-2004 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”.

-
-
-
-

2004-08-29
-

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

+

2004-09-23

+

Table of Contents

-
Introduction to +

Introduction +to Shorewall

+

Glossary
+What +is Shorewall?
+Getting Started with Shorewall
-

-News
- - -Leaf
-Donations
+Shorewall +2.0.3a
+Shorewall 2.0.3
+
+

+ +

Donations

Introduction to Shorewall

Glossary

    -
  • Netfilter -- the -packet filter facility built into the 2.4 and later Linux kernels.
    • -
  • ipchains - the packet filter facility built into the 2.2 -Linux kernels. Also the name of the utility program used to configure -and control that facility. Netfilter can be used in ipchains -compatibility mode.
    • -
  • iptables - the utility program used to configure and -control Netfilter. The term 'iptables' is often used to refer to the +
  • +

    Netfilter - the packet filter facility built into +the 2.4 and later Linux kernels.

    +
    • +
  • +

    ipchains - the packet filter +facility built into the 2.2 Linux kernels. Also the name of the utility +program used to configure and control that facility. Netfilter can be +used in ipchains compatibility mode.

    +
    • +
  • +

    iptables - the utility program used to configure and control +Netfilter. The term 'iptables' is often used to refer to the combination of iptables+Netfilter (with Netfilter not in ipchains -compatibility mode).

    • +compatibility mode).

    +

What is Shorewall?

-
The Shoreline Firewall, more -commonly known as "Shorewall", is -a high-level tool for configuring Netfilter. You describe your -firewall/gateway requirements using entries in a set of configuration -files. Shorewall reads those configuration files and with the help of -the iptables utility, Shorewall configures Netfilter to match your -requirements. Shorewall can be used on a dedicated firewall system, a -multi-function gateway/router/server or on a standalone GNU/Linux -system. Shorewall does not use Netfilter's ipchains compatibility mode -and can thus take advantage of Netfilter's The Shoreline Firewall, more commonly +known as "Shorewall", is a high-level tool for configuring +Netfilter. You describe your firewall/gateway requirements using +entries in a set of configuration files. Shorewall reads those +configuration files and with the help of the iptables utility, +Shorewall configures Netfilter to match your requirements. Shorewall +can be used on a dedicated firewall system, a multi-function +gateway/router/server or on a standalone GNU/Linux system. Shorewall +does not use Netfilter's ipchains compatibility mode and can thus +take advantage of Netfilter's connection -state tracking -capabilities.
+state tracking capabilities.

-Shorewall is not a -daemon. Once Shorewall has configured Netfilter, it's job is complete. -After that, there is no Shorewall code running although the /sbin/shorewall -program can be used at any time to monitor the Netfilter firewall.
-
+Shorewall is not a +daemon. Once Shorewall has configured Netfilter, it's job is +complete. After that, there is no Shorewall code running although the +/sbin/shorewall program +can be used at any time to monitor the Netfilter firewall.

Getting Started with Shorewall

-
New to Shorewall? Start by -selecting the QuickStart Guide -that most -closely matches your environment and follow the step by step -instructions.
-
+

New to Shorewall? Start by selecting +the QuickStart Guide +that most closely matches your environment and follow the step by +step instructions.

Looking for Information?

-
The Documentation -Index is a good place to start as is the Quick Search in the frame -above.
+

The Documentation +Index is a good place to start as is the Quick Search in the +frame above.

Running Shorewall on Mandrake® with a two-interface setup?

-
If so, the documentation on this -site will not apply directly -to your setup. If you want to use the documentation that you find here, -you will want to consider uninstalling what you have and installing a -setup that matches the documentation on this site. See the Two-interface QuickStart Guide for -details.
+

If so, the documentation on this site +will not apply directly to your setup. If you want to use the +documentation that you find here, you will want to consider +uninstalling what you have and installing a setup that matches the +documentation on this site. See the Two-interface +QuickStart Guide for details.

-Update: I've been +Update: I've been informed by Mandrake Development that this problem has been corrected -in Mandrake 10.0 Final (the problem still exists in the 10.0 Community -release).
-

+in Mandrake 10.0 Final (the problem still exists in the 10.0 +Community release).

License

-
This program is free software; -you can redistribute it and/or modify it -under the terms of Version +

This program is free software; you can +redistribute it and/or modify it under the terms of Version 2 of the GNU General Public License as published by the Free -Software Foundation.
-

-

This program is distributed in the -hope that it will be -useful, but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more detail.

-
-

You should have received a copy of -the GNU General Public -License along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA

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

-
+Software Foundation.

+

This program is distributed in the +hope that it will be useful, but WITHOUT ANY WARRANTY; without even +the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR +PURPOSE. See the GNU General Public License for more detail.

+

You should have received a copy of the +GNU General Public License along with this program; if not, write to +the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA +02139, USA

+

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

+

News

-8/22/2004 - -Shorewall 2.0.8
+9/23/2004 - +Shorewall 2.0.9

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. +
  2. Previously, an empty PROTO column or a value of "all" in that +column would cause errors when processing the /etc/shorewall/tcrules +file.
-7/29/2004 - -Shorewall 2.0.7
-
-Problems Corrected:
+New Features:
    -
  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:
    +
  4. The "shorewall status" command now includes the output of "brctl +show" if the bridge tools are installed.
    +
    5. +
+

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

-New Features:
-
+

New Features:

    -
  1. To improve supportability, the "shorewall status" command now +
  2. +

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

-7/16/2004 - -Shorewall 2.0.6
+

7/16/2004 - Shorewall 2.0.6

-Problems Corrected:
+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.
    +
  • +

    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:
    @@ -337,257 +349,337 @@ 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.
    +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:
+

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

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

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

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

-7/03/2004 -- New Shorewall Release Model
+

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

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

    3. -
  3. The first two levels (x.y) -designate the Major Release Number -(e.g., 2.0)
    4. -
  4. The third level (z) -designates the Minor Release Number.
    5. -
  5. 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 +
  6. +

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

    +
    7. +
  7. +

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

    +
    8. +
  8. +

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

    9. -
  9. Support is available through the Mailing List for the two most -recent Stable Releases.
    +your current configuration is 100% compatible with the new release).

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

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

    +
    12. +
  12. +

    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.
    +Development Mailing List.

    13. -
  13. 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.
    14. -
  14. 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.
    15. -
  15. Between minor releases, bug fixes will continue to be made -available through the Errata page for each major release.
    +
  16. +

    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.

    +
    17. +
  17. +

    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.

    +
    18. +
  18. +

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

-The immediate implications of this change are as follows:
+

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

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

    +
    6. +
  6. +

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

    +
    7. +
  7. +

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

    +
    8. +
  8. +

    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.

-7/02/2004 - -Shorewall 2.0.3c
+

7/02/2004 - Shorewall 2.0.3c

-Problems Corrected:
- +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. +

    Error messages regarding +$RESTOREBASE occur during shorewall stop

    +
    4. +
  4. +

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

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


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

-Problems Corrected:
+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. +

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

    +
    3. +
  3. +

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

    4. -
  4. (2.0.3a only) A non-empty DEST entry in /etc/shorewall/tcrules -will generate an error and Shorewall fails to start.
-
Note:: Slackware users may need the +

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).
+installed. These updatged files are also available from the Errata +(2.0, 1.4).

+

6/23/2004 - Shorewall 2.0.3

-

-6/23/2004 - -Shorewall 2.0.3
-
-Problems Corrected:
+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 +
  13. +

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

    +
    14. +
  14. +

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

    +
    15. +
  15. +

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

    +
    16. +
  16. +

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

    +
    17. +
  17. +

    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.

    +
    18. +
  18. +

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

    +
    19. +
  19. +

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

    +
    20. +
  20. +

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

    +
    21. +
  21. +

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

    +
    22. +
  22. +

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

    +
    23. +
  23. +

    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.

    +
    24. +
  24. +

    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.

    25. +ICMP-based DOS attacks.

    +
-Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:
+

Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:

    -
  1. The 'dropNonSyn' standard builtin action has been replaced with +
  2. +

    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.

    3. +used but will generate a warning.

    +
-New Features:
+

New Features:

    -
  1. Shorewall now supports multiple saved configurations.
    2. -
      -
    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.
      -
      +
    2. +

      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.
        -
        +may be included.

        +
        3. +
      3. +

        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.

        4. -
      4. The "restore" command has been extended to be able to specify -the name of a saved configuration:
        -
        +determined by the RESTOREFILE setting.

        +
        5. +
      5. +

        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.

        6. -
      6. 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.
        -
        +restored from the file determined by the RESTOREFILE setting.

        +
        7. +
      7. +

        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.

        8. -
      8. The "shorewall -f start" command restores the state from the -file determined by the RESTOREFILE setting.
        9. -
      -
    3. "!" is now allowed in accounting rules.
      4. -
    4. 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).
      5. -
    5. A new 'rejNotSyn' built-in standard action has been added. This -action responds to "New not SYN" packets with an RST.
      +setting is removed.

      +
      6. +
    6. +

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

      +
      7. +
    + +
  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 @@ -607,88 +699,82 @@ 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):

    5. -
      -
    1. To simulate the behavior of NEWNOTSYN=No: -
        -
      1. Add 'NoNewNotSyn' to /etc/shorewall/actions.
        2. -
      2. Create /etc/shorewall/action.NoNewNotSyn containing:
        -
        +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:
            -
            +dropNotSyn

            +
            4. +
          4. +

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

            5. -
          -
          2. -
        2. Drop 'New not SYN' packets from the net only. Don't log them:
          3. -
            -
          1. Early in your rules file, place:
            -
            +NoNewNotSyn   all   all     tcp

            +
            2. +
          + +
        3. +

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

          +
            +
          1. +

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

            +
            2. +
        -
      -
    2. Slackware users no longer have to modify the install.sh script +
      3. +
    3. +

      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
      +./install.sh

    -
      -

    More News

    -
    -

    Leaf
    -

    -

    (Leaf Logo) LEAF is an open source project -which provides a Firewall/router on a floppy, CD or CF. Several LEAF -distributions including Bering and Bering-uClibc use Shorewall as their -Netfilter configuration tool.
    -

    -
    -
    -
    -
    +
    +

    Leaf

    +

    (Leaf Logo) +LEAF is an open source project which provides a Firewall/router on a +floppy, CD or CF. Several LEAF distributions including Bering and +Bering-uClibc use Shorewall as their Netfilter configuration tool.

    +

    Donations

    -

    (Alzheimer's Association Logo)

    -

    -

    -

    (Starlight Foundation Logo)

    -

    Shorewall -is free but -if you -try it and find it useful, -please consider making a donation to the Alzheimer's Association or to the Starlight Children's -Foundation.
    -

    -

    Thanks
    +

    (Alzheimer's Association Logo)(Starlight Foundation Logo)Shorewall +is free but if you try it and find it useful, please consider making +a donation to the Alzheimer's +Association or to the Starlight +Children's Foundation.

    +

    Thanks

    +



    -

    -


    -

    -
+

SERVER LOCATION