Difference between revisions of "Packet sniffing"

From Noah.org
Jump to navigationJump to search
Line 256: Line 256:
 
<pre>
 
<pre>
 
driftnet -i eth0
 
driftnet -i eth0
 +
</pre>
 +
 +
=== tcpxtract ==
 +
 +
`Tcpxtract` works similar to `driftnet`, but it is more efficient and able to identify a wider variety of files. You can also add formats and convert `foremost` configuration files to `tcpxtract`.
 +
 +
http://tcpxtract.sourceforge.net/
 +
 +
<pre>
 +
tcpxtract -d eth0
 
</pre>
 
</pre>
  

Revision as of 18:58, 6 August 2008


Packet Sniffing Tools

This review of packet sniffing tools focuses on quick ways to get an overview of what's going on with network traffic.

What started all this for me were bandwidth hogs on my network. Some people in the office were downloading far to many videos. The best my gateway could tell me was that 3 Mbit of total bandwidth was being used. I needed more visibility, so I went looking for better tools. Along the way, I also learned that fear about communication privacy is not merely theoretical.

Most of these tools are command-line based. Some of my favorite tools are pktstat, iptraf, and iftop. They all can do more or less the same thing. It's hard to say which is best. I have a slight preference for `pktstat`.

If you are using a UNIX box as a router then you are all set. If you are using a router appliance then you will need to insert an unswitched hub between your switch and router. This will let you plug in a machine that can listen to all the traffic between your LAN and the WAN. It's also possible to have a machine spoof itself as the gateway for a network (see `arpspoof` and `ettercap`). This will force packets to go through the phony gateway even on a switched network. But this technique is not transparent and will cause lots of extra network overhead thus invalidating any measurements of bandwidth. By the way, you can use `arpwatch` to detect people on your networking attempting to spoof arp.

I run a machine with two interfaces, eth0 and eth1. The eth1 interface is connected to the switched side of my LAN. I setup a local IP on eth1 and I SSH into this interface to manage the machine. The eth0 interface is connected to an unswitched hub. This interface is used in "promiscuous mode" as the packet sniffer. This interface needs an IP address too in order to be set active. You can use a machine with a single interface, eth0, but then you have to separate your traffic into the sniffer machine from everyone else's. This may not be a big deal. I just find it cleaner to use two interfaces.

            +------------+   +------------+   +-------------+
            | LAN switch |   | unswitched |   | WAN gateway |
            |            |   |    hub     |   |   router    |
            +-+-+-+-+--+-+   +-+---+---+--+   +--+-------+--+
to            | | | |  |       |   |   |         |       |
rest     <----+ | | |  +-------+   |   +---------+       +------> WAN
of LAN   <------+ | |              |            LAN
drops... <--------+ |              |
                    +-------+      |
                            |      |
     (eth1 is optional) eth1|  eth0|
                       +------------+
                       |  sniffer   |
                       |  machine   |
                       +------------+

bwm

This will show a screen with bandwidth statistics for each interface. It's very brief. This shows overall bandwidth not broken down by IP address.

Just run it like this:

bwm

Example output:

Bandwidth Monitor 1.1.0

       Iface        RX(KB/sec)   TX(KB/sec)   Total(KB/sec)

          lo            0.000        0.000           0.000
        eth0            0.000        0.000           0.000
        eth1           49.875        0.000          49.875
        eth2            0.000        0.000           0.000
        sit0            0.000        0.000           0.000

       Total           49.875        0.000          49.875

Hit CTRL-C to end this madness.

pktstat

This shows a continuously updated curses view of who is using bandwidth. I find this one to be a bit noisy. It does not maintain a long-term average, so top connections jump around a lot on a busy network. The information is compact and easy to read. Neat feature: pktstat shows the URL of HTTP GET and POST requests. Pktstat shows bandwidth over a 5 second window, so you can watch as different connections spike the bandwidth; although, on a busy network all this noise can make it hard to see which connections are really using the most bandwidth over time. See 'iptraf' to get a better idea of connection trends.

Run pktstat like this:

pktstat -i eth0 -n -t

You can add libpcap-style filters as the last argument on the command-line. For example:

pktstat -i eth0 -n -t "port 80"

Example output:

interface: eth0
   bps    % desc                                                               
695.0k  22% tcp 207.46.13.28:80 <-> 192.168.78.242:1917
            └ GET /msdownload/update/v3-19990518/cabpool/windowsmedia-kb911564-
531.0k  17% tcp 207.46.13.28:80 <-> 192.168.78.242:1918
            └ GET /msdownload/update/v3-19990518/cabpool/windowsxp-kb923689-x86
181.2k   5% tcp 192.168.78.242:49175 <-> 78.117.211.178:7480
 86.6k   2% tcp 192.168.78.242:58282 <-> 79.85.212.131:22
 41.0k   1% tcp 192.168.78.242:2951 <-> 89.88.152.10:80
 32.7k   1% tcp 192.168.78.242:3143 <-> 89.88.152.10:80

iftop

This generates curses bar graphs showing bandwidth per host or per connection. That is, it can group all bandwidth per host, or group by individual connections. The view is updated quickly, but also includes a weighted average, so this balances spikes with trends. The top two connections over the last 10 seconds always appear at the top. Bandwidth numbers are shown for the last 2,10, and 40 seconds. Iftop supports libpcap-style filters, so you can look at just certain types of traffic.

Run iftop like this to show bandwidth broken down by individual connections with port numbers (more like pktstat):

iftop -i eth0 -p -P -n -N

Run iftop like this to show bandwidth grouped by host:

iftop -i eth0 -p -n -N

You can add libpcap-style filters if you want to look at only some connections. Here we want to see all connections to 192.168.1.16 (a mail server), but we don't want to see the traffic between 192.168.1.14 (an iSCSCI storage server) and the mail server:

iftop -i eth0 -p -P -n -N -f "net 192.168.1.16 and not net 192.168.1.14"

This shows all HTTP traffic:

iftop -i eth0 -p -P -n -N -f "port 80"

You can also add or change a filter while iftop is running by pressing the f key.

Example output:

                1.91Mb          3.81Mb          5.72Mb          7.63Mb    9.54Mb
└───────────────┴───────────────┴───────────────┴───────────────┴───────────────
192.168.2.79               => 192.168.2.16                  0b   1.68Mb   429Kb
                           <=                               0b    894Kb   223Kb
192.168.2.222              => 63.127.105.19              11.6Kb  8.50Kb  7.13Kb
                           <=                             174Kb  90.5Kb  65.2Kb
192.168.2.101              => 67.81.212.4                   0b   1.24Kb   636b
                           <=                               0b   10.0Kb  5.00Kb
192.168.2.169              => 192.168.2.16               3.66Kb  3.70Kb  3.72Kb
                           <=                            7.31Kb  7.39Kb  7.43Kb
192.168.2.107              => 72.132.51.7                1.03Kb  1.40Kb  1.30Kb
                           <=                            7.84Kb  9.20Kb  8.95Kb
192.168.2.169              => 67.81.212.4                3.45Kb  3.29Kb  3.25Kb
                           <=                            7.24Kb  6.99Kb  6.83Kb
192.168.2.178              => 219.84.199.16               160b   4.90Kb  2.07Kb
                           <=                            1.26Kb  2.31Kb   817b
192.168.2.168              => 64.94.216.122                 0b    421b    105b
                           <=                               0b   6.42Kb  1.60Kb
171.218.122.18             => 192.168.2.45                  0b   3.37Kb  1.20Kb
                           <=                               0b   2.79Kb  1.08Kb
────────────────────────────────────────────────────────────────────────────────
TX:             cumm:     0B    peak:      0b   rates:      0b      0b      0b
RX:                    7.21MB           12.9Mb            249Kb  2.74Mb   894Kb
TOTAL:                 7.21MB           12.9Mb            249Kb  2.74Mb   894Kb

iptraf

Iptraf shows local and remote paired together with IP address and port. Press 's' then 'b' to view traffic sorted by byte count. This view is very similar to 'pktstat -i eth1 -n -t'. The sorting seems to update in a non-intuitive way. This is a useful tool, but you can get the same information with pktstat and iftop.

Run iptraf like this:

iptraf -i eth0

If you run it without arguments you get a screen with many more options, such as "LAN Station Monitor" (shows all MAC addresses in packets seen). Strangely, you can't get to these views if you start iptraf with the "-i eth0" option.

iptraf

tcptrack

Tcptrack is yet another top-like network monitoring tool. It updates its display very quickly. There is no startup delay at all. The fast update can make the output be noisy on a busy network. The output is very compact and easy to read.

tcptrack -i eth0 -n -t

wireshark

Wireshark's specialty is following and decoding streams at the packet level. Wireshark is a GUI app. It's like an IDE for packet anaylsis. Wireshark is the best tool for detailed packet analysis. It isn't as useful for a high-level bandwidth usage overview. It can give far more information than you need just to track down a bandwidth hog. Once someone had a machine on my network that was infected with a virus that was used to relay spam. I couldn't figure out who's machine was sending the traffic. Using Wireshark I generated a Statistics report of "Destinations with filter: SMTP". This report showed that one particular machine on our network was responsible for 43% of our network's SMTP traffic. I was able to confirm the machine was infected by looking at the contents of some of the SMTP packets coming out of the machine. I selected one of the packets from a suspicious SMTP connection then I used "Analyze|Follow TCP Stream" to reconstruct and decode the entire SMTP conversation. From this view it was clear that the contents was spam. Decoding the SMTP stream was helpful, but I didn't even need to do that. From just the ASCII view of a raw packet I could tell most of the SMTP traffic from the suspect machine was spam.

tcpick

Tcpick tries to reassemble packets in order. It's like a mini command-line version of Wireshark. With a bit of Judo you can turn a meaningless buzzing cloud of packets into something meaningful. For example, the following is a crude, but effective Yahoo Instant Messenger sniffer:

tcpick -i eth0 -yP "host 192.168.1.2" | grep YMSG

You could also do the same thing by looking only for Yahoo IM packets like this:

tcpick -i eth0 "port mmcc" -S -yP   # port 5050

For AIM packets use this:

tcpick -i eth0 "port aol" -S -h -yP   # port 5190

The -h option shows headers. You need that for AIM to figure out who sent which message. Yahoo puts this information in the message, so -h is not necessary with Yahoo.

Show HTTP GET requests on the entire network LAN:

tcpick -i eth0 -yP | grep GET

It will also reassemble packet payloads back into the files being transfered.

tcpdump

This is the granddaddy of most packet sniffers. In fact, many tools use the same port filter syntax (since they use libpcap). I don't find this tool useful for quick and dirty jobs. Packet data is dumped in raw binary which makes it hard for a human to read. Tcpick is more useful for this type of quick and dirty dump because it can filter and translate the unreadable characters.

For example, the following will dump all Yahoo IM traffic to stdout:

tcpdump -i eth0 "port mmcc" -n -w -

vnstat

vnstat is an overall bandwidth monitoring tool somewhat like bmw. The advantage of vnstat is that it does not actually sniff packets, so it has almost no overhead. The disadvantage is that it cannot distinguish different types of traffic -- it only knows bytes in and bytes out. It watches /proc/net/dev and logs the packet counts. You can do this too simply by running "cat /proc/net/dev".

Run vnstat once to initialize its database for the device you want to monitor:

vnstat -u -i eth0

Then put the same line in a /etc/crontab to update every 5 minutes:

*/5 * * * * root /usr/bin/vnstat -u -i eth0

Finally, you can see the latest stat by running:

vnstat

or

vnstat -h

driftnet

This is a GUI application. This decodes and displays all images that it sees over the network. Most of these are GIF or JPG images from web requests. This is stupid fun. Man, how I laughed, giddy with the power of my own super villainy. Driftnet is also an object lesson in the complete lack of privacy on a network. Every picture you mail; every picture you see on a web page; and every picture you copy over a shared network drive can by seen by Driftnet.

Driftnet is available here http://www.ex-parrot.com/~chris/driftnet/ .

Run driftnet like this:

driftnet -i eth0

= tcpxtract

`Tcpxtract` works similar to `driftnet`, but it is more efficient and able to identify a wider variety of files. You can also add formats and convert `foremost` configuration files to `tcpxtract`.

http://tcpxtract.sourceforge.net/

tcpxtract -d eth0

urlsnarf

This tool will sniff packets and print out HTTP requests in Common Log Format. It's simple! It's handy not only for egregious invasions of privacy but also for web development and debugging. This comes in real handy when you want to see what is happening in an HTTP session without having to setup some sort of proxy logger.

Run urlsnarf like this:

urlsnarf -i eth0

dsniff

This tool looks specifically for passwords on various protocols. It has no purpose but to demonstrate that stealing passwords from unencrypted network traffic is not merely theoretical, it is in fact trivially easy. So why are you still using FTP?

lanmap

This listens to an interface and draws graphical maps of the network connections that it sees. It uses graphviz to produce images. It shows connections between machines on a network and includes percentage of bandwidth use. Lanmap updates a PNG image every 60 seconds. Unfortunately, it doesn't run as a real daemon process. You just fire it up from the command-line and let it run however long you like. Every 60 seconds it will overwrite the last lanmap.png image with the latest network view.

lanmap -i eth0

darkstat

This gathers network statistics and serves the results in nice graphs over the web. Darkstat has a built-in web server, so all you do it start it up and forget about it. There is almost nothing to configure. I keep this one running all the time. It's handy and doesn't take up many resources. The downside is that it the graphs are not labeled very clearly. It's hard to tell what the scale is. Also, the host statistic only show source ports -- not destination ports -- WFT? Still, it's worth a look.

darkstat -i eth0 -b 192.168.2.2

The -b option tells darkstat which IP address to bind to for running the built-in web server. If you have two NICs then this assumes that your niffer NIC is eth1 and your IP address, 192.168.2.2, is on another NIC such as eth0.

etherape

This is like a real-time X11 windowed output of lanmap. On a busy network this can be pretty noisy, it's still very useful. You can see at a glance who is using the most connections. You have to tune the feature that increases line size and node size based on bandwidth because the default configuration creates giant nodes and fat lines that make the graph nearly unreadable.

Final Thoughts

Sysadmin oath:

 With great power comes great responsibility.
 This is my gift, my curse.

User oath:

 Never trust a Sysadmin.
 All traffic everywhere should be over SSL.
 I will never use the net without SSL.
 My God, why doesn't everybody use SSL?