"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.
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.
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.
- 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).
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