>>>>>>>>>>>>>>>If you read nothing else, please read this<<<<<<<<<<<<<<<<

        This program offers an aid to creating firewall rules.  It offers
ABSOLUTELY NO intelligence in deciding what should be allowed or
disallowed.  It has ABSOLUTELY NO ability to understand your security
policy and implement it.  YOU are responsible for reviewing the rules and
massaging them to fit your needs.
        While this documentation attempts to provide some general
guidelines on how to use Mason, please remember:  the author has no
knowledge of what you want your firewall to do and has not tailored the
documentation or program to specially fit your needs.  If there is ever a
discrepancy between your needs and the program output or your needs and
the documentation, the program and/or documentation are _dead_ _wrong_. 


Copyleft:
    Mason interactively creates a Linux packet filtering firewall.
    Copyright (C) 1998 William Stearns <wstearns@pobox.com>

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

    The author can also be reached at:
        William Stearns
email:  wstearns@pobox.com              (preferred)
web:    http://www.pobox.com/~wstearns
snail:  544 Winchester Place
        Colchester VT, 05446, USA


        This code is entirely owned by William Stearns
(wstearns@pobox.com) and has no relation to any employer or employer
sponsored project.

------------------------------ Mason ------------------------------
        The Mason script interactively builds a (fire)wall on a Linux
machine. For more details about how this is done, please read on for
background, theory of operation, a quick start, and additional
documentation on firewalls and firewall gotcha's. 
        mason.txt and related documentation should have been installed to
/usr/doc/mason-{version}/ .  If they are missing or you would like to make
sure you have the latest version, please go to
http://www.pobox.com/~wstearns/mason/ .


- Bill Stearns




DNS:
	If the firewall or one of the machines behind it is a DNS server,
you have a situation where mason issues a steady flow of DNS requests to
resolve the machine names and each DNS request requires a new rule, which
in turn requires more DNS requests... ugh.
	There are a couple of ways around this:

- Write the correct ipfwadm rules for DNS lookup for your particular setup
and put them in place before running mason. 

- Use trusted external DNS servers, i.e. servers that do not have to
resolve _through_ your firewall.  This reduces the number of rules
necessary to handle DNS to just a few. 

- Put the names of all relevant hosts in the namecache file (see below) or
in /etc/hosts.  Mason uses these files before going out to DNS to try to
minimize the snowball effect when it occurs. 

- Comment out the DNS lookup code in Mason.  At some point this will be 
command line configurable, but not quite yet.

- Insert general rules for DNS in your rule set.  If you're not sure what
these should be, the following six rules should allow all DNS requests
from anywhere to anywhere.  Please note that depending on your security
policy, this are very likely to be too general and should be reviewed. 

	/sbin/ipfwadm -I -i accept -S 0/0 53 -P udp
	/sbin/ipfwadm -I -i accept -D 0/0 53 -P udp
	/sbin/ipfwadm -O -i accept -S 0/0 53 -P udp
	/sbin/ipfwadm -O -i accept -D 0/0 53 -P udp
	/sbin/ipfwadm -F -i accept -S 0/0 53 -P udp
	/sbin/ipfwadm -F -i accept -D 0/0 53 -P udp

	Note that I don't include _tcp_ dns zone transfers here.  These
transfers are generally rare and between a few machines.  These are good
candidates for having explicit rules added automatically by mason.


ftp:
	Ahhh, yes, ftp.  The scourge of firewall creators everywhere.  
	Ftp starts off well because the client opens a connection from a
high port (1024-65535) to the ftp control port 21.  This part of the
connection follows the same model as other tcp protocols: client uses a
random high port and connects to a fixed low port. 
	The problem arises when it's time to actually transmit data.  The
client and server exchange directory listings and files over additional
tcp connections that are between a random high port at the client end and
a random high port at the server end.
	Remember that packet filtering firewalls depend on being able to
identify connections by their (fixed and generally low) server port.  Here
we have connections that need to be allowed if ftp is going to work, but
can't be identified this way. 
	It really comes down to a choice: does the firewall allow ftp
traffic (leaving at least one high to high rule which is a generally
considered a security risk), or do we block ftp?  You'll need to decide. 

	Mason creates these rules as transparently as any others.  It
opens up the ports for the control channel and the high to high rule
(called the data channel).  A single ftp connection could therefore open
12 rules.  You'll need to decide whether these high to high rules are too
much of a security risk. 
	If you do choose to open up ftp rules, you might want to do these
last.  This allows you to put in more specific rules first.


ssh:
	SSH (server port 22/tcp) has one minor note about its operation. 
When installed by root (setuid), it does not use a random high port
between 1024 and 65535 for the client end.  The first client session uses
port 1023, the next uses 1022, etc.  No real problem for Mason, but you
might be surprised at the client ports used. 
	These client ports should NOT be listed in /etc/services, even
though it might seem to make identification easier.  The reason is that
Mason uses this file to identify _server_ ports in the process of deciding
whether to use the ACK flag check.


