![[ Register ]](/images/navbar/register.gif)
![[ Applications ]](/images/navbar/applications.gif)
![[ Documentation ]](/images/navbar/documentation.gif)
![[ Distributions ]](/images/navbar/distributions.gif)
![[ Download Info ]](/images/navbar/download.gif)
![[ General Info ]](/images/navbar/geninfo.gif)
![[ Book Store ]](/images/navbar/bookstore.gif)

![[ Courses ]](/images/navbar/courses.gif)
![[ News ]](/images/navbar/news.gif)
![[ People ]](/images/navbar/people.gif)
![[ Hardware ]](/images/navbar/hardware.gif)
![[ Vendors ]](/images/navbar/vendors.gif)
![[ Projects ]](/images/navbar/projects.gif)
![[ Events ]](/images/navbar/events.gif)
![[ User Groups ]](/images/navbar/usergroups.gif)
![[ User Area ]](/images/navbar/user_area.gif)

![[ About Us ]](/images/navbar/aboutus.gif)
![[ Home Page ]](/images/navbar/homepage.gif)
![[ Advertise ]](/images/navbar/advertise.gif) |

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.
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:
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:
You can also get data from a specific host on the network:
If your machine has more than one network interface, you can
also specify the one you want to listen to:
You can also specify a protocol:
You'll find a list of protocols in /etc/protocols.
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.
tcpdump gives us information about all the packets traveling to
and from our network. But what does it all mean?
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.
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 "push" 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 E...j.@.@.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.
|
 |
|