tcpdump

Rob

Administrator
Staff member
Joined
Oct 27, 2011
Messages
1,210
Reaction score
2,240
Credits
3,485
Looking at Raw Packets with 'tcpdump'

Though tools like Snort do an excellent job of screening everything that comes through our network, sometimes its necessary to see the raw data. To do this, our best tool is 'tcpdump'.


The most basic way of using tcpdump is to simply issue the command:

Code:
tcpdump


You can get more detailed information using the -v option and you can get even more with -vv.


Useful Options

Let's say you've logged in to a remote machine that you manage. Normally, you would use SSH. If you ran 'tcpdump' without any options, the output would be flooded with packets coming from your SSH connection. To avoid this, simply eliminate port 22 from your output:

Code:
tcpdump not port 22


You can do this with a number of different ports:

Code:
tcpdump not port 143 and not port 25 and not port 22


If you wanted to do the reverse, that is, only monitor a certain port - which is good for debugging network applications - you would do the following:

Code:
tcpdump port 143


You can also get data from a specific host on the network:

Code:
tcpdump host hal9000


If your machine has more than one network interface, you can also specify the one you want to listen to:

Code:
tcpdump -i eth1


You can also specify a protocol:

Code:
tcpdump udp


You'll find a list of protocols in /etc/protocols.


Saving Output for Later

In some cases, you may want to redirect the output to a file so that you can study it in detail later or use other programs to parse the output. In the following example, you can still watch the output while saving it to a file:

Code:
tcpdump -l | tee tcpdump_`date +%Y%m%e-%k.%M`


In the above example, we can identify each of the dumps with the date and time. This might come in handy when dealing with problems that come at certain times of the day.

tcpdump also has an option to dump its output into a binary format which it can read later. To create a binary file:

Code:
tcpdump -w tcpdump_raw_`date +%Y%m%e-%k.%M`


Later, you can have tcpdump read the file with

Code:
tcpdump -r tcpdump_raw_YYYMMDD-H.M


You can also use the program ethereal to open up the raw dump and interpret it. We'll talk more about ethereal in the next section.


Things to Look For

tcpdump gives us information about all the packets traveling to and from our network. But what does it all mean?


Using Ethereal with tcpdump

Ethereal is a tool that can also be used to capture network packets. Once installed, you can open up the raw dump file you made. It will look something like this:

That makes it quite a bit easier to see what's going on. You can see what the source and destination IPs are and what type of packet it was. It's easy, then to troubleshoot network problems that you might have and to analyze suspicious behavior. Just to add an anecdote, while I was writing this lesson and interpreting my own dumps, I saw some strange activity on my personal workstation. Almost at regular intervals I was querying port 32772 on machines disparate IPs out in the world. I ran a specific dump for port 32772 like so:

Code:
tcpdump port 32772 -w dump_32772


What I got did look strange indeed. Even after a Google search, I couldn't find any information on this, so I suspected I might have a trojan. I ran 'rootkit hunter' (more about that in the next section) and it turned up nothing. Finally, by shutting things down one by one, it turned out to be Skype, which I always have turned on. Even though this turned out to be innocuous, I was glad that I had tcpdump to point this out to me.


Reading the Raw Output

As you can see, reading even the so-called 'human readable' output from tcpdump can be a bit cryptic. Take a look at the following example, a random packet I just fished out of the dump:

Code:
17:26:22.924493 IP www.linux.org.www > test.linux.org.34365: P 2845:3739(894) ack 1624 win 9648 <nop,nop,timestamp 326501459 24374272>


What we have is a webserver request to www.linux.org. After the timestamp, you'll notice the .www at the end of the hostname (which means port 80). This is being sent to port 34365 of the requesting host, test.linux.org. The 'P' stands for the TCP "oush" function. This means that the data should be sent immediately. Of the numbers after, 2845:3739(894), 2845 marks the number of the octet of the first packet. The number 3739 is the number of the last byte it the packet sent, plus 1. The number 894 is the length of the data packet that was sent. The part that says: 'ack 1624' is the TCP term for 'acknowledge' - that is the packet has been accepted and the packet number that is expected next is 1624. After, we see 'win 9648' that the sending hosts awaits a packet with a window size of 9648 octets. This is followed by a timestamp.


Now, if you think that is a bit difficult to interpret, if you use the -x option, it will include the packet contents in hexadecimal output. Here you'll need an Egyptologist to interpret the output:

Code:
18:12:45.149977 IP www.linux.org.www > test.linux.org.34536: . 1:1449(1448) 
ack 487 win 6432 <nop,nop,timestamp 329284215 27156244>
        0x0000:  4500 05dc 6a81 4000 4006 493b c0a8 0006  E...j.@[email protected];....
        0x0010:  c0a8 0009 0050 86e8 8fa4 1d47 1c33 e3af  .....P.....G.3..
        0x0020:  8010 1920 b4d9 0000 0101 080a 13a0 7a77  ..............zw
        0x0030:  019e 5f14 4854 5450 2f31 2e31 2032 3030  .._.HTTP/1.1.200
        0x0040:  204f 4b0d 0a44 6174 653a 2054 6875 2c20  .OK..Date:.Thu,.
        0x0050:  3135


We can glean from the output, that this is a HTTP request. As for the rest, it's not human readable, but we rest easy knowing that this is a legitimate packet. Another advantage to using this format is that even if we can't exactly interpret what's going on with this packet, we can send it to somebody who might be able to. This is, in the end, the raw data that's going over your network without any filtering.
 


Nice tutorial.

One trick I use for deciphering the hex is using "-A" flag for tcpdump. It will convert packet data into ASCII text. (sometimes, it doesn't convert to something unreadable though) This definitely helps in the readability in many cases. Especially if you're reviewing non-encrypted payloads.

Excuse the redaction, it's raw email data crossing port 25 of a mail relay server, so it's necessary.

s14Tub.jpg
 
Last edited:

Members online


Top