Chapter 19: TCP/IP Stack Tools

Testing the TCP/IP stack of your firewall, web server, or router isn't part of a daily security review or even a weekly audit. However, these tools can help you verify access control lists and patch levels. They also provide a method for analyzing how your servers may respond to Denial-of-Service (DoS) attacks or other extreme network conditions. Some of these tools can also be used to create arbitrary TCP, UDP, or even DNS packets. This functionality enables you to create specific, customized tests for scenarios that range from load testing to protocol compatibility testing. If you've ever had to program Unix sockets, you'll find that these tools significantly reduce the time necessary to generate usable programs.

ISIC: IP STACK INTEGRITY CHECKER

Testing the IP stack of your Windows, Linux, Mac, or BSD system might sound like a purely academic endeavor. After all, it can be difficult to debug an operating system's network code whether or not you have the source code. On the other hand, running a few tests against your network's firewalls, routers, or other bastion hosts provides some useful insight into how each device responds to a variety of traffic. This is important when testing access control lists, anti-spoofing measures, and resistance to some types of DoS attacks.

Implementation

The ISIC suite resides in the /security directory of BSD's ports collection or can be downloaded from http://www.packetfactory.net/Projects/ISIC/. It is based on the libnet packet creation library, which must be installed on your system. The ISIC application is actually a suite that contains five programs: isic, tcpsic, udpsic, icmpsic, and esic. Each of these programs generates various types of valid and invalid packets for the IP, TCP, UDP, ICMP, and ARP protocols. This enables you to test not only general networking protocols (IP) but also more specific ones.

Isic

Isic handles the IP-level tests. This covers the source and destination IP addresses, IP version number, and header length. When you run isic, it acts as a packet cannon, dumping IP packets onto the network as quickly as possible. Some of these packets are intentionally malformed. Use the percentage options to modify the mix of bad and good packets. The list of command-line options is shown in Table 19-1.

Table 19-1: Isic Command-line Options

Option	Description
-v	Prints version.
-D	Prints raw content of packet, useful for debugging.
-s <source IP>	Source IP address to include in the packet.
-d <destination IP>	Destination IP address to include in the packet.
-p n	Generates n packets.
-k n	Skips n packets. This helps to start with a particular test or permutation of the packet contents.
-x n	Sends packet n times.
-r n	Seeds the random number generator with n.
-m n	Generates no more than n kilobytes of traffic per second.
-F p	Of all packets to be generated, p percent of them should be fragmented.
-V p	Of all packets to be generated, p percent of them should contain a bad IP version header.
-I p	Of all packets to be generated, p percent of them should contain a random IP header length value.

For example, you can see how a gateway handles a large number of malformed packets, possibly to determine the impact of a DoS attack on network bandwidth. The following command sends empty IP packets from 192.168.0.12 to 192.168.0.1. As traffic is generated, 10 percent of the packets will contain a bad IP version number (a version other than 4), no packets will contain an improper header length, and 50 percent will be broken into fragments:

# isic -s 192.168.0.12 -d 192.168.0.1 -F50 -V10 -I0
Compiled against Libnet 1.0.2a
Installing Signal Handlers.
Seeding with 13584
No Maximum traffic limiter
Bad IP Version = 10%     Odd IP Header Length = 0%   Frag'd Pcnt = 50%
 1000 @ 6192.1 pkts/sec and 3036.2 k/s
 2000 @ 5175.3 pkts/sec and 2109.4 k/s
 3000 @ 6040.3 pkts/sec and 2208.7 k/s
 4000 @ 6009.8 pkts/sec and 2329.2 k/s
 5000 @ 6072.4 pkts/sec and 2335.6 k/s
 6000 @ 5325.1 pkts/sec and 2018.3 k/s
 7000 @ 6170.7 pkts/sec and 2327.2 k/s

Packet statistics are reported in groups of thousands. In the previous example, isic is generating about 6000 packets per second, which equates to roughly 2–3 megabits per second of throughput. Remember, 50 percent of all these packets are fragmented and require the firewall (or receiving device) to reconstruct the packets, which can be a CPU- or memory-intensive task, or to even bypass an intrusion-detection system. Another 10 percent of the packets have the incorrect IP version number. Hopefully, the receiver's networking stack drops the packets with minimal effect on the system.

If you want to limit isic to a specific bandwidth, throttle it with the -m option. This limits it to a specific kilobytes per second of packet generation. Alternatively, use the -p option to send only a specific number of packets.

No test is useful if you cannot repeat the input or record the results. The -D option lists each packet's contents as it goes onto the network. For example,

192.168.0.12 -> 192.168.0.1 tos[27] id[0] ver[4] frag[0]
192.168.0.12 -> 192.168.0.1 tos[250] id[1] ver[4] frag[56006]
192.168.0.12 -> 192.168.0.1 tos[34] id[2] ver[4] frag[0]
192.168.0.12 -> 192.168.0.1 tos[213] id[3] ver[4] frag[39249]
192.168.0.12 -> 192.168.0.1 tos[249] id[4] ver[4] frag[0]
192.168.0.12 -> 192.168.0.1 tos[91] id[5] ver[4] frag[0]
192.168.0.12 -> 192.168.0.1 tos[26] id[6] ver[4] frag[0]

At first, this might not seem useful, but take a look at the IPID field. Each subsequent packet increments this value by one. Consequently, you can backtrack through a firewall log, for example, to see what specific packet caused an error. Check out the "Tips and Tricks" section later in this chapter for more examples of how to trace back errors.

Note

Add the -D option to get a list of debugging information (packet contents) for any of the *sic packages.

Tcpsic

The TCP prefix indicates the utility for generating random TCP packets and data. The usage is similar to the usage of isic, but you can also specify source and destination ports. This enables you to test a web (port 80), mail (port 25), or VPN (multiple ports) service in addition to the system. Note in the following table that tcpsic adds different percentage options for the good and bad traffic it generates.

Common Options (tcpsic, udpsic, icmpsic)	Description
-v	Be verbose.
-D	Be more verbose (debugging information).
-s <source IP>[, port]	Source IP address and port. This option must be present.
-d <destination IP>[,port]	Destination IP address and port. This option must be present.
-r <seed>	Seed value for random number generator.
-m <max traffic>	Maximum traffic rate to generate, in KB/s.
-p <max packets>	Maximum packets to generate.
-k <packets>	Skips this number of generated packets.
-x <repeat>	Re-sends the packet x times.
tcpsic Options
-F <val>	Percentage of packets that should be fragmented.
-V <val>	Percentage of packets that should contain a bad IP version number.
-I <val>	Percentage of packets that contain IP options.
-T <val>	Percentage of packets that contain TCP options.
-u <val>	Percentage of packets that contain the urgent flag (URG).
-t	Percentage of packets that contain invalid TCP checksums.

Remember to place a comma between the IP address and port number. If you omit the port number, tcpsic selects a random port for each packet.

# tcpsic -s 192.168.0.12,1212 -d 192.168.0.1,80

Udpsic

Udpsic also allows you to specify ports along with the source and destination IP addresses. The UDP protocol does not have as much capability as TCP, so there are fewer percentage options to specify.

udpsic Options	Description
-F <val>	Percentage of packets that should be fragmented
-V <val>	Percentage of packets that should contain a bad IP version number
-I <val>	Percentage of packets that contain IP options
-U	Percentage of packets that contain invalid UDP checksums

UDP makes up a smaller portion of IP traffic. In a production server environment, it usually comprises only DNS traffic, although SNMP services may be worth testing as well:

# udpsic -s 192.168.0.12,1212 -d 192.168.0.1,53

However, this tool can also be used to test servers running streaming protocols such as those used in media servers and networked games.

Icmpsic

The majority of networks block incoming ICMP to their network. Use the icmpsic tool to see how your security device handles ICMP traffic, including traffic that does not fall into the "Ping" category. Normal ICMP traffic usually consists of ICMP echo requests (the host question, "Is there anybody out there?") and ICMP echo replies (the host response, "Us and them"). Other ICMP types cover timestamps and access control. Most of the time, all ICMP traffic is blocked from the Internet into the network. On the internal network, Ping can usually roam freely, so why not examine how devices handle excessive ICMP traffic?

icmpsic Options	Description
-F <val>	Percentage of packets that should be fragmented
-V <val>	Percentage of packets that should contain a bad IP version number
-I <val>	Percentage of packets that contain IP options
-i	Percentage of packets that contain invalid ICMP checksums

Although the usage implies that you can specify ports with the -s and -d arguments, setting a port number makes icmpsic use a broadcast address instead. Port numbers are not part of the ICMP protocol. At the IP level, you can still generate fragmented packets (-F), packets with bad IP versions (-V), and packets with bad IP options (-I). ICMP is a subset of the IP protocol, which is why these options are still available.

The only ICMP-specific option sends a bad ICMP checksum, which should invalidate the packet when it is received. Otherwise, icmpsic generates random values for the message type and message code. An ICMP echo reply, for example, is type 0. An ICMP timestamp reply is type 14. RFC 792 enumerates the majority of the ICMP types. The reason we appear pedantic in the ICMP protocol is that it is an often-overlooked protocol that can be used as a covert channel (see Chapter 10) or even used in operating system identification that relies on stack fingerprinting (http://www.sys-security.com/archive/pa-pers/ICMP_Scanning_v3.0.pdf).

Esic

The e in esic stands for Ethernet. This tool transmits packets with random protocol numbers—in other words, packets not based on the TCP/IP protocol. This is the only tool that works below the IP layer; therefore, it does not provide the same amount of invalid packet generation.

esic Options	Description
-i <int>	Interface on which to transmit packets Required
-s <MAC>	Source MAC address
-d <MAC>	Destination MAC address
-p <protocol>	Protocol number
-r <seed>	Seed for random number generator
-c <val>	Number of packets to send
-l <val>	Maximum packet length
-m <val>	Number of packets between printout

The uses for this tool are limited mainly to testing firewalls or wreaking havoc on switches. Notice that the default destination MAC address is the broadcast address. This means that any packet you create without using the -d option will go to every interface on the hub or switch. This could create a storm of packets, leading to a DoS attack or a flood that a switch cannot handle, thereby downgrading the switch to a hub and therefore enabling traffic sniffing. Of course, it would still take a lot of traffic to affect a 100MB switch.

Tips and Tricks

The isic tool suite isn't for esoteric network tests. Each tool has specific scenarios for which it is useful. Table 19-2 lists each tool and some examples of test scenarios.

Table 19-2: Common Network Test Scenarios

Tool	Test Scenario
isic	Firewalls Routers Bastion hosts (web servers, DNS servers, mail servers)
tcpsic	Firewalls (especially the administration interface) Routers (especially the administration interface) Important services (22: SSH, 25: SMTP, 80: HTTP, 111: Unix RPC, 139:Windows RPC, 443: HTTPS, 8080: proxies)
udpsic	Important services (53: DNS, 161:SNMP, 137: Windows RPC)
icmpsic	Firewalls Routers
esic	Firewalls Routers Switches (including flood attacks that could enable network sniffing and verification of VLAN security)

Firewalls

All of these tools help validate a firewall's ruleset and performance under pressure. For example, you could run isic with high percentages of invalid packets to generate load:

# isic -s 172.16.19.12 -d 192.168.0.1 -F75 -V75 -I75

The invalid packets are intended to create a heavier load on the firewall. Firewalls tend to operate efficiently when the traffic is normal. As a system administrator, you should also be concerned about how the firewall acts under adverse conditions. The number 75 after the -F, -V, and -I means that 75 percent of all packets will have errors in the IP version, header length, and fragment count. Although this is not the signature for any particular DoS attack, its effects could be similar.

Next, you could run tcpsic in parallel to test how the firewall handles traffic to a web farm (for example) behind it:

# tcpsic -s 172.16.19.23,3434 -d 192.168.0.37,80

Theoretically, the firewall should simply drop invalid traffic and move on to the next packet; however, you may uncover cases where the firewall spends an inordinate amount of time on a certain protocol number, fragment, or invalid TCP option. Of course, targeting the firewall is not the only possibility. Table 19-3 highlights other types of tests you can perform.

Table 19-3: Test Scenarios

Test	Scenario
Target the firewall	Send traffic to the firewall's IP address or one of its administration ports.
Spoof IP addresses	Generate traffic on the wrong interface. For example, use source addresses from the 172.16.0.0/16 address space on an interface that serves the 10.1.2.0/24 network. This test is especially useful for firewalls with several interfaces. Also, it may highlight problems with a firewall's anti-spoofing rules or lack thereof.
Target hosts behind the firewall	Attempt to pass traffic through the firewall to see if it stops poorly formed packets.

Another useful technique when generating packets for load testing is to use the rand placeholder for the source IP address. Any of the isic tools will generate random IP addresses if this is specified, even from the reserved address space. For example, use this program to test how the firewall handles DNS traffic, including 50 percent incorrect UDP checksums:

# udpsic -s rand -d 192.168.0.121,53 -U50

Caution

If you generate packets with rand for the source IP address in the tcpsic or udpsic tool, the destination server may respond to those IP addresses when trying to complete the TCP three-way hand- shake! Be aware that you may inadvertently be transmitting TCP RST and FIN packets to random addresses.

Controlling Packets

Each tool supports the -m, -p, -k, and -x options to control packet creation and band- width. Use -m to limit the maximum bandwidth the isic tool tries to use. This option can be useful for establishing a baseline load against a server (such as a router) or service (such as HTTP). For example, the following command does not generate any bad packets but sends a steady 1000 kbps of traffic to the web server:

# tcpsic -s rand -d 192.168.0.37,80 -m 1000 -F0 -V0 -I0 -t0

This test may also reveal how the firewall logs traffic under heavy loads. If this were a DoS attack, but complete information was captured for only the first few connections, you could not be sure that the obvious attack was not covering up a more focused attack on a web server. Also, make sure that the firewall has enough disk space to store the logs. It would be unfortunate to have a $50,000 firewall that can handle high-bandwidth attacks stop functioning because the disk space has filled up.

The -p option instructs isic to send a set number of packets and then stop. The -k option tells isic to skip that number of packets. For example, the following command generates 100,000 packets but omits the first 50,000:

# icmpsic -s rand -d 192.168.0.12 -p100000 -k50000