			Drawbridge 1.0 (Beta Release)

Introduction
------------

Over recent years, the Internet has experienced a growing number
of intrusion incidents. The Computer Emergency Response Team (CERT)
is reporting an average of four security incidents a day which is
a dramatic increase from last year ("Are Your Networks Secure?",
Information Week, April 12, 1993, page 30). These incidents range
in degree from destructive to the network equivalent of joyriding.

Academic environments have traditionally had completely unrestricted
access to and from the Internet. After a major intrusion occurred
at Texas A&M University, we came to the conclusion that this is
no longer an acceptable situation. This puts the users' data and
machines at risk and endangers other sites due to pass-through
attacks. It was decided that some type of firewall would have to
be put in place.

There are several different options for a firewall.  Two major
techniques that distinguish firewalls is the use of filtering
routers only versus firewalls employing bastion hosts.  Unfortunately
both of these techniques are not ideal.  Firewalls using bastion
hosts are very intrusive to the user and are not very flexible.
They require specially modified client software to pass through
the bastion host transparently and support only a few protocols.
In a university campus situation, a firewall using a bastion host
is unworkable due to the inherent problems of implementing one in
a highly heterogenous and autonomous computer population and the
enormous restrictions this would place on users who need and depend
on free access to the Internet.

Filtering routers suffer from performance, maintanence and security
problems.  Filtering in routers tends to be an afterthought and
not efficiently implemented; as the number of filters increases
the performance drops rapidly. It also is not flexible enough to
handle a large population of machines with diverse filtering needs.
There may also exist many unknown security problems when access
is provided directly to host application software.

For these reasons, we decided to take a new approach and developed
a firewall employing custom software to perform packet filtering.
We designed a bridging filter that has filtering at the center of
the design. It uses custom, table driven software on a dedicated
platform which results in a high performance, flexible package.
This has enabled us to set up very diverse and increasingly complex
filtering with almost no performance loss. While this does not
resolve the security issues of a filtering setup we do not have
the same security needs as corporate and military sites and must
satisfy the needs of our academic community. In any case, we have
found that in actual use, packet filtering does provide a substantial
increase in security.

The software package we developed is called Drawbridge and consists
of Filter, Filter Manager (fm) and Filter Compiler (fc). Filter is
a program that runs on a dedicated PC (preferably a 33 MHz 486 or
better) with two ethernet cards (only 16 bit WD cards are currently
supported).  fm and fc both run on a Sun workstation. fm communicates
and manages Filter using Sun's NIT support. fc generates filtering
tables that are loaded into Filter via fm.

Filter filters TCP/IP on an incoming and outgoing basis and UDP/IP
on an incoming basis. Currently, all other protocols are transparently
bridged.

Design
------

Drawbridge is different from any of the current standard firewall
configurations.  Using the categorization of firewalls developed
by Ranum ("Thinking about Firewalls", available on the Internet),
Drawbridge compares best to a filtering router firewall configuration
as shown in Figure 1. In a filtering router firewall, a router
which has packet filtering support is used to filter packets to
and from hosts on the "inside" of the router. This is used to
establish a policy where hosts are provided more or less access
depending on the decisions of the network managers.


			  Internet Link
				|
				|
                          +-----------+
                          | Filtering |
                          |   Router  |
                          +-----------+
   				|
				|
	  +---------------------+---------------------+
	  |       	        |                     |
  	  |       	        |                     |
 +-----------------+    +--------------+    +------------------+
 | Less Accessible |    | Inaccessible |    |  More Accessible |
 |      Host       |    |     Host     |    |       Host       |
 +-----------------+    +--------------+    +------------------+

	Figure 1. Typical filtering router firewall

In a university environment, access typically would be based on
the department the machine is located in, who manages/uses the
machine, and an initial security audit (which is hopefully repeated
on a regular basis). At Texas A&M, we perform security audits using
the Tiger Scripts package which was developed for this purpose.
Any hosts that are never "registered" for access through the filter
would receive some type of default access which would be defined
by the network managers.

While this type of firewall is theoretically weak in comparison to
other firewall methods, in practical use it does provide a useful
increase in security. The points of attack have been greatly reduced
and casual intruders are quickly discouraged.


			  Internet Link
				|
				|
                          +-----------+
                          |   Router  |
                          +-----------+
   				|
				|
                         +--------------+
                         |   Bridging   |
                         |    Filter    |
			 | (Drawbridge) |
                         +--------------+
				|
                                |
	  +---------------------+---------------------+
	  |       	        |                     |
  	  |       	        |                     |
 +-----------------+    +--------------+    +------------------+
 | Less Accessible |    | Inaccessible |    |  More Accessible |
 |      Host       |    |     Host     |    |       Host       |
 +-----------------+    +--------------+    +------------------+

	         Figure 2. Drawbridge firewall

A typical Drawbridge firewall configuration is related to a filtering
router firewall as shown in Figure 2. The difference is that instead
of using a filtering router as the firewall, the filtering function
is moved from the router into Drawbridge which acts as a bridging
filter.  Note however, that Figure 2 just describes a typical setup;
a router is not a necessary component of a Drawbridge configuration.

Comparison to Other Filtering Methods
-------------------------------------

An excellent source of information about packet filtering issues
is Brent Chapman's paper "Network (In)Security Through IP Packet
Filtering" (available from ftp.greatcircle.com as pub/pkt_filtering.ps.Z).
This paper discusses the concepts behind packet filtering and some
of the problems associated with it. It also discusses the problems
with current implementations of packet filtering found in some
current routing products.

Rather than repeat that material, this section will assume that
the reader is familiar with packet filtering and instead will
discuss how Drawbridge tries to address some of the problems
mentioned in Chapman's paper.

One of the first problems with current packet filtering implementations
is that they are difficult to configure. The simple syntax is
designed so that a router can efficiently implement it, not so that
the administrator can effectively configure it. We have found also
that the syntax is just too limited in its power. On a university
campus, there is a need for many different filtering configurations
to satisfy the diverse needs of the many users.  Also, while the
needs of administrators are usually defined in terms of connections,
filters usually are defined in terms of packets only; the semantics
of connections must be tediously mapped on to them.

These issues are addressed in Drawbridge through the use of compiled
tables where each host is a separate entry in a table defined for
the entire IP network the host resides in. This allows a complex
source language to be designed that is in terms that administrators
use and provides enough flexibility that complex sets of filters
can be defined. Also, under TCP, instead of speaking only in terms
of packets, Drawbridge filters in terms of connections. This makes
configuration easier for the administrator and Drawbridge more
efficient.

This table design allows arbitrarily complex filters to be defined
with little penalty. In conventional filtering routers, as filters
are added, the performance begins to quickly drop due to how they
implement the filtering rules.  In Drawbridge, arbitrary numbers
of complex filters can be set up and the performance remains almost
constant since simple look ups are performed and only connection
establishment packets are filtered for TCP. 

The ability to setup arbitrarily complex filters is a necessity in
a university environment. Texas A&M University has approximately
12,000 devices on the campus network with over 5,000 of those
devices registered for IP service.

A second problem with most filtering implementations is that testing
filter configurations is difficult. Drawbridge remedies this by
allowing the administrator to see the results of a compiled
configuration file to see if the correct filtering rules have been
applied. Since Drawbridge is less algorithmic than current filtering
implementations, it is sufficient to investigate the compiler
output.  The administrator can look at the class that a host has
been assigned and at the filtering lists defined for each subtable
in that class.

A last problem that Drawbridge addresses is that there is usually
no support for source port filtering. Drawbridge specifically
defines an entire subtable to support TCP source port filtering
(UDP source port is not supported). Since source port filtering
does allow the possibility of tunneling, Drawbridge does add the
restriction that the destination port must be greater than 900
(900 was chosen due to "broken" FTP implementations which happen
to use FTP data ports beginning at around 900 rather than 1024).

Physical Structure
------------------

 		     Internet

			|	   +-------------+
			|          |		 |
			+----------| Workstation |
			|	   |    	 |
			|	   +-------------+
                        |
                    +--------+
                    |        |
		    |   PC   |
	            |        |
		    +--------+
        		|
			|

                      Campus

	Figure 3. Ideal Drawbridge configuration

Drawbridge is physically structured as shown in Figure 3. The PC
running Filter is placed between the Internet and the network that
will be protected. Optionally, a Sun workstation can be used to
communicate with and manage Filter on the PC.  Filter acts as a
filtering bridge between the Internet and campus networks (Filter
performs bridging but does not conform to bridging standards; e.g.
it has no support for Spanning Tree Protocol.)

In the ideal configuration, the workstation would be placed outside
of Filter so that monitoring of connection attempts can be performed.
This is a good way to look for attacks and probes that are attempted
against your network (and are hopefully blocked by Filter). Since
this does also restrict the workstation's access to your network,
you would have to commit a workstation for specifically this purpose.
If you don't have a workstation to spare you can use a machine on the
internal network to perform the management.


Logical Structure
-----------------

     +--------------------+    +----+    +----+     +--------+
     |	    	          |    |    |    |    |     |        |
     | filter source file | -> | fc | -> | fm | <-> | Filter |
     |                    |    |    |    |    |     |	     |
     +--------------------+    +----+    +----+     +--------+

      Figure 4. Drawbridge compilation and loading process

As was mentioned above, Filter is a table based filtering bridge.
This approach is taken to improve the performance of filtering.
The tables are generated by the process depicted in Figure 4.
A source file containing filtering specifications in a special
language is generated and maintained by an administrator.  This
file is then passed through fc which generates the tables used by
Filter. These tables can be loaded via fm or by floppy disk.

How Filter Works
----------------

fc generates four different kinds of tables. The first is a network
table which has an entry for each host in the network.  The host
portion of an address determines the index into the table. The
value in the table defines the "class" that will be applied to a
host when a TCP connection attempt or UDP packet is directed at
that host. Currently only class B and C networks are supported;
class A tables would consume 16MB of memory and Filter does not
have the capability to use any memory above 1MB.

Note that these tables are defined in terms of the host on the
inside of Filter. No filtering is done based on the address of the
host outside of the filter except on a global basis for reject and
allow. It is assumed that an inside host will control which outside
hosts are allowed access its services. Filter only controls which
inside host's services are open, not which outside hosts may access
an inside host's services.

The host's class is used as an index into the classes table. This
table is composed of four subtables: TCP in, TCP out, TCP source
and UDP in.  These subtables are in turn composed of lists that
contain port number ranges. A class specifies a list out of each
subtable that will define a host's filtering. It is important to
note that the TCP filtering only occurs when ACKless SYNs (connection
initiation) are detected in a TCP header.  All other packets of a
TCP session are not filtered.  Also, all UDP packets are filtered on
an incoming basis only.

The last two tables are the allow and reject tables. The allow
table globally allows packets out from any machine on the inside
of the filter to the list of addresses in the allow table.  The
reject table globally rejects packets coming in from any machine
on the outside of the filter with an address corresponding to an
address in the reject table.

The following two flowcharts describe how Filter uses these tables
to check connections for incoming and outgoing requests. Figure
5 is for incoming packets while Figure 6 is for outgoing packets.


 		 	 no
  +------------------------- bridge packet?
  |     			   | yes
  |     			   V   no
  |     			  IP? ----------------------------------+
  |     			   | yes				|
  |     	yes     	   V					|
  +---------------- source IP address in reject list?			|
  |     			   | no					|
  |     			   V      no    			|
  |     			TCP/UDP? -------------------------------+
  |                        TCP /       \ UDP 				|
  |     	              V no      \				|
  |               ACKless SYN? ----------\------------------------------+
  |     	     | yes		  \				|
  |     	     V			   V				|
  |    network table defined for         network table defined for	|
  |     destination IP address?           destination IP address?	|
  |         | no	   | yes	      |	no	    | yes	|
  |         V		   V		      V		    V		|
  |   use class 0     look up class     use class 0    look up class	|
  |          \	        for host               \         for host	|
  |           \		/		        \	 /		|
  |            V       V       yes     no        V	V		|
  |      does class allow the -----+  +--- does class allow the		|
  |      destination port in?      |  |    destination port in?		|
  |     	  | no		   |  |  	    | yes       	|
  |     	  V	       yes |  |             |                   |
  |      does class allow the -----+  |  	    |   		|
  |     source port in and is      |  |             |                   |
  |     destination port > 900?	   |  |             |   		|
  |	          | no  	   +--|--+          |          		|
  |		  |     	      |  |          |   		|
  |		  V     	      |  |          V   		|
  +-----------> DROP <----------------+  +------> PASS <----------------+

		Figure 5. Incoming packet filtering algorithm


 		 	 no
  +------------------------- bridge packet?
  |     			   | yes
  |     			   V   no
  |     			  IP? ----------------------------------+
  |     			   | yes				|
  |     			   V    no     			        |
  |     			  TCP? ---------------------------------+
  |                                | yes				|
  |     	                   V        no                          |
  |                           ACKless SYN? -----------------------------+
  |                                | yes          			|
  |                                V          				|
  |                    network table defined for                        |
  |                       source IP address?                            |
  |                        | no           | yes                         |
  |                        V              V                             |
  |                  use class 0     look up class                      |
  |                         \          for host                         |
  |                          \          /                               |
  |                           V        V       yes                      |
  |                      does class allow the -------+                  |
  |                      destination port out?       |                  |
  |                               | no               |                  |
  |                               V              yes |                  |
  |                      destination IP address -----+                  |
  |                          in allow list?          |                  |
  |                               | no               |                  |
  |				  |          	     |                  |
  |		       	          |                  V                  |
  +-----------> DROP <------------+                PASS <---------------+

		Figure 6. Incoming packet filtering algorithm

Filter Compiler Language
------------------------

The language used by the compiler contains constructs for creating
the various tables used by the filter.  Constructs exist for
specifying the network access on a per host basis, or on a network
or subnetwork basis.  Groups of services can be created.  These
groups can be used in cases of related services, or to group
related machines.

The basic element of the language is a service specification.  The
service specification contains four pieces of information: the
service, protocol, source or destination, and traffic direction.  The
service can be either an entry from /etc/services, or a numeric port.
Service ranges can also be used.  The protocol specifies the protocol
the service uses.  The source or destination indicates whether the
filter should use the source port or the destination port.  Finally,
the traffic direction indicates whether this is for outbound packets
or inbound packets, or both.

A group is a list of comma separated service specifications or other
previously defined groups.  Groups can be used to relate services,
or to categorize machines, allowing quick global changes to a
category of machines.

Hosts and networks can be granted network access using service
specifications or group names.  As hosts and networks are processed,
the classes used by the filter are created.  Hosts with equivalent
network access (real access, not syntactic) will belong to the same
class.

Constructs also exist for building the reject and allow tables used by
the filter.  The reject table is used to block all incoming packets
from a host or network.  The allow table allows internal machines
access to a restricted external service.

