IPTEST

Iptest formalizes the types of tests that the isic suite loosely performs . It has a large menu of options that you can use to generate very specific test results such as random TTL values in the IP header or TCP packets with sequence numbers on particular bit boundaries. It grew out of the Unix IP Filter project (http://coombs.anu.edu.au/ ipfilter /). IP Filter is firewall and NAT software for BSD and Linux 2.0. x kernels (plus versions for Solaris, HP-UX, and QNX). Its original purpose was to test the firewall's robustness under extreme networking conditions.

Although iptest (and the general IP Filter suite) is still under active development, it mainly supports BSD-style operating systems. The Linux support remains at the 2.0. x kernel level.

Implementation

All tests require four options to specify the source and destination of each packet. The source IP address is specified with -s ; the destination is always the last argument (without an option flag):

 # iptest -s 172.16.34.213 192.168.12.84 

If the source IP address does not belong to the physical NIC used to generate the traffic, you may also need to specify the network interface ( -d ) and gateway ( -g ) on the command line, for example:

 # iptest -s 10.87.34.213 -d le0 -g 192.168.12.1 192.168.12.84 

Then you can let iptest go through its entire list of built-in tests, or you can select more focused tests with the - n and -p t options, where n is a number between one and seven and t is the number of a "point test" for the corresponding n . In other words, you select an option between one and seven. For example, option five ( -5 ) contains the majority of the TCP-based tests. Within option five, there are eight point tests ( -p ). The final command to run option five with its first point test will look similar to this:

 # iptest -s 10.87.34.213 -d le0 -g 192.168.12.1  -5 -p1  192.168.12.84 

This example tests all combinations of the TCP flags. Table 19-4 describes the more useful menu options.

Table 19-4: Quick Start iptest Options

Option Number	Point Test	Description
Iptest Options
-1	7	Generates packets with zero-length fragments .
-1	8	Creates packets that are greater than 64KB after reassembly. This could cause buffer overflows in poor networking stacks.
-2	1	Creates packets that contain an IP option length that is greater than the packet length.
-6	n/a	Generates packet fragments that overlap on reconstruction. This can wreak havoc on less robust TCP/IP stacks. If you use this test, you should perform it separately from others.
-7	n/a	Generates 1,024 random IP packets. The IP layer fields will be correct, but the packet's data will be random.
UDP Test Options
-4	1 , 2	Creates a UDP payload length that is less than ( 1 ) or greater than ( 2 ) the packet length.
-4	3 , 4	Creates a UDP packet in which the source ( 3 ) or destination ( 4 ) port falls on a byte boundary: for instance, 0, 1, 32767, 32768, 65535. This test may reveal off-by-one errors.
ICMP Test Options
-3	1 through 7	Generates various nonstandard ICMP types and codes. This test may reveal errors in ACLs that are supposed to block ICMP messages.
TCP Test Options
-5	1	Generates all possible combinations of the TCP options flags. This test may reveal logic problems in the way that a TCP/IP stack handles or ignores packets.
-5	2 , 3	Creates packets in which the sequence ( 2 ) and acknowledge ( 3 ) numbers fall on byte boundaries. This test may reveal off-by-one errors.
-5	4	Creates SYN packets with various sizes. A SYN packet with a size of zero is the ubiquitous port-scan packet. An intrusion-detection system or firewall should be watching all manner of SYN packets for suspicious activity.
-5	7 , 8	Creates packets in which the source ( 7 ) or destination ( 8 ) port falls on a byte boundary: for instance, 0, 1, 32767, 32768, 65535. This test may reveal off-by-one errors.

Case Study: Firewall Performance

Network administrators are always curious about how well a firewall protects the network, how it performs under active attacks (such as DoS attacks and intensive scans ), and how it performs under heavy loads. With this in mind, Jethro sets out to test his firewall. He takes the following script and loads it onto his laptop running FreeBSD. This laptop is placed "in front of" the firewall, which means that it represents traffic originating from the Internet.

 #!/bin/sh # IP Stack test # usage: test.sh <gateway> <source> <destination> # note, change "le1" to your interface iptest -1 -d le1 -g  -s   iptest -2 -d le1 -g  -s   iptest -3 -d le1 -g  -s   iptest -4 -d le1 -g  -s   iptest -5 -d le1 -g  -s   iptest -6 -d le1 -g  -s   iptest -7 -d le1 -g  -s   isic -s  -d  -p10000 tcpsic -s  -d  -p10000 

He takes another laptop and places it behind the firewall. This is a high- band - width network, so only switches are availablemeaning he'll have to turn on what is called a span port to catch all the traffic with tcpdump. Luckily, an intrusion-detection system is already on a span port. The IDS hasn't picked up any attacks in the last two months and the test is being performed after hours, so no one is going to complain about the IDS being offline for a few minutes. Jethro unplugs the IDS and plugs in his laptop running tcpdump. He launches the test but nothing happens!

After a few minutes of double-checking the IP stack test script, Jethro realizes that the span port on which the IDS has been listening was never, in fact, set to span. In other words, for the last two months the IDS has been able to capture only traffic that was sent directly to it. Jethro quickly corrects this and continues with the firewall test, but it shows that regular testing is necessary to maintain the health of a networkeven when you're not looking for a particular problem!