TCPDump: A Simple Overview

Recall what you've read in earlier chapters. You learned about IP addressing, subnetting, and the headers of some of those core protocols. In this chapter the TCPDump tool will be examined and you will see some of those protocols up close and personal. Armed with an understanding of how to monitor your network at this level, you can be confident that you'll be able to troubleshoot a wide range of problems, not just those related to computer security.

An important tool in the intrusion analyst's toolkit is TCPDump. At a basic level, TCPDump is real-time packet capture and analysis software. This means that TCPDump can be used to eavesdrop on network communication as it travels through the network. As has already been mentioned, however, the amount of traffic that one can eavesdrop on is dictated by the network topology. If the computer from which TCPDump is running is connected to a switched network, TCPDump will see only traffic destined for that host or broadcast/multicast traffic. Because TCPDump (and libpcap) are so lightweight, there's really no reason they couldn't be installed onto as many computers as necessary. However, a better approach in a switched network would be to use a "span" port to which will be copied all network traffic by the switch itself. Of course, none of this is of concern in a hub-based network because all traffic is copied to all ports on the hub.

TCPDump places the network interface into promiscuous mode. Before you get too excited, consider that on busy interfaces this means that a huge amount of traffic will be flying past the screen, which has the potential to slow down the traffic ever so slightly. In any event, a large amount of traffic will be too much for a human to comprehend, so you'll want to capture the output to a file, pipe the output to a pager, or filter the traffic to look for something specific. Filtering through a TCPDump expression is by far the best option, but the choices are by no means mutually exclusive. I'll usually use a filter and a pager such as less, just in case something interesting flies past my screen too quickly.

TCPDump can filter traffic by virtually any criteria you can imagine. Most commonly for the intrusion analyst, you'll look at traffic by protocol, host, port number, or a combination thereof. Before I go further, I would be remiss if I didn't recommend reading or at least referring to the TCPDump(1) manual page (type man tcpdump to read it). The man page is a comprehensive document providing not only syntax but samples of use, as well as some protocol diagrams. If you get stuck trying to use TCPDump and you don't have a copy of this book handy, maybe you should buy two copies of the book. Alternatively, use the TCPDump man page for reference too.

Obtaining and Installing TCPDump

TCPDump can be downloaded from http://www.tcpdump.org/. TCPDump requires the PCap library libpcap, so while you're downloading TCPDump, you should download libpcap as well. Most popular Linux distributions such as SUSE also include TCPDump as an available package. For example, if you're using Debian you can simply type this:

 apt-get install tcpdump 

The package maintenance system will install TCPDump and any prerequisites too. For everyone else, you can probably search your distribution's repository for a package or just download the source and compile it, which I would recommend. TCPDump requires the PCap library, which is not usually installed on most systems. Whichever method you choose for installing TCPDump, you'll also need to grab the PCap library, sometimes referred to as libpcap. Both TCPDump and the PCap library can be downloaded from http://www.tcpdump.org/.

Should you attempt to compile TCPDump without having libpcap installed, you'll see an error similar to the following while running the configure script for TCPDump:

 checking for main in -lpcap... no configure: error: see the INSTALL doc for more info 

Installation of both libpcap and TCPDump is fairly straightforward as far as compiling software goes. Unarchive each piece of source code, run the configure script, compile, and install.

In essence:

 tar -zxvf libpcap-<version>.tar.gz cd libpcap-<version> ./configure make make install 

Do the same for TCPDump:

 tar -zxvf tcpdump-<version>.tar.gz cd tcpdump-<version> ./configure make make install 

Should you encounter problems while compiling the software, refer to previous chapters where the compile process is detailed further or, as an even better solution, practice your analyst skills by troubleshooting the error on the Internet. Chances are that someone else has encountered and solved the problem that you're working through.

TCPDump Options

TCPDump accepts a wide range of command-line options that alter its behavior, the amount of data captured, and the way in which the data is captured. Such a wide range of options means that you have the power to significantly change how the program operates. For TCPDump, you'll find that you frequently use a common set of options for most data capture activities, and you may not use others at all.

Some of the more commonly used options include those listed in Table 11.1.

Table 11.1. Some Common Options for TCPDump

OPTION	DESCRIPTION
-i <interface>	Specifies the interface to use.
-v	Produces output in verbose mode.
-vv	Produces output in really verbose mode.
-x	Causes TCPDump to print the packet itself in hexadecimal format.
-X	Causes TCPDump to also print the output in ASCII.
-n	Tells TCPDump not to perform DNS lookups for the IP addresses seen during the capture.
-F <file>	Reads the expression from <file>.
-D	Prints available interfaces.
-s <length>	Sets the length for each packet of the capture to <length>.

Examining each of these options in turn reveals the steps necessary for performing basic packet capture and analysis. Not all of these options are necessarily required to capture traffic with TCPDump (in fact, none of them is required). It's perfectly valid to simply type the tcpdump command on the command line to start capturing traffic. However, in practice many of these options are necessary to gain the level of detail needed in order to properly analyze the traffic.

The -i <interface> option changes the default interface on which TCPDump will listen for packets to capture. By default, TCPDump will listen on the first interface, eth0. However, for multihomed machines it may be necessary to use this option so that the correct traffic is captured. For example, on a firewall the eth0 interface might be connected to the internal network while the eth1 interface is connected to the Internet. You may be interested in seeing the traffic that's hitting your external interface (eth1); thus, you would use the -i <interface> option in TCPDump.

The verbose mode options, -v, -vv, and -vvv (not included in Table 11.1), cause TCPDump to print more (and more, and more) information about each packet received. With -v this information includes such important things as the TTL, packet ID, length, and options. Experimentation is usually necessary during a packet capture to determine which of these options will suit your needs. Different protocols may not have much (or any) additional information to print, so adding verbosity with these switches won't do any good.

The -x option causes TCPDump to also print hex dumps of each packet. For my eyes, this option isn't particularly helpful because I don't read hex so well. However, using the lowercase -x is required to take advantage of the ASCI dump of the packets that can be had by using the uppercase -X. Therefore, I'll rarely if ever use just -x and instead use both -x and -X. Although some parts of the packet may be printed by using just -X, using both can be helpful.

A sometimes-helpful option out of the most common options is the -s <length> option. Using this option is helpful to print the contents of packets themselves rather than the default 68 bytes only. If you're only interested in the headers of packets, this option won't be much, if any, use. However, if you'd like to peek inside the packet itself, this option will help to ensure that the packet capture isn't truncated.

An option that becomes more useful the more you use TCPDump is the -F <file> option. This option tells TCPDump to read the contents of <file> for the filter expression rather than reading the command line. This option is very handy for longer expressions or expressions that are used frequently (or even infrequently). After using TCPDump for a while, you may get tired of typing the same old filter expression to capture the same packets week after week. Storing that expression in a file and then reading the expression from the file when using TCPDump is a great way to save time.

When just starting out with TCPDump, an option that you may find useful is the -D option. The -D option informs TCPDump to print a list of interfaces on which you can perform the packet capture. Because packet captures are interface dependent, knowing which interface to use is the most important thing you will have to choose. In Linux, it's somewhat easier to choose the right interface because interface names are usually simple, like eth0 for the first Ethernet card. However, in Windows, -D is much more important because interface names can be quite difficult to remember.

A final option worth noting is the -n option. Using -n tells TCPDump not to perform reverse DNS lookups on the hosts as it sees them during the capture. Doing reverse lookups frequently slows down packet capture and naturally also increases the amount of traffic. Therefore, adding -n is helpful for speeding up the capture as well as reducing the signal-to-noise ratio. When I forget to set the -n option, I sometimes find myself asking, "Why is this machine performing DNS lookups?" only to realize that the lookups are the result of my packet capture activity.

TCPDump Expressions

Now the fun begins. By default, TCPDump will capture and output every packet that hits the interface. Sometimes this is useful for quickly listening to some traffic on a quiet interface. However, most captures will make use of expressions in TCPDump. A TCPDump expression is a collection of criteria for network traffic that you'd like to view with TCPDump. Expressions consist of one or more qualifiers and possibly a primitive, both of which are discussed in the following subsections. An expression might be used to capture only traffic that originates from a certain host or that is destined for a certain host. The possibilities with expressions and combinations of expressions give you the ability to hone in on exactly the packets you need to see to assess a given network situation.

One of the more powerful features of expressions is the capability to negate. For instance, if you want to listen to all traffic except network traffic on port 80 (usually http traffic), you could have TCPDump capture all traffic except that which is transmitted or received on port 80. TCPDump can also use other logical terms as well, such as AND, OR, and the already mentioned negation keyword NOT.

TCPDump expressions are enclosed within single quotes (') and can be grouped together by enclosing the various parts of a given expression within parentheses. This means that you can combine multiple expressions to capture only that traffic that is of interest. The key to grouping expressions together is the use of the logical terms AND, OR, and NOT. TCPDump has three qualifiers, each of which is introduced in turn in the discussion that follows. The first kind of qualifier is the type qualifier.

TCPDUMP'S TYPE QUALIFIER

Just as TCPDump has three kinds of qualifiers, the type qualifier itself contains three variations: host, port, and net. The host qualifier is used to specify the host or destination of interesting traffic. The port type qualifier is not surprisingly used to specify the port on which to capture packets. The net type is used to specify the subnet for interesting traffic. You could use the net qualifier in an expression to listen for traffic on an entire range of addresses. Of course, there are times when you don't want to listen to an entire range of addresses. TCPDump also accepts the modifier mask with the net qualifier to specify the subnet mask. You can also use CIDR notation to specify the mask bits.

Before I go further, here's an example of a TCPDump expression to capture traffic on port 80:

 tcpdump 'port 80' 

Because this expression uses only a single criterion (port 80) there's no need to enclose it within parentheses. If, however, the goal was to capture traffic on port 80 with a source or destination of one or more specific hosts, say 192.168.1.10 and 192.168.1.11, then parentheses would be required, as in this example:

 tcpdump 'port 80 and (host 192.168.1.10 or host 192.168.1.11)' 

Parentheses are required only for logical grouping. In practice, you'll suffer no penalty for using them, and truthfully I normally use them just out of habit. When writing the preceding simple port 80 example, I included the parentheses at first only to go back and remove them after I thought about what I was doing. Old habits die hard. Speaking of unnecessary terms, the term host in the example isn't required eithermore on that later.

Here are some examples using the net type qualifier to listen for traffic:

 tcpdump 'net 192.168.1' 

Here's that same example using CIDR notation:

 tcpdump 'net 192.168.1.0/24' 

And finally, here's that same example using the mask modifier:

 tcpdump 'net 192.168.1.0 mask 255.255.255.0' 

If you fail to specify a type qualifier (host, net, port) within a TCPDump expression, the host type is assumed. Therefore, don't be surprised when you receive a "parse error" when attempting something like this:

 tcpdump '80' 

Really, you probably wanted to have TCPDump listen for traffic on port 80:

 tcpdump 'port 80' 

TCPDUMP'S DIRECTION QUALIFIER

Another kind of qualifier within a TCPDump expression is the direction qualifier. The previous examples will look for traffic flowing in either direction, coming or going, on port 80 for instance. For example, this might mean that traffic destined for a web server running at 192.168.1.10 will be captured but so will traffic leaving the computer at 192.168.1.10 and destined for another server on port 80. You can also specify the direction with which to capture traffic by using a direction qualifier. The terms src for the source and dst for the destination are the two direction qualifiers used by TCPDump. Adding the destination term to one of the previous examples yields an expression that will look for port 80 traffic going to 192.168.1.10 or 192.168.1.11:

 tcpdump 'port 80 and (src 192.168.1.10 or src 192.168.1.11)' 

The direction qualifier isn't limited to looking for traffic on certain addresses. It's perfectly valid to look for traffic with a source or destination of a specific port, as in this example that looks for traffic with a destination of port 25 (usually SMTP):

 tcpdump 'dst port 25' 

Some protocols use the terms inbound and outbound to specify the direction. See the TCPDump man page for more details.

TCPDUMP'S PROTOCOL QUALIFIER

A final kind of qualifier for use in a TCPDump expression is the protocol qualifier. Not surprisingly, protocol qualifiers enable you to choose which protocols should be captured with TCPDump. The protocols that can be captured with TCPDump include, among others, Ethernet (abbreviated ether for TCPDump syntax), TCP, UDP, ICMP, IP, IPv6 (abbreviated ip6 for TCPDump syntax), ARP, reverse ARP (abbreviated to rarp), and more.

PRIMITIVES

Aside from the main three qualifiers (type, direction, and protocol), there are also what are known as primitives for use in TCPDump expressions. Primitives are keywords that help to specify additional parameters for the packet capture. The primitives for use with TCPDump include these:

• Arithmetic operators

• broadcast

• gateway

• greater

• less

The arithmetic operators include +, -, *, /, >, <, >=, <=, =, !=, and a few others. TCPDump can use quite complex arithmetic operators and packet offsets to look into packets. I'd prefer to leave it as an exercise for the reader to dive into these areas should you find it necessary to do so.

The broadcast primitive, when prepended with either ip or ether, will look for packets that are IP or Ethernet broadcasts respectively, though ether is the default type to look for. For example, a TCPDump expression looking for ip broadcast will search for broadcasts on an IP network. However, if the interface card on which TCPDump is listening has no subnet mask or if the any interface is being used, this broadcast primitive will not work.

The primitives greater and less are used to search for packets with a length greater than or equal to or less than or equal to the given length. These primitives are functionally equivalent to using the arithmetic operators for the same. So for example, the syntax

 len >= 1500 

is equivalent to this:

 greater 1500 

Beyond the Basics with TCPDump

You should now have a feel for the basic syntax of TCPDump, including some of the options, the syntax, and TCPDump expressions. The amount of troubleshooting and diagnosis that can be accomplished with even a basic grasp of TCPDump syntax makes it an essential tool for anyone managing networked computers. However, even a basic knowledge of TCPDump is sometimes insufficient to examine some problems successfully. To examine more difficult problems, you may find that you need to go beyond the basics of TCPDump.

Going beyond the basics of TCPDump requires deeper understanding of the protocols themselves. Knowing the flags of TCP or the types of ICMP can help to narrow the focus to only the packets of interest. Although this information and knowing how to use it with TCPDump is not mandatory, having the ability to call on the information at any time is valuable to say the least. Take time to familiarize yourself with TCPDump's more involved syntax. It costs nothing but time to test a packet-filtering expression to see how it works under various network conditions.