This tcpdump Masterclass article series aimes to provide in-depth technical information on the installation, usage and operation of the classic and supremely popular tcpdump network traffic analysis program including alternatives, running tcpdump as a process, building expressions, understanding output and more. I’ll cover the Basics here and move on to Parameters, then filter Expressions and finally Interpreting Output.
tcpdump output can be considerable if the network traffic your expression defines is high bandwidth; particularly if you are capturing more than the default 68 Bytes of packet content.
Capturing packets, for example, related to a large file transfer or a web server being actively used by hundreds or thousands of clients will produce an overwhelming amount of output. If writing this output to stdout you will probably be unable to enter commands in your terminal, if writing to a file you may exhaust the host’s disk space. In either case tcpdump is also likely to consume a great deal of CPU and memory resources.
To avoid these issues;
- Be very careful when specifying expressions and try to make them as specific as possible.
- Don’t capture during times of heavy traffic/load.
- If you wish to capture entire packet contents, do a test capture only capturing the default 68Bytes first and make a judgement on whether the system will cope with the full packet content capture.
- Where writing to disk, carefully monitor the size of the file and make sure the host in question has the likely disk resources required available, or use the -c parameter to limit the number of packets captured.
- Never use an expression that would capture traffic to or from your remotetelnet/SSH/whatever terminal/shell. tcpdump output would generate traffic to your terminal, resulting in further output, resulting in more traffic to your terminal and so on in an infinite and potentially harmful feedback loop.
Tcpdump and Libpcap (see next) are maintained and developed by http://www.tcpdump.org/ and have been since 1999. The original authors that created tcpdump in 1987 are: Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
The low-level packet capture and file writing/reading related code of tcpdump was extracted at some point and formed into a library to which tcpdump is linked. This library, libpcap now provides the underlying functionality of tcpdump and many other Linux and Windows packet capture tools including Wireshark, Snort, Nmap, iftop, ngrep and Bro amongst others.
Linux User Permissions
Root or root equivalent user account privileges are required to run tcpdump.
This can present potential security and stability risks; I’ve never had an issue myself but for information on how to run tcpdump as a non-root user, see this link:http://packetlife.net/blog/2010/mar/19/sniffing-wireshark-non-root-user/.
As noted in a comment (unfortunately anonymous) you can also (rather more simply) just prefix your tcpdump command and syntax with the nice command. This will assign a lower scheduling priority and should ensure system CPU resources cannot be exhausted by the command.
tcpdump can be installed or upgraded as follows, depending on your platform;
- Ubuntu/Debian: apt-get install tcpdump
- RHEL/Fedora Core/CentOS: yum install tcpdump
- FreeBSD: pkg_add -v -r tcpdump
tcpdump is only available for Unix/Linux and is the program used to perform packet capture and analysis on Arista, F5 BIG-IP and Vyatta network devices, amongst others.
For capturing and decrypting/decoding SSL/TLS packets and data at the CLI, ssldump can be used:http://www.rtfm.com/ssldump/. Update: I’ve now written an article on using this tool, available here: Using ssldump to Decode/Decrypt SSL/TLS Packets.
The tshark and dumpcap CLI programs which are a part of Wireshark or of course, Wireshark itself.
The ngrep CLI program: http://ngrep.sourceforge.net/
WinDump has equivalent functionality and runs in a Windows command prompt:http://www.mirrorservice.org/sites/ftp.wiretapped.net/pub/security/packet-capture/winpcap/windump/. WinDump requires WinPcap which can be obtained here:http://www.winpcap.org/install/default.htm. Command syntax is exactly the same as tcpdump, but some older version, most options and syntax detailed in this article will work.
The tshark and dumpcap command prompt programs which are a part of Wireshark or of course, Wireshark itself.
It seems you can now perform Native Packet Capture in Windows 8.x with the netsh command!
VMWare ESXi Equivalents
I recently just stumbled across this tool: tcpdump-uw to capture vmkernel and vm packets:http://rickardnobel.se/tcpdump-uw-for-troubleshoot-esxi-networking/.
tcpdump can capture but not decrypt or decode SSL/TLS packet data.
To do this, either;
- Use a real-time tool such as ssldump (available at: http://www.rtfm.com/ssldump/). Update: I’ve now written an article on using this tool, available here: Using ssldump to Decode/Decrypt SSL/TLS Packets.
- Write your capture to a file and use a tool such as Wireshark (available at:http://www.wireshark.org) to decode the packet data instead. I’ll do a Using Wireshark to Decrypt SSL/TLS Packet Data article for information on how to do this if anyone thinks it’ll be useful. Update: Find that article here.
In either case, you will need the SSL/TLS private key.
tcpdump [-i interface] [parameter(s)] [expression(s)]
Running tcpdump As A Process (Unattended Captures)
Update: Using the screen command would appear to be a better method than the one described below (and negates the need for writing to a file) although it’s unlikely to be part of any Linux base install unfortunately. See here for more information: http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to/ (thanks to Gabriel and Nicola for there comments around this).
You can use the nohup command with the shell function & to run tcpdump as a background process that will continue running even if the terminal/shell it is launched from is closed. This is very useful for running unattended captures and in situations where, for instance, an SSH shell is terminated after a period of inactivity.
Use following command syntax;
nohup tcpdump [-i interface] [parameters] -w [dir/]filename [expression(s)] &
Note: Output must be written to a file using the -w option.
To stop the process, use the ps command to identify the relevant tcpdump process and then thekill command to terminate it.
Update: The jobs command seems to be a rather superior alternative to using ps as the output is considerably smaller. Better yet, you can use the fg command to return the tcpdump process to the foreground and then stop it simply using [CTRL]+C (thanks to Paul Cantle for these tips).
Standard Output & Writing To A File
You can display tcpdump output on standard output (STDOUT,) the default and capture that output to a file as well using the tee command, using the syntax below;
tcpdump [-i interface] [parameters] [expression(s)] | tee [dir/]filename
- The file will be saved as a text file, not in the format used when the -w parameter is used (libpcap.)
- You will not be able to use Wireshark or similar tools to analyse the output captured in the file, as the format is not supported.
- If you specify the name of an existing file it will be overwritten without warning unless you specify the tee command parameter -a.
Specifying An Interface
You do not need to specify the interface if you wish to capture traffic on the lowest numbered, configured interface on the system (often eth0.) Loopback interfaces are ignored. Use -D to display a list of interfaces that tcpdump is capable of capturing on.
For Linux, use the ifconfig command to display information on interfaces available to the system, but note this command limits the display of interface names to 9 characters. Alternatively, use theip link command which displays names up to 255 characters long.
On Linux systems with kernel 2.2 or later an interface argument of any or 0.0 is supported. This captures packets from all interfaces but not in promiscuous mode.
Using Tcpdump With SPAN Traffic
You might want to take a look at this around some of the drawbacks of SPAN in general: http://packetpushers.net/benefits-limitations-of-span-ports/.
Thanks to Ian for this. Note that a NIC that does TCP offload will reconstruct large fragments even for traffic that has been SPANed to it. So, disable offload features as necessary (ethtool -k under Linux) when using tcpdump and SPAN to see what is actually on the wire.