  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.

  Copyright (C) 1998-2002 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:

     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
     ___________________________________________________________________


  or

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


  or

  ______________________________________________________________________
  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
  ______________________________________________________________________


  or

  ______________________________________________________________________
  ipchains -L -n -x -v | grep -v '^ *0 *0 ' | egrep '(Chain|target|DENY|REJECT)' | 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.



















































