|
|
All of the penetration tests for the UnderFire program are located under the tests directory under the main UnderFire installation directory. Tests are added and deleted just by creating or removing a directory in the tests directory. In other words, to create a new test, just create a new directory under the tests directory and populate it with the appropiate files, (described below).
Each test directory may contain zero or more test programs, zero or more signature programs, zero or more timeout files, and a data file. The way a test is executed is as follows. First, all of the signature programs are run and immediately put into the background. These programs, whose file names end in .sig, are stand alone programs that are used to figure out if the test is successful or not. For example, say you are running a packet fragmenting attack to determine if the firewall does not reassemble fragmented packets before checking them against its filter rules. The signature program for this test would probably run tcpdump on the "inside" network and sniff for a specific packet to make it through the firewall. If the signature program sends any data to STDOUT or STDERR, it is an indication that the firewall failed the test, (e.g. the invalid packet was allowed through in this case). The string that the signature program sends to STDOUT or STDERR is saved in the test report directory and a link is made to it from the HTML test report. If you create a new test, it might be a good idea to send a descriptive message to STDOUT or STDERR detailing why you decided that the test failed so that a viewer of the log file might get a good idea of what the problem may be. HTML code may be inserted into this output.
After all of the signature programs are executed and put into the background, the test programs, (if any), are run. These programs are files that end in .tst and are stand alone programs that execute a given test. They are given as arguments the process IDs of the signature programs, (which may be used for synchronization as we will discuss below). The test programs just implement a specific test and any output they generate is usually ignored. In the packet fragmentation example given above, the test program would generate and send a fragmented packet which attempts to overwrite the IP header of the first fragment sent by later fragments, (in other words, it attempts to send a packet through the firewall which would usually be rejected by specifying a valid destination host--one to which the spoofed source address is allowed access--in the first fragment sent and then attempting to overwrite that data with later fragments so that an invalid packet is allowed through).
Each test may have a timeout value associated with it. This value is contained in a file taking the same prefix of the test program, (everything before the .tst extension), followed by .timeout. For example, the timeout file belonging to the test program foo.tst would be named foo.timeout. A timeout file need not exist. The purpose of the timeout file is twofold; it indicates if the test should run in the forground or background, and if placed into the background, the timeout file specifies how long the test should be allowed to run before the evaluation procedure continues to the next step. If the timeout file exists, it should only contain an ASCII representation of a positive or negative value. If the value is less than 0, or the timeout file does not exist, the test program is run in the background and control is immediately returned to the calling function. If the timeout file contains a positive integer, the test program is run in the background. Before control is returned to the calling function, however, there is a pause of x seconds where x is defined by the integer stored in the timeout file. Finally, if the timeout file contains the integer 0, then the test is run in the forground and control is only passed back to the controlling function when the test program exits.
Using the timeout file, a variety of behaviors can be configured for each test program to be executed. In some cases, the test program may only be used for building a framework for other test programs, or the result of the test may be immediately obvious. In these situations, a timeout file is not needed, (or may contain a negative value to signal others that the lack of a timeout file was not just an oversight). Other tests, such as a denial of service attack, may need some time to run before the evaluation process continues; this is where a positive timeout value may be desired. Another situation that may arrise is the need to synchronize the test program with the signature programs previously executed, or user interaction with the test program. This is why running the test in the foreground is allowed.
The data file is named index.html and contains HTML code which describes the test. Other .html files may also exist in the test directory as needed. The purpose of this file is to explain to the user the test. It may also describe the implementation and provide links to other sources.
As examples, let us look at a couple tests and how they might use the structure given above. First, we will look at a generic denial-of-service attack such as a SYN flood. In this case, the signature programs do not exist since our only concern is if valid traffic is still allowed through during the attack, (and invalid traffic is rejected). What we do is have the test files launch the attack, and place an appropriate value in the timeout file which will allow the attack to run a little bit before valid and invalid connections are tested, (30 seconds ought to be plenty of time to fill a connection queue on a 10-BaseT LAN). The test programs are in a tight, infinite loop, which will continue to run until the test is fully completed.
Next, let us look at a DNS cache poisoning attack. In this case, we want the signature program, (which will probably do a lookup on a specific host and see if the "poisoned" or invalid data is returned), to run only after the attack program is executed. This will be implemented by having the signature program wait for a signal, (e.g. USR1), to be sent to it before doing the lookup. The test program, (which, if you recall, is given the process IDs of all signature programs), runs the attack, waits a couple seconds for things to settle, then sends a signal to the signature program before exiting.
|