- 1 Packet Sniffing
- 1.1 Create a virtual promiscuous interface
- 1.2 Create undetectable interface
- 1.3 Create a virtual wifi monitor mode interface
- 1.4 Packet Sniffing Tools
- 1.4.1 ipaudit
- 1.4.2 ipband
- 1.4.3 bwm
- 1.4.4 pktstat
- 1.4.5 iftop
- 1.4.6 iptraf
- 1.4.7 tcptrack
- 1.4.8 Wireshark
- 1.4.9 tcpflow
- 1.4.10 tcpick
- 1.4.11 tcptrace
- 1.4.12 ttt
- 1.4.13 ngrep
- 1.4.14 ssldump
- 1.4.15 chaosreader
- 1.4.16 tcpxtract
- 1.4.17 tcpdump
- 1.4.18 vnstat
- 1.4.19 driftnet
- 1.4.20 urlsnarf
- 1.4.21 dsniff
- 1.4.22 lanmap
- 1.4.23 darkstat
- 1.4.24 etherape
- 1.5 Final Thoughts
Create a virtual promiscuous interface
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.
The problem with this is that it may still dirty the network by sending some packets (in response to ARP and ICMP and the like). This isn't totally silent.
Create undetectable interface
# Set the interface MAC address so that it is invalid # even if it does send out a packet (which it shouldn't). # Turn on promiscuous mode. ifconfig eth0 hw ether 00:00:00:00:00:00 promisc # Bring up the interface and ignore ARP. ifconfig eth0 -arp up
ARP can also be disabled via `sysctl`.
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
You can permanently set this by editing /etc/sysctl.conf:
net.ipv4.conf.eth0.arp_ignore = 1
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 too 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 | +------------+
This is a good tool when you want to gather long-term statistics that record [internal_IP]->[external_IP, dest_port, bandwidth]. This lets you track bandwidth per IP and port. You can see who hogs all the bandwidth on Friday afternoon by watching YouTube videos.
This is a similar tool to ipaudit. This is a good tool for logging long-term bandwidth usage statistic associated with internal IP addresses. It is a bit simpler and easier to build. It is console-only.
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.
aptitude install bwm-ng
Just run it like this:
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.
+ 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"
interface: eth0 bps % desc 695.0k 22% tcp 220.127.116.11:80 <-> 192.168.78.242:1917 └ GET /msdownload/update/v3-19990518/cabpool/windowsmedia-kb911564- 531.0k 17% tcp 18.104.22.168:80 <-> 192.168.78.242:1918 └ GET /msdownload/update/v3-19990518/cabpool/windowsxp-kb923689-x86 181.2k 5% tcp 192.168.78.242:49175 <-> 22.214.171.124:7480 86.6k 2% tcp 192.168.78.242:58282 <-> 126.96.36.199:22 41.0k 1% tcp 192.168.78.242:2951 <-> 188.8.131.52:80 32.7k 1% tcp 192.168.78.242:3143 <-> 184.108.40.206:80
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.
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 => 220.127.116.11 11.6Kb 8.50Kb 7.13Kb <= 174Kb 90.5Kb 65.2Kb 192.168.2.101 => 18.104.22.168 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 => 22.214.171.124 1.03Kb 1.40Kb 1.30Kb <= 7.84Kb 9.20Kb 8.95Kb 192.168.2.169 => 126.96.36.199 3.45Kb 3.29Kb 3.25Kb <= 7.24Kb 6.99Kb 6.83Kb 192.168.2.178 => 188.8.131.52 160b 4.90Kb 2.07Kb <= 1.26Kb 2.31Kb 817b 192.168.2.168 => 184.108.40.206 0b 421b 105b <= 0b 6.42Kb 1.60Kb 220.127.116.11 => 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 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.
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
See also 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. 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.
This is a like `tcpdump`, but it separates each session (connection/stream).
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.
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
IMPORTANT!!! Use RIGHT-CLICK to view the next graph.
Real-time graph of bandwidth split on sessions.
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 -> 18.104.22.168: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.... #######
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.
This tool will analyze a packet capture log and rebuild a timeline of all sessions and the binary payload data that was transmitted. It builds an HTML report with links to detailed information about each sessions, including links to images and binary data. It works best by analyzing capture files. It can capture data itself by calling tcpdump. The syntax is weird because you have to trick it to select the interface.
Chaosreader has not been updated in a long time, but it is a pretty solid program and is worth a look.
tcpdump -i eth0 -s 0 -v -w CAPTURE_DATA.pcap chaosreader -ve CAPTURE_DATA_IN.pcap
Here is the only way I could figure out how to select the interface:
chaosreader -S 1 -f '-i eth2'
The -f option is supposed to set a filter that is passed to tcpdump. In this case I pass '-i eth2' which seems to work. It appears that chaosreader just appends this string to the command it builds for tcpdump.
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. `Tcpxtract` works similar to [[#chaosreader] and #driftnet. You can also add new file formats and convert `foremost` configuration files to `tcpxtract`. The only downside is that it usually retrieves corrupt images and it seems to dump core a lot.
Note that it is not spelled tcpextract.
tcpxtract -d eth0
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 will record all raw traffic to a dump file for latter analysis. The -s 0 option specifies that the full packet should be saved without truncation; the -v option will report every 10 seconds the number of packets captured so far.
tcpdump -i eth0 -s 0 -v -w traffic.pcap
The following tcpdump example will dump raw binary Yahoo IM traffic to stdout. Note the '-w -' option to write binary to stdout.
tcpdump -i eth0 -n -l -w - "port mmcc"
This will dump Yahoo IM with filtering of unreadable binary characters. Note the -A, -q, and -s 0 options are used to filter and dump ASCII data. The -l option sets line-buffered output. You may also remove the -t option if you would like to see timestamps on each packet.
tcpdump -i eth0 -l -t -A -q -s 0 "port mmcc"
The following will dump mail traffic.
tcpdump -i eth0 -l -t -A -q -s 0 "port 25 or port 587 or port 110 or port 143"
Error: "Permission denied" with tcpdump
You may get a Permission denied error when working with tcpdump. This is probably caused by AppArmor. You can check by running this command:
grep tcpdump /sys/kernel/security/apparmor/profiles
If you see tcpdump in that file then you can set AppArmor to just complain instead of block by running the following:
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:
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
- See also #tcpxtract.
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'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.
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
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.
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.
With great power comes great responsibility. This is my gift, my curse.
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?