(Also see the INSTALL and README files in the Seawall distribution).
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 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 PPP, DHCP or PPPoE then leave this empty (e.g., myip="").
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").
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.
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.
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 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:
- 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".
- 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 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.
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:
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.
Seattle Firewall supports VPN in two ways:
- IPIP tunnels from the firewall itself
- Masquerade of PPTP clients and servers
IPIP Tunnels
Ipip tunnels provide a simple way to connect a mobile host to your masqueraded network or to connect two masqueraded subnetworks. Directions are here.
PPTP
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.
Seawall is integrated with the Linux Router Project.
If you currently run LRP and want to use Seattle Firewall:
- Get the seawall-lrp module from the download site.
- Change the name of the downloaded module to seawall.lrp and use your preferred method (mcopy, lrcfg) to add it to your boot floppy.
- Add seawall to the module list in syslinux.cfg file on your boot floppy.
- Reboot your LRP system.
- Follow the normal Seattle Firewall configuration instructions. Note that you will have to change the value of the firewall variable in /etc/seawall.conf to "/etc/init.d/firewall".
- Start the firewall and test.
- Use lrcfg to save the updated configuration on your floppy.
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/7/2000 - Tom Eastep