Packet sniffing
Packet Sniffing
Create a virtual promiscuous interface
Edit /etc/network/interfaces:
iface eth1 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
Then use `ifup eth1` to bring up the interface.
Create a virtual wifi monitor mode interface
iw dev wlan0 interface add wlan0-mon type monitor
ifconfig wlan0-mon up
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
+ easy to read
+ shows GET and POST requests
- noisy on a busy network (no weighted average)
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.
tcpflow
This is a like `tcpdump`, but it separates each session (connection/stream).
tcpick
Tcpick rebuilds individual connection streams by assembling packets in order. It's like a mini command-line version of Wireshark's "Follow TCP Stream" function. Tcpick has options to output data in hex or plain text with binary stripped.
You can also use it to display individual packets as that are seen. In this mode you don't make use of the stream rebuilding features, but it is still handy for quickly displaying packets with binary stripped out.
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.
tcptrace
This can be used to create graphs of network traffic capture files in tcpdump format.
tcpdump -s 0 -v -w CAPTURE_DATA.pcap
tcptrace -b CAPTURE_DATA.pcap
1 arg remaining, starting with 'CAPTURE_DATA.pcap'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
1795 packets seen, 1652 TCP packets traced
elapsed wallclock time: 0:00:00.007251, 247552 pkts/sec analyzed
trace file elapsed time: 0:03:12.421647
TCP connection info:
1: noah-www-2.local:22 - noah-lab-1.local:35333 (a2b) 260> 273<
2: noah-www-2.local:46979 - apache2.hosting.example.com:21 (c2d) 12> 11< (complete)
3: noah-lab-1.local:35383 - noah-www-2.local:22 (e2f) 6> 3<
4: noah-lab-1.local:52213 - noah-www-2.local:80 (g2h) 14> 12< (complete)
...
17: noah-lab-1.local:52266 - noah-www-2.local:80 (ag2ah) 14> 12< (complete)
This will generate graphs for all the connections found. This assumes you have a /var/www/tmp directory created.
tcptrace -G --output_dir=/var/www/tmp CAPTURE_DATA.pcap
This will display plots of all the
xpl' files. This is a GUI client; the output goes to your X-Server DISPLAY. The
-1 options tells xplot to only display one plot at a time; otherwise, you could end up with hundreds of windows opening all at once!
xplot.org -1 /var/www/tmp/*.xpl
ttt
Real-time graph of bandwidth split on sessions.
ngrep
This watches traffic and displays packets that match a regular expression. A hash (#) is printed for packets that do not match. You can silence these with the '-q' option.
ngrep noahinterface: eth0 (192.168.1.0/255.255.255.0)
match: noah
###################################
T 192.168.1.100:37782 -> 72.14.213.103:80 [AP]
GET /search?client=navclient-auto&ch=1432752782324342&features=Rank&q=info:
www.noah.org/wiki/index.php?title=Packet_sniffing&action=edit&num=10&filter
=0 HTTP/1.1..Host: toolbarqueries.google.com..User-Agent: Mozilla/4.0 (comp
atible; GoogleToolbar 2.0.014-big; Windows XP 5.1)..Accept: text/html,appli
cation/xhtml+xml,application/xml;q=0.9,*/*;q=0.8..Accept-Language: en-us,en
;q=0.5..Accept-Encoding: gzip,deflate..Accept-Charset: ISO-8859-1,utf-8;q=0
.7,*;q=0.7..Keep-Alive: 300..Connection: keep-alive..Cookie: PREF=ID=23e242
dc21976ddf:U=4342ff978587e8A5:FF=4:LD=en:NR=10:TM=234634112:LM=34237456845:
L=0aa1ytQ5aNF-iaPVLnr_d5Xa7S6pnnMA:GM=1:IG=3:S=dtZloh8oE31hU522; NID=27=Z0z
Iu218YeVhAA4_mn78874HF_sdf234u342asdfAKJDhasDHKJH48y3HKJH_i7RQv9QR71GWFi0Jx
op5RsdfHSJDFHkhjd8247saKJffasdhkjh_haAA_iahz-78pYf; __utmv=162373262.gweb-e
xperiment-GoOrNoGo%20gweb-variation-go; TZ=420....
#######
ssldump
This looks interesting, but it is very old and it does not build on modern systems.
It identifies identifies SSLv3/TLS traffic and displays records in textual form. It can also decrypt the payload data if provided with the keys.
dead:
ssldump
tcpxtract
This tool will track network streams; identify data by patterns; and extract the data to files. For example, it can identify audio files, images, Word documents, etc. See also
#driftnet
http://tcpxtract.sf.net
Note that it is not spelled tcpextract.
tcpdump
Tcpdump is the command-line tool that comes with
libpcap -- the packet capturing library that is at the heart of most packet sniffing tools. In fact, you will see that many tools use the same port filter syntax since they just pass these options through to
libpcap.
Tcpdump is good for quick and dirty viewing of traffic, and for long-term monitoring. I find that
Tcpick is a little more intuitive because it puts packets from different sessions in the right order and it can save sessions to separate capture files.
Tcpxtract (not tcpextract) will actually reorder network packets, identify different types of data; and save the data to files (similar to what 'Foremost' will do for drive images).
The following
tcpdump example will dump raw binary Yahoo IM traffic to stdout:
tcpdump -i eth0 "port mmcc" -n -w -
This will dump Yahoo IM with filtering of unreadable binary characters:
tcpdump -i eth0 "port mmcc" -l -n -A -q -t -s 0
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` or better yet, `watch -n 0.5 cat /proc/net/dev`. All vnstat does is clean this up a little bit.
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`... The only downside is that it seems to core dump and it often retrieves corrupt files. It does not seem to be very good at reassembling packets. Maybe using it with tcpick could help.
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
Dsniff's is one tool in collection of tools that are often packaged as "Dsniff". The purpose of these tools is to demonstrate how trivial it is to compromise privacy on a network.
- sniff and record all logins and passwords on many different insecure protocols. Why are you still using FTP?
- spoof arp packets and make your machine become the network gateway. You can then see all packets even on a switched network.
- flood a switch with bogus MAC addresses which can cause some switches to fail into a open "hub" mode. Like spoofing arp packets this may let you see all packets on the network.
- sniff and record all web traffic.
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.
Source : http://www.noah.org/wiki/Packet_sniffing
