Switched Net? dsniff It.
There's no way to sniff traffic over a switched network? dsniff begs to differ.
This article was inspired by a recent conversation on IRC. A person calling himself Zeus (no ego problems there) claimed to be the senior network administrator for a big company, which shall remain nameless. I rather doubt this claim, as he seemed to lack understanding of networking basics. Such as, among other things, claiming that using encryption to protect sensitive data on a switched network was unnecessary, since it was not possible for users to sniff any traffic but their own.
Well now, when it comes to computing, never say never. The wonderfully useful dsniff utility makes snooping on switched segments rather easy. As with all tools, it can be used for good or ill. It's a great addition to the network administrator's toolbox, and it can also be used for difficult-to-detect unauthorized snooping.
Of course the easiest way to capture LAN traffic is to replace a switch with a hub, which you can do when you are in charge and have some troubleshooting to do, and the switches are low-budget cheapies that have no monitoring ports. But you don't always have the luxury of bringing the network down for even the fraction of a minute that it takes to swap out a switch for a hub. Or you are averse to leaving your underground submarine lair because your Persian cat is asleep on your lap, and it is simply not possible to disturb the kitty, so you want to do everything from your master control center. That's when dsniff makes your life easier.
Using dsniff is not risk-free; you can mess up your network connectivity by bogging it down, or shutting it down entirely. Use it carefully. The best way to sniff network traffic is to use switches with monitoring ports but when this is not an option, dsniff is quite useful. And, you should have a good understanding of this small but mighty tool, since the black hats know and use it well.
Inside the Box
dsniff contains the following individual utilities:
A fearfully effective password sniffer that handles FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, VRRP, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase and Microsoft SQL protocols.
Grabs files sent via NFS (define)
Grabs mail POP and IMAP mail messages in realtime (mbox format only)
Grabs instant messages from AIM, ICQ 2000, IRC, MSN Messenger, and Yahoo Messenger
Grabs URL requests. See exactly where your users are surfing
Displays snarfed URLs in real-time in a Netscape browser
Forges ARP (define) entries to capture traffic intended for another host. This is how you spy on switched networks
Impersonate a DNS server
Floods the local network with random MAC (define) addresses, hopefully causing some switches to fail in open mode
"SSH monkey-in-the-middle." Intercepts and hijacks SSH1 sessions, in combination with dnsspoof. The author says "Only SSH protocol version 1 is (or ever will be) supported - this program is far too evil already."
Proxies and captures HTTP /HTTPS traffic redirected by dnsspoof, capturing most "secure" SSL-encrypted webmail logins and form submissions
Kill in-progress TCP (define) connections. This one is loads of fun!
Slows down TCP connections. It is nice only in comparison to tcpkill
Getting Past Those Pesky Switches
As you can see, it's trivially easy with arpspoof. All you do is fool a host or hosts into thinking that your machine is the gateway by sending it a forged ARP packet. Then you can capture and examine the re-directed traffic at your leisure. Meanwhile, your PC is forwarding the traffic on to its destination as though nothing untoward had happened.
So it goes like this:
# echo 1 > /proc/sys/net/ipv4/ip _forward
# arpspoof > dumpfile.txt
And there you are, spying on all traffic on your subnet, and storing it in a file for later analysis. Make sure that forwarding is enabled, or network traffic will stop at your box! To make forwarding permanent, surviving reboots, make this entry in /etc/sysctl.conf:
net.ipv4.ip_forward = 1
You can specify a single host:
# arpspoof -t 192.168.1.10 > dumpfile.txt
And that's pretty much all there is to it. Then turn loose your arsenal of analysis and filter tools on the captured packets, and soon you will know far too much about what your users are doing. If you want to see the packets in realtime as well as stuff them in a file, use the tee command:
# arpspoof | tee dumpfile.txt
Interesting Problems Resolved by Killing
libnids, dsniff's underlying TCP/IP reassembling library, needs to see the start of a connection in order to follow it. This means that at first your packet sniffer, whether it's tcpdump, Ethereal, or something else, won't show all network activity. If you want to be evil and impatient, use tcpkill to reset connections, then when the user re-connects you'll see the whole thing. Use ordinary tcpdump filters to select the connections you want to kill. This one wipes out an entire subnet:
# tcpkill -9 net 192.168.1
Or, kill individual hosts:
# tcpkill -9 net 192.168.1.25
tcpkill offers a range of brute force used to kill connections, from 1-9, with 9 being the most forceful. The default is 3. You may need the higher numbers on fast connections.
When connections are re-established and you can see the new traffic flowing, you can select specific URLs to kill:
# tcpkill -9 host www.nekkedstuff.com and host www.shoptilyoudrop.com
You can name ports:
# tcpkill -9 port 8888 and port 6699
You may use tcpnice in the same way. tcpnice slows connections, using the values 1-20, with 20 being the slowest. This is a handy little tool for messing with slacking Web surfers and downloaders.
The other dsniff tools are equally easy to use, and equally powerful. Use them to get an idea of how leaky your LAN really is.
dsniff home page at Monkey.org