~ubuntu-branches/ubuntu/natty/mason/natty

  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