|
|
The following is a description of the firewall evaluation test bed as well as a detailed explanation of the testing procedure and the tests performed. To begin, let us take a look at the physical layout of the test bed.
----+-----------+-------------+----
| | |
+---+--+ +---+----+ +---+--+
|HOST A| |FIREWALL| |HOST B|
+---+--+ +---+----+ +---+--+
| | |
----+-----------+-------------+----
Fig. 1
Host A is the main control system for the testing process. It also serves as
the "attacker" and a "sniffer." Host B represents two separate hosts--one
on the inside network, (protected by the firewall), and on on the outside
network, (a legitimate user). It may seem confusing that Host A, as the
attacker, has a direct connection to the network protected by the firewall.
This connection is only for packet tracing and testing if an attack is
successful, however, and will not be used to aid any of the attack
attempts. It might make things clearer to look at a theoretical view of the
test bed.
+------+ +------+
|HOST W| |HOST X|
+---+--+ +---+--+
| |
----+--+------------------+---+----
| |
+---+---+ +----+---+
|SNIFFER| |FIREWALL|
+---+---+ +----+---+
| |
----+--+------------------+---+----
| |
+---+--+ +------+
|HOST Y| |HOST Z|
+------+ +------+
Fig. 2
In this view, Host W is considered to be the attacker. Host X is a user on
the outside, (e.g. the Internet), that is allowed access to Host Y which is
on the network protected by the firewall. Host Y is also permitted to access
Host X. Any traffic to or from Host Z is not allowed through the firewall.
Finally, the sniffer is only used to monitor packet flow on the two networks
and is not allowed to talk to anyone, (imagine that the transmit wires are
cut on the lines connected to the sniffer machine).
In order to map the picture presented in Figure 1 to that in Figure 2, take the Host W and Sniffer machines from Figure 2 and combine them into one physical machine, (Host A in Figure 1). Also, take the Host X and Host Y machines from Figure 2 and combine them into one physical machine, (Host B in Figure 1). Host Z from Figure 2 is implemented by disallowing traffic from Host A to Host B, (in Figure 1), when routed through the firewall and vice versa. This may be somewhat confusing, but hopefully it will become clearer as we describe the test procedure.
The labels given in Figure 1 will be used when detailing how the tests will be made, so let us quickly go over the routing on the test bed. First, let us look at Host B, (see Figure 3). Any traffic from the outside to the inside is routed through the firewall. The outside network uses a separate class A than the inside, so this is easy to implement with static routing tables. Also, any traffic from the inside interface to the outside is routed through the firewall. Because there are two physical network cards in Host B, we are able to implement this without too much hassle. This is how we are able to combine Host B and Host C as shown in Figure 1 into one machine, (this actually makes it easier to synchronize the tests which are described below). The same sort of design is used for Host A. In that case, the inside connection takes the place of the Sniffer machine's connection to the inside as shown in Figure 2 while the outside connection is used as both Host A, (as shown in Figure 2), as well as the sniffer's connection to the outside network. Host Z, (in Figure 2), is implemented by disallowing traffic between the inside connection of Host B to the outside connection of Host A, (keep in mind that the inside connection of Host A is considered to be non-addressable).
----+----
| <- Outside
+---+--+
|HOST B|
+---+--+
| <- Inside
----+----
Fig. 3
One final issue regarding the routing is the firewall configuration. The
firewall should disallow all telnet traffic from the outside interface of Host
A to the inside interface of Host B. Telnet traffic between the outside and
inside interfaces of Host B are allowed through the firewall. All other
traffic should be denied, (e.g. from the inside interface of Host B to Host
A). Telnet traffic can be substituted for something else if needed, but for
this incarnation of the testing procedure, telnet is used for testing valid
and invalid connections because of its wide availability and ease of use.
Now that we have the physical layout of the test bed and its routing, let us take a look at the details of the test engine. The main control program is written in Perl and will be run from Host A. The specific steps the control program follows are:
The above steps are accomplished by a few separate programs all of which are run from Host A. One of the driving factors behind the physical layout and the design of the test engine is the ability to have most anyone stick a firewall into the test bed, configure it, run all of the available tests against it, and generate a report without any sort of operator intervention, (e.g. make things as automatic and equal as possible). Before I describe the programs used, let me outline the directory structure on Host A where the testing software is housed.
| bin/ | The directory which contains the main test driver programs. | |
| fwtest | This program is the main controller. It uses the other programs and directories listed to configure itself and execute all of the available tests, (or only those specified). | |
| logctrl | This program handles all of the logging functions. | |
| control | This program establishes a connection from the outside interface on Host B to the inside interface on Host B and vice versa. It also can be used to test these connections. | |
| invalid_connect | This program attempts "invalid" connections from the outside interface of Host A to the inside interface on Host B and vice versa. | |
| tests/ | This directory contains all of the tests for the firewall as well as programs that may be used to determine if the test--attack--was successful or not. | |
| logs/ | This directory contains all of the temporary logs created during a test. | |
| reports/ | This directory contains the final reports of the tests run. |
The fwtest program is a Perl script that basically handles all of the testing. It is what an operator will run to test a firewall. It executes all of the test steps listed above, determines if an attack was successful or not, and generates a report. In other words, on operator just runs this program and it handles everything.
The logctrl program is a Perl script that handles executing and logging of programs. It is a stand-alone program that is very versatile in what it can do. Briefly, what it does is take a command to run and a user defined session name, runs the command, and logs all output, (anything printed to STDOUT or STDERR), to a unique file which it creates. This program accepts a number of arguments which allow a user to start, pause, and stop log sessions, add "time stamps" to log files, and print and erase log files.
The control program is an Expect script that first establishes a telnet connection to a host, (in this case, from the outside interface of Host A to the outside interface of Host B), then establishes a telnet connection to another host, (in this case, from the outside interface on Host B to the inside interface on Host B), and finally, establishes one more telnet connection to another host, (in this case, from the inside interface on Host B to the outside interface on Host B). If all of these connections are successful, then the program puts itself into the background and prints its process ID to STDOUT. If any errors occur during the connections, then the program prints 0 to stdout, writes an error message to a log file, and exits, (closing all connections). Once in the background, the control program waits for an indication that the connections it established were severed, or a USR1 signal. If any of the established connections are closed, the string "Not OK" is printed to a log file, a more detailed message is printed to a separate log file, and the program exits, (closing any connections not already closed). If a USR1 signal is received, the connections are tested, (by printing a character through the connections and seeing if the same character is echoed). If the test is unsuccessful, then the string "Not OK" is printed to a log file, and a more detailed message is printed to another log file. Otherwise, the string "OK" is printed to a log file. In both cases, the program exits, (closing all still established connections). This program is used to implement steps 2, 3 and 7 as listed above.
The invalid_connect program is an Expect script that first attempts a telnet connection from the outside interface of Host A to the inside interface of Host B, (which should be rejected by the firewall). It then establishes a valid telnet connection from the outside interface of Host A to the outside interface of Host B. From there, it establishes a telnet connection to the inside interface of Host B. Finally, it attempts a telnet connection from the inside interface of Host B to the outside interface of Host A, (which should be rejected by the firewall). This program prints the string "OK" to STDOUT if all of the assumptions were met, (i.e. the firewall blocked all invalid traffic), otherwise it prints an error message to STDOUT.
The tests directory contains each of the tests to run. Each test program and its supporting programs and data files are stored in a separate directory under the test directory. Since the tests are not hard-coded anywhere, individual tests may be added and deleted by adding a new directory under the test directory and populating it with the appropriate files. For a full description of how tests are created and executed, please see the test information page.
Some of the attacks that we have or plan on implementing are listed below. All of the attacks may not relevant to a given firewall system.
|