Understanding tcpdump

address filtering

• An address can refer to a host, a network, a multicast/broadcast, or a mac/ethernet address
• An address can be a source or a destination

So if I am interested in all IP traffic involving host mudra:

Let's say I want only traffic where mudra is the destination:

Obviously, if you use names (instead of IP addresses) name resolution must be set up.

Below we capture IP traffic involving a source ethernet address of 0:a0:3b:3:e1:1d

Note the syntax: ether host {mac address}

Here we will display the first 100 packets involving network 192.168.1.0 with a netmask of 255.255.255.0 and save everything to a text file (called net_1.0.txt.dump):

Note that the switches must come first.

protocol filtering

• Five common protocols can be specified by name (also called keywords):

  	ip
  	tcp
  	udp
  	icmp
  	igmp
  

• The remaining protocols must be specified by number.

So if I want to capture all udp related packets:

If I wanted to do the same but save 300 bytes of data per packet to a tracefile (called udp1000hits.dump) containing the first 1000 hits on interface vr0 then:

Here I am telling tcpdump to capture esp related packets:

Note the syntax: proto {protocol number} (see /etc/protocols)

port filtering

For example, I am sniffing around my network for any Telnet activity:

Note the syntax: port {port number} (see /etc/services)

packet characteristics filtering

Remember in the beginning when we were decoding fields in the headers of a packet? Well we can filter using the same strategy. Here is the syntax:

tcpdump "{protocol}[{bypass n bytes}] = {number}"

The available protocols are: ip, tcp, udp, icmp, ether, arp, rarp, and fddi. What "protocol" refers to is a little murky. If we use "ip" then it represents the IP header. If we use "icmp" (there is no such thing as an ICMP header) it represents the payload or data portion of the packet.

An indirect way to capture all icmp traffic is like this:

This works because the transport protocol is given by the tenth byte of the IP header. And we know that icmp's protocol number is "1".

Now given that host daffy is currently pinging host spider, the following command will capture only the echo replies of spider:

04:20:22.056929 spider > daffy.pmatulis.homeunix.net: icmp: echo reply
                         4500 0054 c20e 0000 8001 f4db c0a8 0128
                         c0a8 0146 0000 6354 d87b 0000 3d09 a7a8
                         000d f46d 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435

Focus your attention on the first 2 digits of chunk 11. That's byte 1 of the data portion of the packet and it is zero. Well the first byte of an ICMP message is it's type and by golly type "0" means echo reply.

Let's try that again but this time we'll capture only what we need for the test (the 14 bytes for the frame header, the first 20 bytes for the IP header, and 1 byte for the ICMP type). We'll test for echo requests on the part of daffy this time (echo request is type "8"):

04:56:12.618507 daffy.pmatulis.homeunix.net > spider: [|icmp]
                         4500 0054 8c8e 0000 ff01 ab5b c0a8 0146
                         c0a8 0128 08

Pretty good. Exactly as expected.

Something else that's fun is to filter on TCP flags. The key here is to find where the flags are located in the TCP header. Well, they are found at byte 14 (we need to bypass 13 bytes). Therefore, we can do the following if we want to identify all packets containing the RESET flag (which must necessarily also contains the ACK flag):

Why? Well first, its actually only the last 6 bits of byte 14 that supply flag information:

|U|A|P|R|S|F|
|R|C|S|S|Y|I|
|G|K|H|T|N|N|

Therefore ACK and RST gives us a byte of 00010100. I think the first two bits are always zero (?). Converting binary to decimal (we do not use hex [which would of been 14 or 0x14]) gives us "20".

Sometimes it may be useful to identify (datagram) fragments. In this case we filter on fields in the IP header where information regarding fragmentation is stored. Without elaborating on fragmentation theory, suffice it to say that if there is no "fragment offset" listed in the IP header then that packet is either not a fragment or it is the datagram's very first fragment.

The offset is given by bytes 7 and 8 with the exception of the first 3 bits: reserved (always zero?), "do not fragment" (DF), and "more fragments to follow" (MF). Any one datagram will therefore have these two bytes looking like this:

Where ? may be "1" or "0" and the string of x's contains at least one "1".

So if we can do a bitwise AND operation on those two bytes with the following binary number then we know our datagram is of the first two types providing the result is zero:

So this will sniff non-fragments or "frag zeroes" (initial fragments):

Why? Well we bypass 6 bytes and examine the next two (bytes 7 and 8). We then perform the AND operation and specify a result of zero.

In hexadecimal the expression becomes:

compound filtering

Compound filtering is where we combine multiple filtering options in the same tcpdump command. This is very common on real networks. I can either specify exactly what I want or specify what I don't what. We do this through the use of three operators:

1. Negation -- (not or !)
2. Concatenation -- (and or &&)
3. Alternation -- (or or ||)

An example: Say I am working with tcpdump remotely by SSH and I want to take a sample capture of my network traffic and store it in a tracefile. Now I don't want to contaminate my capture with the remote session traffic itself so here is what I must do:

But wait. This is no good. What if there is SSH activity on my network to begin with? Hmmm. I will tell tcpdump to forget about SSH activity between me (spider) and the remote host (fulton):

Good idea but the syntax is all wrong. This is the correct command:

We're saying to ignore anything that makes the entire contents of the parentheses true. This means packets that involve port 22 AND host spider AND host fulton will be ignored. But still, tcpdump will complain. The real final command is this: