Welcome!

Linux Authors: Yeshim Deniz, Pat Romanski, Jim Kaskade, Liz McMillan, Elizabeth White

Blog Feed Post

The Ins and Outputs of TCPDUMP

The Ins and Outputs of TCPDUMP
By: Nicholas Beris

As a Network Engineer, I spend a lot of time on, in, and around the terminal. Many of the systems that I work with are remote and taking the time to download a packet capture in the middle of an emergency call and waiting for Wireshark to get the necessary details is just too much of a hassle. (Plus, it makes me feel like I’m an operator in the Matrix with the scrolling code.) Now don’t get me wrong, Wireshark is a great tool and has many uses, but a lot of times it’s just not practical. Besides, are you really going to download the packets from a snort alert and pump them into Wireshark? This my friends is where Tcpdump comes into play and shines.

What is Tcpdump?

Tcpdump is the most commonly and widely used tool to analyze and intercept various types of Ethernet traffic. A network administrator, security auditor, or anyone else dealing in the end to end connectivity of their infrastructure will find this tool pre-installed most of time. Many times when working with third party vendors, sometimes you have to prove that its isn’t your network, firewall, or NAT causing the issue with the application and its just poor coding on their end.

First we will look at some simple traffic and in this case will be an apt install of 2 packages.

The following is the command that I used to to ‘capture’ or record this network traffic.

tcpdump -s 1500 -Avvvn -i wlan0 -w package.pcap host 208.100.4.53

Command Breakdown

tcpdump: Name of the application.

-s 1500: Snap length is how much of the packet to get. The default is 65535 bytes. Setting the snap length to 0 sets it to it’s default. (According to the man page for my version)

-A: Prints the packet in ASCII. Useful for plain text traffic and application troubleshooting.

-vvv: Very very verbose – Prints more information about the packet such as TTL and a lot more

-n: Won’t convert address to human names

-i: Which interface to listen and capture on

-w: Write the packet to said file name

host: The remote peer

Now that we have successfully written the packets to a file we can now analyze the traffic. In any type of troubleshooting situation you have to start at square one. Lets open this file and pipe it into something useful instead of filling the scroll back buffer and missing the first essential connection details.

Since the TCP/IP stack has retransmission as part of the protocol if the first few packets fail then the rest of the connection is doomed.

tcpdump -s 1500 -Avvvn -r package.pcap | less

The -r switch reads the file instead of writing it. Since we already filtered out any other traffic with the host argument we don’t need to be as detailed in our command. The | (pipe) means direct the standard output (console screen) to another application, in the case “less”. This give us the ability to scroll through the whole .pcap file.

The first the 3 packets represent the 3 way-handshake which every TCP connection must go through to set up the connection.

12:26:58.632628 IP (tos 0x0, ttl 64, id 20547, offset 0, flags [DF]
, proto TCP (6), length 60)
10.0.1.38.59181 > 208.100.4.53.80: Flags [S], cksum 0xb5e9 (cor
rect), seq 1526109302, win 5840, options [mss 1460,sackOK,TS val 68
00437 ecr 0,nop,wscale 7], length 0
E.. .
..&.d.5.-.PZ..v...................
.g.5........

12:26:58.663268 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], pr
oto TCP (6), length 60)
208.100.4.53.80 > 10.0.1.38.59181: Flags [S.], cksum 0x7075 (co
rrect), seq 2554095472, ack 1526109303, win 5792, options [mss 1460
,sackOK,TS val 2580458519 ecr 6800437,nop,wscale 7], length 0
E..<..@.3.g..d.5
..&.P.-. .....g.5....

12:26:58.663321 IP (tos 0x0, ttl 64, id 20548, offset 0, flags [DF]
, proto TCP (6), length 52)
10.0.1.38.59181 > 208.100.4.53.80: Flags [.], cksum 0xb5ab (cor
rect), ack 1, win 46, options [nop,nop,TS val 6800445 ecr 258045851
9], length 0
E..4PD@.@.
.
..&.d.5.-.PZ..w. .g.=....

And now my host is sending its HTTP GET request to the remote HTTP server. Remember when I said in the beginning that I was going to install two packages? Well you can see two GET requests made to the server in the output below. Can you tell what I was installing?

12:26:58.663524 IP (tos 0x0, ttl 64, id 20549, offset 0, flags [DF]
, proto TCP (6), length 435)
10.0.1.38.59181 > 208.100.4.53.80: Flags [P.], cksum 0x0d68 (correct), seq 1:384, ack 1, win 46, options [nop,nop,TS val 6800445 ecr 2580458519], length 383
E...PE@.@. A
..&.d.5.-.PZ..w. .g.=....GET /debian/pool/main/a/awn-extras-applets/awn-applets-c-extras_0.4.0-3_amd64.deb HTTP/1.1
Host: mirror.steadfast.net
Connection: keep-alive
User-Agent: Debian APT-HTTP/1.3 (0.8.10.3)

GET /debian/pool/main/a/awn-extras-applets/awn-applets-python-extras_0.4.0-3_all.deb HTTP/1.1
Host: mirror.steadfast.net
Connection: keep-alive
User-Agent: Debian APT-HTTP/1.3 (0.8.10.3)

How do we know that the server even received our request? TCP will always send an ACK, or in the case of a corrupt packet, a reset (RST) the last packet. As you can see in the following output there is the acknowledge of the GET request and then the server’s HTTP 200 OK response.

12:26:58.693420 IP (tos 0x0, ttl 51, id 52036, offset 0, flags [DF]
, proto TCP (6), length 52)
208.100.4.53.80 > 10.0.1.38.59181: Flags [.], cksum 0xb406 (cor
rect), ack 384, win 54, options [nop,nop,TS val 2580458549 ecr 6800
445], length 0
E..4.D@.3....d.5
..&.P.-. ...5.g.=
12:26:58.750220 IP (tos 0x0, ttl 51, id 52037, offset 0, flags [DF]
, proto TCP (6), length 1500)
208.100.4.53.80 > 10.0.1.38.59181: Flags [.], seq 1:1449, ack 3
84, win 54, options [nop,nop,TS val 2580458605 ecr 6800445], length
1448
E....E@.3....d.5
..&.P.-. ...m.g.=HTTP/1.1 200 OK
Date: Sun, 18 Mar 2012 16:27:03 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Mon, 19 Jul 2010 07:02:03 GMT
ETag: "2ae23c67-1e17e-48bb8254eb0c0"
Accept-Ranges: bytes
Content-Length: 123262
Connection: close
Content-Type: text/plain; charset=UTF-8

And as they say “the rest is history”. Well, technically the rest is of the TCP stream for my packages, but if you are troubleshooting further than the initial connections you are going to need to roll up your sleeves and have a firm grasp of the TCP protocol. If you’re not as strong at reading packet captures or understanding how the whole TCP/IP stacks work, then this is the best way to learn with simple, easy to define and read traffic. In my next entry I plan on going more in depth with situational examples.

Read the original blog entry...

More Stories By Hurricane Labs

Christina O’Neill has been working in the information security field for 3 years. She is a board member for the Northern Ohio InfraGard Members Alliance and a committee member for the Information Security Summit, a conference held once a year for information security and physical security professionals.