Purchase Linux CDs / DVDs / Flash Drives at OSDisc.com

Welcome to Our Community

While Linux.org has been around for a while, we recently changed management and had to purge most of the content (including users). If you signed up before April 23rd, 2017 please sign up again. Thanks!

  1. More ways to get the info! - we shoot all of our new original content out as well as random messages on Twitter and our newsletter!. Twitter | Newsletter
    Dismiss Notice


Discussion in 'Linux Advanced Tutorials' started by Rob, Jul 9, 2013.

  1. Rob

    Rob Administrator
    Staff Member

    Oct 27, 2011
    Likes Received:
    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:


    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:

    tcpdump not port 22

    You can do this with a number of different ports:

    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:

    tcpdump port 143

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

    tcpdump host hal9000

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

    tcpdump -i eth1

    You can also specify a protocol:

    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:

    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:

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

    Later, you can have tcpdump read the file with

    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.

    (Log in to hide this advertisement)

    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:

    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:

    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:

    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  [email protected]@.I;....
            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.

Share This Page