Tcpdump and WinDump
|
| < Day Day Up > |
|
Downloadable from http://www.tcpdump.org, tcpdump is a highly configurable, command-line packet sniffer for Unix. WinDump is tcpdump’s Windows counterpart. It can be found at http://windump.polito.it/ and has almost the exact same functionality as tcpdump. Whereas BUTTSniffer was originally intended as a hacker’s plug-in to eavesdrop on a system you already own, tcpdump was made strictly for network monitoring, traffic analysis and testing, and packet interception.
Tcpdump/WinDump is more of a network packet analyzer than a sniffer. Its filtering capabilities are superior to many other tools out there, but it doesn’t necessarily make it easy for you to capture packet data. It does let you obtain a lot of interesting low-level information about the packets passing on your network, and it can help you diagnose all kinds of network problems.
Installation
Tcpdump and WinDump both use the pcap library, a set of packet capture routines written by the Lawrence Berkeley National Laboratory. The pcap routines provide the interface and functionality for OS-level packet filtering and disassembling IP packets into raw data.
Installing Tcpdump (and Libpcap) on Unix
First, you’ll need to download and install libpcap if you don’t have it. Libpcap is a system-independent interface to kernel-level packet filters. If you’re uncertain whether you have libpcap installed, try installing tcpdump; it will tell you if libpcap is not on your system. You can also retrieve libpcap from http://www.tcpdump.org. Libpcap works only if your system uses a kernel-level packet filtering mechanism that it can recognize. Linux has its own built-in “packet” protocol that libpcap recognizes and works with, assuming your Linux kernel has been compiled with the proper options. BSD (Berkeley Software Distribution) variants and other Unix operating systems use BPF (Berkeley Packet Filtering).
After you’ve downloaded libpcap and untarred it, run the configure script. Look for a line that says “checking packet capture type” to find out what mechanism your system uses. If libpcap doesn’t recognize your packet filter, you’ll have to refer to the included documentation to determine how to fix this problem. Otherwise, you can continue to install libpcap just as you would any other Unix source (make and make install). After libpcap is installed, tcpdump can be installed in a similar manner.
Installing WinDump (and WinPcap) on Windows
As with Unix, you’ll need to install the pcap library before installing WinDump (and WinPcap) on Windows. WinPcap and WinDump now work with Windows 9x, Me, NT, 200x, and XP. The package comes in a single executable and can be downloaded from http://winpcap.polito.it/. WinPcap has no install options and installs in about five seconds.
Now all you have to do is head to http://windump.polito.it/ and download windump.exe. You’re ready to go.
Implementation
Because WinDump is simply a Windows port of tcpdump, the usage of tcpdump and WinDump are nearly interchangeable. Throughout the chapter, we will focus on tcpdump, noting any differences between WinDump and tcpdump as we go. In general, if you’re playing along at home, you can substitute WinDump for tcpdump.
The first thing to keep in mind is that tcpdump usually requires root access. It either needs to be run as root or setuid root. This level of access is necessary for tcpdump and libpcap to have such low-level (that is, kernel-level) access to the network interfaces and network data. This also keeps “Joe User” from setting up a packet sniffer for inappropriate use. Some Unix systems require more or less access than others—see the man page or README file for full details.
| Note | Security of WinDump/WinPcap is a bit more lax than that of tcpdump/libpcap. When WinDump runs, it attempts to load the WinPcap DLL if it is not already running. Only someone with Administrator privileges can load this DLL. However, once WinPcap is running, any user can use it from that point on until the system is rebooted or the Netgroup Packet Filter service is stopped. |
Another reason libpcap and WinPcap users need low-level access is because, by default, these sniffers put the network interface on which they’re operating into promiscuous mode. If you remember our discussion at the beginning of the chapter, some network devices such as Ethernet hubs will actually broadcast a packet to all ports on the hub, looking for the rightful recipient to step up and accept the packet. The other hosts connected to the hub receive this packet as well, but they are supposed to ignore it. Promiscuous mode tells the interface to be nosey, and it allows tcpdump to see all network traffic on the hub—not just traffic directed to or from the host. The same goes if you were running tcpdump on a router or a firewall. If the interface isn’t in promiscuous mode, you see only traffic directed specifically to the router. But if we put the interface in promiscuous mode, we can sniff every packet that passes through. Many organizations will run packet sniffers off their main routers to the Internet for monitoring purposes.
We should be ready to run the application now. If you simply type tcpdump at the command prompt, tcpdump will attempt to listen on the first available network interface (or all interfaces, if possible) and spit out all the data it sees. Depending on how busy your system is, or if it’s connected to a hub or a switch monitor port, you may see loads of text scroll past. You may notice that tcpdump seems to display only the hosts involved in the network transaction, a timestamp, and some other IP data. But where are the packet contents? Obviously, you’re going to need to learn more about this tool to get it to tell you a little more.
Tcpdump is a powerful tool—with no user-friendly interface. Like Netcat, nmap, and other extremely useful command-line tools we’ve covered, tcpdump becomes useful only after you master the command-line options and syntax.
Command-Line Syntax: Specifying Filters
Tcpdump lets you use a Boolean expression to specify a packet filter using the Berkeley Packet Filter (BPF) mechanism. The Boolean expression can consist of several expressions joined together with AND, OR, or NOT. The typical format of an expression is
<packet characteristic> <value>
Type Qualifiers The most typical packet characteristics (called qualifiers) are the type qualifiers: host, net, and port. For example, the command line
# tcpdump host 192.168.1.100
tells us that we want to see only packets to or from 192.168.1.100. If all we care about is web traffic, we can try this:
# tcpdump host 192.168.1.100 and port 80
This expression lets us have the same level of filter functionality we had with BUTTSniffer. But tcpdump has several more modifiers from which you can choose. And here, we don’t have to exclude all other traffic first to focus on a particular host.
Directional Qualifiers Tcpdump lets you specify directional filters. For example, if we care about only traffic coming from 192.168.1.100 that is destined to somebody’s web port, we use the directional qualifiers src and dst:
# tcpdump src host 192.168.1.100 and dst port 80
This filter gets us exactly what we’re looking for. Otherwise, we might see traffic coming in from other places to 192.168.1.100’s web server when we didn’t care about that at all.
If you do not specify a directional qualifier for your type qualifier, tcpdump assumes src or dst. The second command we looked at could be rewritten like this:
# tcpdump src or dst host 192.168.1.100 and src or dst port 80
| Note | For Point-to-Point Protocols, such as the dial-up protocols Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP), tcpdump uses the direction qualifiers inbound and outbound instead. |
Protocol Qualifiers Tcpdump also has protocol qualifiers that can be applied to your expression. For example, this line
# tcpdump src host 192.168.1.100 and udp dst port 53
will give us outgoing Domain Name System (DNS) queries from 192.168.1.100. Notice the udp protocol qualifier in front of the dst port qualifier. Other protocol qualifiers for port type qualifiers are tcp and icmp. Some protocol qualifiers are used on host type qualifiers such as ip, ip6, arp, and ether.
This command gives us all the arp requests on our local subnet:
# tcpdump arp net 192.168.1
If we know the MAC address of a particular host and we want to filter on that, we can use
# tcpdump ether host 00:e0:29:38:b4:67
If no protocol qualifiers are given, tcpdump assumes ip or arp or rarp for host type qualifiers and tcp or udp for port type qualifiers.
Other Qualifiers So far, the syntax for a single packet-matching expression looks like this:
[protocol qualifier] [directional qualifier] <type qualifier> <value>
A few more optional qualifiers can be used to specify additional packet matching characteristics, as shown in Table 16-1.
| Qualifier | Description | Examples |
|---|---|---|
| gateway | Display only packets that use router1 as a gateway. The value used with gateway must be a hostname, as the expression needs to resolve the hostname to an IP (using /etc/hosts or DNS) as well as an Ethernet address (using /etc/ethers). | tcpdump gateway router1 (To use straight IP and MAC addresses, use tcpdump ether host <mac_of_gateway> and not ip host <ip_of_gateway>, which is equivalent to using the gateway filter but with addresses instead of hostnames.) |
| broadcast, multicast | broadcast displays only packets that are broadcast packets (in this case, packets with a destination of 192.168.1.0 or 192.168.1.255). multicast displays only IP multicast packets. | tcpdump ip broadcast net 192.168.1 |
| proto | This useful qualifier allows you to specify subprotocols of a particular protocol, even if tcpdump doesn't have a built-in keyword for it. Protocol names must be escaped using backslashes to keep tcpdump from interpreting them as keywords, but you can also use protocol numbers here. Some popular IP subprotocol numbers are 1 (ICMP), 6 (TCP), and 17 (UDP). | tcpdump ip proto 17 (The expression ip host 192.168.1.100 and tcp port 80 could be written ether proto \\ip and host 192.168.1.100 and ip proto \\tcp and port 80. Notice how the protocol modifier in each case gets expanded to <protocol> proto <sub-protocol>.) |
| mask | This qualifier can specify a subnet mask for net type qualifiers. It is rarely used, because you can specify the netmask in the value for the net type qualifier. | tcpdump net 192.168.1.0 mask 255.255.255.0 (Or alternatively tcpdump net 192.168.1.0/24) |
| len, greater,less | Packets can be filtered on their size. The greater and less qualifiers are simply shorthand for length expressions that use the len keyword. Both examples show only packets that are 80 bytes or larger. | tcpdump greater 80 and |
| Packet content expressions | For advanced users. You can match packets based on their contents. Take a protocol name (such as ether, ip, or tcp), followed by the byte offset and size of the desired header value in brackets, followed by a Boolean operator and another expression. Note that most expressions need to be enclosed in quotation marks because the shell you're using will probably try to interpret them before tcpdump does. | tcpdump 'udp[4:2] = 24' Referencing Appendix A, you'll notice that byte 4 of a UDP header refers to the “length” of the packet. You'll also notice that the “length” value is 16 bits or 2 bytes long. Therefore, the above expression looks at the value in the two bytes 4 and 5 (the “length”), and matches only packets with a value of 24. |
Values Obviously, the values for the qualifiers depend on the qualifier used. In general, the value will be either a symbolic name or a corresponding number:
-
host type qualifiers have values of hostnames or numeric addresses. (Whether they’re IP addresses, MAC addresses, or other addresses depends on the protocol qualifier preceding them.)
-
port type qualifiers use symbolic names (from /etc/services) for ports or the port numbers themselves.
-
net type qualifiers use network addresses and network masks written either with only the network octets (such as 192.168), with a network followed by the number of network bytes (192.168.0.0/16), or with a network followed by a netmask (192.168.0.0 mask 255.255.0.0).
-
proto type qualifiers use symbolic names (ip, tcp, udp) or protocol numbers defined in /etc/protocols.
| Note | Because Windows has no /etc directory, WinDump uses hosts and services files that are installed in the Windows root directory (for example, C:\Windows\) for Windows 9x systems and C:\Windows\System32\Drivers\Etc for current Windows systems. |
Command-Line Flags: Formatting Output and Toggling Options
Now let’s move on to a description of the more important flags and options described in Table 16-2.
| Option | Explanation |
|---|---|
| -a | Resolves IP addresses to hostnames. |
| -c <num> | Sniffs until we've received <num> packets, and then exits. |
| -C <file_size> | If you're using –w to write captured packets to a file, you can use –C to limit the size of that file. For example, tcpdump –w capture.dat –C 20 would write the first 20 million bytes of data to capture.dat, the next 20 million bytes to capture.dat.2, and so on. |
| -d, -dd, -ddd | Takes the filter you specify on the command line and, instead of sniffing, outputs the packet matching code for that filter in compiled assembly code, a C program fragment, or a decimal representation, respectively. Used mainly for debugging and rarely useful to beginner and intermediate users. |
| -e | Displays the link-level header. For example, if you're on an Ethernet network, you can display the Ethernet headers of your packets. Useful if you're interested in the lower level networking details of a particular part of traffic (such as determining the MAC address of another machine). |
| -E <algo:secret> | Attempt to decrypt sniffed IPSEC packets using the encryption algorithm algo and the ESP secret secret. This works only if tcpdump is compiled with cryptography and is not recommended in production environments, as providing an ESP secret on the command line is usually a bad idea. |
| -F <file> | Specifies your filter expression from a file instead of on the command line. |
| -i | Listens on a particular interface. With Unix, you can use ifconfig to see the available network interfaces. With Windows, you can use windump –D to find the interface number that corresponds to the network interface in which you're interested. |
| -l | Has tcpdump's standard output use line buffering so that you can page through the output. Without this option, output redirection will keep any output from being written until tcpdump exits. |
| -n | Does not resolve IP addresses to hostnames. |
| -N | Suppresses printing of the FQDN (fully qualified domain name) of the host—use only the hostname. |
| -O | Suppresses the packet matching code optimizer. You can use this if it appears that the packet filter you feed to tcpdump is missing packets or includes packets that should be filtered out. |
| -p | Tells tcpdump not to put the network interface in promiscuous mode. Useful if you're interested in sniffing only local traffic (that is, traffic to and from the machine you're using). |
| -q | Tells tcpdump not to print as much packet header information. You lose a lot of the nitty-gritty details, but you still see the timestamp and hosts involved. |
| -r <file> | Tcpdump can write its output to a binary file (see -w). This tells tcpdump to read that file and display its output. Since tcpdump captures the raw data based on the packet filter you specify on the command line, you can use –r to reread the packet capture data and use output formatting command-line flags after the fact (-n, -l, -e, and -X) to display the output in a variety of ways. |
| -s <bytes> | Specifies how many bytes per packet tcpdump should try to “snarf.” The default is 68. Making this value too high can cause tcpdump to miss packets. |
| -S | Tells tcpdump to print absolute TCP sequence numbers. The default is to use relative sequence numbers so that you can see by how many bytes the sequence number changes between packets over the time of a TCP connection. Using absolute numbers means that you'll have to do the math yourself. |
| -t, -tt, -ttt | Tells tcpdump not to print a timestamp at all, print an unformatted timestamp (the number of seconds since the epoch, January 1, 1970), or print the change in time (in micro-seconds) between output lines, respectively. |
| -T <type> | Tcpdump can natively interpret some other IP protocols and display appropriately formatted output on them, such as DHCP, DNS, NBT, and ARP. Tells tcpdump to interpret specifically the selected packets as a particular protocol type, such as RPC or SNMP. |
| -v, -vv, -vvv | Controls tcpdump's level of verbosity. The more vs you have, the more information you'll get and the more interpretation tcpdump will do. |
| -w <file> | Don't translate the packet capture data into human-readable format—write it to a binary file called <file>. Useful if you've captured data and want to use tcpdump or another tool such as Ethereal to view it later in different ways (see -r). Since it isn't translating the data to a human-readable format, it makes tcpdump more efficient and less likely to miss packets. Useful on a system with an extremely large volume of traffic. |
| -x | Displays the packet in hex. Sit down with the output of this command and a TCP/IP book if you want to learn more about TCP headers and things of that nature. This is an advanced feature that can help you sniff out packets that might have data hidden in the IP options or other packet mangling. |
| -X | Similar to the hex option, but it also displays the contents of the packet in ASCII, letting us see any clear-text character data contained within the packet. This is where you might be able to sniff usernames, passwords, and other interesting information floating around the Net. |
Tcpdump Output
In the man page for tcpdump, the output section is probably one of the largest sections. Because tcpdump tries to interpret some protocols differently, the actual output of tcpdump will also vary depending on the options you feed it and the type of packets you’re filtering. We can’t cover everything here, but we’ll take a look at some basic tcpdump output and talk about what it means.
Here is tcpdump output with no options:
20:11:28.527191 eth0 B somehost.netbios-ns > 192.168.1.255.netbios-ns:NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 20:11:28.531361 eth0 > arp who-has 192.168.1.1 tell originix (0:e0:29:38:b4:67) 20:11:28.531939 eth0 < arp reply 192.168.1.1 is-at 0:4:5a:e3:44:a3 (0:e0:29:38:b4:67) 20:11:28.531994 eth0 > originix.1024 > ns01.domain: 49930+ PTR? 255.1.168.192.in-addr.arpa. (44) 20:11:28.630838 eth0 < ns01.domain > originix.1024: 49930 NXDomain* 0/1/0 (116) (DF) 20:11:28.632600 eth0 > originix.1024 > ns01.domain: 49931+ PTR? 1.1.168.192.in-addr.arpa. (42) 20:11:28.655958 eth0 < ns01.domain > originix.1024: 49931 NXDomain 0/1/0 (114) (DF) 20:11:28.657685 eth0 > originix.1024 > ns01.domain: 49932+ PTR? 150.1.1.10.in-addr.arpa. (41) 20:11:28.668566 eth0 < ns01.domain > originix.1024: 49932 1/2/2 PTR ns01. (162) (DF) 20:11:29.277025 eth0 B somehost.netbios-ns > 192.168.1.255.netbios-ns:NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
Let’s first focus on a single line. The first value is a timestamp for the packet. Notice that the default format does not include a date. The next bit of information is the interface on which this packet was collected (eth0). After the interface, we see <, >, or B. This indicates whether the packet was incoming, outgoing, or broadcast. Next we see the hostnames or IP addresses followed by a dot and the port name or number. The greater-than sign (>) indicates that the source host and port will always be on the left and the destination host and port will always be on the right.
The first packet is recognized as a NetBIOS over TCP (NBT) packet. Because tcpdump can interpret some of the information about the packet, it tells you that “somehost” was performing a NetBIOS broadcast query, probably trying to look up a hostname for an IP address on the network.
The second packet appears to be an Address Resolution Protocol (ARP) request. ARP maps IP addresses to Ethernet MAC addresses and vice versa. Originix sends out an ARP request asking for the MAC address of 192.168.1.1 (conceivably, its gateway). On the next line, the gateway responds with its MAC address. Now the two Ethernet adapters can talk to each other on the Data Link layer. This is a necessary step before any IP communication can take place.
The fourth and following lines contain what appear to be DNS traffic. Originix is making a request to ns01 on the “domain” port 53. Because tcpdump can also interpret DNS packets, it attempts to provide information about the actual packet contents, including the type of query and the address being queried. First it appears to perform a reverse lookup on the broadcast address (192.168.1.255), then it tries a reverse lookup on 192.168.1.1, and finally it tries to resolve 10.1.1.150. It fails on the first two, receiving a “NXDomain” or “non-existent domain” message from the DNS server. But 10.1.1.150 does successfully resolve to ns01, which is the name server itself.
That was a sampling of some of the packets tcpdump can interpret natively. Other packets, like normal telnet or SSH traffic, will just display information about the packets, and nothing more.
20:28:48.375504 eth0 < somehost.2765 > originix.ssh: P 13024:13068(44) ack 42597 win 64695 (DF) 20:28:48.375574 eth0 > originix.ssh > somehost.2765: P 42597:42877(280) ack 13068 win 32120 (DF) 20:28:48.377010 eth0 < somehost.2765 > originix.ssh: P 13068:13200(132) ack 42877 win 64415 (DF) 20:28:48.377081 eth0 > originix.ssh > somehost.2765: P 42877:43157(280) ack 13200 win 32120 (DF)
Here we’ve caught the middle of an SSH session between originix and somehost. We can see that the push flag, P, is set. We can also see the size of the packets, as it displays the relative TCP sequence number, followed by the next expected sequence number and the size of the packet (13024:13068(44)). Notice how the second line says ack 13068. It appears to be acknowledging receipt of the previous packet by acknowledging that the next sequence number it expects is 13068. On the third line, that’s exactly what somehost sends us. The TCP window size (the largest amount of data it can handle) is advertised by the host in each packet, and in this example, the “don’t fragment” bit is set to keep the packet from being broken up. Watching TCP traffic in this way can be extremely helpful in learning how the protocol works.
You can learn a lot about the inner workings of TCP by running tcpdump and watching what happens when you start a telnet session. Check this out:
20:30:58.635657 eth0 < somehost.2910 > originix.telnet: S 213111209:213111209(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) 20:30:58.636019 eth0 > originix.telnet > somehost.2910: S 1513461939:1513461939(0) ack 213111210 win 32120 <mss 1460,nop,nop,sackOK> (DF) 20:30:58.636659 eth0 < somehost.2910 > originix.telnet: . 1:1(0) ack 1 win 65535 (DF) 20:30:58.639213 eth0 < somehost.2910 > originix.telnet: P 1:4(3) ack 1 win 65535 (DF)
This is what tcpdump shows us when it sees a telnet connection. Notice how the first two lines are different from the packets we were viewing in the SSH session. This packet begins a connection. We can tell because the S (SYN) flag is set. We also see that the sequence numbers in the first two lines are much larger. That’s because tcpdump uses the actual TCP sequence numbers (32-bit values ranging from 0 to 4294967295) during the initial part of a TCP connection. For the rest of the connection it defaults to using relative sequence numbers so that it’s easier to see the changes as packets go back and forth. We also see some TCP options negotiated during the three-way handshake (mss1460,nop,nop,sackOK). After the three-way handshake and option negotiation take place, somehost begins sending data (3 bytes worth).
Using BUTTSniffer, we were able to see the login process from a telnet session. We can do that with tcpdump by using the -X option to display packet contents in ASCII. However, because this option displays the packet headers as well as the data, it’s difficult to locate what we’re looking for. A telnet session is particularly difficult to sniff using tcpdump because a packet is sent for every character we type. It can be difficult to piece these together manually. But any client that keeps user and password information in memory and then sends it together all at once in a packet (such as a web transaction over HTTP or an FTP login) can still be easily sniffed this way.
Let’s try sniffing an FTP session with the command tcpdump -X dst port 21. Because FTP uses the USER and PASS commands to send username and passwords, we have to search for output containing those commands:
20:51:06.697724 somehost.2937 > originix.ftp: P 0:10(10) ack 84 win 65452 (DF) 0x0000 4500 0032 5bd4 4000 8006 1ad8 c0a8 0165 E..2[.@........e 0x0010 c0a8 0164 0b79 0015 0cc6 3325 a621 9a45 ...d.y....3%.!.E 0x0020 5018 ffac 68a7 0000 5553 4552 2062 6f62 P...h...USER.bob 0x0030 0d0a .. 20:51:06.893543 somehost.2937 > originix.ftp: . ack 116 win 65420 (DF) 0x0000 4500 0028 5fd4 4000 8006 16e2 c0a8 0165 E..(_.@........e 0x0010 c0a8 0164 0b79 0015 0cc6 332f a621 9a65 ...d.y....3/.!.e 0x0020 5010 ff8c a023 0000 0000 0000 0000 P....#........ 20:51:10.828077 somehost.2937 > originix.ftp: P 10:23(13) ack 116 win 65420 (DF) 0x0000 4500 0035 64d4 4000 8006 11d5 c0a8 0165 E..5d.@........e 0x0010 c0a8 0164 0b79 0015 0cc6 332f a621 9a65 ...d.y....3/.!.e 0x0020 5018 ff8c fe75 0000 5041 5353 2062 6f62 P....u..PASS.bob 0x0030 3132 330d 0a 123..
By filtering only traffic destined for port 21 and using the -X option, we can easily discover FTP login information. Here’s bob again, logging in to the FTP server on originix with the password bob123.
Advanced Examples
In Table 16-1, we briefly mentioned packet content expressions. This is an extremely powerful part of the tcpdump tool, but it requires knowledge of protocol headers and binary mathematics. We’ll show you a few advanced examples here to get you started. If you need to reference the layout of a particular protocol header, the Ethernet, ARP, ICMP, IP, TCP, and UDP header diagrams are all located in Appendix A of this book.
In Table 16-1, the packet content example we gave involved checking the length of a UDP packet recorded in its header. The length, or size of the packet, can tell us how much data the packet contains. If you remember from Chapter 4, some UDP scanners will send 0 or 1 byte UDP packets as part of their scan. We can use tcpdump to look for those kinds of packets. A UDP packet will always have a length of at least 8, as the header is always 8 bytes long. So, we want to look for UDP packets with a length of either 8 or 9 bytes.
# tcpdump 'udp[4:2]=8 or udp[4:2]=9'
This command will show us all UDP packets with either 0 or 1 data byte. What does the udp[4:2] mean? The numbers inside the brackets indicate that we’re interested in the value of 2 bytes starting at byte offset 4. If you look at the UDP header diagram in Appendix A, you’ll see that offset 0x00 (byte 0) is the beginning of the UDP source port, and the source port fills up 16 bits (or 2 bytes, bytes 0 and 1). Offset 0x02 (byte 2) is the beginning of the UDP destination port, and the destination port also fills up 16 bits (bytes 2 and 3). Offset 0x04 (byte 4) is the beginning of the UDP length—the characteristic we want. It also fills up 16 bits or 2 bytes (bytes 4 and 5). By specifying the starting byte offset, followed by a colon and the number of bytes to examine, we can extract the value from the header and use mathematical operations to compare it with a desired value.
Let’s look at another example. If we were interested only in monitoring initial TCP connection attempts from a particular host (192.168.1.100), how would we do it? Well, we know that all TCP packets that begin a connection have the SYN flag set. So how do we set up a packet content expression that shows us only packets with the SYN flag set?
# tcpdump 'tcp[13] & 2 = 2 and host 192.168.1.100'
This example requires a little binary mathematics. This time, we’re examining offset 0x0d (byte 13) of the TCP header. If you look carefully, you’ll see that byte 13 consists of 2 reserved bits and 6 flag bits. We’re interested only in one particular bit: the SYN bit. How can we tell if this bit is set?
First, in case you don’t have experience with binary numbers, we’ll give you as much as you need to know for our example (though we recommend you research the subject on your own for a better understanding). Table 16-3 shows the first eight binary numbers and their decimal equivalents.
| Binary Representation | Corresponding Decimal Number |
|---|---|
| 000 | 0 |
| 001 | 1 |
| 010 | 2 |
| 011 | 3 |
| 100 | 4 |
| 101 | 5 |
| 110 | 6 |
| 111 | 7 |
The first eight decimal numbers (0 through 7) can be represented using three binary digits, or 3 bits. If you use eight binary digits, or 8 bits (1 byte), you can represent the first 256 decimal numbers. The number 6 can be represented using 3 bits (110), but it can also be represented using 8 bits (00000110).
Let’s examine each of the 8 bits in byte 13. What would those bits look like if only the SYN flag was set? Since the SYN flag is the second least significant bit, it would look like 00000010. If we ignore the leading zeroes and refer to Table 16-3, we’ll see that the decimal value of this byte is 2. So if only the SYN flag is set, byte 13 should have a decimal value of 2.
We could use a simple equals (=) comparison between tcp[13] and the number 2, but what if some other flag is set? What if one of the two reserved bits on the most significant end of byte 13 have been set? Wouldn’t it be nice to see SYN/ACK packets as well as SYN packets, so we’ll know which connections actually got answered? If both the SYN and ACK flags are set, byte 13 will look like 00010010, giving it a decimal value of 18. An equals comparison won’t catch SYN/ACK packets.
What we need is the binary AND operator (&). The AND operator does a comparison of each individual bit in the two values. If the two bits are both set (have a value of 1), it returns a 1 for that bit (1 & 1 = 1). Any other combination of bits (0 & 0, 1 & 0, or 0 & 1) will all return 0 for that bit. In other words, the AND operation will return a 1 for a bit only if it is set in both the left and the right values.
Let’s say byte 13 has only the SYN flag set (00000010). If we AND tcp[13] with the number 2, it expands to this:
00000010 & 00000010 = 00000010
Because the two bytes are the same, the resulting comparison will yield 00000010, or a value of 2. What if both the SYN and ACK flags are set (00010010) in byte 13? If we AND tcp[13] with the number 2, it expands to
00010010 & 00000010 = 00000010
This comparison also yields 00000010 because even though the ACK bit of tcp[13] is set, the same bit on the right side is not set, so AND returns a 0 for that particular bit. What if byte 13 only had the ACK bit set? If we AND tcp[13] with the number 2, it expands to this:
00010000 & 00000010 = 00000000
Here, none of the set bits line up, so the comparison yields all zeroes.
What have we discovered? If we AND tcp[13] with the number 2 and tcp[13] has the SYN bit set, the comparison will always return 00000010 (or the number 2). If the SYN bit is not set, the comparison will always return 0. Therefore, we can use either of the following two packet content expressions to look for TCP packets to or from 192.168.1.100 with the SYN flag set:
# tcpdump 'tcp[13] & 2 = 2 and host 192.168.1.100'
or
# tcpdump 'tcp[13] & 2 != 0 and host 192.168.1.100'
What if we wanted to see both the beginning and end of a connection? We could make a slight modification to our expression. In this scenario, we’d be looking for packets that had either the SYN or FIN flag set. If both flags were set (something that shouldn’t occur naturally), the value of byte 13 would be 00000011, or 3. If we use the expression
# tcpdump 'tcp[13] & 3 != 0 and host 192.168.1.100'
we’ll be able to see packets with either SYN or FIN flags set. However, the expression
# tcpdump 'tcp[13] & 3 = 3 and host 192.168.1.100'
won’t work. Why? Because, as we mentioned, the SYN and FIN flags should never both be set in the same packet. The only way an AND of byte 13 and the number 3 could ever return a value of 3 is if both bits were set in byte 13. The first expression works because we’re only making sure the comparison value is not zero. If only the SYN bit is set, the AND comparison will return a 2. If only the FIN bit is set, the AND comparison will return a 1. If neither bit is set, the AND comparison will return a 0. Therefore, the first expression gives us what we want.
| Tip | Don’t fret if you’re having trouble following these advanced examples, especially if you have limited experience with binary and hexadecimal numbers. For more information on binary math, visit http://www.learnbinary.com/. You’ll find a wealth of information online as well as links to books on the topic. |
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 189