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.
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.
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
The man page for tcpdump lists all available options, but here are a few of the noteworthy ones:
-i interface: interface to listen on.
-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.
-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.
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
or, grouped and
nested with parentheses, and negated with
not to achieve virtually
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:
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
-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 184.108.40.206 (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 220.127.116.11. 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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- My +1 Sword of Productivity
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide