1. Philosophy
Shorewall is designed to allow flexible firewall configuration. Whereas
its predecessor (Seattle Firewall a.k.a. Seawall) had a large number of very
specific parameters and had firewall policy built in, Shorewall takes a different approach.
Shorewall:
- has no policies built in.
- creates a simple but powerful model for expressing firewall rules
- includes documentation for using this simple model to solve specific
problems.
2. Components
Shorewall consists of the following components:
- shorewall.conf -- a parameter file installed in /etc/shorewall
that is used to set several firewall parameters.
- zones - a parameter file installed in /etc/shorewall that defines
a network partitioning into "zones"
- policy -- a parameter file installed in /etc/shorewall/ that
establishes overall firewall policy.
- rules -- a parameter file installed in /etc/shorewall and used
to express firewall rules that are exceptions to the high-level
policies established in /etc/shorewall/policy.
- functions -- a set of shell functions used by both the firewall and
shorewall shell programs. Installed in /etc/shorewall.
- modules -- a parameter file installed in /etc/shorewall and that
specifies kernel modules and their parameters. Shorewall will
automatically load the modules specified in this file.
- tos -- a parameter file installed in /etc/shorewall that is used to
specify how the Type of Service (TOS) field in packets is to be set.
- icmp.def -- a parameter file installed in /etc/shorewall and that
specifies the default handling of ICMP packets. This file should not be
modi9fied but may be copied to /etc/shorewall/icmpdef which can then be
modified as desired.
- interfaces -- a parameter file installed in /etc/shorewall/
and used to describe the interfaces on the firewall system.
- hosts -- a parameter file installed in /etc/shorewall/ and
used to describe individual hosts or subnetworks in zones.
- masq - This file
also describes IP masquerading under Shorewall and is installed in
/etc/shorewall.
- firewall -- a shell program that reads the configuration files in
/etc/shorewall and configures your
firewall. This file is installed in your init.d
directory (/etc/rc.d/init.d on RedHat and Caldera,
/etc/init.d on Debian,
...) where it is renamed shorewall.
- nat -- a parameter file in /etc/shorewall used to define static
NAT.
- proxyarp -- a parameter file in /etc/shorewall used to define Proxy
Arp.
- tunnels -- a parameter file in /etc/shorewall used to define
IPSec tunnels.
- shorewall -- a shell program (requiring a Bourne shell or
derivative) used to control and monitor
the firewall. This should be placed in /sbin or in
/usr/sbin (the install.sh script installs this file
in /sbin).
- version -- a file created in /etc/shorewall/
that describes the version of Shorewall
installed on your system.
3. Firewall Structure
Shorewall views the network in which it is running as a set of disjoint zones. Shorewall itself defines exactly
one zone called "fw" which refers to the firewall system itself. The
/etc/shorewall/zones file is used to define additional zones and the example file
provided with Shorewall defines the zones:
- net -- the (untrusted) internet.
- dmz - systems that must be accessible from
the internet and from the local network. These systems cannot be trusted completely since their servers may have been
compromised through a security exploit.
- local - systems in your local network(s).
These systems must be protected from the internet and from the DMZ and in
some cases, from each other.
- gw - Systems accessed through a tunnel gateway. Depending on your
environment these may or may not be trusted. This zone was added to the
example in
version 1.0.1.
Traffic directed from a zone to the firewall itself is sent through a
chain named <zone name>2fw. For example, traffic inbound from the
internet and addressed to the firewall is sent through a chain named net2fw.
Similarly, traffic originating in the firewall and being sent to a host in a
given zone is sent through a chain named fw2<zone name>. For
example, traffic originating in the firewall and destined for a host in the
local network is sent through a chain named fw2local.
Traffic being forwarded between two zones (or from one interface to a
zone to another interface to that zone) is sent through a chain named <source
zone>2<destination zone>. So for example, traffic
originating in a local system and destined for a remote web server is
sent through chain local2net. This chain is referred to as the canonical
chain from <source zone> to <destination zone>. Any destination NAT will have occurred before
the packet traverses one of these chains so rules in /etc/shorewall/rules
should be expressed in terms of the destination system's real IP address as
opposed to its apparent external address. Similarly, source NAT will occur after
the packet has traversed the appropriate forwarding chain so the rules again
will be expressed using the source system's real IP address.
Beginning with Shorewall 1.1, the firewall structure is slightly
modified. For each record in the /etc/shorewall/policy file, a chain is
created. Policies in that file are expressed in terms of a source zone and
destination zone where these zones may be a zone defined in
/etc/shorewall/zones, "fw" or "all". Policies specifying
the pseudo-zone "all" matches all defined zones and "fw".
These chains are referred to as Policy Chains. Notice that for an
ordered pair of zones (za,zb), the canonical chain (za2zb) may also be the
policy chain for the pair or the policy chain may be a different chain
(za2all, for example). Packets from one zone to another will traverse chains
as follows:
- If the canonical chain exists, packets first traverse that chain.
- If the canonical chain and policy chain are different and the packet
does not match a rule in the canonical chain, it then is sent to the
policy chain.
- If the canonical chain does not exist, packets are sent immediately
to the policy chain.
The canonical chain from zone za to zone zb will be created only if there are
exception rules defined in /etc/shorewall/rules for packets going from za to
zb.
Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred to
as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than
in terms of "packets". With Shorewall, you:
- Identify the client's zone.
- Identify the server's zone.
- If the POLICY from the client's zone to the server's zone is what you
want for this client/server pair, you need do nothing further.
- If the POLICY is not what you want, then you must add a rule. That rule
is expressed in terms of the client's zone and the server's zone.
Just because connections of a particular type are allowed between zone A
and the firewall and are also allowed between the firewall and zone B DOES
NOT mean that these connections are allowed between zone A and zone B.
It rather means that you can have a proxy running on the firewall that accepts
a connection from zone A and then establishes its own separate connection from
the firewall to zone B.
If you adopt the default policy of ACCEPT from the local zone to the
internet zone and you are having problems connecting from a local client to an
internet server, adding a rule won't help
(see point 3 above).
4. Getting Started
The steps involved in configuring Shorewall are as follows:
- Define your Zones (/etc/shorewall/zones). Zones
allow you to define sets of systems that are to be treated similarly by
the firewall. A zone may be all of the hosts accessible through a
particular network interface (see /etc/shorewall/interfaces)
or may be a more specific set of hosts (see /etc/shorewall/hosts).
- Define your Policies (/etc/shorewall/policy).
Policies are like default rules for connections between zones.
- Define your Rules (/etc/shorewall/rules). Rules are
exceptions to the policies defined in the previous step.
- Define NAT and/or Proxy ARP (/etc/shorewall/masq, /etc/shorewall/nat
and /etc/shorewall/proxyarp).
- Review the other files in /etc/shorewall to see if you wish to make any
changes.
A couple of things to note:
- Where specifying an IP address, a subnet or an interface, you can
precede the item with "!" to specify the complement of the item.
For example, !192.168.1.4 means "any host but 192.168.1.4".
- In the rules file, rules are evaluated in the order that they appear and
the first rule that a connection request matches is the one that governs
the connection's disposition.
- Do not use blanket rules such as
ACCEPT fw net
That rule is a policy and belongs in the policy file as
fw net ACCEPT
5. /etc/shorewall/zones
This file was introduced in version 1.0.4 and is used to define the
network zones. Prior to version 1.0.4, the firewall script itself defined the
network zones. There is one entry in /etc/shorewall/zones for each zone;
Columns in an entry are:
- ZONE - short name for the zone. The name should be 5 characters or
less in length and consist of lower-case letters or numbers. Short names
must begin with a letter and the short name "fw" is reserved for
use by Shorewall itself. Note that the output produced by iptables is much
easier to read if you select short names that are three characters or less
in length.
- DISPLAY - The name of the zone as displayed during Shorewall startup.
- COMMENTS - Any comments that you want to make about the zone.
Shorewall ignores these comments.
The /etc/shorewall/zones file released with Shorewall is as follows:
ZONE |
DISPLAY |
COMMENTS |
net |
Net |
Internet |
local |
Local |
Local networks |
dmz |
DMZ |
Demilitarized zone |
gw |
Gateway |
Tunnels to Peers |
You may add, delete and modify entries in the /etc/shorewall/zones file
as desired so long as you have at least one zone defined.
Warning: If you rename or delete a
zone, you should perform "shorewall stop; shorewall start" to
install the change rather than "shorewall restart".
6. /etc/shorewall/interfaces
This file is used to tell the firewall which of your firewall's network
interfaces are connected to which zone. There will be one entry in
/etc/shorewall/interfaces for each of your interfaces. Columns in an entry
are:
- ZONE - A zone defined in the /etc/shorewall/zones
file.
- INTERFACE - the name of the interface (examples: eth0, ppp0, ipsec+)
- BROADCAST - the broadcast address for the sub-network attached to the
interface. This should be left empty for P-T-P interfaces (ppp*, ippp*); if you need to
specify options for such an interface, enter "-" in this column.
If you supply the special value "detect" in this column, the
firewall will automatically determine the broadcast address. Note that to
use this feature, you must have iproute installed and the interface must
be up before you start your firewall.
- OPTIONS - a comma-separated list of options. Possible options
include:
dhcp - The interface is assigned an IP address via DHCP or is
used by a DHCP server running on the firewall. The
firewall will be configured to allow DHCP traffic to and from the
interface even when the firewall is stopped.
noping - ICMP echo-request (ping) packets will be ignored by this
interface.
routestopped - When the firewall is stopped, traffic to and from
this interface will be accepted and routing will occur between this
interface and other routestopped interfaces. norfc1918 -
Packets arriving on this interface and that have a source address that is
reserved in RFC 1918 will be logged and dropped. routefilter -
Invoke the Kernel's route filtering facility on this interface. The kernel
will reject any packets incoming on this interface that have a source
address that would be routed outbound through another interface on the
firewall. Warning: If you specify this option
for an interface then the interface must be up prior to starting the
firewall. multi - The
interface has multiple addresses and you want to be able to route between
them. Example: you have two addresses on your single local interface eth1,
one each in subnets 192.168.1.0/24 and 192.168.2.0/24 and you want to
route between these subnets. Because you only have one interface in the
local zone, Shorewall won't normally create a rule to forward packets from
eth1 to eth1. Adding "multi" to the entry for eth1 will cause
Shorewall to create the local2local chain and the appropriate forwarding
rule.
Example 1: You have a conventional firewall setup in which eth0 connects
to a Cable or DSL modem and eth1 connects to your local network and eth0 gets
its IP address via DHCP. You want to ignore ping requests from the internet.
Your /etc/shorewall/interfaces file would be as follows:
ZONE |
INTERFACE |
BROADCAST |
OPTIONS |
net |
eth0 |
detect |
dhcp,noping,norfc1918 |
local |
eth1 |
detect |
routestopped |
Example 2: You have a standalone dialup Linux System. Your
/etc/shorewall/interfaces file would be:
ZONE |
INTERFACE |
BROADCAST |
OPTIONS |
net |
ppp0 |
|
|
7. /etc/shorewall/hosts Configuration (version 1.1 and
later)
For many applications, specifying zones entirely in terms of network
interfaces is sufficient. There may be times though where you need to define a
zone to be a more general collection of hosts. This is the purpose of the
/etc/shorewall/hosts file. Columns in this file are:
- ZONE - A zone defined in the /etc/shorewall/zones
file.
- HOST(S) - The name of a network interface followed by a colon
(":") followed by either:
- An IP address (example - eth1:192.168.1.3)
- A subnet in the form <subnet address>/<width> (example
- eth2:192.168.2.0/24)
If you want to specify an address or subnet without a network
interface, use "+" as the interface (example - +:155.186.235.151).
- OPTIONS - A comma-separated list of options. Currently only a single
option is defined:
routestopped - When the firewall is stopped, traffic to and from
this host (these hosts) will be accepted and routing will occur between this
host and other routestopped interfaces and hosts.
If you don't define any hosts for a zone, the hosts in the zone default
to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces to
the zone.
Note 1: You probably DON'T want to specify
any hosts for your internet zone since the hosts that you specify will be the
only ones that you will be able to access without adding additional rules.
Note 2The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow
you to define nested or overlapping zones. That is allowed (although
discouraged) but be aware that Shorewall processes zones in the order that
they appear in the /etc/shorewall/zones file. So if you have nested zones, you
want the sub-zone to appear before the super-zone and in the case of
overlapping zones, the rules that will apply to hosts that belong to both
zones is determined by which zone appears first in /etc/shorewall/zones.
8. /etc/shorewall/policy Configuration.
This file is used to describe the firewall policy regarding
establishment of connections. Connection establishment is described in terms
of clients who initiate connections and servers who receive
those connection requests. Policies defined in /etc/shorewall/policy describe
which zones are allowed to establish connections with other zones.
Policies established in /etc/shorewall/policy can be viewed as default
policies. If no rule in /etc/shorewall/rules applies to a particular
connection request then the policy from /etc/shorewall/policy is applied.
Three policies are defined:
- ACCEPT - The connection is allowed.
- DROP - The connection request is ignored.
- REJECT - The connection request is rejected with an ICMP
destination-unreachable packet being returned to the client.
For each policy specified in /etc/shorewall/policy, you can indicate
that you want a message sent to your system log each time that the policy is
applied.
Entries in /etc/shorewall/policy have four columns as follows:
- CLIENT - The name of a client zone (a zone defined in the /etc/shorewall/zones
file, "fw" or "all").
- SERVER - The name of a destination zone (a zone defined in the /etc/shorewall/zones
file, "fw" or "all").
- POLICY - The default policy for connection requests from the CLIENT
zone to the DESTINATION zone.
- LOG LEVEL - Optional. If left empty, no log message is generated when
the policy is applied. Otherwise, this column should contain an integer or
name indicating a syslog level. See the syslog.conf man page for a
description of each log level.
In the CLIENT and SERVER columns, you can enter "all" to
indicate all zones.
The policy file installed by default is as follows:
CLIENT |
SERVER |
POLICY |
LOG LEVEL |
local |
net |
ACCEPT |
|
net |
all |
DROP |
info |
all |
all |
REJECT |
info |
This table may be interpreted as follows:
- All connection requests from the local network to hosts on the
internet are accepted.
- All connection requests originating from the internet are ignored and
logged at level KERNEL.INFO.
- All other connection requests are rejected and logged.
WARNING:
The firewall
script processes the /etc/shorewall/policy file from top to bottom and uses
the first applicable policy that it finds. For example, in the following
policy file, the policy for (local, local) connections would be ACCEPT as
specified in the first entry even though the third entry in the file specifies
REJECT.
CLIENT |
SERVER |
POLICY |
LOG LEVEL |
local |
all |
ACCEPT |
|
net |
all |
DROP |
info |
local |
local |
REJECT |
info |
9. /etc/shorewall/rules
The /etc/shorewall/rules file defines exceptions to the policies
established in the /etc/shorewall/policy file. There is one entry in
/etc/shorewall/rules for each of these rules.
Entries in the file have the following columns:
These forms are used in conjunction with the ADDRESS column described
below in order to perform port forwarding and port redirection respectively.
In order to make use of this feature, you must have NAT
enabled.
- PROTO - Protocol. Must be a protocol name from /etc/protocols, a number,
"all" or "related" (Version 1.1.4 and later). Specifies the protocol of the connection
request. "related" should be specified only if you have given
ALLOWRELATED="no" in /etc/shorewall/shorewall.conf and you wish
to override that setting for related connections originating with the
client(s) and server(s) specified in this rule. When "related"
is given for the protocol, the remainder of the columns should be left
blank.
- PORT(S) - Port or port range being connected to. May only be
specified if the protocol is tcp, udp or icmp. For icmp, this column's
contents are interpreted as an icmp type. If you don't want to specify
PORT(S) but need to include information in one of the columns to the
right, enter "-" in this column. Beginning with version 1.1.12,
you may give a list of ports and/or port ranges separated by commas.
- CLIENT PORTS(S) - May be used to restrict the rule to a particular
client port or port range. If you don't want to restrict client ports
but want to specify an ADDRESS in the next column, enter "-" in this column.
Beginning with version 1.1.12, you may give a list of ports and/or port
ranges separated by commas.
- ADDRESS - If included and different from any IP address given in the
SERVER column then this is an address for some interface on the firewall
and connections to that address that match this rule will be forwarded to
the server specified in the SERVER column. In order to make use of this
feature, you must have NAT enabled. If you use the special value
"all" then requests matching this rule will be forwarded to the
IP address given in SERVER. The IP address (or "all") may be
optionally followed by ":" and a second IP address. This latter
address, if present, is used as the source address for packets forwarded
to the server (This is called "Source NAT" or SNAT).
Note: If you use SNAT and qualify the client zone with the name
of an interface (e.g., net:eth0), SNAT will occur regardless of which
interface the packet arrived on.
If SNAT is not used (no ":" and second IP address), the
original source address is used.
Example 1. You wish to forward all ssh connection requests from the
internet to local system 192.168.1.3.
RESULT |
CLIENT(S) |
SERVER(S) |
PROTO |
PORT(S) |
CLIENT PORT(S) |
ADDRESS |
ACCEPT |
net |
local:192.168.1.3 |
tcp |
ssh |
- |
all |
Example 2. You want to redirect all www requests from the local network
to a Squid server running on the firewall and listening on port 8080. Squid
will require access to remote web servers.
RESULT |
CLIENT(S) |
SERVER(S) |
PROTO |
PORT(S) |
CLIENT PORT(S) |
ADDRESS |
ACCEPT |
local |
fw::8080 |
tcp |
www |
- |
all |
ACCEPT |
fw |
net |
tcp |
www |
|
|
Example 3. You want to run a web server at 155.186.235.222 in your DMZ
and have it accessible remotely and locally. the DMZ is managed by Proxy ARP
or by classical sub-netting.
RESULT |
CLIENT(S) |
SERVER(S) |
PROTO |
PORT(S) |
CLIENT PORT(S) |
ADDRESS |
ACCEPT |
net |
dmz:155.186.235.222 |
tcp |
www |
- |
|
ACCEPT |
local |
dmz:155.186.235.222 |
tcp |
www |
|
|
Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded
DMZ. Your internet interface address is 155.186.235.151 and you want the FTP
server to be accessible from the local 192.168.1.0/24 and dmz 192.168.2.0/24
subnetworks. Note that size the server is in the 192.168.2.0/24 subnetwork, we
can assume that access to the server from that subnet will not involve the
firewall.
RESULT |
CLIENT(S) |
SERVER(S) |
PROTO |
PORT(S) |
CLIENT PORT(S) |
ADDRESS |
ACCEPT |
net |
dmz:192.168.2.2 |
tcp |
ftp |
- |
all |
ACCEPT |
local:192.168.1.0/24 |
dmz:192.168.2.2 |
tcp |
ftp |
|
155.186.235.151 |
If you are running wu-ftpd, you should restrict the range of passive
in your
/etc/ftpaccess file. I only need a few simultaneous FTP sessions so I use port
range 65500-65535. In /etc/ftpaccess, this entry is appropriate:
passive ports 0.0.0.0/0 65500 65534
If you are running pure-ftpd, you would include "-p
65500:65534" on the pure-ftpd runline.
The important point here is to ensure that the port range used for FTP
passive connections is unique and will not overlap with any usage on the
firewall system.
Look here for information on other services.
10. /etc/shorewall/masq
The /etc/shorewall/masq file is used to define classical IP
Masquerading. There is one entry in the file for each subnet that
you want to masquerade. In order to make use of this feature, you must have NAT
enabled.
Columns are:
- INTERFACE - The interface that will masquerade the subnet; this is
normally your internet interface. This interface name can be optionally
qualified by adding ":" and a subnet or host IP. When this
qualification is added, only packets addressed to that host or subnet will
be masqueraded.
- SUBNET - The subnet that you want to have masqueraded through the
INTERFACE.
Example 1: You have eth0 connected to a cable modem and eth1 connected to
your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq file would look
like:
INTERFACE |
SUBNET |
eth0 |
192.168.9.0/24 |
Example 2: You have a number of IPSEC tunnels through ipsec0
and you want to masquerade traffic from your 192.168.9.0/24 subnet to the
remote subnet 10.1.0.0/16 only.
INTERFACE |
SUBNET |
ipsec0:10.1.0.0/16 |
192.168.9.0/24 |
11. /etc/shorewall/proxyarp
The /etc/shorewall/proxyarp file is used to define Proxy ARP. You need
one entry in this file for each system to be proxy arp'd. Columns are:
- ADDRESS - address of the system.
- INTERFACE - the interface that connects to the system.
- EXTERNAL - the external interface that you want to honor ARP requests
for the ADDRESS specified in the first column.
Example: You have public IP addresses 155.182.235.0/28. You configure
your firewall as follows:
- eth0 - 155.186.235.1 (internet connection)
- eth1 - 192.168.9.0/24 (masqueraded local systems)
- eth2 - 192.168.10.1 (interface to your DMZ)
In your DMZ, you want to install a Web/FTP server with public address
155.186.235.4. On the Web server, you subnet just like the firewall's eth0 and
you configure 155.186.235.1 as the default gateway. In your
/etc/shorewall/proxyarp file, you will have:
ADDRESS |
INTERFACE |
EXTERNAL |
155.186.235.4 |
eth2 |
eth0 |
Note: You may want to configure the servers in your DMZ with a
subnet that is smaller than the subnet of your internet interface. See the
Proxy ARP Subnet Mini Howto for details.
12. /etc/shorewall/nat
The /etc/shorewall/nat file is used to define static NAT. There is one
entry in the file for each static NAT relationship that you wish to define. In
order to make use of this feature, you must have NAT
enabled.
Columns in an entry are:
- EXTERNAL - External IP address
- INTERFACE - Interface that you want the EXTERNAL IP address to appear
on.
- INTERNAL - Internal IP address.
Look here for additional information and an example.
13. /etc/shorewall/tunnels
The /etc/shorewall/tunnels file allows you to define IPSec and IPIP tunnels with
end-points on your firewall. To use ipsec, you must install version 1.9, 1.91 or the
current FreeS/WAN
development snapshot.
Note: For kernels 2.4.4 and above, you will need to use version 1.91 or a development
snapshot as patching with version 1.9 results in kernel compilation errors.
Instructions for setting up IPSEC tunnels may be found
here and instructions for IPIP tunnels are here.
14. /etc/shorewall/shorewall.conf
This file is used to set the following firewall parameters:
- LOCKFILE
This parameter should be set to the name of a file that the firewall
should create if it starts successfully and remove when it stops. Creating
and removing this file allows Shorewall to work with your distribution's
initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall.
For Debian and LRP, the value is /var/state/shorewall. Example: LOCKFILE=/var/lock/subsys/shorewall.
- STATEDIR
This parameter specifies the name of a directory where Shorewall stores
state information. If the directory doesn't exist when Shorewall starts,
it will create the directory. Example: STATEDIR=/tmp/shorewall.
- ALLOWRELATED (Version 1.1.4 or later)
This parameter must be assigned the value "Yes"
("yes") or "No" ("no") and specifies whether
Shorewall allows connection requests that are related to an already
allowed connection. If you say "No" ("no"), you can
still override this setting by including "related" rules in
/etc/shorewall/rules ("related" given as the protocol).
- MODULESDIR (Version 1.1.5 or later)
This parameter specifies the directory where your kernel netfilter modules
may be found. If you leave the variable empty, Shorewall will supply the
value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
- LOGRATE and LOGBURST (Version 1.1.6 or later).
These parameters set the match rate and initial burst size for logged
packets. Please see the iptables man page for a description of the
behavior of these parameters (the iptables option --limit is set by
LOGRATE and --limit-burst is set by LOGBURST). If both parameters are set
empty, no rate-limiting will occur.
- NAT_ENABLED (Version 1.1.9 or later)
This parameter determines whether Shorewall supports NAT operations. NAT
operations include:
Static NAT
Port Forwarding
Port Redirection
Masquerading
If the parameter has no value or has a value of "Yes" or
"yes" then NAT is enabled. If the parameter has a value of
"no" or "No" then NAT is disabled.
- MANGLE_ENABLED (Version 1.1.9 or later)
This parameter determines if packet mangling is enabled. If the parameter
has no value or has a value of "Yes" or "yes" than
packet mangling is enabled. If the parameter has a value of "no"
or "No" then packet mangling is disabled. If packet mangling is
disabled, the /etc/shorewall/tos file is ignored.
- IP_FORWARDING (Added in version 1.1.10)
This parameter determines whether Shorewall enables or disables IPV4
Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values are:
On or on - packet forwarding will be enabled.
Off or off - packet forwarding will be disabled.
Keep or keep - Shorewall will neither enable nor
disable packet forwarding.
If this variable is not set or is given an empty value (IP_FORWARD="")
then IP_FORWARD=On is assumed.
15. /etc/shorewall/modules Configuration
The file /etc/shorewall/modules contains commands for loading the kernel
modules required by Shorewall-defined firewall rules. Shorewall will source
this file during start/restart provided that it exists and that the directory
specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf
above).
The file that is
released with Shorewall calls the Shorewall function "loadmodule" for the set of modules that I load.
The loadmodule function is called as follows:
loadmodule <modulename> [ <module parameters> ]
where
<modulename>
is the name of the modules without the trailing ".o" (example
ip_conntrack).
<module parameters>
Optional parameters to the insmod utility.
The function determines if the module named by <modulename> is
already loaded and if not then the function determines if the ".o"
file corresponding to the module exists in the moduledirectory; if so,
then the following command is executed:
insmod moduledirectory/<modulename>.o <module
parameters>
If the file doesn't exist, the function determines of the ".o.gz"
file corresponding to the module exists in the moduledirectory. If it
does, the function assumes that the running configuration supports compressed
modules and execute the following command:
insmod moduledirectory/<modulename>.o.gz <module
parameters>
16. /etc/shorewall/tos Configuration
The /etc/shorewall/tos file allows you to set the Type of Service field in
packet headers based on packet source, packet destination, protocol, source
port and destination port. In order for this file to be processed by
Shorewall, you must have mangle support enabled.
Entries in the file have the following columns:
- SOURCE -- The source zone. May be qualified by following the zone name
with a colon (":") and either an IP address, an IP subnet or the
name of an interface. This column may also contain "fw" to
indicate packets originating on the firewall itself or "all" to
indicate any source.
- DEST -- The destination zone. May be qualified by following the zone
name with a colon (":") and either an IP address or an IP
subnet. Because packets are marked prior to routing, you may not specify
the name of an interface. This column may also contain
"all" to indicate any destination.
- PROTOCOL -- The name of a protocol in /etc/protocols or the protocol's
number.
- SOURCE PORT(S) -- The source port or a port range. For all ports, place
a hyphen ("-") in this column.
- DEST PORT(S) -- The destination port or a port range. To indicate
all ports, place a hyphen ("-") in this column.
- TOS -- The type of service. Must be one of the following:
Minimize-Delay (16)
Maximize-Throughput (8)
Maximize-Reliability (4)
Minimize-Cost (2)
Normal-Service (0)
The /etc/shorewall/tos file that is included with Shorewall contains the
following entries.
SOURCE |
DEST |
PROTOCOL |
SOURCE PORT(S) |
DEST PORT(S) |
TOS |
all |
all |
tcp |
- |
ssh |
16 |
all |
all |
tcp |
ssh |
- |
16 |
all |
all |
tcp |
- |
ftp |
16 |
all |
all |
tcp |
ftp |
- |
16 |
all |
all |
tcp |
- |
ftp-data |
8 |
all |
all |
tcp |
ftp-data |
- |
8 |
17. Starting/Stopping and Monitoring the Firewall
If you have a permanent internet connection such as DSL
or Cable, I recommend that you start the firewall
automatically at boot. Once you have installed
"firewall" in your init.d directory, simply type
"chkconfig --add firewall". This will start the
firewall in run levels 2-5 and stop it in run levels 1 and 6.
If you want to configure your firewall differently from this
default, you can use the "--level" option in
chkconfig (see "man chkconfig") or using your
favorite graphical run-level editor.
Important Note:
If you use dialup, you may want to start the firewall
in your /etc/ppp/ip-up.local script. I recommend just placing
"shorewall restart" in that script.
You can manually start and stop Shoreline Firewall using
the "shorewall" shell program:
- shorewall start - starts the firewall
- shorewall stop - stops the firewall
- shorewall restart - stops the firewall (if it's
running) and then starts it again
- shorewall reset - reset the packet and byte counters
in the firewall
- shorewall clear - remove all rules and chains
installed by Shoreline Firewall
- shorewall refresh - refresh the rules involving the broadcast
addresses of firewall interfaces.
The "shorewall" program may also be used to monitor the
firewall.
- shorewall status - produce a verbose report about the firewall
(iptables -L -n -v)
- shorewall show chain - produce a verbose report about chain
(iptables -L chain -n -v)
- shorewall show nat - produce a verbose report about the nat table
(iptables -t nat -L -n -v)
- shorewall show tos - produce a verbose report about the mangle table
(iptables -t mangle -L -n -v)
- shorewall show log - display the last 20 packet log entries.
- shorewall monitor [ delay ] - Continuously display the firewall
status, last 20 log entries and nat. When the log entry display
changes, an audible alarm is sounded.
- shorewall hits - Produces several reports about the Shorewall packet log
messages in the current /var/log/messages file.
18. Extension Scripts
Beginning with version 1.1, Shorewall includes provisions for
extending Shorewall through Extension Scripts. Extension scripts are
user-provided scripts that are invoked at various points during firewall
start, restart, stop and clear. The scripts are placed in /etc/shorewall and
are processed using the Bourne shell "source" mechanism. The
following scripts can be supplied:
- init -- invoked early in "shorewall start" and
"shorewall restart"
- start -- invoked after the firewall has been started or restarted.
- stop -- invoked after the firewall has been stopped.
- clear -- invoked after the firewall has been cleared.
You can also supply a script with the same name as any of the filter
chains in the firewall and the script will be invoked after the
/etc/shorewall/rules file has been processed but before the
/etc/shorewall/policy file has been processed.
Beginning with version 1.1.2, the following two
files receive special treatment:
- /etc/shorewall/common -- If this file is present, the rules that it
defines will totally replace the default rules in the common chain. These
default rules are contained in the file /etc/shorewall/common.def which
may be used as a starting point for making your own customized file.
- /etc/shorewall/icmpdef -- If this file is present, the rules that it
defines will totally replace the default rules in the icmpdef chain. These
default rules are contained in the file /etc/shorewall/icmp.def which may
be used as a starting point for making your own customized file.
Rather than running iptables directly, you should run it using the
function run_iptables. Similarly, rather than running "ip" directly,
you should use run_ip. These functions accept the same arguments as the
underlying command but cause the firewall to be stopped if an error occurs
during processing of the command.
19. LRP
There are currently a couple of people working on getting LRP to work
with the 2.4 kernel:
At the current time, there are a couple of things to be aware of:
Updated 8/28/2001 - Tom
Eastep
|