Site Problem
The server that normally hosts www.shorewall.net and
ftp.shorewall.net is currently down. Until it is back up, a small
server with very limited bandwidth is being used temporarly. You
will likely experience better response time from the Sourceforge
site or from one of the other mirrors. Sorry for the
inconvenience.
Introduction to Shorewall
This is the Shorewall 1.4 Web Site
The information on this site applies only to 1.4.x releases of
Shorewall. For older versions:
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?
The Shoreline Firewall, more commonly known as "Shorewall", is
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 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 match 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.
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 details.
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, 2002, 2003 Thomas M.
Eastep
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.
News
12/07/2003 - Shorewall 1.4.9 Beta 1
Problems Corrected since version 1.4.8:
- 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.
- The description of NEWNOTSYN in shorewall.conf has been
reworded for clarity.
- 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.
Migration Issues:
None.
New Features:
- 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'.
- 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'.
- 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"
- 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/LogAndAccept and in that file, you would add the two
rules:
LOG:info
ACCEPT
12/03/2003 - Support Torch Passed
Effective today, I am reducing my participation in the day-to-day
support of Shorewall. As part of this shift to community-based
Shorewall support a new Shorewall
Newbies mailing list has been established to field questions
and problems from new users. I will not monitor that list
personally. I will continue my active development of Shorewall and
will be available via the development list to handle development
issues -- Tom.
11/07/2003 - Shorewall 1.4.8
Problems Corrected since version 1.4.7:
- Tuomo Soini has supplied a correction to a problem that occurs
using some versions of 'ash'. The symptom is that "shorewall start"
fails with:
local: --limit: bad variable name
iptables v1.2.8: Couldn't load match
`-j':/lib/iptables/libipt_-j.so:
cannot open shared object file: No such file or
directory
Try `iptables -h' or 'iptables --help' for more
information.
- Andres Zhoglo has supplied a correction that avoids trying to
use the multiport match iptables facility on ICMP rules.
Example of rule that previously caused "shorewall
start" to fail:
ACCEPT loc $FW
icmp 0,8,11,12
- Previously, if the following error message was issued,
Shorewall was left in an inconsistent state.
Error: Unable to determine the routes through
interface xxx
- Handling of the LOGUNCLEAN option in shorewall.conf has been
corrected.
- In Shorewall 1.4.2, an optimization was added. This
optimization involved creating a chain named "<zone>_frwd"
for most zones defined using the /etc/shorewall/hosts file. It has
since been discovered that in many cases these new chains contain
redundant rules and that the "optimization" turns out to be less
than optimal. The implementation has now been corrected.
- When the MARK value in a tcrules entry is followed by ":F" or
":P", the ":F" or ":P" was previously only applied to the first
Netfilter rule generated by the entry. It is now applied to all
entries.
- An incorrect comment concerning Debian's use of the SUBSYSLOCK
option has been removed from shorewall.conf.
- Previously, neither the 'routefilter' interface option nor the
ROUTE_FILTER parameter were working properly. This has been
corrected (thanks to Eric Bowles for his analysis and patch). The
definition of the ROUTE_FILTER option has changed however.
Previously, ROUTE_FILTER=Yes was documented as enabling route
filtering on all interfaces (which didn't work). Beginning with
this release, setting ROUTE_FILTER=Yes will enable route filtering
of all interfaces brought up while Shorewall is started. As a
consequence, ROUTE_FILTER=Yes can coexist with the use of the
'routefilter' option in the interfaces file.
- If MAC verification was enabled on an interface with a /32
address and a broadcast address then an error would occur during
startup.
- he NONE policy's intended use is to suppress the generating of
rules that can't possibly be traversed. This means that a policy of
NONE is inappropriate where the source or destination zone is $FW
or "all". Shorewall now generates an error message if such a policy
is given in /etc/shorewall/policy. Previously such a policy caused
"shorewall start" to fail.
- The 'routeback' option was broken for wildcard interfaces
(e.g., "tun+"). This has been corrected so that 'routeback' now
works as expected in this case.
Migration Issues:
- The definition of the ROUTE_FILTER option in shorewall.conf has
changed as described in item 8) above.
New Features:
- A new QUEUE action has been introduced for rules. QUEUE allows
you to pass connection requests to a user-space filter such as
ftwall (http://p2pwall.sourceforge.net). The ftwall program allows
for effective filtering of p2p applications such as Kazaa. For
example, to use ftwall to filter P2P clients in the 'loc' zone, you
would add the following rules:
QUEUE loc
net tcp
QUEUE loc
net udp
QUEUE loc
fw udp
You would normally want to place those three rules BEFORE any
ACCEPT rules for loc->net udp or tcp.
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
Shorewall will only pass connection requests (SYN packets) to user
space. This is for compatibility with ftwall.
- A BLACKLISTNEWNONLY option has been added to shorewall.conf.
When this option is set to "Yes", the blacklists (dynamic and
static) are only consulted for new connection requests. When set to
"No" (the default if the variable is not set), the blacklists are
consulted on every packet.
Setting this option to "No" allows blacklisting to stop existing
connections from a newly blacklisted host but is more expensive in
terms of packet processing time. This is especially true if the
blacklists contain a large number of entries.
- Chain names used in the /etc/shorewall/accounting file may now
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
1.4.7c released.
- The saga with "<zone>_frwd" chains continues. The 1.4.7c
script produces a ruleset that should work for everyone even if it
is not quite optimal. My apologies for this ongoing mess.
10/24/2003 - Shorewall 1.4.7b
This is a bugfx rollup of the 1.4.7a fixes plus:
- The fix for problem 5 in 1.4.7a was wrong with the result that
"<zone>_frwd" chains might contain too few rules. That wrong
code is corrected in this release.
10/21/2003 - Shorewall 1.4.7a
This is a bugfix rollup of the following problem
corrections:
- Tuomo Soini has supplied a correction to a problem that occurs
using some versions of 'ash'. The symptom is that "shorewall start"
fails with:
local: --limit: bad variable name
iptables v1.2.8: Couldn't load match
`-j':/lib/iptables/libipt_-j.so:
cannot open shared object file: No such file or
directory
Try `iptables -h' or 'iptables --help' for more
information.
- Andres Zhoglo has supplied a correction that avoids trying to
use the multiport match iptables facility on ICMP rules.
Example of rule that previously caused "shorewall
start" to fail:
ACCEPT loc $FW
icmp 0,8,11,12
- Previously, if the following error message was issued,
Shorewall was left in an inconsistent state.
Error: Unable to determine the routes through
interface xxx
- Handling of the LOGUNCLEAN option in shorewall.conf has been
corrected.
- In Shorewall 1.4.2, an optimization was added. This
optimization involved creating a chain named "<zone>_frwd"
for most zones defined using the /etc/shorewall/hosts file. It has
since been discovered that in many cases these new chains contain
redundant rules and that the "optimization" turns out to be less
than optimal. The implementation has now been corrected.
- When the MARK value in a tcrules entry is followed by ":F" or
":P", the ":F" or ":P" was previously only applied to the first
Netfilter rule generated by the entry. It is now applied to all
entries.
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
Congratulations to Jacques and Eric on the recent release of
Bering 1.2!!!
Donations
Shorewall is free but if you try it and find it useful,
please consider making a donation to Starlight Children's Foundation.
Thanks!
|