Chapter 17. Device Security Testing

Network devices should be tested regularly to discover potential issues before an attacker does. You can test security features and stability:

There is a variety of open source and proprietary software and hardware to do such tests. This chapter focuses on two types of testing:

Replaying traffic is not as easy as it seems. There are lots of tools available to do it, but they do not have the same design or the same features. It is important to define clearly what you are trying to test to choose the best tool for your tests. Then, you need to work on the automation. Most of the free tools presented in this chapter require you to do your own automations. There are vendors who offer powerful software or hardware that do all the work, but not for free.

In this chapter, we'll examine the Tcpreplay suite (including flowreplay), Traffic IQ Pro, the ISIC suite, and the Protos suite. It is important to understand how these tools work and what they should be used for. Misusing them makes their results useless and your network vulnerable.

Replay Traffic with Tcpreplay

Tcpreplay is a command-line tool used to replay packet captures (see Ethereal/Wireshark) and is available on Linux, Mac OS X, and BSD. It is also the name of a suite of tools containing:

Tcpreplay

Replays packet captures on one or two interfaces

flowreplay

Replays client traffic only to an existing server

tcpprep

Preprocesses a packet capture to determine clients and servers

tcprewrite

Modifies the packets (introduced in version 3)

tcpbridge

Bridges two network segments

Tip

Some Linux distributions do not distribute tcprewrite and tcpbridge as part of the Tcpreplay version 3 package. If you need these tools, you should download the sources from http://tcpreplay.synfin.net/trac/wiki/download.

Tcpreplay is open source. It is now maintained by Aaron Turner. As of this book's writing, 2.x is the stable branch. 3.x is still in development, but it is already more optimized than the stable branch and it replays traffic faster.

Tcpreplay does not generate traffic; it replays existing packet captures (see Ethereal/Wireshark). The tool replays traffic on two interfaces. It is possible to use one interface for the client requests and one for the server. However, Tcpreplay does not tell you if the packet sent on one interface reached the second one. So, it is not possible to know whether a packet was dropped by a firewall device.

Use Tcpreplay to test IDSes (see Using File Integrity Checkers) and firewall features such as backdoor detections or deep inspection. This tool cannot be used to test if these devices drop the traffic, but can be used to create logs. Tcpreplay allows you to precisely:

First configure the IDS or the firewall to log attacks while letting them through.

Tip

IDSes should not drop traffic silently. Firewalls, however, often drop malformed traffic but do not always generate a log. This makes the testing of firewalls a bit harder, as you have to double-check that the traffic was not dropped silently.

If you test a device inline (a firewall or an IDS configured inline), the test bed will look something like Figure 17-1.

Test bed set up to replay traffic

Figure 17-1. Test bed set up to replay traffic

If you replay traffic to an IDS in sniffer mode, only one interface is needed, connected directly to the sniffer interface.

Note that flowreplay (see "flowreplay") should be used to test a server. It also requires a packet capture, but it replays the client packets only to the server to test. flowreplay can also be used to replay exploits against a server.

tcpreplay can replay traffic on one or two physical interfaces. It can also modify the packets before sending them. To replay a packet capture on one interface, enter the following:

[root@crab ˜]# tcpreplay -i eth0
/tmp/packets.pcap
sending on: eth0
722 packets (513944 bytes) sent in 334.65 seconds
1535.8 bytes/sec 0.01 megabits/sec 2 packets/sec

Warning

Tcpreplay tools must be run as root on Linux.

By default, tcpreplay replays the packets at the same speed as the original capture. Note that the speed displayed at the end is not accurate enough to use this tool to measure performance.

A couple of error messages can appear when replaying a packet capture (and tcpreplay can fix them):

Bad checksums

With the -F option,tcpreplay can automatically correct the IP, TCP, and UDP checksums before sending packets.

Wrong Maximum Transmission Unit (MTU)

Packets can be larger than the MTU of the interface they must be sent to. By default, these packets are skipped. They can be truncated with the -T option and sent on the wire. This enables the -F option automatically.

Truncated packets

If packets were truncated during the initial capture, they must be padded with null bytes or the IP length must be changed. This can be done with the -u pad or -u trunc options. This enables the -F option automatically.

Warning

The option -u works for IPv4 packets only. Other types of packets, such as IPv6, are not modified.

Wrong or missing layer 2

Some tools do not capture layer 2. For packet captures on Linux, you might see Linux cooked captures in Wireshark as layer 2 data (see Ethereal/Wireshark). The layer 2 data must be rewritten before it is sent. This is possible with the −2 option followed by the data in hexadecimal format. For IP packets, you can use:

-2 01,02,03,04,05,06,AA,BB,CC,DD,EE,FF,08,00

Tip

The first six bytes (01,02,03,04,05,06) define the MAC destination address. The next six bytes are the source MAC address. Do not worry about their values. tcpreplay has arguments to rewrite the MAC addresses easily (see pcap Utilities: tcpflow and Netdude).

The last two bytes are the protocol number (8000 for IPv4).

To enable all these options when replaying packet captures for IPv4 traffic only, the command looks like this:

tcpreplay -ieth0 -u trunc-T −201,02,03,04,05,06,AA,BB,CC,DD,EE,FF/tmp/packe
ts.pcap

Instead of adding the options to the command line, you can also put all the options in a file and tell tcpreplay to use it. For the previous command, the file is:

#Common options
intf    eth0
truncate    trunc
untruncate
l2data    01,02,03,04,05,06,AA,BB,CC,DD,EE,FF,80,00

Use the -f option to load the file:

tcpreplay -f/path/common-options.txt/tmp/packets.pcap

You can create an alias for this command:

[root@crab ˜]# aliasreplay="tcpreplay -f/path/common-options.txt"

You can control the speed at which packets are replaced by using these options:

Option

Description

-mx

Replays the packets x times faster. You can use decimal numbers; e.g., -m 0.1 sends packets 10 times slower than the original capture.

-pn

Replays n packets per second.

-R

Replays packets as fast as possible.

−1

Replays one packet at a time. The user must press a key to send the next packet.

It is also possible to control which packets are sent:

Option

Description

-xn,p,q

Replays packets number n,p, and q only.

-Xn,p,q

Replays all packets except number n, p, and q.

-M

Do not send martian packets; i.e., packets with IP addresses that should not be seen on a network: 0.*.*.*, 127.*.*.* and 255.*.*.*.

-on

Start with the packets that fall after n bytes in the capture.

-ln

Replays the packet capture n times.

-Ln

Stop after sending npackets.

I usually test devices that can handle a much higher throughput than my 10 MB Ethernet card, so I use the -R option frequently.

Tcpreplay can alter packets in addition to fixing them. It can modify layer 2 (MAC addresses), layer 3 (IP addresses), and layer 4 (TCP and UDP ports). These options are very powerful. Let's look at examples of each and how they can be used.

Tip

In the Tcprelay version 3.x branch, all packet-editing features were moved to a new tool called tcprewrite. A couple of new features, such as vlan editing, were added to this program.

tcpreplay can modify the source and destination MAC address base. If you use two interfaces to replay the client and server side traffic (see the following section "Tcpreplay with Two Interfaces"), tcpreplay can set a new source and/or or destination MAC address for each interface. The arguments are -I and -k to change the destination and source MAC address on the primary interface, -J and -K for the secondary interface:

tcpreplay -ieth0-I11:22:33:44:55:66 -k AA:BB:CC:DD:EE:FF
/path/capture.pcap

This option is used to test routing devices or firewalls. The destination MAC address must be set to either the device interface MAC address or to the MAC address of the second interface that replays traffic; otherwise, the device drops the packets.

You can also change the source or destination MAC address to a layer 2 broadcast address; e.g., FF:FF:FF:FF.

You can normalize a packet capture by changing all source and destinations to the same pair of addresses with the -e argument. This command changes all source IP addresses to 1.1.1.1 and all destination IP addresses to 2.2.2.2:

tcpreplay -ieth0-e1.1.1.1:2.2.2.2/path/capture.pcap

The address can be changed to a multicast or broadcast address to verify how the device handles this type of traffic. When testing a router, you can make the traffic go from one network to another. Or it can be used simply to replay different packet captures from known IP addresses to easily sort the device logs.

With its ability to write packet captures to a file instead of a physical interface, tcpreplay is a great tool for providing clean pcaps:

tcpreplay -ieth0-e1.1.1.1:2.2.2.2/path/capture.pcap-w/path/normalized.pcap

You can change the IP address to test corner cases, including:

It is also possible to translate IP addresses from one block to another with the -N option, but I rarely use this, and only to test a NAT feature of a device. To translate IP addresses to a new block, the command is:

tcpreplay -ieth0-N1.1.1.1,1.255.255.255:10.1.1.1,10.255.255.255.255
/path/capture.pcap

IP addresses can also be changed pseudorandomly with the -s argument. This option is usually used with the -l (loop) argument to replay the packet capture with different IP addresses. Using different seed numbers, you get different pseudorandom sequences of IP addresses. The command to replay a packet capture 5000 times with different addresses is:

tcpreplay -ieth0-s600-l 5000/path/capture.pcap

Tip

The -N and -s arguments automatically enable the -F argument (fix checksums). All the packets have to be modified, so new checksums must be created.

Like the IP address, the source and destination ports can be changed. This is very useful to check whether an IPS or Firewall can be evaded by replaying an exploit on a different nonstandard port (e.g., an HTTP exploit on port 22). It can also be used to verify whether the device can recognize, for instance, HTTP traffic on less common ports such as 8080 and 8000). Several products, such as Oracle Web Server, run by default on a nonstandard port. If the IPS parses HTTP on port 80 only, a default configuration of these products would leave them unprotected.

To change a port number, use the −4 argument. It changes the source or destination port to the new value. A list of translations can be provided:

tcpreplay -ieth0−480:8080,81:7000 /path/capture.pcap

Warning

It is not possible to specify or replace only the destination or the source port. If the flow contains a connection to a privileged port, under 1024, the client source port is likely to be over 1024 whereas the destination port is under 1024. The preceding example assumes that 80 and 81 are destination ports.

By the way, the −4 argument also fixes checksums on all TCP/UDP packets.

tcpreplay can separate requests and replies on two physical interfaces, based on the IP address. This is used to test inline devices such as firewalls and IPSes. However, the disadvantage to testing inline devices that can block traffic is that tcpreplay does not reveal how many packets are received on each interface. If you sent packets on interface eth0, you do not know how many of them reached the second interface.

The second interface is specified with the -j argument. You can manually specify what source IP addresses should be replayed from the primary interface with the -C option:

tcpreplay -C192.168.0.0/24,10.0.0.0/24-ieth0-jeth1/path/capture.pcap

Tip

-C takes a list of IP address with a mask (0 to 32). The mask indicates the range of addresses to include around the IP address mentioned.

/32 is the equivalent of the netmask 255.255.255.255. 192.68.0.1/32 represents only the IP address 192.168.0.1.

/24 corresponds to the netmask 255.255.255.0. 192.168.0.0/24 contains all addresses from 192.168.0.0 to 192.168.0.255

Similar to how we used the -I and -k arguments to change the destination and source MAC address on the primary interface, we can use the -J and -K options for the secondary interface:

tcpreplay -C192.168.0.1/32-ieth0-j11:22:33:44:55:66 -k AA:BB:CC:DD:EE:FF-j
eth1 -J 66:55:44:33:22:11 -K FF:EE:DD:CC:BB:AA/path/capture.pcap

All other options apply to both interfaces.

Specifying the IP address in the command line is possible when the capture contains a few sessions and when only a few packet captures are replayed. But this requires too much time with large captures or with a large set of files. Fortunately, Tcpreplay comes with tcpprep, a tool to automate this process. tcpprep creates a file that identifies the IP addresses of client requests from the IP addresses of server replies. This file can then be used with tcpreplay.

Tip

Non-IP packets are sent as client traffic (secondary interface) by default. To send them as packets from the server, use the option -Nserver.

tcpprep can be used in auto-mode to separate client traffic (assigned to the secondary interface) from the server traffic (assigned to the primary interface). You must also specify what type of network tcprep should recreate:

Bridge

tcpprep tries to determine which machines are clients and which ones are servers. By default, if a machine opens twice more connections as server than clients, it is considered a server. The ratio can be modified with the -R option.

The bridge option is the only one that can cause tcpprep to give up when a system cannot be classified.

Client

Same as bridge, but unclassified machines are set to clients.

Server

Same as bridge, but unclassified systems are set as servers.

Router

tcpprep tries to build a list of subnetworks. Systems that cannot be classified with the ratio of connections are set as servers if they belong to a subnetwork that contains servers.

Port

The classification is done on the port number for UDP and TCP traffic.

The command to create a cache file for tcpreplay in client mode is:

tcpprep -a -nclient-i/path/capture.pcap-o/path/capture.pcap.cache

Sometimes tcpprep may wrongly classify a client as a server when used on packet captures that contain a large number of connections. To avoid this, it's possible to do a classification based on ports, providing better results with captures that contain only UDP and TCP traffic. If a destination port is under 1024, the destination is very likely to be a server. To help tcpprep with ports over 1024, you can provide a list of known server ports. This list should be in the same format as the Unix file /etc/services:

[...]
radius    1812/tcp
radius    1812/udp
nfs        2049/tcp
nfs        2049/udp
[...]

If you run tcpprep on a Unix or Linux system, you can point it directly to this file:

[julien@asus ˜] tcpprep -p -s/etc/services-i/path/capture.pcap-o/path/capture.pcap.cache
Parsing services...

Tip

A comment can be inserted into the cache file with the argument -C "Add a comment here". It can then be read with the -P option.

tcpprep can use the -c argument as tcpreplay uses -C, or it can match the source IP address against a regular expression to perform a manual classification. For example, tcpprep can classify all IP addresses starting with 10 or 192 and ending with 100 or more as belonging to a server and the others to clients:

tcpprep -r" (10|192)\.\d+\.\d+\.(1|2)\d\d" -i/path/capture.pcap-o
/path/capture.pcap.cache

The cache file can be used by tcpreplay with the -c option:

tcpreplay -c/path/capture.pcap.cache-ieth0-jeth1/path/capture.pcap

flowreplay is under heavy development, and it is not fully functional as of this writing. It is part of Tcpreplay version 3.x, and you must install it from source. flowreplay does not handle IP fragmentation, but it works well for simple cases.

flowreplay replays the TCP/UDP client side of a packet capture against a real server. To replay TCP traffic, the three-way handshake must be present. flowreplay replays layers 5-7, and the underlying layers are handled directly by the operating system, so the source port and sequence numbers are not the same as the original packet capture. I usually use it to reproduce an exploit captured previously against a different server.

The only mandatory argument, beside which packet capture to use, is the time when the server has sent all the data and flowreplay should send the next packet. The three modes for this are:

send

Sends the clients packets as fast as possible. It is the best mode to replay a denial of service against a real server.

bytes

Waits for the amount of bytes originally seen from the server in the packet capture before sending the next packet. This is the correct mode when the server is expected to send the same amount of data as seen in the packet capture.

Bytes mode does not work if the server sends less data because flowreplay waits indefinitely for more data, but it may work if the server sends more data. For example, if flowreplay replays an HTTP request against a web server, and the web server replied about 500 bytes of HTTP traffic, it will still work if the web server replies with less than 1,500 bytes as long as it is contained in one packet. There are other cases like this where flowreplay works well when the sever replays more data than in the original packet capture.

wait

Waits for a period of time specified with -wseconds.micro-seconds. This mode should be used when the amount of data sent back by the server may be very different from the original packet capture.

The command to replay a packet capture in bytes mode is:

flowreplay -msend/path/capture.pcap

flowreplay automatically determines who the client is and who the server is. But it is possible to help identify the IP addresses of the clients and the IP addresses of the servers with arguments similar to the -C option of tcpreplay. To identify client IP addresses, use this format:

-c 192.168.1.100/32,10.0.0.0/24

To identify server IP addresses, use this format:

-s 4.2.2.1/24, 208.10.10.1/24

It is also possible to replay traffic against another server by changing the target IP address with the -t argument:

flowreplay -msend-t10.0.0.1/path/capture.pcap

If the packet capture contains several sessions, you can specify to replay the traffic with a certain protocol and/or certain destination port only. To replay the traffic on TCP/80 only, type:

flowreplay -msend-ptcp/80/path/capture.pcap

Tomahawk is another open source tool that replays traffic. This section does not describe how to use it, but rather how it compares to tcpreplay. Tomahawk and its documentation can be downloaded from http://www.tomahawktesttool.org/.

Tomahawk was specifically designed to test the blocking ability of inline devices such as firewalls and IPSes. It requires two interfaces: one for the client traffic and one for the server traffic. Similar to tcpreplay, Tomahawk can automatically (or semi-automatically with hints from the user) separate both sides of the traffic from a packet capture.

The main difference with tcpreplay is that Tomahawk checks whether packets sent on one interface reach the second interface. It can resend a packet that did not go through the device after a specified timeout delay. It also ensures that packets are received in the same order that they are sent.

Tomahawk, like tcpreplay, can misclassify client traffic as being sent by the server, or the reverse. It also has trouble dealing with heavily fragmented traffic.

Although it has been used as a performance tool to test inline devices, Tomahawk was not designed for this and should not be used for testing performance.