Spy on Yourself with tcpdump
As a network administrator, you've got to cultivate a certain amount of professional paranoia. tcpdump indulges your need to know and tells you exactly what's going on over your networks.
I confess, I'm an outlaw at heart. I like using packet sniffers like tcpdump because it satisfies my base snooping impulses. Packet-sniffing is wiretapping after all, only it's applied to TCP/IP packets, not voice transmissions. Sure, they're my packets on my systems, but still the idea is appealing. Even more appealing is knowing I have the ability to monitor incoming and outgoing traffic, and knowing exactly what's going on.
For example, being an untrusting soul as all wise network administrators are, I can use tcpdump to verify that encryption is working. Here is what a plain unencrypted POP mail session looks like. This is an abbreviated example showing only the initial three-way TCP handshake. You can do this yourself by firing up tcpdump, then checking mail. Ctrl+C stops it:
# tcpdump port 110
15:04:49.050227 windbag.34348 > venus.domain.com.pop3: S 2974284112:2974284112(0) win 5840
15:04:49.190076 venus.domain.com.pop3 > windbag.34348: S 2862911212:2862911212(0) ack 2974284113 win 5840
15:04:49.190168 windbag.34348 > venus.domain.com.pop3: . ack 1 win 5840 (DF)
Handshake DissectionThere is a whole lot going on here, which I shall now deign to explain.
15:04:49.050227 is the timestamp, in hh:mm:ss:fraction format.
windbag.34348 > is the originating host and port.
venus.domain.com.pop3: is the destination host and port (see /etc/services).
S is the first part of the three-way TCP handshake (SYN, SYN, ACK).
2974284112:2974284112 is the byte sequence/range. The initial sequence number (ISN) is generated randomly. Then sequence numbers for the rest of the bytes in the connection are incremented by 1 from the ISN. Since no data are exchanged at this stage, both numbers are the same.
win 5840 is the window size, or the number of bytes of buffer space the host has available for receiving data.
mss 1460 is the maximum segment size, or maximum IP datagram size that can be handled without using fragmentation. Both sides of the connection must agree on a value; if they are different, the lower value is used.
sackOK means "selective acknowledgments," or allow the receiver to acknowledge packets out of sequence. Originally, packets could only be acknowledged in sequence. So if the third packet out of a thousand packets received went missing, the host could only acknowledge the receipt of the first two packets, and the sender would have to resend all packets from number three through one thousand. sackOK allows only the missing third packet to be re-sent.
timestamp 995173 0 measures the round-trip time. There are two fields: the Timestamp Value and the Timestamp Echo Reply. On the first exchange, the Echo Reply is set to 0. When the second host receives that packet, it transfers the timestamp from the old packet's Timestamp Value field to the new packet's Timestamp Echo Reply field. Then it generates a new value for the Timestamp Value field. So the Timestamp Value field contains the latest timestamp, while the Timestamp Echo Reply field contains the previous timestamp.
nop, or "no operation," is just padding. TCP options must be multiples of 4 bytes, so nop is used to pad undersized fields.
wscale 0> is a nifty hack to get around the original window size limitation of 65,535 bytes, because the window size field is only 16 bits long. wscale provides for a full gigabyte of buffer. Both sides of the connection must support this and agree; otherwise the window size does not change.
(DF) means "don't fragment."
Here is a sample of the rest of the dump, showing data transfer:
15:04:49.548954 windbag.34348 > venus.domain.com.pop3: P 46:52(6) ack 181 win 5840 (DF)
15:04:49.653945 venus.domain.com.pop3 > windbag.34348: P 181:238(57) ack 52 win 5840 (DF)
The P flag means "push", or data are being sent. And now you see an example of the byte sequence/range when data are sent: 181:238(57); or 57 packets in this particular exchange.
Verifying EncryptionNow let's get back to our original task of examing packets to verify that logging in to our mail server is properly encrypted. Here is the quick way:
# tcpdump port 995
tcpdump: listening on eth0
16:10:05.054198 windbag.34465 > venus.euao.com.pop3s: S 2698160498:2698160498(0) win 5840
16:10:05.171235 venus.domain.com.pop3s > windbag.34465: S 2694170013:2694170013(0) ack 2698160499 win 5840
16:10:05.171319 windbag.34465 > venus.domain.com.pop3s: . ack 1 win 5840 (DF)