Shorewall 2.0

Tom Eastep

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

The current 2.0 Stable Release is 2.0.9 -- Here are the release notes.
The current 2.1 Developement Release is 2.1.11 -- Here are the release notes.

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-10-14

Table of Contents

Introduction to Shorewall

Glossary
What is Shorewall?
Getting Started with Shorewall
Looking for Information?
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

Leaf

Donations

Introduction to Shorewall

Glossary

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

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.

Looking for Information?

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.

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

License

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

News

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.
New Features:
  1. The "shorewall status" command now includes the output of "brctl show" if the bridge tools are installed.

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.

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. Multiple interfaces with the 'blacklist' option no longer result in an error message at startup.

  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.

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:

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. The first two levels (x.y) designate the Major Release Number (e.g., 2.0)

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

  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. Support is available through the Mailing List for the two most recent Stable Releases.

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

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

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

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

  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.

7/02/2004 - Shorewall 2.0.3c

Problems Corrected:

  1. Error messages regarding $RESTOREBASE occur during shorewall stop

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


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. The security vulnerability fix released in Shorewall 2.0.3a failed if mktemp was not installed.

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.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 '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. The /var/lib/shorewall/restore script did not load the kernel modules specified in /etc/shorewall/modules.

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

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

  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. The install.sh script reported installing some files in /etc/shorewall when the files were actually installed in /usr/share/shorewall.

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

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

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

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

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

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.

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. 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. 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. 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. The "shorewall -f start" command restores the state from the file determined by the RESTOREFILE setting.

  2. "!" is now allowed in accounting rules.

  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. 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. Create /etc/shorewall/action.NoNewNotSyn containing:

                    dLogNotSyn
                    dropNotSyn

      3. Early in your rules file, place:

                 NoNewNotSyn   all   all     tcp

    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

  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

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.

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