TCP DUMP ---Part -I

Packet capture is one of the most fundamental and powerful ways to do network analysis. You can learn virtually anything about what is going on within a network by intercepting and examining the raw data that crosses it. Modern network analysis tools are able to capture, interpret and describe this network traffic in a human-friendly manner.
tcpdump is one of the original packet capture (or "sniffing") tools that provide these analysis capabilities, and even though it now shares the field with many other utilities, it remains one of the most powerful and flexible.
If you think that tcpdump has been made obsolete by GUI tools like Wireshark, think again. Wireshark is a great application; it's just not the right tool for the job in every situation. As a refined, universal, lightweight command-line utility—much like cat, less and hexdump—tcpdump satisfies a different type of need.
One of tcpdump's greatest strengths is its convenience. It uses a "one-off-command" approach that lends itself to quick, on-the-spot answers. It works through an SSH session, doesn't need X and is more likely to be there when you need it. And, because it uses standard command-line conventions (such as writing to STDOUT, which can be redirected), tcpdump can be used in all sorts of creative, interesting and extremely useful ways.
In this article, I introduce some of the basics of packet capture and provide a breakdown of tcpdump syntax and usage. I show how to use tcpdump to zero in on specific packets and reveal the useful information they contain. I provide some real-world examples of how tcpdump can help put the details of what's happening on your network at your fingertips, and why tcpdump is still a must-have in any admin's toolbox.

Essential Concepts

Before you can begin to master tcpdump, you should understand some of the fundamentals that apply to using all packet sniffers:

• Packet capturing is passive—it doesn't transmit or alter network traffic.
• You can capture only the packets that your system receives. On a typical switched network, that excludes unicast traffic between other hosts (packets not sent to or from your machine).
• You can capture only packets addressed to your system, unless the network interface is in promiscuous mode.

It is assumed that you're interested in seeing more than just your local traffic, so tcpdump turns on promiscuous mode automatically (which requires root privileges). But, in order for your network card to receive the packets in the first place, you still have to be where the traffic is, so to speak.

Anatomy of a tcpdump Command

A tcpdump command consists of two parts: a set of options followed by a filter expression (Figure 1).
Figure 1. Example tcpdump Command
The expression identifies which packets to capture, and the options define, in part, how those packets are displayed as well as other aspects of program behavior.

Options

tcpdump options follow the standard command-line flag/switch syntax conventions. Some flags accept a parameter, such as -i to specify the capture interface, while others are standalone switches and can be clustered, such as -v to increase verbosity and -n to turn off name resolution.
The man page for tcpdump lists all available options, but here are a few of the noteworthy ones:

• -i interface: interface to listen on.
• -v, -vv, -vvv: more verbose.
• -q: less verbose.
• -e: print link-level (Ethernet) headers.
• -N: display relative hostnames.
• -t: don't print timestamps.
• -n: disable name lookups.
• -s0 (or -s 0): use the max "snaplen"—capture full packets (default in recent versions of tcpdump).

None of these are required. User-supplied options simply modify the default program behavior, which is to capture from the first interface, and then print descriptions of matching packets on the screen in a single-line format.

Filter Expression

The filter expression is the Boolean (true or false) criteria for "matching" packets. All packets that do not match the expression are ignored.
The filter expression syntax is robust and flexible. It consists primarily of keywords called primitives, which represent various packet-matching qualifiers, such as protocol, address, port and direction. These can be chained together with and/or, grouped and nested with parentheses, and negated with not to achieve virtually any criteria.
Because the primitives have friendly names and do a lot of the heavy lifting, filter expressions are generally self-explanatory and easy to read and construct. The syntax is fully described in the pcap-filter man page, but here are a few example filter expressions:

• tcp
• port 25 and not host 10.0.0.3
• icmp or arp or udp
• vlan 3 and ether src host aa:bb:cc:dd:ee:ff
• arp or udp port 53
• icmp and \(dst host mrorange or dst host mrbrown\)

Like the options, filter expressions are not required. An empty filter expression simply matches all packets.

Understanding tcpdump Output

How much sense the output makes depends on how well you understand the protocols in question. tcpdump tailors its output to match the protocol(s) of the given packet.
For example, ARP packets are displayed like this when tcpdump is called with -t and-n (timestamps and name lookups turned off):

arp who-has 10.0.0.1 tell 10.0.0.2
arp reply 10.0.0.1 is-at 00:01:02:03:04:05

ARP is a simple protocol used to resolve IPs into MAC addresses. As you can see above, tcpdump describes these packets in a correspondingly simple format. DNS packets, on the other hand, are displayed completely different:

IP 10.0.0.2.50435 > 10.0.0.1.53: 19+ A? linuxjournal.com. (34)
IP 10.0.0.1.53 > 10.0.0.2.50435: 19 1/0/0 A 76.74.252.198 (50)

This may seem cryptic at first, but it makes more sense when you understand how protocol layers work. DNS is a more complicated protocol than ARP to begin with, but it also operates on a higher layer. This means it runs over top of other lower-level protocols, which also are displayed in the output.
Unlike ARP, which is a non-routable, layer-3 protocol, DNS is an Internet-wide protocol. It relies on UDP and IP to carry and route it across the Internet, which makes it a layer-5 protocol (UDP is layer-4, and IP is layer-3).
The underlying UDP/IP information, consisting of the source and destination IP/port, is displayed on the left side of the colon, followed by the remaining DNS-specific information on the right.
Even though this DNS information still is displayed in a highly condensed format, you should be able to recognize the essential elements if you know the basics of DNS. The first packet is a query for linuxjournal.com, and the second packet is an answer, giving the address 76.74.252.198. These are the kind of packets that are generated from simple DNS lookups.
See the "OUTPUT FORMAT" section of the tcpdump man page for complete descriptions of all the supported protocol-specific output formats. Some protocols are better served than others by their output format, but I've found that tcpdump does a pretty good job in general of showing the most useful information about a given protocol.