Without strong motivation for change, insecure network protocols and their implementations often go uncorrected, leaving much of the Internet vulnerable to attacks the research community has warned about for years (e.g. intercepting SSH / PGP private keys and .Xauthority files via NFS, sniffing in a switched environment, exploiting trust relationships based on DNS, monkey-in-the-middle attacks against SSH and HTTPS, etc.). At the same time, pending legislation such as UCITA, the European Draft Cybercrime Treaty, and the DMCA threatens to criminalize security research that exposes flaws in the design and implementation of distributed systems. By publishing dsniff while it is still legal to do so, sysadmins, network engineers, and computer security practitioners will be better equipped with the tools to audit their own networks before such knowledge goes underground.

OpenBSD has already integrated the first three packages into the base system, leaving only libnet and libnids as additional dependencies (see /usr/ports/net/{libnet,libnids} or the OpenBSD FTP site for binary packages).

Linux, Solaris, and most other OSs require building all third-party packages first (including Redhat, which ships with a non-standard libpcap) (see rpmfind.net for binary RPMs, which you should always check with rpm --checksig).

This software also requires a basic understanding of network security for its proper use. I will not entertain such inane questions as "Can I use this to spy on my wife's chat sessions?", nor will I bother explaining the mechanism behind each exploit. RTFM, and RTFS.

A mailing list for dsniff announcements and moderated discussion is available. Send e-mail with the word "subscribe" in the body of the message to dsniff-request@monkey.org. No archive of this list is available yet.

You're probably linking against a different version of libpcap than the one used to build libnids (this is often reported by Linux users who've installed libnids from an RPM). Be sure to build libnids and dsniff against the same libpcap distribution.

The easiest route is simply to impersonate the local gateway, stealing client traffic en route to some remote destination. Of course, the traffic must be forwarded by your attacking machine, either by enabling kernel IP forwarding (sysctl -w net.inet.ip.forwarding=1 on BSD) or with a userland program that acccomplishes the same (fragrouter -B1).

Several people have reportedly destroyed connectivity on their LAN to the outside world by arpspoof'ing the gateway, and forgetting to enable IP forwarding on the attacking machine. Don't do this. You have been warned.

Make sure you are actually forwarding the intercepted packets, either via kernel IP forwarding or with fragrouter.

If you are indeed seeing the client's half of the TCP connection (e.g. as verified using tcpdump), make sure you've enable dsniff's half-duplex TCP stream reassembly (dsniff -c). The *snarf tools do not yet support this mode of operation.

libnids, dsniff's underlying TCP/IP reassembling library, needs to see the start of a connection in order to follow it. There are several good reasons for this, as outlined in Ptacek and Newsham's seminal paper on network IDS evasion.

The best you can do, in a live penetration testing scenario, is to

start sniffing

selectively reset existing connections with tcpkill, and then

wait for the users to reconnect

This is horribly intrusive and evil, but then again, so are pen tests. :-)

You may be losing some packets, either at the switch's monitor port (mirroring ten 100 Mbit Ethernet ports to a single port is never a good idea) or within libpcap - anathema to libnids, which needs to see all packets in a connection for strict reassembly. Try enabling dsniff's best-effort half-duplex TCP stream reassembly (dsniff -c) instead.

Other general performance enhancements for sniffing include:

SMP, which on most OSs results in only one processor handling the high interrupt load, leaving the other to do real work

Try enabling dsniff's magic (dsniff -m) automatic protocol detection, which should detect the appropriate protocol (if dsniff knows about it) running on any arbitrary port. If dsniff still fails to pick up the traffic, it may be an unusual protocol dsniff doesn't yet support. Create a dsniff services file like

hex 12345/tcp

where 12345 is the TCP port of the unknown service, run dsniff with -f services and send the resulting hexdump of the connection trace to me. Some proprietary protocols transmogrify almost daily, it's not easy keeping up!

dsniff's decode routines are admittedly pretty sleazy, and cut many corners for the sake of performance (and simplicity - you try fully decomposing all 30+ open / proprietary protocols that dsniff handles!). Additionally, many of the protocols dsniff handles are completely proprietary, and required a bit of reverse engineering which may not have been all that complete or accurate in the face of new protocol versions or extensions.

The best way to get new protocols handled by dsniff is to send me traffic traces of a few complete connections / sessions, from start to finish (making sure to capture the packets in their entirety with tcpdump -s 4096, or with Ethereal), along with any pointers to relevant documentation (or client/server implementations).

If you'd like to give it a try yourself, add an entry to dsniff's dsniff.services file to map the traffic you wish to analyze to the "hex" decode routine, and dissect the hexdumps manually.

Although HTTPS and SSH are encrypted, they both rely on weakly bound public key certificates to identify servers and to establish security contexts for symmetric encryption. As the vast majority of users fail to comprehend the obtuse digital trust management PKI presents (e.g. is an X.509v3 DN really meaningful to you?), a simple monkey-in-the-middle attack works quite well in practice.

Client traffic to a target server may be intercepted using dnsspoof and relayed to its intended destination using the sshmitm and webmitm proxies (which also happen to grep passwords in transit). For example, to sniff Hotmail webmail passwords, create a dnsspoof hosts file such as:

1.2.3.4 *.passport.com
1.2.3.4 *.hotmail.com

where 1.2.3.4 is the IP address of your attacking machine. Local clients attempting to connect to Hotmail will be sent to your machine instead, where webmitm will present them with a self-signed certificate (with the appropriate X.509v3 distinguished name), and relay their sniffed traffic to the real Hotmail site.

sshmitm is perhaps most effective at conference terminal rooms or webcafes as most travelling SSH users don't carry their server's key fingerprint around with them (only presented by the OpenSSH client, anyhow). Even sophisticated SSH users who insist on one-time passwords (e.g. S/Key), RSA authentication, etc. are still at risk, as sshmitm supports monitoring and hijacking of interactive sessions with its -I flag.

Chances are, you've built against an unstable version of libnids (libnids-1.14 on Solaris in particular). Upgrade to the latest version at http//www.packetfactory.net/Projects/Libnids/, and if you still have problems, rebuild everything with -g and send me a gdb stack backtrace.

From Brian Costello (http://www.mksecure.com/): You need to compile your kernel to include a Packet Socket - under Networking Options in your linux kernel config, you say YES to Packet Socket. If you have a 2.3/2.4 kernel, you should probably say yes to the mmapped I/O, as it gives superior performance.

From Simon Taylor (simon@band-x.net): It's actually already in the kernel, as a module: /sbin/insmod af_packet.

At layer-2: LBL's arpwatch can detect changes in ARP mappings on the local network, such as those caused by arpspoof or macof.

At layer-3: A programmable sniffer such as NFR can look for either the obvious network anomalies or second-order effects of some of dsniff's active attacks, such as:

ICMP port unreachables to the local DNS server, a result of dnsspoof winning the race in responding to a client's DNS query with forged data

excessive, or out-of-window TCP RSTs or ACK floods caused by tcpkill and tcpnice

dsniff's passive monitoring tools may be detected with the l0pht's antisniff, if used regularly to baseline network latency (and if you can handle the egregious load it generates). Honeynet techniques for sniffer detection (such as the sniffer detector at IBM Zurich GSAL) also present an interesting countermeasure of last resort...

At layer-2: Enabling port security on a switch or enforcing static arp entries for certain hosts helps protect against arpspoof redirection, although both countermeasures can be extremely inconvenient.

At layer-3: IPSEC paired with secure, authenticated naming services (DNSSEC) can prevent dnsspoof redirection and trivial passive sniffing. Unfortunately, IPSEC's IKE is an overblown key exchange protocol designed by committee, so unwieldy and perverse that widespread deployment across the Internet is almost unthinkable in the immediate future.

At layer-4: Don't allow proprietary, insecure application protocols or legacy cleartext protocols on your network. dsniff is useful in helping to detect such policy violations, especially when used in magic (dsniff -m) automatic protocol detection mode. This is largely a matter of remedial user education perhaps best left to the experienced BOFH. :-)

Strong, trusted third-party network authentication (such as Kerberos) isn't generally subject to the kind of trivial monkey-in-the-middle attacks that plague PKI in such ad-hoc deployments as SSH and HTTPS. Leveraging an authenticated naming service like DNSSEC for secure key distribution is one solution, although realistically several years off from widespread deployment. A reasonable interim measure is to have users enable SSH's StrictHostKeyChecking option, and to distribute server key signatures to mobile clients.

Firewalls can be a mixed blessing - while they protect sensitive private networks from the untrusted public Internet, they also tend to encourage a "hard on the outside, soft on the inside" perimeter model of network security. dsniff has perhaps been most effective behind the firewall, where Telnet, FTP, POP, and other legacy cleartext protocols run freely, unfettered by corporate security policy.