The Mason HOWTO: Introduction

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

- Distributions
  - Heavily tested on RedHat 5.x, 6.x, and 7.x
  - Compatible with Debian 2.x
  - Probably works with Slackware
  - Probably works with Suse, but you need to choose between the default /etc/rc.d/init.d/firewall and the one included with Mason
- Requirements
  - Bash 1.x or 2.x
  - Standard system utilities: awk, cat, chmod, cut, grep, head, ifconfig, mkdir, ps, route, sed, sleep, sort, tail, touch, tr, true, uniq and wc
  - A kernel that supports packet filtering and packet logging (kernel 2.0's ipfwadm, kernel 2.2's ipchains, or 2.4's iptables)
  - The ipchains, ipfwadm or iptables binaries.
- Things Mason doesn't care about
  - Hardware architecture (i386, Axp, Sparc...)
  - Number or type of interfaces
  - 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)

- It accepts any mix of ipchains, ipfwadm or iptables log entries as input.
- It can run on an ipfwadm, ipchains or iptables kernel.
- It can spit out ipfwadm, ipchains or iptables output.
- 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.
- It will run on the firewall machine or on another machine, using the firewall's packet logs as input.
- It can run as the traffic is flowing through the machine or be fed the firewall logs later.
- While there are some advantages to running as root, it can be run as a non-root user.
- Mason will put in a macro for dynamic IP addresses, usually for your ppp link.
- It supports any kind of interface that can carry TCP/IP traffic.
- It recognizes any protocol listed in /etc/services and commonly used icmp protocols.
- It automatically handles setups such as cable modem or satellite where the packets go out on one interface and come back on another.
- It automatically handles masquerading on the firewall and the strange rules that can require.
- 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.
- It automatically generalizes the firewall rules in the following ways:
  - 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.
  - Non-local IP's are converted to 0/0 (anywhere).
  - Port numbers in /etc/services are converted to the corresponding service name.
  - 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.
- The ack flag is set for all tcp connections except for ftp.
- 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.
- Each output line is commented to give you an idea of what it's for and allow for easy grouping via sort.
- The rule policy can be changed on the fly without having to stop Mason.
- 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.
- 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.
- 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.
- automatically makes masq rules for reserved addresses
- icmp subcodes
- support for ip tunneling, cipe and a number of other protocols
- removal of the namecache (no longer needed)
- mason now stops logging packets quickly while it does the main processing
- stop using ipcalc to calculate broadcast
- don't touch /etc/hosts or /etc/services
- more Debian integration and two man pages (Thanks, Jeff!)
- support for ipchains-save output format
- support for --sport and --dport (Thanks, Rusty!)
- major documentation updates
- 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).
- misc. bug fixes and performance improvements
- fixes to the Cisco output format
- the ability to generalize the ack rules for tcp connections, cutting 25%-35% of the rules
- an internal checkpointing ability to help in debugging
- Mason can find the smallest subnet that encompasses the ips found on a dynamic interface
- and no_outgoing_ protocols