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.
Seattle Firewall consists of the following components:
- apps -- a parameter file installed in /etc/seawall that defines client applications that run on the firewall system
- firewall -- a shell program that reads seawall.conf and /etc/seawall/* 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 and LRP, ...).
- seawall -- 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).
- seawall.conf -- a parameter file that is placed in /etc and that is used to configure the firewall.
- servers -- a parameter file installed in /etc/seawall that defines servers running of the firewall system or on masqueraded systems in your local network
- version -- a file created in /etc/seawall/ that describes the version of the Seattle Firewall installed on your system.
- Additional files in /etc/seawall/ -- a set of optional files that can be used to extend the firewall ruleset.
Seattle Firewall makes heavy use of user-defined chains. These chains are:
- remote -- All packets received on the external interface are passed to this chain.
- tcp -- All TCP packets from the external interface are passed to this chain
- tcpsyn -- All SYN packets from the external interface that aren't handled by standard rules or /etc/seawall/servers are passed to this chain. SYN packets are TCP session establishment requests.
- tcpdata -- All non-SYN TCP packets from the external interface that aren't handled by standard rules or by /etc/seawall/apps or /etc/seawall/servers are passed to this chain.
- icmp-acc -- All ICMP packets from the external interface are passed to this chain.
- udp-in -- All UDP packets from the external interface are passed to this chain.
- seawall -- This chain is added as a last step in starting the firewall. It's presence indicates that the firewall is completely started.
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.
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.
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:
- PROTOCOL -- must start in column 1 and be either "tcp" or "udp"
- SOURCE PORT -- The source port in packets entering your local network. Because these are reply packets, the source port is the port that the local applications connected to. For example, if you ant to run a web browser on your gateway, the SOURCE port is "80" or "www".
- SOURCE ADDR (Optional) -- The address(es) of servers providing this service. If not supplied, your gateway system may obtain this service from any host. If you need to specify DEST PORT but don't want to restricct SOURCE ADDR, specify 0.0.0.0/0 as the SOURCE ADDR.
- DEST PORT (Optional) -- The port or port range on the local system that is/are permitted to receive these packets. If omitted, the localports value is assumed.
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.
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:
- PROTOCOL -- must start in column 1 and be "tcp" or "udp".
- PORT -- Local port number. For example, if you run a web server locally the port number would be "80" or "web".
- CLIENT(s) -- IP Address or network of clients allowed to connect to the server (Note: This column does not exist in version 3.1 and earlier).
- SERVER (Optional) IP Address of the masqueraded system providing the service. If omitted, the gateway system itself is presumed to provide the service.
- SERVER PORT (Optional) -- May only be specified if SERVER is specified and gives the port that the application is listening on. If omitted, the PORT column contents are assumed.
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.
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.
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:
- seawall start - starts the firewall
- seawall stop - stops the firewall
- seawall restart - stops the firewall (if it's running) and then starts it again
- seawall reset - reset the packet and byte counters in the firewall
- seawall clear - remove all rules and chains installed by Seattle Firewall
You can also monitor the firewall using "seawall monitor" and "seawall status"
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:
- /etc/seawall/start - is executed after Seattle Firewall has completed it normal startup
- /etc/seawall/stop - is executed after Seattle Firewall has completed it normal shutdown
Note: to avoid unbounded recursion, do not use run_ipchains or run_ipmasqadm in /etc/seawall/stop.
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.
Seattle Firewall supports VPN in several ways:
- IPIP tunnels from the firewall itself
- IPSec tunnels from the firewall itself or from a masqueraded system
- Masquerade of PPTP clients and servers
- PoPToP Running on the firewall.
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.
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