Introduction to Shorewall
This is the Shorewall 2.0 Web Site
The information on this site
applies only to 2.0.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
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 match your environment and follow the step by step instructions.
Looking for Information?
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 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". Copyright © 2001-2004 Thomas M. Eastep
News
5/13/2004 - Shorewall 2.0.2 
Problems Corrected since 2.0.1
- The /etc/init.d/shorewall script installed on Debian by
install.sh failed silently due to a missing file
(/usr/share/shorewall/wait4ifup). That file is not part of the normal
Shorewall distribution and is provided by the Debian maintainer.
- A meaningless warning message out of the proxyarp file
processing has been eliminated.
- The "shorewall delete" command now correctly removes all
dynamic rules pertaining to the host(s) being deleted. Thanks to Stefan
Engel for this correction.
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:
- Extension Scripts -- In order for extension scripts to work
properly with the new iptables-save/restore integration (see New
Feature 1 below), some change may be required to your extension
scripts. If your extension scripts are executing commands other than
iptables then those commands must also be written to the restore file
(a temporary file in /var/lib/shorewall that is renamed
/var/lib/shorewall/restore-base at the end of the operation).
The following functions should be of help:
A. save_command() -- saves the passed command to the restore file.
Example:
save_command echo Operation
Complete
That command would simply write "echo Operation Complete"
to the restore file.
B. run_and_save_command() -- saves the passed command to the restore
file then executes it. The return value is the exit status of the
command.
Example:
run_and_save_command "echo 1 >
/proc/sys/net/ipv4/icmp_echo_ignore_all"
Note that as in this example, when the command
involves file redirection then the entire command must be enclosed in
quotes. This applies to all of the functions described here.
C. ensure_and_save_command() -- runs the passed command. If the command
fails, the firewall is restored to it's prior saved state and the
operation is terminated. If the command succeeds, the command is
written to the restore file.
- Dynamic Zone support -- If you don't need to use the
"shorewall add" and "shorewall delete commands, you should set
DYNAMIC_ZONES=No in /etc/shorewall/shorewall.conf.
New Features:
- Shorewall has now been integrated with
iptables-save/iptables-restore to provide very fast start and restart.
The elements of this integration are as follows:
a) The 'shorewall save' command now saves the current configuration in
addition to the current dynamic blacklist. If you have dynamic zones,
you will want to issue 'shorewall save' when the zones are empty or the
current contents of the zones will be restored by the 'shorewall
restore' and 'shorewall -f start' commands.
b) The 'shorewall restore' command has been added. This command
restores the configuration at the time of the last 'save'.
c) The -f (fast) option has been added to 'shorewall start'. When
specified (e.g. 'shorewall -f start'), shorewall will perform a
'shorewall restore' if there is a saved configuration. If there is no
saved configuration, a normal 'shorewall start' is performed.
d) The /etc/init.d/shorewall script now translates the 'start' command
into 'shorewall -f start' so that fast restart is possible.
e) When a state-changing command encounters an error and there is
current saved configuration, that configuration will be restored
(currently, the firewall is placed in the 'stopped' state).
f) If you have previously saved the running configuration and want
Shorewall to discard it, use the 'shorewall forget' command. WARNING:
iptables 1.2.9 is broken with respect to iptables-save; if your kernel
has connection tracking match support, you must patch iptables 1.2.9
with the iptables patch availale from the Shorewall errata page.
- The previous implementation of dynamic zones was difficult
to maintain. I have changed the code to make dynamic zones optional
under the control of the DYNAMIC_ZONES option in
/etc/shorewall/shorewall.conf.
- In earlier Shorewall 2.0 releases, Shorewall searches in
order the following directories for configuration files.
a) The directory specified in a 'try' command or specified using the -c
option.
b) /etc/shorewall
c) /usr/share/shorewall
In this release, the CONFIG_PATH option is added to shorewall.conf.
CONFIG_PATH contains a list of directory names separated by colons
(":"). If not set or set to a null value (e.g., CONFIG_PATH="") then
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed. Now
Shorewall searches for shorewall.conf according to the old rules and
for other configuration files as follows:
a) The directory specified in a 'try' command or specified using the -c
option.
b) Each directory in $CONFIG_PATH is searched in sequence.
In case it is not obvious, your CONFIG_PATH should include
/usr/share/shorewall and your shorewall.conf file must be in the
directory specified via -c or in a try command, in /etc/shorewall or in
/usr/share/shorewall.
For distribution packagers, the default CONFIG_PATH is set in
/usr/share/shorewall/configpath. You can customize this file to have a
default that differs from mine.
- Previously, in /etc/shorewall/nat a Yes (or yes) in the
LOCAL column would only take effect if the ALL INTERFACES column also
contained Yes or yes. Now, the LOCAL columns contents are treated
independently of the contents of the ALL INTERFACES column.
- The folks at Mandrake have created yet another kernel
module naming convention (module names end in "ko.gz"). As a
consequence, beginning with this release, if MODULE_SUFFIX isn't
specified in shorewall.conf, then the default value is "o gz ko o.gz
ko.gz".
- An updated bogons file is included in this release.
- In /etc/shorewall/rules and in action files generated from
/usr/share/shorewall/action.template, rules that perform logging can
specify an optional "log tag". A log tag is a string of alphanumeric
characters and is specified by following the log level with ":" and the
log tag.
Example:
ACCEPT:info:ftp
net dmz
tcp 21
The log tag is appended to the log prefix generated by the LOGPREFIX
variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate
"Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum
length of a log prefix supported by iptables is 29 characters; if a
larger prefix is generated, Shorewall will issue a warning message and
will truncate the prefix to 29 characters.
- A new "-q" option has been added to /sbin/shorewall
commands. It causes the start, restart, check and refresh commands to
produce much less output so that warning messages are more visible
(when testing this change, I discovered a bug where a bogus warning
message was being generated).
- Shorewall now uses 'modprobe' to load kernel modules if
that utility is available in the PATH; otherwise, 'insmod' is used.
- It is now possible to restrict entries in the
/etc/shorewall/masq file to particular protocols and destination
port(s). Two new columns (PROTO and PORT(S)) have been added to the
file.
Example:
You want all outgoing SMTP traffic entering the firewall on eth1 to be
sent from eth0 with source IP address 206.124.146.177. You want all
other outgoing traffic from eth1 to be sent from eth0 with source IP
address 206.124.146.176.
eth0
eth1 206.124.146.177 tcp 25
eth0
eth1 206.124.146.176
THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
Assuming that 10.0.0.0/8 is the only host/network connected to eth1,
the progress message at "shorewall start" would be:
Masqueraded Networks and Hosts:
To 0.0.0.0/0 (tcp 25) from
10.0.0.0/8 through eth0 using 206.124.146.177
To 0.0.0.0/0 (all) from 10.0.0.0/8
through eth0 using 206.124.146.176
- Two new actions are available in the /etc/shorewall/rules
file.
ACCEPT+ -- Behaves like ACCEPT
with the exception that it exempts matching connections from subsequent
DNAT[-] and REDIRECT[-] rules.
NONAT -- Exempts
matching connections from subsequent DNAT[-] and REDIRECT[-] rules.
- A new extension script 'initdone' has been added. This
script is invoked at the same point as the 'common' script was
previously and is useful for users who mis-used that script under
Shorewall 1.x (the script was intended for adding rules to the 'common'
chain but many users treated it as a script for adding rules before
Shorewall's).
- Installing/Upgrading Shorewall on Slackware has been
improved. Slackware users must use the tarball and must modify settings
in the install.sh script before running it as follows:
DEST="/etc/rc.d"
INIT="rc.firewall"
Thanks to Alex Wilms for helping with this change.
4/17/2004 - Presentation at LinuxFest NW
Today I gave a presentation at LinuxFest NW in Bellingham. The
presentation was entitled "Shorewall
and the Enterprise" and described the history of Shorewall and gave
an overview of its features.
More News
 LEAF is an open source project
which provides a Firewall/router on a floppy, CD or CF. Several LEAF
distributions including Bering and Bering-uCLib use Shorewall as their
Netfilter configuration tool.
Donations
 Shorewall
is free but
if you
try it and find it useful,
please consider making a donation to the Alzheimer's Association. Thanks!
|