Seattle Firewall Version 3.2.2

Documentation


1. Philosophy

2. Components

3. Firewall Structure

4. The /etc/seawall.conf file

5. The /etc/seawall/apps file

6. The /etc/seawall/servers file

7. Starting/stopping and Monitoring the firewall

8. Extending Seattle Firewall through /etc/seawall/*

9. DMZ

10. VPN

11. LRP


1. Philosophy

The Seattle Firewall is intended to strictly limit the types of packets admitted from the Internet without restricting what users at masqueraded systems are allowed to run. When running on a masquerading gateway/firewall system, Seattle Firewall reflects my personal belief that only a minimum set of applications should run on the firewall system itself. Simple changes to /etc/seawall.conf , /etc/seawall/apps and /etc/seawall/servers allow you to taylor the firewall for most purposes. Experts are able to define additional ipchain rules by adding more files to /etc/seawall.

When running on a standalone system, Seattle Firewall allows you a lot of freedom but you may have to extend it for particular applications.

2. Components

Seattle Firewall consists of the following components:

3. Firewall Structure

Seattle Firewall makes heavy use of user-defined chains. These chains are:

These chains are created when the firewall is started and are deleted when the firewall is stopped. When the firewall is stopped, the external (Internet) interface on the firewall system is essentially disabled.

4. /etc/seawall.conf

The file /etc/seawall.conf is sourced by the firewall script using the bourne shell "." command. This file defines a number of shell variables that the firewall script uses to directly configure the firewall. The commonly-used variables are described in this section; those that are involved with tunneling are described below.

internet

This is the interface that connects you to your ISP. If you have a DSL or Cable connection, this is probably eth0; if you use dialup, it is probably ppp0.

Example: internet="eth0"

myip

This is the IP address of your internet interface. If you have a fixed IP address, set myip to that address (example: myip="203.191.149.222"). If you have a dynamic address via DHCP then leave this empty (e.g., myip=""). Otherwise, set myip="PPP".

local

This is a list of local interfaces that you want to masquerade (example: local="eth1 eth2"). If this is a standalone system, then leave this variable empty (e.g., local="").

nonmasq

This variable lists local interfaces that you want to enable but that you don't want masqueraded and that you don't want forwarded to/from the internet (Example: nonmasq="eth1"). Interfaces listed under nonmasq should not be listed under local or dmz.

strong

The setting of this variable specifies how the firewall determines the set of TCP client applicatons that can run on the firewall system. If the variable is set to "Yes" or "yes", then the applications allowed on the firewall are determined by the /etc/seawall/apps file.

If the variable is set to "No" or "no" then any TCP application is permitted on the firewall system.

If the variable is left empty then if either the
local or dmz variables are non-empty, then 'strong=Yes' is assumed. If local and dmz are both empty then 'strong=No' is assumed.

localports

The IANA recommends that the range of port numbers used for local dynamic ports should start no lower than 49152 while Linux has traditionally used the range 1024:4999. If you wish to change the local port range to conform to the IANA recommendation, you may do so by assigning this variable to the desired range (Example: localports="50000:54999").

WARNING: If you change the value of this variable and restart Seattle Firewall, applications that have allocated dynamic ports in the old range will stop working. It is therefore recommended that this value be changed only while you are running in single-user mode or just before you reboot.

If you leave this variable empty, the contents of /proc/sys/net/ipv4/ip_local_port_range (with suitable reformatting) are used.

log

Set this variable to "Yes" or "yes" if you want denied packets to be logged. Ipchains packet log messages are logged under the Kernel facility with priority of Info - see "man syslog.conf" for information about routing these messages to their own destination.

lockfile

The lockfile variable is used to integrate Seattle Firewall with SysVInit. If your version of init uses lockfiles (as RedHat's does), then this variable should contain the name of the lockfile for this service. For RedHat, this should be set as:

lockfile="/var/lock/subsys/firewall"

For Debian/LRP, this should be set as:

lockfile="/var/state/firewall"

dnsservers

If you need to access external DNS servers from the firewall system, list the IP addresses of those servers here (example: dnsservers="203.191.149.2 203.191.150.10"). If you want to disallow any traffic on port 53 between the firewall and the outside world, set this variable to "none" or "None" (dnsservers="None"). If you want your firewall to be able to talk to any DNS server, leave this variable empty (e.g.,  dnsservers="").

dnslocalports

The contents of this variable determine the local ports range used for DNS queries and is of primary use to people who run dnscache on their firewall. Dnscache selects a random port in the range 1025:65535 for each DNS query so users of that program will want to set dnslocal ports as follows: dnscache="1025:". Other users can leave this variable empty (dnslocalports="") in which case the localports range will be used.

ntpservers

If you run xntpd on your firewall system and synchronize with an external NTP server, set this variable to the address of the server(s) (example: ntpservers="203.191.149.1").

ntpnonpriv

If you run ntp clients on your firewall system that use non-privileged local ports, set this variable to "Yes" or "yes". Otherwise, set the variable to "No" or "no".

icqports

If you wish to run an ICQ client on a standalone system, you need to set the client up as firewalled and reserve a series of ports for incoming connnections. You specify that port range in this variable (example: icqports="3000:3999").

If you are running a masquerading firewall, see the discussion of icqports below.

Note: The remaining variables only need to be set if you are masquerading (i.e., if the "local" variable is non-empty). If you are using Seattle Firewall on a standalone system, just make these variables empty.

networks

If you have subnetworks that are to be masqueraded but that are accessed through a routers in your local network(s), you must list them here. Example: networks="192.168.8.0/24".

smtpservers

If you need to send mail from the firewall system to external SMTP servers (e.g. sendmails "smartrelay" directive), list their IP addresses here (e.g., smtpservers="203.191.148.10").  On a dedicated firewall system, you will probably send external mail from your masqueraded systems and will leave this variable empty (e.g., smtpservers="").

popservers

If you need to retreive mail from external POP-3 servers directly to your firewall, list the IP addresses of those servers in this variable (e.g., popservers="203.191.141.10 146.44.242.3").

icqports

If you plan to run ICQ clients on masqueraded systems, I recommend that you use the ICQ Masquerade module and include "icq" in the value of the "modules" variable (see below). By default, this module uses ports 60200:61000 for forwarding ICQ connections. If you don't use the ICQ Masquerade module or if you do use the module but you don't override the standard forwarding ports, leave this variable empty (e.g., icqports="").

If you do override the standard forwarding ports through a parameter to the ICQ Masquerade module, you need to specify those ports here (example: icqports=60200:60400).

modules

This variable lists the Masquerade modules that you want loaded when the firewall is started. The masquerade modules all have names that start with "ip_masq_" so Seattle Firewall will provide that part of the name and you only need to specify the last part of the module names (example: modules="ftp icq raudio pptp". This would cause the ip_masq_ftp, ip_masq_icq, ip_masq_raudio and ip_masq_pptp modules to be loaded).

masq_timeouts

This variable defines the length of time that the firewall will maintain inactive masquerade sessions. I recommend

masq_timeouts="7200 10 160"

which is 2 hours for TCP, 10 seconds for traffic after the TCP "FIN" packet is received and 160 seconds for UDP.

5. The /etc/seawall/apps File

The file /etc/seawall/apps determines those applications which can be run on a masquerading gateway system that uses Seattle Firewall (You won't normally need this file on a standalone system using Seattle Firewall).

The file contains a table with four columns as follows:

The default file is as follows:

#PROTOCOL SOURCE PORT SOURCE ADDR (Optional) DEST PORT (Optional)
tcp whois    

The single entry in the file allows whois to run on the firewall system.

If you want to run ftp clients on a firewall with 'strong="Yes"', then see these instructions.

6. The /etc/seawall/servers File

If you wish to run server applications on the firewall system or on masqueraded systems, you must describe those applications in the file /etc/seawall/servers.

The /etc/seawall/servers file format was changed in Seattle Firewall version 3.2. Beginning with that version, the first line of the file must be as follows:

#VERSION=2

Comments may follow the version specification provided that they are separated from the version number by white space. If a version 3.2 or later firewall is started and the first line of the file does not contain a version specification as just described, the file will be automatically converted to the new format. If you did not install the new version of Seattle Firewall using install.sh, the original file will be saved as /etc/seawall/servers-<version>.bkout (e.g., /etc/seawall/servers-3.2.bkout).

The file contains a table with five colums as follows:

The default table is as follows:

#PROTOCOL PORT CLIENT(S) SERVER (Optional) SERVER PORT (Optional)
tcp ssh      
tcp auth      

In my installation, I have a small server at address 192.168.2.2 that runs Apache (http only), an ftp server, sshd, a mail server. The gateway system itself runs an identd daemon. My table is as follows:

#PROTOCOL PORT CLIENT(S) SERVER (Optional) SERVER PORT (Optional)
tcp ssh 0.0.0.0/0 192.168.2.2  
tcp www 0.0.0.0/0 192.168.2.2  
tcp auth 0.0.0.0/0    
tcp smtp 0.0.0.0/0 192.168.2.2  
tcp ftp 0.0.0.0/0 192.168.2.2  

If you specify a server IP address, you must have ipmasqadm installed and you must include "portfw" in modules.

Note: The current ftp masquerade module only supports active mode clients when masquerade an ftp server. I have a 2.2.14 and 2.2.16 ports of the ftp server masquerade patch available at ftp://seawall.sourceforge.net/pub/Seawall/patches/. The patch was originally written by Fred Viles for kernel version 2.0 and was ported to 2.2 by Neil Toronto. The patch at the above URL is a extensively modified version of Neil's port.

If you use this patch and want to masquerade an ftp server, include the following in your /etc/conf.modules file:

options ip_masq_ftp server=1

When running with server support, you are limited to using port 21 for incoming ftp.

Look here for additional requirements for running an FTP server on the firewall or on a masqueraded system.

If you need to specify a list of clients for a masqueraded server, you should only include the Server's IP address (and it's port number if you need to specify that) on the first line for that service. Example:

#PROTOCOL PORT CLIENT(S) SERVER (Optional) SERVER PORT (Optional)
tcp smtp 155.198.127.44 192.168.2.2  
tcp smtp 130.252.100.0/24    
tcp smtp 24.133.19.45    

In this example, the SMTP server on internal system 192.168.2.2 will be available to 155.198.127.44, the subnetwork 130.252.100.0/24 and from 24.133.19.45.

 

7. 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 your internet connection has a dynamic address (you have myip="" in /etc/seawall.conf), then your internet interface must be started before you start the firewall. Your local interfaces must always be started before you start the firewall. If you are worried about the window between when your internet interface is started and when Seattle Firewall is started, you can always arrange for the firewall to be stopped prior to starting your internet interface. To see how I do that, go here.

If you use dialup, you will want to start the firewall in your /etc/ppp/ip-up.local script. I recommend just placing "seawall restart" in that script.

You can manually start and stop Seattle Firewall using the "seawall" shell program:

You can also monitor the firewall using "seawall monitor" and "seawall status"

8. Extending Seattle Firewall through /etc/seawall/*

The variables in seawall.conf and the facilities provided by /etc/seawall/apps and /etc/seawall/servers are ones that I have found useful. Depending on what you want to do, the level of configuration control that these files provide may not be sufficient. To allow you to extend Seattle Firewall's function without having to modify the firewall program (of course you can also do that if you want -- it will just make it more difficult for you to upgrade to later versions of my code), Seattle Firewall provides the ability for you to extend each of the chains (standard chains and user-defined). For each chain, you can supply the file "/etc/seawall/chain". When the firewall script is defining each chain, it checks to see if there is a corresponding file in /etc/seawall and if the file is executable; if so, that file is read (sourced) using the shell "." command). If you want to run ipchains within one of these files, I recommend that you use the "run_ipchains" function -- the function accepts the same arguments as ipchains but if an error occurs, run_ipchains will automatically stop the firewall so you can correct the problem and try to restart it. Similarly, if you need to run ipmasqadm, use the function "run_ipmasqadm".

Two additional files can be provided:

Note: to avoid unbounded recursion, do not use run_ipchains or run_ipmasqadm in /etc/seawall/stop.

9. DMZ

The 3.0 version of Seattle Firewall contains limited support for a DMZ. The DMZ is assumed to be interfaced through a separate ethernet controller and external access to the DMZ is through entries in /etc/seawall/servers. The dmz is specified using the following variable in the configuration file:

dmz

Specifies the interface to the DMZ (example: dmz="eth2"). The DMZ interface should NOT be included in the local or nonmasq variables.

Servers in the DMZ may be accessed from the local network(s) either by their internal IP address or by the IP address of the gateway's external interface. The local network(s) may not be accessed from the DMZ.

10. VPN

Seattle Firewall supports VPN in several ways:

IPIP Tunnels

Ipip tunnels provide a simple way to connect a mobile host to your masqueraded network or to connect two masqueraded subnetworks. For Seattle Firewall version 3.1 and later, see these instructions. For Seattle Firewall versions before 3.1, see these instructions.

IPSec

Seattle Firewall allows the firewall system to act as an IPSec gateway when Linux FreeS/WAN is installed on that system. Seattle Firewall also supports a masqueraded IPSec gateway. Instructions are here.

PPTP/PopToP

PPTP is the tunneling protocol favored by Microsoft. I have support for it in Seattle Firewall because I telecommute and need to use PPTP in my daily work. Documentation is here.

11. LRP

Seattle Firewall is integrated with the Linux Router Project.

Tim Wegner has helped put together these instructions for installing Seattle Firewall on the Eiger LRP Distribution.

There is also a version of Seattle Firewall available for Coyote and these are the instructions for installing it.

If you need help with building an LRP boot floppy, try mkrtrfd -- the documentation that comes with mkrtrfd is also useful for making your own boot floppies by hand. See the LRP site for additional documentation.


Last updated 7/26/2000 - Tom Eastep