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.
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.
- interfaces -- a parameter file installed in /etc/shorewall/ and used to describe the interfaces on the firewall system.
- 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.
Shorewall divides hosts 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; the file provided with Shorewall defines the following additional zones:
- net -- Interfaces to the (untrusted) internet.
- dmz - Interfaces for connecting systems that must be accessible from the internet and from the local network. Hosts connected to these interfaces cannot be trusted completely since their servers may have been compromised through a security exploit.
- local - Interfaces for connecting 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 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. 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.
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.
- 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".
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; 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. 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.
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 the local2local chain nor will it accept a local to local policy in the /etc/shorewall/policy file (see below). Adding "multi" to the entry for eth1 will cause Shorewall to create the local2local chain and accept local to local policy and rules.
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
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: When establishing the default policy for a (CLIENT,SERVER) pair, 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
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:
- RESULT - ACCEPT, DROP or REJECT. These have the same meaning here as in the policy file above. Beginning with Shorewall version 1.0.4, this may optionally be followed by ":" and a syslogd log level (example: REJECT:info). This causes the packet to be logged at the specified level prior to being ACCEPTed, DROPped or REJECTed.
- CLIENT - Describes the client. The contents of this field must begin with the name of a zone but may be qualified further by following the zone name with a colon (":") and the qualifier. Qualifiers may include:
- An interface name - refers to any connection requests arriving on the specified interface (example local:eth4).
- An IP address - refers to a connection request from the host with the specified address (example net:155.186.235.151)
- A subnet - refers to a connection request from any host in the specified subnet (example net:155.186.235.0/24).
- SERVER - Describes the server. May take any of the forms described above for CLIENT plus the following two additional forms:
- An IP address followed by a colon and the port number that the server is listening on (service names from /etc/services are not allowed - example local:192.168.1.3:80).
- Two colons followed by a port number (again, service names not allowed - example fw::8080) - this form is only allowed in the "fw" zone and refers to a server running on the firewall itself and listening on the specified port.
These forms are used in conjunction with the ADDRESS column described below in order to perform port forwarding and port redirection respectively.
- PROTO - Protocol. Must be a protocol name from /etc/protocols or a number or "all". Specifies the protocol of the connection request.
- 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.
- 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.
- 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. If you use the special value "all" then requests matching this rule will be forwarded to the IP address given in SERVER.
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 dmz:192.168.2.2 net tcp - ftp-data ACCEPT local:192.168.1.0/24 dmz:192.168.2.2 tcp ftp 155.186.235.151 ACCEPT dmz:192.168.2.2 local:192.168.1.0/24 tcp - ftp-data If you are running wu-ftpd, you 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.
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. Columns are:
- INTERFACE - The interface that will masquerade the subnet; this is normally your internet interface.
- SUBNET - The subnet that you want to have masqueraded through the INTERFACE.
Example: 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
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 establish a host route to 192.168.10.1 and use that as the Web Server's default route. In your /etc/shorewall/proxyarp file, you will have:
ADDRESS INTERFACE EXTERNAL 155.186.235.4 eth2 eth0
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. 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.
The /etc/shorewall/tunnels file allows you to define IPSec tunnels with end-points on your firewall. To use this feature, you must install version 1.9 or the current FreeS/WAN development snapshot.
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.
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 have specified "detect" for any interfaces in /etc/shorewall/interfaces, then those interfaces must be started before you start the firewall. If you are worried about the window between when your internet interface is started and when Shorewall is started, you can always arrange for the firewall to be stopped prior to starting your internet interface or you can remove the "detect" keyword and replace it with the actual broadcast address for the interface. This will allow you to start your firewall prior to starting your network interfaces.
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
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 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.
Updated 3/18/2001 - Tom Eastep