Author: Joe Barr
tcpdump at the command line. It will take the default values and go, pumping out packets as they are received. Here’s what it looks like starting out on my desktop box:
# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:44:52.149255 IP xenon.oftc.net.6667 > 192.168.0.103.33091: P 3312142394:3312142472(78) ack 3550737549 win 5792
Unless you are used to looking at dumped TCP/IP packets, it doesn’t exactly overwhelm you with usable information, does it? Let’s take a look at some of the options for formatting the output that might make it a little more human-readable.
The first and second lines describe how tcpdump is being run, the interface being listened to, the type of interface, and the packet capture size. By default, a timestamp — 09:44:52.149255 in the sample above — precedes the actual packet, which, per the defaults, is trimmed to the first 96 bytes.
Why should we care about tcpdump? Look at the following captured packet, particularly at the last line:
08:31:29.302962 IP 192.168.0.103.33839 > 208.53.170.81.6667: P 1328174875:1328174909(34) ack 2550614308 win 32022E..V.,@.@.z....g.5.Q./..O*W...I$..}..'..... ..v..^..PRIVMSG #tcpdump :hello, tcpdump
To capture it, I increased the default packet length using an argument of -s 512 and also requested ASCII output with the -A option. The text that appears (the “hello, tcpdump”) is a message I typed on IRC while tcpdump was running.
Now imagine yourself using telnet, or POP-3 email, or any unprotected Internet protocol that doesn’t encrypt the data before it’s sent. Imagine how happy the kiddy will be who has a sniffer anywhere on the route between you and the packet’s destination. Imagine the fun he will have with your passwords and your credit card data. That’s the primary reason that tcpdump is of interest to us: as an educational tool.
One thing you’ll quickly discover as you play with tcpdump is that there is way too much traffic on your Internet connection. If you are trying to follow a particular session, it can very easily be hidden or lost in the volume. So let’s back the volume down a little. We don’t really need to go all the way to 11.
The real magic
Tcpdump’s real magic is in its ability to focus. It can produce only the packets you’re interested in, across a number of interfaces, protocols, destinations IP address (including specific ports), packet size, sessions, and so on. This magic comes in the form of a matching expression which can be entered at the command line.
Let’s say I am interested only in seeing packets leaving my machine for elsewhere on the Internet. The command to do that would be:
tcpdump host 192.168.0.103
Actually, that’s wrong. That would capture traffic to me as well as from me. Let’s fine-tune that a bit further.
tcpdump ether src 192.168.0.103
The flip side of that, to capture only packets received at my machine, could be given as follows, so long as 192.168.0.103 is one of the addresses given for localhost in your /etc/hosts file:
tcpdump ether dst localhost
What if you’re interested in traffic to or from a certain port? No problem. Anything coming to or going from port 6667 would be snared in this tcpdump trap:
tcpdump port 6667
Just like an IP address, the port filter can be throttled down to accept only incoming or outgoing traffic, as in these two commands:
tcpdump dst port 6667
or
tcpdump src port 6667
Does size matter?
Maybe you’re only interested in packets smaller than or larger than a certain size. If 512 is your tipping point, you can handle it like this:
tcpdump less 512
or
tcpdump greater 512
Or you could state those as len or len >= 512.
Those are just a few of the simplest examples of what tcpdump can do in terms of packet selection. It can get very complex, very quickly. For that level of understanding, I refer you to the man pages, and to volumes 1 through 3 of W. R. Stevens' "TCP/IP Illustrated."
