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.
Precautions
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 remote telnet/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.
Development
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.
Libpcap
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.
Linux Installation
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
Availability
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.
Linux Alternatives
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/
Windows Equivalents
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/.
Docker Containers
As a lightweight alternative to installation you could use one of the many container images out there. You’ll find my very own, tiny image here: https://hub.docker.com/r/itsthenetwork/alpine-tcpdump/.
Decoding SSL/TLS
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.
Usage Syntax
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 the kill 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
Notes;
- 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
-i 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 the ip 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: https://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.
The icon Artwork used in this article is by the GNOME Project and licensed under the Creative Commons Attribution-Share Alike 3.0 United States License.
Thanks for this Steven. Just yesterday, I used tcpdump and traceroute -T -p 80 on a Ubuntu Live CD to get to the bottom of an issue at work. We were trying to rule out our network as being the cause of why certain clients couldn’t get to a remote server over http.
I’m a beginner with Linux but more and more I’m convinced that it’s an invaluable resource to have. Things like traceroute with protocol/port options, tcpdump, mtr, grep, etc are all great to have in an engineer’s tool bag.
I wouldn’t get to hung up on the OS – all those tools are cross-platform. Whilst it’s true that, out the box, Linux has these tools one may not always have the luxury of running it.
Agreed. In my environment and previous environments, Microsoft was the only OS allowed. We just so happened to have a non-domain laptop that we were able to use Ubuntu Live CD on in this one particular case.
Very true Euan; thanks for prompting me to look into the cross-platform aspects a bit further. I’ve added some detail on libpcap to the article.
I’ve rarely found server administrators with the necessary privileges to run tools like this on Linux systems. I’m more focussed on network devices that either run Linux or have a Linux based management subsystem (such as F5 devices). Have this capability at the core of or gateway to a network is incredibly useful.
You’re welcome, thanks for your comments. mtr is new to me so I’ll be investigating that. Cheers
Great post and very useful tool! I am very glad to see tcpdump added to some of the networking operating systems. Here are a couple tcpdump, (or similar tools) which have been added to switch/router OSes.
Arista EOS has full blown TCPDump: https://eos.aristanetworks.com/2011/06/using-tcpdump-for-troubleshooting/
JunOS: http://kb.juniper.net/InfoCenter/index?page=content&id=KB23313
NX-OS has a similar tool called Ethananlyzer: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps11541/white_paper_c11-673817_ps9670_Products_White_Paper.html
Standard IOS doesn’t have any real equivalent. In theory you could try and munge the output of packet debugs, but that would kill the appliance.
Thanks Alex, indeed. Cheers
Thanks Alex, that’s really useful. I’ve updated the article accordingly.
Or nice the process so it can only interrupt with a certain priority.
Thanks Anon, I added your suggestion too.
– instead of nohup, one could start tcpdump in a screen/tmux session
– if one wants to see the capture in real-time AND write to a file in .pcap format, -w and -r can be combined: start tcpdump in a console with -w file.pcap as parameter and then start another tcpdump instance in another console with -r file.pcap. It (kinda) works (I keep getting errors like “tcpdump: pcap_loop: truncated dump file; tried to read 16 header bytes, only got 12” before it stops).
Thanks Gabriel. I don’t think I’d take the risk of your second suggestion but could you expand on the first please? Clearly my Linux skills are wanting.
I was thinking that, instead of sending the tcpdump process in the background, you could run it in a screen (or tmux) session. These allow you to multiplex virtual consoles and attach to / detach from them whenever.
So, you could start a session, run tcpdump in a virtual console inside that session and detach from the session. Later, you could re-attach to the session (even after ssh-ing into the machine from a remote location) and stop the capture. I guess the main difference between this and nohup would be that you could see the statistics tcpdump presents at the end (received/captured/dropped pkts) or, if tcpdump stopped unexpectedly, you could see the error message.
Hey Gabriel; thanks again and forgive my continued ignorance but how would that be achieved; it sounds seriously useful. Cheers
When you have installed screen (apt-get install or whatever) just launch it in the console.
Typing Ctrl+A and then D you can detach it.
With the command “screen -ls” you get a list of sessions (PID is the identifer)
With “screen -r PID” you can reattach to the session
(something similar to RDP session in windows: you can disconnect and reattach without logging off)
It’s one of those tools I’ve never heard of that I suspect I won’t be able to live without very soon. Many thanks Gabriel and Nicola both; I’ve updated the article quickly now and will look into this more. This is one of the many reasons I love blogging here; I learn something every time. Cheers
“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.”
I would find this extremely useful. My primary use for TCPdump is to capture packets on a VCS Expressway (SIP registrar/proxy), and most of the endpoints are using TLS encrypted SIP. The ability to debug these call flows without having to change the remote endpoint to TCP would be most helpful.
Hey Jamie. Sure thing, I’ll get something up early next week.
Btw, anyone notice how the Disqus Twitter login now wants far more access than it used to?
Many thanks for persisting Gabriel and you’re welcome. I don’t think I’ve ever learnt so much from a blog post, albeit nothing network related! A friend also pointed out yesterday that the jobs command is probably better than using ps.
Anyway, I’ll be taking a close look at both and my latest ‘almost ready’ book will be getting a few extra sections. If you could drop me your full name via Twitter or email I’ll give you a mention. Thanks again.