>>>>>>>>>>>>>>>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_. Copyleft: Mason interactively creates a Linux packet filtering firewall. Copyright (C) 1998 William Stearns 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: William Stearns email: wstearns@pobox.com (preferred) web: http://www.pobox.com/~wstearns snail: 544 Winchester Place Colchester VT, 05446, USA This code is entirely owned by William Stearns (wstearns@pobox.com) and has no relation to any employer or employer sponsored project. ------------------------------ Mason ------------------------------ 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/ . - Bill Stearns 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. There are a couple of ways around this: - Write the correct ipfwadm rules for DNS lookup for your particular setup and put them in place before running mason. - Use trusted external DNS servers, i.e. servers that do not have to resolve _through_ your firewall. This reduces the number of rules necessary to handle DNS to just a few. - Put the names of all relevant hosts in the namecache file (see below) or in /etc/hosts. Mason uses these files before going out to DNS to try to minimize the snowball effect when it occurs. - Comment out the DNS lookup code in Mason. At some point this will be command line configurable, but not quite yet. - Insert general rules for DNS in your rule set. If you're not sure what these should be, the following six rules should allow all DNS requests from anywhere to anywhere. Please note that depending on your security policy, this are very likely to be too general and should be reviewed. /sbin/ipfwadm -I -i accept -S 0/0 53 -P udp /sbin/ipfwadm -I -i accept -D 0/0 53 -P udp /sbin/ipfwadm -O -i accept -S 0/0 53 -P udp /sbin/ipfwadm -O -i accept -D 0/0 53 -P udp /sbin/ipfwadm -F -i accept -S 0/0 53 -P udp /sbin/ipfwadm -F -i accept -D 0/0 53 -P udp Note that I don't include _tcp_ dns zone transfers here. These transfers are generally rare and between a few machines. These are good candidates for having explicit rules added automatically by mason. ftp: Ahhh, yes, ftp. The scourge of firewall creators everywhere. 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. ssh: SSH (server port 22/tcp) has one minor note about its operation. When installed by root (setuid), it does not use a random high port between 1024 and 65535 for the client end. The first client session uses 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.