"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.pobox.com/~wstearns/mason/ .
The impatient should go right to the
Quickstart.
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 or
ipchains 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.
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:
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 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.
- Distributions
- Heavily tested on RedHat 5.x and 6.0
- 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 or kernel 2.2's ipchains - 2.4's iptables support is underway)
- The ipchains or ipfwadm 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.
Mason supports the following: (see the release notes for additional features)
- It accepts any mix of ipchains or ipfwadm log entries as input.
- It can run on an ipfwadm or ipchains kernel.
- It can spit out ipfwadm or ipchains output.
- 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.
- 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 finally has a first pass at Cisco rules! And no, I don't personally think Cisco rules, but anyways.
It hasn't been tested on a live router. I'd love to get feedback on how well it works - or doesn't!
- 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
- 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 (Use at your own risk for the
moment - this needs to be checked)
- 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