It is not only useful for security professionals. Anybody doing any kind of network programming should have it under their belt. Application level debugging only goes so far. Sooner or later you'll hit a problem like a network card sometimes sending super jumbo frames which the switch cannot handle or some weird performance problems. Packet level debugging is a must in such cases.
As a sysadmin, I find it's great for problem localization. Usually an application has a pile of services behind it. Where is it going wrong? Appserver? Backend database? Name resolution? network contention? misrouted? blocked by a firewall?
You can cut away huge swaths of troubleshooting areas just by watching what is on the wire. There are problems you just won't find without knowing how to use a sniffer. I once had a core router dropping packets because of a flawed ACL implementation (It would treat fragmented packets as if they had port numbers at the matching payload offset).
Knowing how to use a packet sniffer makes hard problems so easy it feels like cheating.
Exactly the points I was coming to make. People I work with think I am some sort of addict when my default answer when someone asks me about a problem is to fire up a packet capture. Between tcpdump, nc, and burpsuite, seems like few network gremlins can hide.
I used it several months ago to reverse engineer the data our POSes (point of sale devices) send to our licensed ERP app (bundled together by vendor) so we can use a superior POS, as they would rather force us to use their crap than publish an API.
A good tutorial but there some missing options or remarks that are very handy like:
- -A is equivalent to -X displaying the payload of the packet in ASCII format. If you want to do some scripting based on a payload, that's very handy for matching specific pattern (don't forget offset notation '[a:b]' is limited to 4 bytes block in the bpf filter)
- -tttt if you want to print the complete time-stamp per packet
- When capturing on a long period of time, the -G or -C helps to rotate capture files while capturing. tcpdump -i en1 -s 0 -G 60 -w tst%y%m%d%H%M%S.cap (if you want to rotate the file every 60 secs) or -C to do the rotation based of the size of the capture file.
- There are many tcpdump forks (OpenBSD tcpdump is slightly different than the tcpdump on Debian)
The power of a ring buffered capture should not be underestimated. Having an intermittent problem that you can't seem to catch while it's happening? Just let the capture run saving the last 2hrs of traffic. When the problem happens, pull the capture files.
Personally I prefer dumpcap and wireshark for this, but it's similar.
If I'm only a few key presses away from the solution when using a terminal to some small box, I certainly don't want to play with a big who-knows-dependent-on-which-libraries who-knows-how-much-time-to-install Wireshark.
I use Wireshark when I need to. I prefer to type a few characters in the command line if that's enough to get the right answer.
People are obsessed with command line tools because they offer the most basic interface, which is not likely to change. One of the commonly cited programming aphorisms is to "Program to an 'interface', not an implementation." Learning a GUI tool is usually easier in the short term, but becomes less flexible in the long run. As you become an increasingly skilled developer you realized that you gain order of magnitude more productivity by working at increasingly higher levels of automation and abstraction. This can be very difficult with a graphical interface since it would likely take much more work to create an adapter which will allow your code to work with the GUI interface than a command line one. GUIs are also likely to be complex and thus have the potential for bugs and performance costs.
Sometimes (most times?) you want to do the analysis in real-time in which case it helps to be fluent in tcpdump. Also, whether you're looking at the wireshark gui or tcpdump in a terminal, you're essentially looking at text. So a high res (retina) display is going to be nice to have in either case.
Wireshark solves another problem, when you need it, you have a problem where you want to analyze the packet content, or drill and cut through a historical capture. That's not always what you need, and it's often cumbersome to run on a remote server that isn't supposed to have GUI stuff installed anyhow.
Sometimes you just need to know if DNS resolution is working.
Or if the right DNS server is queried.
Or if some server backend is actually firing off packets to the proper place when you hit a button on the frontend.
Or you just need to verify that data are coming in when the guy on the phone says "check again now".
For these sort or problems, tcpdump is great, as it easily allows you to experiment with different filters on the command line, which will take you an order of magnitude more time click through in wireshark or wait for reparsing if you use a display filter.
Since when is "displaying stuff" synonymous with "analysis?" If you're "analyzing" your data by staring at it, you're almost certainly doing it wrong. Real questions with real (i.e. non-ambiguous) answers have small representations, more or less by defintion. The point of analysis is coming up wiht ideas and testing them. That's a programming problem (whether or not it's done in a "programming language") and is naturally well suited to a text stream.
I mean, I'm all for having nice GUI tools. And I've even been known to stare at giant data dumps when stumped (though I'll note that a maximized terminal window with grep-over-tcpdump-output content works just as well as wireshark for that purpose). But that argument is just silly.
Wireshark is really useful, but it's also had security problems (I think I'm not being unfair here) continuously over its entire existence. I started using it over 10 years ago back when it was called Ethereal, and I feel like I've seen probably hundreds of Ethereal/Wireshark security advisories in that time.
The recording part is cumbersome. On these systems there's hardly any writable disk space and I'm not sure if NFS or SMB client is built in. tcpdump is often a quick alternative to capture just the packets I'm interested in in clear text. That requires knowing a little bit about the filter syntax.
