Introduction to Shorewall

This is the Shorewall 1.4 Web Site

• The 1.3 site is here.
• The 1.2 site is here.

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 combination of iptables+Netfilter (with Netfilter not in ipchains compatibility mode).

What is Shorewall?

Getting Started with Shorewall

Looking for Information?

License

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

Copyright © 2001-2004 Thomas M. Eastep

Running Shorewall on Mandrake with a two-interface setup?

News

1/30/2004 - Shorewall 1.4.10

Problems Corrected since version 1.4.9

1. The column descriptions in the action.template file did not match the column headings. That has been corrected.
2. The presence of IPV6 addresses on devices generated error messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are specified in /etc/shorewall/shorewall.conf. These messages have been eliminated.
3. The CONTINUE action in /etc/shorewall/rules now works correctly. A couple of problems involving rate limiting have been corrected. These bug fixes courtesy of Steven Jan Springl.
4. Shorewall now tried to avoid sending an ICMP response to broadcasts and smurfs.
5. Specifying "-" or "all" in the PROTO column of an action no longer causes a startup error.
   
   

1. The INTERFACE column in the /etc/shorewall/masq file may now specify a destination list.
   
   Example:
   
       #INTERFACE            SUBNET        ADDRESS
       eth0:192.0.2.3,192.0.2.16/28    eth1
   
   If the list begins with "!" then SNAT will occur only if the destination IP address is NOT included in the list.
   
   
2. Output traffic control rules (those with the firewall as the source) may now be qualified by the effective userid and/or effective group id of the program generating the output. This feature is courtesy of  Frédéric LESPEZ.
   
   A new USER column has been added to /etc/shorewall/tcrules. It may contain :
   
         [<user name or number>]:[<group name or number>]
   
   The colon is optionnal when specifying only a user.
   
          Examples : john: / john / :users / john:users
   
   
3. A "detectnets" interface option has been added for entries in /etc/shorewall/interfaces. This option automatically taylors the definition of the zone named in the ZONE column to include just  those hosts that have routes through the interface named in the INTERFACE column. The named interface must be UP when Shorewall is [re]started.
   
    WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
   

1/17/2004 - FAQ Wiki Available 

It has been asserted that the use of CVS for maintaining the Shorewall documentation has been a barrier to community participation. To test this theory, Alex Martin has created a Wiki and with the help of Mike Noyes has populated the Wiki with the Shorewall FAQ.

1/13/2004 - Shorewall 1.4.9 

Problems Corrected since version 1.4.8:

1. There has been a low continuing level of confusion over the terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all instances of "Static NAT" have been replaced with "One-to-one NAT" in the documentation and configuration files.
2. The description of NEWNOTSYN in shorewall.conf has been reworded for clarity.
3. Wild-card rules (those involving "all" as SOURCE or DEST) will no longer produce an error if they attempt to add a rule that would override a NONE policy. The logic for expanding these wild-card rules now simply skips those (SOURCE,DEST) pairs that have a NONE policy.
4. DNAT rules that also specified SNAT now work reliably. Previously, there were cases where the SNAT specification was effectively ignored.
   

Migration Issues:

    None.

New Features:

1. The documentation has been completely rebased to Docbook XML. The documentation is now released as separate HTML and XML packages.
   
2. To cut down on the number of "Why are these ports closed rather than stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def have been changed from 'reject' to 'DROP'.
3. For easier identification, packets logged under the 'norfc1918' interface option are now logged out of chains named 'rfc1918'. Previously, such packets were logged under chains named 'logdrop'.
4. Distributors and developers seem to be regularly inventing new naming conventions for kernel modules. To avoid the need to change Shorewall code for each new convention, the MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names in your particular distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".
   
   To see what suffix is used by your distribution:
   
   ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
   
   All of the files listed should have the same suffix (extension). Set MODULE_SUFFIX to that suffix.
   
   Examples:
   
        If all files end in ".kzo" then set MODULE_SUFFIX="kzo"
        If all files end in ".kz.o" then set MODULE_SUFFIX="kz.o"
5. Support for user defined rule ACTIONS has been implemented through two new files:
   
   /etc/shorewall/actions - used to list the user-defined ACTIONS.
   /etc/shorewall/action.template - For each user defined <action>, copy this file to /etc/shorewall/action.<action> and add the appropriate rules for that <action>. Once an <action> has been defined, it may be used like any of the builtin ACTIONS (ACCEPT, DROP, etc.) in /etc/shorewall/rules.
   
   Example: You want an action that logs a packet at the 'info' level and accepts the connection.
   
   In /etc/shorewall/actions, you would add:
   
        LogAndAccept
   
   You would then copy /etc/shorewall/action.template to /etc/shorewall/action.LogAndAccept and in that file, you would add the two rules:
           LOG:info
           ACCEPT
   
6. The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn TCP packets that are not part of an existing connection are filtered according to the rules and policies rather than being dropped). I have made this change for two reasons:
   
   a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any timeout during TCP session tear down results in the firewall dropping all of the retries.
   
   b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots of confusing messages when a connection got "stuck". While I could have changed the default value of LOGNEWNOTSYN to suppress logging, I dislike defaults that silently throw away packets.
7. The common.def file now contains an entry that silently drops ICMP packets with a null source address. Ad Koster reported a case where these were occuring frequently as a result of a broken system on his external network.
   
   

More News

Jacques Nilo and Eric Wolzak have a LEAF (router/firewall/gateway on a floppy, CD or compact flash) distribution called Bering that features Shorewall-1.4.2 and Kernel-2.4.20. You can find their work at: http://leaf.sourceforge.net/devel/jnilo

Donations

Shorewall is free but if you try it and find it useful, please consider making a donation to Starlight Children's Foundation. Thanks!