~ubuntu-branches/ubuntu/natty/mason/natty : contents of mason.txt at revision 7

~ubuntu-branches/ubuntu/natty/mason/natty : (revision 7)

The Mason HOWTO
William Stearns wstearns@pobox.com

v1.0.0, May 2002

This describes the basic operation of Mason and its use in creating
firewalls under Linux.

______________________________________________________________________

Table of Contents

1. Formalities

1.1 Disclaimer
1.2 Copyleft

2. Introduction

2.1 Background and motivation
2.2 Basic theory of operation
2.3 Compatibility and requirements
2.4 Features

3. Quickstart

3.1 Make sure the system is already pretty secure.
3.2 Install the Mason package
3.3 Prepare /etc/services
3.4 Prepare /etc/hosts
3.5 Prepare the routing table and interfaces
3.6 Check the configuration file
3.7 Place any known rules in /var/lib/mason/baserules
3.8 Run mason-gui-text
3.9 Tell your boss that you're going to need a few weeks to build this.
3.10 Implement the final firewall.

4. Special considerations

4.1 Kernel
4.2 Ipfw, Ipfwadm, Ipchains, and Iptables
4.3 DNS
4.4 Rule order
4.5 Generalization
4.6 Router or end node
4.7 Slow machines or fast nics
4.8 Active hacking while mason running
4.9 Masquerading
4.10 Offline and non-root creation
4.11 /etc/services and special ports
4.12 Insert vs. append
4.13 Allow versus deny and reject
4.14 Input, Output, and Forwarding
4.15 Remote firewall creation - Telnet/ssh lockout
4.16 Ack flag
4.17 Limitations, Ideas and future enhancements

5. Configuring Mason

6. IP protocols and their firewall characteristics

6.1 Standard TCP and UDP protocols
6.2 ICMP
6.3 DNS
6.4 FTP
6.5 Netbios
6.6 NTP
6.7 SSH
6.8 Other IP protocols

7. Version summary (out of date, sorry)

8. Advanced scenarios

8.1 General approach
8.2 Ordering rules
8.3 Tips and tricks

9. Notes about Mason itself

9.1 File descriptions

10. Additional resources

11. Authors, credits, feedback, copyright, how to help!

11.1 Thanks

______________________________________________________________________

1. Formalities

1.1. Disclaimer

---------------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_.

1.2. Copyleft

Mason interactively creates a Linux packet filtering firewall.

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:

email
wstearns@pobox.com (preferred)

web
http://www.stearns.org/mason/

snail

William Stearns
6 Manchester Dr.
Lebanon NH, 03766, USA

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

2. Introduction

"If you have not checked out Mason, I highly recommend it.
Mason is a Linux based firewall, but none like you've ever
used. In short, you put Mason into learning mode and run
the services to the Internet you wish to support. Mason will
then take these log entries and turn them into a set of
packet filtering rules. Pretty cool eh? No ACK compliment
rules to worry about, no "what was that service port again?"
decisions to worry about, simply plug it in, let it learn
and off you go. :)"

- - Chris Brenton, cbrenton@sover.net

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.stearns.org/mason/ .

The impatient should go right to the ``Quickstart''.

2.1. Background and motivation

The built-in firewall features of the Linux kernel offer a powerful
set of packet filtering features that can be used to build a firewall.
The various pieces of available documentation provide an introduction
on how to configure the firewall for simple setups, but can't possibly
explain how to configure a firewall for more complex setups, including
fine-grained allow and deny lists. This is especially obvious when
trying to create a firewall with a default policy of deny.

Someone looking to configure a linux firewall is simultaneously hit
with the complexity of trying to understand the ipfwadm syntax, trying
to understand the structure of TCP/IP connections, and trying to
create and implement a security policy. No wonder firewalls are
daunting!

The Mason application attempts to handle the first two problems by
dynamically creating the firewall based on the traffic flowing through
it. For example, if you start up a telnet session through your
firewall from a machine on your LAN to a machine out on the WAN while
mason is running, mason will create all the rules necessary to allow
this traffic.

Conversely, if you're looking to block incoming NFS requests, simply
launch mason, select a "deny" or "reject" policy, and make the NFS
connection. When the firewall is restarted, voila! No more incoming
NFS.

Creating a firewall no longer requires understanding the ipfwadm,
ipchains or iptables syntax. Even novices can create a firewall under
Linux. _HOWEVER_, creating a _good_ firewall _still_ requires some
understanding of TCP/IP protocols and packet filtering. Many good
books cover this. Check out O'Reilly and Associates (
http://www.ora.com or http://www.oreilly.com ) for some excellent
general coverage of firewall designs.

One last novice's mistake I'd like to see Mason users avoid is the
false sense of security that a firewall can provide. _Truly_ securing
a system or network requires _much_ more than simply filtering
packets. The aforementioned books provide a great background in
general security.

2.2. Basic theory of operation

Before starting, if the user has some rules that he or she knows
should be used in this machine, these can be added to
/var/lib/mason/baserules. As part of the process of running Mason,
we'll add rules that log all other packets to /var/log/messages. The
"tail" command is used to feed these log messages into Mason, which
converts each log entry into the corresponding command necessary to
allow that kind of traffic. In the previous telnet example, 6
different firewall rules would be created on the firewall, three for
the original request packet, 3 for the response back from the server
(just 1 or 2 in iptables firewalls):

pkt 1: Allow telnet request in from LAN
pkt 1: Forward request through firewall
pkt 1: Allow request to exit to WAN
pkt 2: Allow telnet response back into firewall from WAN
pkt 2: Forward response through system
pkt 2: Allow response to exit back to the original machine on the LAN.

All packets from 3 on are handled by these rules. There may be a
short delay in the initial connection as the rules are created.

The script creates the actual ipfwadm/ipchains/iptables commands to
accomodate the packet flow. When the command is executed the new rule
is inserted at the head of the existing rules so that future packets
of this type no longer reach the logging rule at the bottom.

The rules are also echoed to the console so that you can see the rules
as they are executed or redirect them to a file. This process is
handled automatically by mason-gui-text.

If any of this is unclear, take a look at the ``Quickstart'' which
walks you through actually running it. It'll make more sense when you
see it in action.

2.3. Compatibility and requirements

o Distributions

o Heavily tested on RedHat 5.x, 6.x, and 7.x

o Compatible with Debian 2.x

o Probably works with Slackware

o Probably works with Suse, but you need to choose between the
default /etc/rc.d/init.d/firewall and the one included with Mason

o Requirements

o Bash 1.x or 2.x

o Standard system utilities: awk, cat, chmod, cut, grep, head,
ifconfig, mkdir, ps, route, sed, sleep, sort, tail, touch, tr,
true, uniq and wc

o A kernel that supports packet filtering and packet logging (kernel
2.0's ipfwadm, kernel 2.2's ipchains, or 2.4's iptables)

o The ipchains, ipfwadm or iptables binaries.

o Things Mason doesn't care about

o Hardware architecture (i386, Axp, Sparc...)

o Number or type of interfaces

o Whether the machine is a router or end-node (a normal server or
workstation).

2.4. Features

Mason supports the following: (see the release notes for additional
features)

o It accepts any mix of ipchains, ipfwadm or iptables log entries as
input.

o It can run on an ipfwadm, ipchains or iptables kernel.

o It can spit out ipfwadm, ipchains or iptables output.

o In theory, the above 3 are independent from each other. Mason can,
for example, accept ipchains and ipfwadm log entries, run on an
ipfwadm host, and output ipchains rules. Unfortunately, the
structure and design of an iptables firewall is sufficiently
different from ipfwadm and ipchains firewalls that you can't
automatically convert back and forth.

o It will run on the firewall machine or on another machine, using
the firewall's packet logs as input.

o It can run as the traffic is flowing through the machine or be fed
the firewall logs later.

o While there are some advantages to running as root, it can be run
as a non-root user.

o Mason will put in a macro for dynamic IP addresses, usually for
your ppp link.

o It supports any kind of interface that can carry TCP/IP traffic.

o It recognizes any protocol listed in /etc/services and commonly
used icmp protocols.

o It automatically handles setups such as cable modem or satellite
where the packets go out on one interface and come back on another.

o It automatically handles masquerading on the firewall and the
strange rules that can require.

o It allows you to put in any rules you may know you need and fills
in the rest, or just builds the entire thing for you if you prefer.
It can also be used after a firewall has been created to fill in
some new rules or new protocols.

o It automatically generalizes the firewall rules in the following
ways:

o Any local IP addresses are converted to the corresponding local
network. Special IP's (0.0.0.0, 127.0.0.1, 255.255.255.255) are
handled appropriately. Mason can also be configured to leave
addresses alone or convert them to hostnames. This gives you the
ability to either treat all machines in a subnet as having equal
access rights or create fine-grained access rules for individual
servers, as you choose.

o Non-local IP's are converted to 0/0 (anywhere).

o Port numbers in /etc/services are converted to the corresponding
service name.

o High port numbers are generalized to 1024:65535. The special port
needs of ssh, traceroute, nfs, ip masquerading, irc, x,
openwindows, and vnc are handled automatically.

o The ack flag is set for all tcp connections except for ftp.

o The TOS (type Of Service) flag is set for ftp, ftp-data, imap, irc,
nntp, pop, ssh, snmp, and telnet to improve interactive performance
by queuing interactive packets ahead of bulk transfer packets.

o Each output line is commented to give you an idea of what it's for
and allow for easy grouping via sort.

o The rule policy can be changed on the fly without having to stop
Mason.

o Because Mason is a shell script, it can run on any system with bash
and basic GNU tools (sed, awk, grep, etc.). Actually creating the
firewall log entries, interactively building the firewall, or
implementing the finished firewall needs requires a Linux system
with appropriate kernel (generally 2.0.0 and up, including 2.1.x
and 2.2.x) with firewalling and firewall packet logging built in.

o Thanks to Don Howard howarddj@bigvax.alfred.edu, Mason 0.12.0 and
above have initial support for creating Cisco ACL's. The support
is not truly complete, and hence untested. It needs someone that's
interested in working with me on the project before it's complete.

o A rather extensive manual/howto/notes file covers operating Mason
and some issued associated with packet filtering firewalls. Good
reading for anyone trying to understand some of the more advanced
topics in packet filtering firewalls.

o automatically makes masq rules for reserved addresses

o icmp subcodes

o support for ip tunneling, cipe and a number of other protocols

o removal of the namecache (no longer needed)

o mason now stops logging packets quickly while it does the main
processing

o stop using ipcalc to calculate broadcast

o don't touch /etc/hosts or /etc/services

o more Debian integration and two man pages (Thanks, Jeff!)

o support for ipchains-save output format

o support for --sport and --dport (Thanks, Rusty!)

o major documentation updates

o the ability to add packet counts to each rule, sorting the most
commonly used rules to the top (ipfwadm and ipchains only; iptables
no longer requires this).

o misc. bug fixes and performance improvements

o fixes to the Cisco output format

o the ability to generalize the ack rules for tcp connections,
cutting 25%-35% of the rules

o an internal checkpointing ability to help in debugging

o Mason can find the smallest subnet that encompasses the ips found
on a dynamic interface

o and no_outgoing_ protocols

3. Quickstart

This document is designed to help people who are unfamiliar with Mason
build a firewall using it. A novice user should be able to start
building a basic firewall using these instructions in 20 minutes.

______________________________________________________________________
#include <disclaimer.h>
______________________________________________________________________

3.1. Make sure the system is already pretty secure.

See the Linux security sites and the Linux Administrators Security
Guide for more info. A strict packet filtering firewall is useless if
someone can get root access somehow; they can just turn off the
firewall.

3.2. Install the Mason package

5 minutes or less.

If you're using an rpm-based system, type just

______________________________________________________________________
rpm -Uvh ftp://www.stearns.org/pub/wstearns/mason/mason-1.0.0-0.noarch.rpm
______________________________________________________________________

Otherwise, download the latest version to /usr/src,

______________________________________________________________________
cd /usr/src<Enter>
tar -xzvf mason...tar.gz<Enter>
cd mason...<Enter>
make install<Enter>
______________________________________________________________________

3.3. Prepare /etc/services

Probably mostly done!

Mason depends on a few setup details to be able to provide a firewall
that works in the way you intended. Make sure that /etc/services
includes the server port names for all services you intend to work
with, whether those services are running on the firewall machine or on
some other machine.

For example, if you intend to use ssh to connect to another system,
make sure that the line

ssh 22/tcp

is in /etc/services. Entries that might be missing include:

ftp-data 20/tcp
ssh 22/tcp #Secure shell
linuxconf 98/tcp
squid 3128/tcp #Squid proxy cache requests
icp 3130/udp #Inter Cache Protocol, used in squid

It is not necessary to include entries for services that you don't
use. Also, do _not_ place entries for _client_ ports in this file;
Mason assumes anything referenced in this file is a server port. For
example, even though one of the client ports used for ssh is 1022/tcp,
you would _not_ place this in /etc/services. Doing so would cause
Mason to provide incorrect rules.

If you're not sure which ports are being used as servers on the
firewall or on other machines on your network, use the "netstat -an |
less" command on Linux/Unix systems and look for lines with "LISTEN".

3.4. Prepare /etc/hosts

Probably mostly done!

Try to place short names first. You don't have to do this, but the
firewall will be much more readable in the end if you do.

Make sure that your /etc/hosts file has at least entries for:

o locahost

o the ip addresses of all interfaces on your firewall

o all the networks in your routing table except 0.0.0.0.

o all dns servers

o any other hosts that Mason might treat specially

For example:

127.0.0.1 localhost
172.16.0.1 fwall-inside bastion bastion.mydomain.org
12.13.14.15 fwall-outside
172.16.0.0 INSIDE #I use all caps to distinguish networks from normal IP's.
12.13.14.0 OUTSIDE
12.13.16.10 myisp-dns1
12.13.16.11 myisp-dns2
12.13.14.44 ntp bonzo bonzo.mydomain.org

3.5. Prepare the routing table and interfaces

Probably already done!

Mason assumes that the routing table and interfaces are set up to
match the way the final firewall will run. If you're running this on
the actual firewall machine and all the interfaces and networks have
been configured, proceed to the next step.

Edit /etc/masonrc on the machine on which Mason will run. Edit the
line (or add it if it's not there)

NETWORKS="....."

Inside the quotes, place the following:

o All ip addresses of all interfaces for the firewall, each followed
by /32 .

o The ip's of any hosts that shouldn't be treated identically to the
other machines on their respective networks.

o All networks whose machines the firewall should treat identically.

For example, if the firewall had IP address 172.16.0.1 on network
172.16.0.0/255.255.0.0 and IP address 12.13.14.15 on network
12.13.14.0/255.255.255.0, I would add the following line to
/etc/networks if I was building the firewall on another machine:

NETWORKS="127.0.0.1/32 172.16.0.1/32 12.13.14.15/32 172.16.0.0/16 12.13.14.0/24"

3.6. Check the configuration file

5 minutes, more if you want to customize.

The configuration choices in /etc/masonrc are ordered so that the
fields you'll most likely need to edit are at the top and the really
obscure ones are at the bottom.

There are a few setting you must set for Mason to work at all:
NEWRULEPOLICY, DEFAULTPOLICY, and FLUSHEDPOLICY. If you have no
firewall at all and are creating one for the first time, set each to
"ACCEPT". During the learning process, you will have no protection at
all (all packets will be accepted), but note that this is no _less_
secure than a system without a firewall.

If you want to make the creation process a little more secure, you
might consider setting one of these to DENY or REJECT; see the
comments in /etc/masonrc and mason.txt for more info on this. In
particular, if you are building this remotely via a telnet or ssh
session, note that setting one of the above to something other than
ACCEPT before Mason knows about the telnet or ssh traffic almost
guarantees that you will lose the ability to telnet or ssh to the box
until it is rebooted from the console.

If you're in a rush to try out Mason, feel free to set just these
three fields and continue. The more of the settings you set to match
your needs, the better the firewall will be at matching your security
policy in the end.

3.7. Place any known rules in /var/lib/mason/baserules

No time for most people.

If you know some rules you'll need already, put them in this file.
For example, if you know you'll need to masquerade all traffic from
the 172.16.0.0/255.255.0.0 network, a sample rule for this is already
in baserules.

If you don't know of any, no problem.

3.8. Run mason-gui-text

This (admittedly rudimentary) interface helps you build the firewall.
Choose "BL" (begin learning) and watch mason start to spit out the
firewall rules that perfectly match your system's network traffic.

Check that stopwatch - you're building a firewall less than 20 minutes
from when you started! Give yourself a pat on the back. Mason will
do a great deal of the rest in the background while you're doing your
day to day work.

Do all of the things you want this firewall to support. If you want
to allow mail to be sent through it, send mail through it. if you
want to be able to ping it, ping it. If you want to be able to
traceroute from it, traceroute from it.... You get the idea.

Mason will present the new rules that match your networks traffic.
For each rule you'll be given the chance to modify the rule or commit
the rule. Here are the modify choices:

o Edit manually Edit the rule. You can make any changes you'd
like to the rule before committing it to the permanent ruleset.

o Jot Jot a note at the end of the rule. You can enter a
comment to be placed at the end of the rule.

o Accept change policy to Accept and commit. Without changing
any of the rest of the rule, this changes the rule action to Accept
(let the packet pass) and commits it to the permanent ruleset.

o Deny change policy to Deny and commit. Like the above, but
change the policy to Deny (or drop, as appropriate for the firewall
type; deny and drop discard the packet without sending any error
message back to the original sender).

o Masq change policy to Masquerade and commit. Like the
above, but change the policy to Masquerade. Masquerading allows
multiple machines to share a single IP address; the more general
term is "many-to-one NAT".

o Reject change policy to Reject and commit. Like the above,
but Reject the packet. Like Deny/Drop, the packet is discarded,
but Reject sends back an error message to the original sender.

Here are the commit choices:

o Postpone Postpone choice. If you can't decide what to do with a
rule, or don't have the time to decide, choose postpone. This
saves it to the "newrules" file, which is not used in the firewall
at boot time. You'll be asked later about any rule choices you
postponed.

o Throw away Throw away line. Forget the rule entirely.

o Blockedhost make this host a BLOCKEDHOST and delete the rule. Good
if someone's attacking you and you want to shun them entirely.

o Noincoming make this port a NOINCOMING port and delete the rule.
This is good for ports that should never be allowed in to your
network.

o Commit Commit to the permanent firewall set. Commit the rule
verbatim.

o Quit postpone any remaining rules and Quit. Oops, time for
lunch! Use this to postpone the current rule and any others in the
queue.

Once you're happy with a firewall ruleset, stop learning. From the
main menu you can either Edit the Base ruleset with "EB" or Quit.
Edit New and Merge Rules are generally not needed and will be removed
in a future version.

Baserules is reserved for rules that you are _sure_ are correct; only
these rules get loaded at boot time if you've enabled the firewall
(run "ntsysv" in RedHat and enable the firewall service, or make the
appropriate symlink from /etc/rc.d/init.d/firewall to
/etc/rc.d/rc3.d/S92firewall for other distributions).

The goal is to have a baserules file that has all of the rules you've
approved and an empty newrules file. Keep in mind that the firewall
that will normally be started at boot time _only_ uses rules from
baserules.

If you need to step away from the firewall for a minute, choose "LC"
(lock console) from the main menu. Mason will keep on learning and
you'll still see the new rules, but that console will be locked.
You'll need to enter the root password to return to the main menu.

3.9. Tell your boss that you're going to need a few weeks to build
this.

Then head off to Bermuda and bask in the sun while Mason does its
learning.

And make sure you have a penguin typing away in your chair so no-one
is suspicious.

*grin*

3.10. Implement the final firewall.

Once you've let Mason run in the background for a couple of days, are
confident that you've gotten all of the traffic types this machine
needs to support, have merged all of the rules to baserules, and are
confident they are what you want, lock down the firewall.

In /etc/masonrc, change DEFAULTPOLICY to DENY. If you want to keep
Mason running to see if any stragglers show up, you'll probably want
to change NEWRULEPOLICY to DENY as well; this has the effect of
creating rules for new packet types, but they are DENY rules now.

Otherwise, just start the standard firewall with:
/etc/rc.d/init.d/firewall start

If you've made the symlink in step 7, the firewall will be started
automatically at boot time.

4. Special considerations

4.1. Kernel

(Please note that most kernels provide the support necessary; it's
probably safe to check back with this section only if you have
problems.)

IP firewalling and firewall packet logging have to be compiled into
the kernel. To see if IP firewalling is compiled into your kernel,
type the command:

______________________________________________________________________
ls -al /proc/net/ip_fwchains /proc/net/ip_input
______________________________________________________________________

If ip_fwchains exists, you have ipchains compiled into your kernel.
If ip_input exists, you have ipfwadmin firewalling compiled into your
kernel. If neither file exists, one of the following is true:

o Your kernel is too old. It appears that linux firewalling switched
from the old "ipfw" firewalling in 1.3.66, but some features
require 2.0.0.

o Your kernel is missing the proc filesystem or it's not mounted
("mount /proc" will probably fix the latter). If your kernel truly
doesn't support the proc filesystem, reboot into the kernel that
came with your distribution, which almost certainly does.

o You have the right version of the kernel, but firewalling is not
enabled. You must recompile the kernel and turn on firewalling.
See the HOWTO's at http://metalab.unc.edu/linux/HOWTO/ to see how
this is done. In particular, see the masquerading and kernel
HOWTO's.

o Your 2.4 kernel has iptables, which doesn't have a flag file like
ipfwadm and ipchains.

When you recompile the kernel, I recommend you have all of the
following enabled: network firewalls, ip firewalling, firewall packet
logging, always defragment, proc filesystem, transparent proxy
support, IP masquerading, and icmp masquerading.

To see if firewall packet logging is enabled in your kernel, type one
of the following commands:

______________________________________________________________________
/sbin/ipfwadm -a deny -F -S 127.12.2.3/32 -o <Enter>
/sbin/ipchains -A forward -s 127.12.2.3/32 -l <Enter>
/sbin/iptables -A FORWARD -s 127.12.2.3/32 -j LOG<Enter>
______________________________________________________________________

The "-o" or "-l" at the end tells the kernel to log this particular
packet type (one which should never show up). If your kernel does not
support logging, I _think_ you would get an error. On the other hand,
I've never had a kernel that has firewalling but does not have
logging. The solution is the same - recompile your kernel to include
both firewalling _and_ firewall packet logging.

(If recompiling a kernel is too daunting, try my automated kernel
builder, "buildkernel", which can be found at
http://www.stearns.org/buildkernel/).

4.2. Ipfw, Ipfwadm, Ipchains, and Iptables

Current versions of Mason handle ipfwadm, ipchains and iptables. It
will accept log entries created under all three firewall types
automatically. Mason automatically detects which kind of rule to
create, although this can be overridden with environment variables set
in /etc/masonrc. The masonrc file has comments describing these
fields.

Make sure you have the ipfwadm, ipchains or iptables executable - one
of these should be included with your distribution.

Mason has no support for ipfw firewalls (the firewalling used in
kernels prior to 1.3.66). I don't intend to pursue this type of
firewalling, but am not against integrating a patch if someone feels
like adding the support. Does anyone still use this?

4.3. DNS

Mason does not try to look up the hostnames of any machines involved
in DNS requests (unless they're in /etc/hosts). If it did, Mason
could enter a situation where it 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.

The easy way to get machine names into your DNS rules is to make sure
all your DNS servers are listed in /etc/hosts . If they're not listed
there, Mason will just leave them as IP's.

4.4. Rule order

When a packet needs to be processed (at entry, forwarding, or exit),
the firewall scans the existing list of rules to decide whether to
allow, deny or reject the packet. As this scans stops at the first
rule that matches the packet, the order in which your final firewall
rules are executed can make a difference. This document only provides
basic coverage of how to order your rules - sorry. The best place to
find out more about this is in the O'Reilly and associates books.

(If anyone would like to provide additional general guidelines as to
how this is done, I would be glad to place them here with the
appropriate disclaimers).

4.5. Generalization

The packets Mason processes are data transfers between specific ports
on specific machines. For example, here's a response packet from a
specific FTP server (linux.kernel.org) to what is probably a machine
on your LAN:

______________________________________________________________________
/sbin/ipfwadm -i accept -W ppp0 -I -P tcp -S linux.kernel.org/32 ftp -D \
devel1.goober.net/32 1024:65535 # ftp/tcp
______________________________________________________________________

The rule above (possibly along with others) would only allow devel1 to
reach only linux.kernel.org, making for a ridiculously large ruleset
if other machines wanted to ftp out to linux.kernel.org or wanted to
reach other ftp servers.

By default, Mason _generalizes_ the source and destination IP
addresses. For example, devel1.goober.net/32 is replaced with
210.134.12.0/24 (the fictitious network address block of which devel1
is a part). Since linux.kernel.org is not a part of any local network
blocks, linux.kernel.org is replaced with 0/0 (which matches any
machine anywhere).

This automatic generalization can be disabled by setting IPCONV="HOST"
in /etc/masonrc.

Mason also does some generalization on the source and destination
ports. Irc, X, realaudio, traceroute, and others use ranges of ports;
Mason knows how to generalize many protocols to the appropriate range.

For the standard tcp and udp services, Mason generalizes the client
port to 1024:65535. The connection that prompted this rule might have
been, for example, port 1745 on devel1. As Mason didn't recognize
1745 as some special server, it assumed that the next connection might
be from, say, port 1788. By using the entire range of high ports
("1024:65535" in the above rule), Mason uses a pretty standard
approach to packet filtering to reduce the number of rules.

4.6. Router or end node

This program was originally intended for use on a traditional firewall
- a packet filtering router (linux box that connects 2 or more
networks through one or more interfaces). It works equally well on
Linux boxes with only one interface. These could be workstations on a
LAN, servers outside of your firewall, or even slip or ppp connected
workstations. The number of interfaces and their type and speed are
irrelevant to the firewall creation process.

This would be great for locking down a web or mail server outside your
firewall, for example. Start up Mason and make sure you make one of
every kind of connection you want to that machine. Mason will create
the corresponding rules. Generalize these and add a default policy of
"deny". _Only_ the connection types you specified will be allowed to
that machine. The difficulty of setting up the rules has been the
major impediment to this kind of hardened end node in the past. Now
that Mason is here, there's no reason why every machine on your LAN
can't have packet filtering enabled and active.

Note that on an end node (Linux box with a single NIC connected to a
single IP network) you should never see forwarding rules created -
this makes sense if you think about it.

You could technically create a firewall on a machine with only the
loopback interface, but this would be more for instructional value
about internal tcp connections than for any security goal. On the
other hand, if you wanted to stop shell account users from getting to
an internal Web server, you certainly could; just make sure you put in
blocking rules for all interfaces, not just the loopback interface.

4.7. Slow machines or fast nics

As a shell script, Mason is much less efficient at its work than a C
app would be. On a slow machine, it can take a couple of seconds from
the time the log entry is fed into it until the firewall rule is
implemented. If the system is slow, if it has a lot of packets
traveling through it, or if it simply has a great deal of log file
traffic it can take Mason a long time to catch up. If this is the
case, start slow. Try one connection type at a time and give the
system a chance to settle before you move on.

If Mason _cannot_ catch up, choose the "EL" (End Learning) option in
mason-gui-text. Wait until Mason stops, then restart learning.

4.8. Active hacking while mason running

If at all possible, try to set up these rules in a controlled
environment. Hook up your firewall to machines that simulate the
routers and networks that will be used in its final location. It is
not a good idea to create a firewall in an environment not completely
under your control.

If you must create the firewall rules in a live environment, be
warned: Mason simply creates rules based on what traffic is passing
through it. IT CANNOT DISTINGUISH BETWEEN THE TRAFFIC YOU'RE CREATING
TO TEACH IT AND SOMEONE ACTIVELY TRYING TO HACK THROUGH YOUR FIREWALL.
IF THIS HAPPENS, MASON WILL CREATE RULES THAT _SPECIFICALLY_ _ALLOW_
PEOPLE TO GET BACK IN LATER. _Please_ read and try to understand the
rules before you put them to use in a production environment.

(I hate all caps too, but the "boldface" button on my keyboard is
jammed :-).

The "hacker" mentioned above does not need to be a computer criminal
in a far-off country looking to crash your machines. This individual
could be someone in accounting that is (without malicious intent)
connecting to an Internet IRC server, when this doesn't fit in the
security policy you're trying to implement. If you don't read and
understand the rules Mason spits out, you may very well leave an
explicit opening for this user's future IRC use.

One more time: Mason _does_ _not_ understand the traffic flowing
through your firewall; it just creates the rules that you can later
use to specifically allow or disallow this traffic. This is why it is
a good idea to delete any rules that look even vaguely suspicious. If
it turns out these rules are needed for normal operation, they will be
relearned when you restart Mason.

4.9. Masquerading

One of the common uses for Linux firewalling is to act not only as a
packet filter but also as a masquerading host, allowing multiple
machines to share a single IP address.

As of Mason 0.13.0, Mason will automatically masquerade traffic from
RFC 1918 (also called "reserved") addresses. Since you probably don't
want to masquerade between internal lans, you need to list all the
interfaces leading _out_ to the real world (_not_ the interfaces that
use these reserved addresses).

4.10. Offline and non-root creation

If you are especially cautious, you might not want Mason actively
creating rules on your production server. Or maybe you think you've
created a good firewall, but keep getting log messages and don't know
how to keep your log files from filling your disk. Or perhaps your
CPU can't keep up. Or maybe you just don't trust Mason's author - no
offense taken :-). In all of the above circumstances, Mason can
create the commands without actually being fed the log messages live.
For example, if you have packet logging entries in /var/log/messages,
try this:

______________________________________________________________________
cat /var/log/messages | grep ' I=' | DOCOMMAND="none" mason <Enter>
______________________________________________________________________

The output can, of course, be tee'd, redirected to a file, piped to
less, etc. "... | sort | uniq" can be useful too when you're not
converting it live.

Obviously, the source file can be one that has been transferred from
another machine.

There is one caveat to the offline approach. The specific case is
when one has a "deny" or "reject" policy in place for the input
logging rule. Let's say I try to telnet through the firewall. My
packet arrives at the firewall, is stopped and logged (so Mason can
successfully create the correct input rule later). The firewall never
has a rule implemented that allows me to get any further than that,
however, so there is never a log entry created for any of the
remaining 5 packet checks.

One way around this might be to use a policy of "accept" on your
logging rules while you're creating /var/log/messages for later
consumption by Mason. I'm not saying this is appropriate for you, but
might be one way to handle this. Be warned; this can create very
large log files as every packet passing through the system can create
6 log entries!

One final use for this technique is creating the rules when you're not
root. Simply edit /etc/masonrc to set DOCOMMAND="NO" and the script
will still output the appropriate ipfwadm/ipchains commands but won't
try to execute them, allowing non-root users to create the firewall
rules. Note that you still need to be root long enough to turn on
some kind of logging, or /var/log/messages will never contain any
entries to convert. Root privileges are also required to implement
the rules once you've created them.

4.11. /etc/services and special ports

Mason converts the protocol number and type (i.e. 53, udp) into the
more common name (domain, in this example). It uses the /etc/services
file to do make this conversion. Before you start, make sure all the
protocols you will work with are listed there. If a particular
protocol is not in that file, Mason will have serious problems
producing accurate rules.

Having this entry is especially important if you are working with
services whose ports are >= 1024 (nfs, X, squid, irc, vdolive, etc.).
If a service >= 1024 is not found in /etc/services, it will be
automatically (and incorrectly) generalized to the port range of
1024-65535. If your favourite service isn't in there, simply edit the
file and add it in the same format as the other entries.

These services whose ports are >=1024 can occasionally show up in your
rules where Mason should have used 1024:65535 instead. Well, you know
how to fix this, right? Just delete the rule, add the service to
/etc/services, and relearn it.

The entries in /etc/services should only be for well-known server
ports. Client ports (which are usually just random ports between 1024
and 65535 anyways) should not be listed in here. The specific example
of something that should be missing is the ssh client port.

If you plan to do the conversion on one machine and actually run the
firewall on another, make sure all of the protocols used are listed in
the /etc/services on both machines.

The authoritative source for these ports is the Internet Assigned
Numbers Authority (IANA). A list of these ports can be found at:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers . Mason
includes what seems to be an even more up-to-date reference; see
/var/lib/mason/nmap-services. Many thanks to the authors of nmap.

4.12. Insert vs. append

Ipfwadm has two ways of adding rules: at the beginning of the rule
list using insert ("-i"), or at the end of the list using append
("-a"). The usual way of creating the firewall is to flush the
existing rules and then add each of the rules using append so they
will be scanned in the same order in which they were implemented. For
this reason, the rules that Mason spits out to stdout use "append" so
they can easily be put in a shell script.

Mason needs some way to tell the kernel to not log already logged
packets anymore. The way to do this is to put a matching rule before
the logging rule. Unfortunately, that means one of two things:
deleting the logging rule at the end, implementing the new rule at the
end, and reinstating the logging rule, or simply inserting the new
rule at the top of the list. The first option is tricky to do well.
It's also a bad choice because the user using Mason may not be logging
everything, so mason doesn't know what logging rule to reinstate.
That leaves using "-i" to insert the rule at the very top of the list.

The end effect is that the rules that Mason displays use "-a" to match
how that would be put into a rule file, but the rules that are
actually implemented while Mason is running use "-i" to avoid
relogging those packets again in this Mason run.

The major side effect of this approach is that the rule set in memory
as Mason is running is almost certainly _not_ in the order you'd want.
The final firewall rule set you put in place should flush whatever is
in memory before starting so as to clean out these incorrectly ordered
rules.

As ipchains and iptables support additional user defined chains, we
can throw all the temporary rules in user defined chains (called
inputN, outputN, and forwardN; the "N" stands for Nolog). These
chains get called just before the logging rules.

4.13. Allow versus deny and reject

During the course of a Mason run, it's quite reasonable that the
firewall creator might want to spend some time working with traffic
types that he/she wants to allow, and then switch over to other
traffic types that he/she wants to reject or deny (see man ipfwadm for
the subtle difference between deny and reject). If you change any
settings by choosing "Change Settings" in mason-gui-text, it will
automatically signal a running Mason to re-read its configuration
file. You can do the same if running mason manually by typing
"killall -USR1 mason".

Changing the target of a single rule to Accept, Deny, Reject, or
Masquerade can be done right in the menu under that rule without
having to go back to the main menu and changing the global settings.

4.14. Input, Output, and Forwarding

To implement packet filtering, the Linux kernel needs to inspect each
packet at at least one of the following three times: when the packet
enters the system, as it passes through the system on the way to its
exit interface, and as it leaves the system.

At each of those three times, the kernel can decide to allow or
deny/reject the packet. The rules can be different at each stage -
it's perfectly legal to, for example, allow it in, allow it to be
forwarded, but then block it at the last second before it leaves the
system.

A simple firewall could be implemented using just, say, input
rules(*). It's when you get complex firewalls that having rules at
all three stages is useful. You might want to allow hosts from eth0
to get to a pop-3 server on eth1, but not allow hosts from eth2 to get
to the same server. This kind of restriction might be impossible to
do without forwarding rules, especially if eth2 hosts _should_ be
allowed to get to a pop-3 server on eth0.

For simpler firewalls, or if you want less than the imposing grandeur
of a firewall ruleset that goes on for pages and pages, Mason can
accomodate you. If you just want input rules, add the following to
/var/lib/mason/baserules :

______________________________________________________________________
if [ -f /proc/net/ip_fwchains ]; then
/sbin/ipchains -A forward -j ACCEPT
/sbin/ipchains -A output -j ACCEPT
elif [ -f /proc/net/ip_input ]; then
/sbin/ipfwadm -F -a accept
/sbin/ipfwadm -O -a accept
fi
______________________________________________________________________

Place any general traffic types you don't care about in baserules.

Please note that I am _not_ advocating the above, but pointing out
that the technique is available for those that feel the reduced
security is appropriate for them.

(*) The exceptions to this are the special rules for redirecting
packets (which must be done as an input rule), and masquerading
packets, (which must be done as a forwarding rule). Even in the cases
where you wish to use these facilities, it's still legal to implement
packet filtering using another rule type.

Please note that the above does not apply to iptables. In iptables,
packets are not inspected multiple times in multiple chains.

4.15. Remote firewall creation - Telnet/ssh lockout

If you're creating this firewall rule set and you're telnetting,
ssh'ing, or rsh'ing (collectively, "telnetting") in to the firewall,
be careful. Some of the first rules to be created will be for the
telnet packet flow you're using. If you are so unfortunate as to
start this process with a policy of deny, guess what packet flow will
be stopped almost immediately? That's right, your telnet session(s).
Your machine will be completely locked down with no way to remotely
reach it. (Now where were my car keys? <grrrr>)

If you want to put the rules allowing your remote access before
starting Mason, great. If not, just make sure that your startup
policy is allow or it's remote reboot time! Logging in on any of the
console's virtual terminals does not require TCP/IP packets, so you
can never lock yourself out completely.

You did read the section above on "simulating the working environment
under controlled conditions", didn't you? Are you still sure you want
to be creating a firewall not directly under your control? Just a
thought...

4.16. Ack flag

Let's look at some standard rules that allows a telnet connection to a
server somewhere (these are only two of the 6 possible rules).

allow LAN_IP's, ports 1024-65535 -> Outside_world_IP's, port 23
allow Outside_world_IP's, port 23 -> LAN_IP's, ports 1024-65535

It looks pretty safe, right? Hmmm....

Let's say that one of your LAN machines runs a squid server. This
sits waiting for connections on port 3128. Additionally, consider the
possibility that the root user on some Outside_world_IP machine writes
some program that starts a connection _from_ port 23. This user
starts this program and connects to your LANs squid server.

All with your firewalls full consent. Ugh.

The way to avoid this problem is to be able to identify the
_direction_ in which the connection is created. We want to allow
connections that start _from_ LAN:1024-65535 _to_ Outside:23, but
block connections that start _from_ Outside:23 _to_ LAN:1024-65535.

The TCP ACK flag comes to the rescue. The first packet in a
connection does _not_ have this flag set. Every packet after the
first _does_ have this flag set. If we require all packets coming
from the server port have their ACK flag set, we can stop the bogus
connection from port 23 back to port 3128.

In short, by requiring all packets from a server port have their ACK
flag set, we block connections that originate from those server ports.

Three notes. Only TCP uses ACK flags, so we can't use this to control
the direction in which icmp or udp conversations are initiated.
Secondly, DNS may be a problem. Tcp domain transfers and large dns
requests can be from port 53 to port 53, depending on what dns
software you're using. FTP-data connections do not have their ACK
flag set because they can be created in either direction. Finally,
there may be issues from ssh low ports if /etc/services has entries up
near 1023.

Mason is able to automatically set the ack flag if your /etc/services
lists all of the services you use.

I specifically avoided the "-b" (bidirectional) flag so that I could
use "-k" to control the direction.

Iptables uses the state of the connection as a more dependable way of
handling the above problem. I'd generally encourage you to use the
"-m state --state ESTABLISHED,RELATED" lines in baserules. If you do,
then Mason hands you a single rule for any given type of traffic; the
opening packet. The ESTABLISHED,RELATED lines handle all the other
packets.

4.17. Limitations, Ideas and future enhancements

o group foreign machines into additional rule? (Document how.)

o Document the living hell of NFS.

5. Configuring Mason

Most of the configuration is set via environment variables. For
permanent changes, try

______________________________________________________________________
export VARIABLE=value
______________________________________________________________________

For one time settings, just put the variables on the command line just
before calling the program. For example:

______________________________________________________________________
tail -f --lines=0 /var/log/messages | ECHOCOMMAND=ipchains mason
______________________________________________________________________

If you set a variable both on the command line and in /etc/masonrc, be
warned that /etc/masonrc wins.

o ECHOCOMMAND=ipchains|ipfwadm|none #Autodetected if unset or invalid

Which kind of command should Mason display? This does _not_ have
to match the firewalling in the current kernel; this lets you
create an ipfwadm firewall ruleset on an ipchains kernel and vice-
versa. (Remember that iptables can't take part in this cross-
creation.)

The following two commands will spit out an ipfwadm firewall and an
ipchains firewall, respectively, from the same input: cat
/var/log/messages | grep ' L=' | ECHOCOMMAND=ipfwadm mason
>ipfwadm-wall cat /var/log/messages | grep ' L=' |
ECHOCOMMAND=ipchains mason >ipchains-wall

Both kinds of firewall log entries have L= in them; this is a
reasonably good filter to keep Mason from having to process _all_
the junk entries.

o DOCOMMAND=ipchains|ipfwadm|none #Autodetected if unset or invalid

Which kind of command should Mason run to prevent that type of
traffic from being logged in the future? Set to none if you're
processing the log entries later, or on another machine.

Unless you're forcing it to "none", probably best to let Mason
autodetect.

o HEARTBEAT=yes|no

If yes, mason displays a "." or "-" when it processes an input line
that has been handled by one of the recently implemented rules.
The heartbeat character is sent to stderr so it doesn't screw up
logging to a file or piping to some other program.

o DYNIF="ppp0 sl0"

If your machine has interfaces whose entries change IP address, put
the interface name(s) in quotes, separated by spaces. Mason will
handle these interfaces specially by handing you a line that will
assign that interfaces IP address to an environment variable when
executed, and uses that variable throughout the ruleset.

If your Ethernet IP address is assigned via DHCP, BOOTP, or RARP,
_and_ _changes_ from time to time, you might even want to put your
Ethernet interface name(s) in the list. If the addresses are
assigned via one of those tools, but _never_ _change_ (those
protocols are supposed to try to give you the same address you had
last time if at all possible), don't put the Ethernet interface(s)
in there.

Make sure you re-run your firewall ruleset (or at least the rules
with dynamic IP entries) when the address changes. For ppp
interfaces, restart your firewall inside /etc/ppp/ip-up. I think
DHCP has a similar ability to run commands when the address
changes; consult the DHCP documentation.

The main documentation for all the configurable fields is conveniently
in /etc/masonrc .

6. IP protocols and their firewall characteristics

6.1. Standard TCP and UDP protocols

Most of the connections made in tcp/ip follow a standard form. The
client machine picks a random port between 1024 and 65535. The
packets are sent to a fixed, known port that's below 1024.

For example, I need to send an email message from mybox.office.com to
mailserver.office.com. Since email goes to tcp port 25 (see
/etc/services for some of these), the tcp/ip code on mybox picks a
random tcp port, such as 1931. Packets flow from mybox port 1931 to
port 25 on mailserver. Packets also flow back from mailserver port 25
to mybox port 1931.

Here are some of the protocols that follow this form:

o 23/TCP - telnet

o 25/TCP - SMTP

o 80/TCP - HTTP

o 110/TCP - POP3

o 143/TCP - IMAP

o 512/UDP - BIFF

6.2. ICMP

ICMP doesn't use source and destination ports, but it has icmp codes
and subcodes, each a number between 0 and 15.

6.3. 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.

Mason no longer does DNS lookups on machines involved in DNS lookups.
If you have the names and IP addresses of your DNS servers, add them
to /etc/hosts.

6.4. FTP

Ahhh, yes, ftp. The scourge of firewall creators everywhere.

If you're using iptables, have the ip_conntrack_ftp module loaded and
have uncommented the "-m state --state ESTABLISHED,RELATED" lines in
baserules, the problem I'm about to describe does not apply to you.
Since iptables is a stateful firewall, this problem has been solved in
an elegant and now hassle-free way.

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.

6.5. Netbios

For those hoping to come here for a simple set of rules for
firewalling netbios, sorry. This one is all over the map.

Mason comes in really handy for netbios because it works with whatever
netbios throws at it. The netbios ports are 135, 137, 138, and 139 -
both tcp and udp. Connections can be from one of these low ports to
itself, from a high port to one of these ports, or from a high port to
a high port.

In short, good luck trying to do this without Mason.

By the way, allowing netbios traffic in from and out to the Internet
may be a very bad idea.

6.6. NTP

NTP is one of the few protocols that uses the same port at both the
client and server end. In this case, it is port 123/udp.

6.7. SSH

SSH (server port 22/tcp) has one minor note about its operation. When
installed by root (setuid), it may not use a random high port between
1024 and 65535 for the client end. The first client session may use
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.

6.8. Other IP protocols

The other protocols, such as ipip, igmp, ospf, etc (see
/etc/protocols), don't use port numbers. For this reason, Mason only
creates rules between individual machines for these.

7. Version summary (out of date, sorry)

o 0.9.0

_Lots_ of good new stuff. Mason handles log entries from ipchains
or ipfwadm automatically. The command it runs can be either an
ipchain or ipfwadm command, and it can output either an ipchain or
ipfwadm command. All independently. See the ECHCOMMAND=... and
DOCOMMAND=... parameters, above.

_Major_ speedup! Keep reading lines until the 7th-13th fields are
different from the previous line; this probably quadruples Mason's
throughput or better. Bonus points to the readers who can read
morse code from the heartbeat output... Oh, and I added heartbeat
output to show that Mason hasn't just crashed. :-)

Mason handles interfaces whose IP address changes automatically;
see the DYNIF=... parameter, above.

Note: additional ipchains fields are:

L=Total length
S=TOS
I=ip->id?
F=Fragment offset
T=TTL

o 0.8.0

-k added to control the direction in which connections are made.
Unfortunately, the ftp-data port doesn't honor the simple rule for
-k; I suspect this is a consequence of PASV vs. "active?" ftp
opening the data connection in one direction of the other. Hmmm...
This was released to the world as 0.7.9.

o 0.7.0

(6/21/98) 20% speed improvement by changing read command. Local
name cache added. On the fly policy changing. Comments. Major
documentation updates. Another 20% performance improvement by
replacing some sed's with bash internal pattern deletion. 6% more
by using ${#..} instead of wc --bytes to size strings. Cut time
necessary to process non-firewall lines in third by using &&
instead of -a.

o 0.6.0

(6/4/98) Documentation added

o 0.5.0

(6/2/98) Bare code, almost no documentation, ipfwadm support only.
8. Advanced scenarios

8.1. General approach

Once you've gone through the Quick Start, what now? Now we learn how
to use this to match your security policy.

The first lesson to learn about packet filtering rules is that they
are only useful if you have a mix of accept and deny (equivalent to
reject in this discussion) rules. Think about it. If all of your
rules are allow rules and your default policy is also allow, this
setup is no different from having no rules at all; the system is
completely open.

At the other end of the spectrum, if all of your rules are deny and
the default policy is also deny, well, it's going to be pretty hard to
use TCP/IP at all. :-)

This means that putting a firewall together involves deciding what
should be allowed _and_ what should not be allowed.

The first thing for you to decide is what your default policy should
be. In the next few minutes we'll be looking at what you specifically
want to allow and what you specifically want to disallow. What should
the firewall do with the rest of the packets? That depends on how you
view your firewall.

If you primarily want your firewall to block a relatively small amount
of malicious things, but want users on both sides of the firewall to
have relatively unencumbered access to the opposite side, you'd
probably want to use a default policy of accept. This tends to be a
good choice in the case where there are a large number of types of
TCP/IP traffic that should be allowed to pass through the firewall.

If, on the other hand, you tend more toward the paranoid and want very
fine grained control over _exactly_ what passes through your firewall,
you'll probably want to use a default policy of deny. This tends to
work well when there are a relatively small number of protocols that
should be allowed.

Choosing a policy becomes difficult when you want fine grained control
but there are a large number of protocols used by your users. You'll
still choose a default policy of deny, but you'll have to create a
large number of rules to accomodate them. Good thing you've got Mason
to give you a hand!

Now that you've chosen a policy, what goes next? Here's where you can
become an artist.

With the help of Mason, your job is to decide what should be allowed
and what should not be allowed.

[More to be added as time allows...]

8.2. Ordering rules

Here are a couple of guidelines about how to order your rules. I
refer to policy below; for this discussion, there are 6 possible
policies: accept, deny, reject, accept and log, deny and log, and
reject and log.

As there is no way that input rules and output rules could ever
overlap, the rulesets for those can be considered seperately. The
same logic holds true for input and forwarding and output and
forwarding. Effectvely, even though you might have them all mixed
together in your firewall creation shell script, you can work with the
input rules according to the principles below, then come back and work
with the forwarding rules, and then come back one last time for the
output rules.

o I suggest placing dns (also called domain; port 53/tcp and 53/udp)
rules at the top of your firewall if you're using the default mode
of HOSTLOOKUP=FULL. The other rules in your firewall may require
dns lookups; if those requests can't get through because the dns
rules aren't in place yet, the early rules may not get put in
place.

o If your ruleset contains a block of 2 or more rules with the same
policy (accept, deny, or reject) that immediately follow each
other, the order of the rules in that block has no functional
difference to the operation of the firewall. If you are very
concerned about performance, you might want to put the rules that
process the largest number of packets at the top of this block and
the rules that process the least number of packets near the bottom
of this block. See the SORTMODE option in /etc/masonrc (not
available in iptables).

o If two consecutive rules do not have any overlapping cases in the
patterns they match, they can appear in either order without
affecting the operation of the firewall. As long as no two rules
in the set overlap, this can be extended to a set with more than
two rules.

o If two rules overlap in the patterns they match and have different
policies, they _cannot_ be reordered without affecting the
functional operation of the firewall. Specifically, the packets in
the overlapping case will have their policy changed.

o If two consecutive rules have the same policy and one is subset of
the other, the more specific rule can be discarded and the more
general rule can be kept without affecting the functional operation
of the firewall.

One common case of this is when your default policy is, say,
accept, and the last rule just before the default policy rule also
has a policy of accept. This more specific rule (not the policy,
of course) can be discarded.

o Your default policy always comes at the end.

I've referred to discarding rules above. One reason why you might
_not_ want to discard a particular rule rule is when you're using your
firewall to do accounting as well as blocking. You might want to be
able to have seperate accounting for the packet traffic in the rule
that would have been discarded.

8.3. Tips and tricks

The following are tools and techniques I use. They may not be
appropriate for you. Please consider whether they are appropriate for
you before using them.

o If you want to see which rules in your running firewall are
actually carrying traffic, try this:

___________________________________________________________________
( ipfwadm -lenI ; ipfwadm -lenF ; ipfwadm -lenO ) | grep -v '^ *0 *0 ' | less -S
___________________________________________________________________

______________________________________________________________________
ipchains -L -n -x -v | grep -v '^ *0 *0 ' | less -S
______________________________________________________________________

______________________________________________________________________
iptables -L -n -x -v | grep -v '^ *0 *0 ' | less -S
______________________________________________________________________

The "grep -v ..." removes all packets with 0's in the count and bytes
columns.

If the number of rules returned is still too large, flush the firewall
and restart it; this clears out all the packet counts. Then you can
rerun whatever test you've been doing and run the above command again
to see what rules are carrying your traffic. This is especialy useful
if you've got a deny rule somewhere blocking a certain connection:

______________________________________________________________________
( ipfwadm -lenI ; ipfwadm -lenF ; ipfwadm -lenO ) | grep -v '^ *0 *0 ' | less -S
______________________________________________________________________

o If you don't want to go through the above process, but just want to
convert a few log entries to rules, you can do the feed yourself.
For example:

___________________________________________________________________
tail --lines=1000 /var/log/messages | grep 'kernel.*I=' | DOCOMMAND="none" mason >afewrules
___________________________________________________________________

Any other options can be placed on the command line or in
/etc/masonrc.

o If you want rules that will run under ipfwadm and ipchains kernels,
you have two good choices. Create ipfwadm rules no matter what
kind of kernel you have (put ECHOCOMMAND="ipchains" in /etc/masonrc
or on the command line). The first choice is to use the ipfwadm-
wrapper (part of the ipchains-scripts package) as a front end to
either ipfwadm or ipchains, as appropriate. The second choice is
to take all of the ipfwadm rules and create the following file as
your real firewall:

___________________________________________________________________
if [ -f /proc/net/ip_fwchains ]; then
#Convert your ipfwadm rules to ipchains rules and place the converted rules here.
/sbin/ipchains...
elif [ -f /proc/net/ip_input ]; then
#Place your ipfwadm rules here:
/sbin/ipfwadm....
fi
___________________________________________________________________

The above conversion is actually darn simple:

______________________________________________________________________
cat ipfwadmfile | ipfwadm2ipchains >ipchainsfile
______________________________________________________________________

The ipfwadm2ipchains script is available at
http://www.stearns.org/i2i/ . This site also holds ipchains2iptables,
a similar script that gives a first pass output in iptables format
from a given ipchains firewall. Note that this output won't use any
of the advanced features of iptables, but you can add these.

o If you have a number of interfaces that all get the same rules,
replace the if0, if1, if2, etc rules with if+ . I believe this is
ipchains only.

o (Diald users only). The packets leaving your system on sl+ (or
tap+) may have different source addresses (0.0.0.0/32, some dummy
ip address, an old ppp address...). You might want to replace them
with 0/0 to say I don't care what the source address is.

o To see what program is using a particular port, try:

___________________________________________________________________
ps axf | grep "^ *`fuser port_number/proto | awk '{print $2}'` "
___________________________________________________________________

9. Notes about Mason itself

9.1. File descriptions

COPYING
The GNU General Public License.

Makefile
Used in packaging and distribution.

baserules
The baserules file is one of two files that hold your firewall
rules. baserules holds the rules that you've checked over and
are sure should be part of your final firewall.

baserules.sample
A few possible rules for use as a starting point.

firewall
The boot time script for use in /etc/rc.d/init.d.

index.html
The Mason web page.

mason
The actual mason script.

mason-gui-text
The rudimentary interface to running Mason and building a
firewall.

mason-gui-text.1
man page for mason-gui-text.

mason.1
man page for mason.

mason.html
The primary documentation for the package, in hypertext.

mason.lsm
The Linux Software Map entry.

mason.sgml
The primary documentation for the package. The sgml format is
designed to allow easy conversion to more readable formats.

mason.spec
The RPM spec file.

mason.txt
The primary documentation for the package, in a flat text file.

masonlib
A library of functions used by a number of the other files.

masonrc
The main configuration file. There are intelligent defaults for
all of these fields.

moreservices
The services file I use, good as a reference if you don't
recognize a protocol.

nmap-services
The additional services file includes with the nmap tool. An
even better reference.

newrules
newrules is the other file that holds firewall rules. It holds
rules created by mason that you haven't looked over yet. Think
about what would happen if you were port scanned while Mason was
running; if you only had one file to hold rules, all of these
portscan rules you don't want would be mixed in with the rules
you do want.

An important note - rules in newrules are not part of your
regular firewall - they are only used during the learning
process. This is why you need to merge rules from newrules to
baserules once you're sure of them.

10. Additional resources

o http://www.netfilter.orgNetfilter/iptables for 2.4.x kernels.

o http://www.rustcorp.com/linux/ipchains Linux IP firewalling chains
for 2.2.x kernels.

o http://ipmasq.cjb.net The Linux IP Masquerade Resource.

o http://www.xos.nl/linux/ Experts in Open Systems; specifically, Jos
Vos, one of the firewall code authors.

o http://metalab.unc.edu/linux/HOWTO/HOWTO-INDEX-3.html The Linux
HOWTO index, part of the:

o http://metalab.unc.edu/linux/ Linux Documentation Project.

o http://metalab.unc.edu/linux/HOWTO/mini/IP-Masquerade.html The IP
Masquerade HOWTO. Useful information on ipfwadm and masquerading.

o http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html David
Ranch's excellent networking resource. Check out the "Trinity OS"
document and the IP Masquerade Howto, co-authored with Ambrose Au.
Both are comprehensive documents about Linux networking - well
worth reading.

11. Authors, credits, feedback, copyright, how to help!

Once again, the linux kernel and firewall developers deserve all the
credit. Mason is simply a front end to a fast, powerful, stable
firewall implementation in the linux kernel. Many thanks to all the
linux firewall developers.

The name "Mason" comes from two sources; first of all, it builds a
(fire)wall. Second, it's my nephew's name. Mason lives in Brooklyn
with my sister and her husband and my niece Eve. He's a great guy!

If you have comments, suggestions, problems, ideas, flames, patches,
whatever, I'd like to hear them. I'd even be interested in hearing
where Mason fell short for your needs. My permanent email address is
wstearns@pobox.com. The permanent web site for the software is
http://www.pobox.com/~wstearns/mason/.

Jeff Licquia has kindly offered to package up Mason into a Debian
package. The Debian requirements are helping to make a better program
for all distributions.

Jens Knudsen wrote nicerules, a wrapper script for Mason. It's a
simple script that takes the "newrules" output, sorts and orders the
firewall rules in a way that makes it easier to review security, and
produces a "standalone" firewall script and a firewall.disable script.
The script probably has many "bugs", use it as an aid, but don't blame
him for any problems it may cause you. There is more information in
the actual script which is also heavily commented. Have fun.

If you choose to send me actual mason firewall rules and choose to
hide the IP addresses and/or networks for security reason, that's
fine, but please replace them with something that describes their
general use so I can make sense of them. For example:

______________________________________________________________________
cat myrules | sed -e 's@11.22.33.44/32@fw-outside@' \
-e 's@192.168.1.1/32@fw-inside@' \
-e 's@192.168.1.0/24@inside-net@' \
>myrules.mailable
______________________________________________________________________

- or something like that.

There are a number of things you can do to help this project:

o Send in bug reports.

o Send in suggestions or fixes.

o Organize the documentation.

o Design a logo.

o Take over the announcement process.

o Help integrate Mason into your distribution. Heck, just letting me
know under which distributions Mason works is helpful!

o Organize the Web site into a more useful resource.

o Set up mailing lists for developers, announcements, and users.

The files in the Mason package are Copyright (c) 1998-2002 by William
Stearns wstearns@pobox.com or Jeff Licquia. They are released under
the GNU GPL, which is included in the package. If you did not recieve
a copy of this license, please contact the author for a copy (see the
top of the Mason script for contact information for the author and the
Free Software Foundation).

William is also the author of buildkernel, the automated Linux
kernel builder, and other minor shell scripts.

11.1. Thanks

Chris Brenton deserves very special thanks for spending an evening
with me discussing a number of questions I've had about packet
filtering. He was very kind to share his knowledge with me. I owe
him a pizza sometime. :-)

Chris has written some excellent networking texts - I'm about halfway
through Mastering Network Security and am very impressed with the
writing and content: Multiprotocol Network Design & Troubleshooting,
Mastering Network Security. The above plug was not requested, but is
well deserved.

Thanks to Nathan Bailey who took the time to remind me that there is a
Perl Module that's also called Mason. Thanks also to Jonathan
Swartz, the author of HTML::Mason who graciously agreed to share the
name and pointers with me.

Many thanks to Dave Stern, who has offered suggestions on how to
improve Mason and helped with beta testing early versions. Maybe
someday I'll tell him they were prerelease versions... :-)

Thanks to all of the people who have sent in questions, bug reports,
fixes, improvements, and six foot long lizards.

The new section of masonrc with a boatload of backdoor ports is
courtesy of the authors of and contributors to snort. Specifically,
Nick Rogness, Jim Forster and Martin Markgraf are credited with the
work on the ports - many thanks, guys.

Snort can be found at http://www.snort.org. It's a really cool
intrusion detection tool. Thanks to Marty roesch@clark.net for the
tool.

A special thank you to all the authors in the Linux movement. In a
small way, the code I return to the community is my way of paying
back my incredible debt to the people who came before me.

As always, many thanks to my wife Debbie, who has shown amazing
patience with my Linux related projects. Many thanks, my love.