Seattle Firewall

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. The /etc/seawall.conf file

The seawall.conf file 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="").

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="").

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").

replyports

If you wish to run other TCP applications that talk to external hosts from the firewall system, list their TCP port numbers in this variable (example: replyports="ftp www https telnet finger whois").

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.

6. The /etc/seawall/servers File

If you wish to run server application on masqueraded systems, you must describe those applications in the file /etc/seawall/servers (You don't need this file on a standalone system).

The file contains a table with four colums as follows:

The default table is as follows:

#PROTOCOL PORT 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 SERVER (Optional) SERVER PORT (Optional)
tcp ssh 192.168.2.2  
tcp www 192.168.2.2  
tcp auth    
tcp smtp 192.168.2.2  
tcp ftp 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 port of the ftp server masquerade patch available at ftp://dsl.206.191.149.206.emeraldnet.net/pub/patches/ip_masq_ftp.patch. 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 ftp.

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 /etc/seawall.conf:

dmz

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

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

Seawall is integrated with the Linux Router Project.

If you currently run LRP and want to use Seattle Firewall:

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 5/29/2000 - Tom Eastep