Logo Background

Running Network Sniffer With dsniff

  • By on August 23, 2008 | No Comments

    Dsniff is a collection of free tools that were originally written for network and penetration testing, but that can be used for evil to sniff and hijack network sessions.

    As mentioned, dsniff is actually a collection of various tools. We’ll take a brief look at each individual tool, what it can do, and how it can be used for both good and evil purposes.


    We’ve talked about how network switches make sniffing more difficult because the switch is smart; it knows the Ethernet MAC address of every machine on every port, so only the destination machine receives the packet.

    However, sniffing on switched networks is still possible by forging ARP replies for the destination host. Arpspoof allows us to do that.

    You’ll recall that ARP is the protocol used to map an IP address to Ethernet MAC addresses. Because ARP requests are broadcast to the entire network (as in, “Hey everyone, which of your Ethernet cards has an IP address of”), they will always go out to everyone.

    The host running arpspoof can tell the issuer of the ARP request that it has the IP address in question, even if it doesn’t. You can fool the ARP request host and the switch into sending the packet to you instead of the intended recipient.

    You can then make a copy of the packet and use a packet forwarder to send the packet on to its intended destination like a relay.

    The command-line usage of arpspoof is arpspoof host_to_snarf_packets _from. You can specify which network interface to use with the -i option, and you can specify particular hosts you want to lie to by using the -t option.

    By default, arpspoof forges the MAC address of host_to_snarf_packets_from to all hosts on the LAN. The most popular host on a LAN to ARP spoof is the default router.

    Because all LAN traffic will pass through the router to get to other networks, ARP spoofing the router lets you sniff everything outbound on the LAN! Just don’t forget to set up IP forwarding so that the router still gets the packet; otherwise, your entire LAN loses its Internet connection!

    In the following example, we’re enabling IP forwarding on our Linux box (this has to be compiled into the kernel first) and trying to ARP poison into thinking that we ( are the default gateway (

    To enable the IP forwarding: –

    UNIX> cat /proc/sys/net/ipv4/ip_forward
    UNIX> echo 1 > /proc/sys/net/ipv4/ip_forward

    To poison the victim’s ARP cache with our MAC address: –

    UNIX> arpspoof -t

    In a seperate command we poison the gateway’s address –

    UNIX> arpspoof -t

    The first command checks to make sure the Linux kernel was compiled with IP forwarding. If this file does not exist, you’ll have to rebuild your kernel with IP forwarding.

    The second command enables the IP forwarding. The third command says that we should tell that we’re so that he’ll send all of his Internet-bound traffic through us.

    The fourth command says that we should tell the gateway that we’re him! If we don’t do this, we’ll be able to snoop only on the outgoing traffic, not the incoming traffic.


    This tool works similarly to arpspoof. It lets you forge DNS responses for a DNS server on the local network. Because DNS runs on User Datagram Protocol (UDP), a connectionless protocol, a DNS client will send out a query and expect a response.

    The dnsspoof tool will simply forge a response (telling the client that the hostname resolves to its IP) and attempt to get it there before the real response from the intended DNS server arrives.

    Dnsspoof can forge responses for all DNS queries it receives, or you can create a file in hosts(5) format (called spoofhosts, for example) that resolves only specific names to your local IP address and then run dnsspoof with the -f spoofhosts option to have it lie about only these specific IP-host mappings.

    An example spoofhosts file is shown next ( is the address of the machine running dnsspoof): mail* www*

    This file tells dnsspoof to forge DNS responses only for hostnames beginning with mail or www instead of forging responses to every DNS query it intercepts.

    Other than the same -i option that arpspoof takes to specify a network interface, the only argument dnsspoof takes is a tcpdump packet-filter expression for sniffing. It will use that expression to find any DNS traffic so that it can forge responses to any incoming queries on the LAN that it can see.

    If you first use arpspoof to spoof the MAC address of the intended DNS server, you can ensure that dnsspoof will always receive the DNS queries for the LAN and will always be able to respond with spoofed hostname/IP mappings.

    In the next example, is the DNS server and is once again our victim.

    UNIX> echo 1 > /proc/sys/net/ipv4/ip_forward
    UNIX> arpspoof -t &;
    UNIX> arpspoof -t &;
    UNIX> dnsspoof -f spoofhosts host and udp port 53

    The first few commands set up the same bidirectional ARP spoofing that we used in the previous section. It allows us to fool into thinking that we’re the DNS server.

    The final command listens for DNS traffic involving, and any queries for hosts beginning with www or mail will be answered with an IP address of Other DNS queries should be ignored and passed through to the real DNS server.

    So if points his web browser at http://www.yahoo.com, he’ll actually be talking to the web server running on our machine, Notice that we’ve been careful to specify the host in our dnsspoof command.

    If we leave this out, dnsspoof will attempt to forge a DNS response to every DNS request it snoops, which is not what we want in this case.

    Arpspoof and dnsspoof allow you to masquerade as different machines on a network. The benefits are obvious for malicious hackers, but can these two tools be used for good? Of course! In addition to network and firewall testing, system administrators could use the masquerading techniques to create a type of honeypot for potential “insider” hackers.

    You could set up arpspoof and dnsspoof so that a visit to a popular hacking and vulnerability web site actually went to a bogus site under your control. The bogus site looks much like the real site, except the bogus site tells the tale of a simple exploit for a critical system you’re running.

    Of course, this tale is completely fabricated and won’t harm your system at all, but you can sit back and see whether anyone tries this bogus exploit against you. If someone does, you’ve found yourself a troublemaker.


    The dsniff tool is an advanced password sniffer that recognizes several different protocols, including TELNET, FTP, SMTP, Post Office Protocol (POP), Internet Message Access Protocol (IMAP), HTTP, CVS, Citrix, Server Message Block (SMB), Oracle, and many others.

    Whereas other sniffers such as Ethereal will give you tons of additional information about the connection and the individual packets, you use dsniff if all you want are usernames and passwords.

    The only other argument that dsniff can use is a tcpdump packet-filter expression so that you can specify what kind of traffic you want to sniff for passwords.

    Let’s run dsniff to see whether our friend bob logs into something:

    [root@originix sbin]

    UNIX> dsniff -t 21/tcp=ftp,23/tcp=telnet -n

    Kernel filter, protocol ALL, raw packet socket
    dsniff: listening on eth0 []
    03/23/02 09:40:50 tcp – (ftp)
    USER bob
    PASS bob123
    03/23/02 09:41:52 tcp – (telnet)

    There’s bob. He FTP’ed in and we grabbed his password. But what about the telnet session below it? Dsniff appears to have captured an attempted root login via telnet. The login seems to have been unsuccessful, because it appears the user then tried logging in as jdoe with the password password and got into the system.

    Dsniff then recorded the ls command being executed. Now, most systems don’t allow root access via telnet even if the correct password is provided. The password guessme could very well be the root password. And because we now know jdoe’s password, we can get on the system and give it a try.

    Had jdoe attempted an su to root later in the connection, dsniff would have caught that, too. That’s why dsniff captures subsequent commands as well as login information from the telnet session.

    You’ll notice that dsniff waits until a connection terminates before it outputs its information. This is in case it detects any other useful username/password information somewhere other than in the initial login.


    Tcpdump can be used to sniff NFS traffic. The filesnarf tool can actually take the sniffed file and reassemble it on your system. Anytime someone moves a file via NFS over the network, you can grab a copy of it, even if the NFS export isn’t available to you.

    Again, you can use the –i option to specify the network interface. On the command line, you can also specify a tcpdump packet-filter expression to use for sniffing NFS traffic and the file pattern to match (only snarf *.conf files or snarf files called passwd).

    If you want to snarf all files except certain files (say, you want to snarf everything except MP3 files), you can invert the file pattern matching with –v like so:

    UNIX> filesnarf -v '*.mp3'

    And if you wanted to snarf only non-MP3 files from, you would use this:

    UNIX> filesnarf -v '*.mp3' host


    The macof tool will flood the local network with random, conjured MAC addresses in the hopes of causing a switch to fail and start acting like a hub, allowing dsniff to have more success in a switched network environment.

    You can run macof by itself to generate random TCP/IP traffic with the random MAC addresses, or you can specify the type of traffic using command-line flags. You can control the network interface used (-i), the source and destination IP address (-s and -d), the source and destination port (-x and -y), a single target hardware address (-e), and the number of made-up packets to send (-n).


    As filesnarf does for NFS, mailsnarf reassembles sniffed e-mail messages from SMTP and POP protocols. It saves the messages in standard mbox format so that you can browse them as you would any Unix mailbox using mutt, pine, or whatever Unix mail application you choose.

    The options are exactly the same as filesnarf, except instead of specifying file pattern matching, you specify regular expressions to be matched in the header or body of the message.


    Like the other snarf programs, msgsnarf does the same thing for popular chat programs such as AOL Instant Messenger, Internet Relay Chat (IRC), ICQ, and MSN and Yahoo!’s messenger utilities.

    In this case, you can specify a regular expression pattern to search for in the messages (such as saving only messages that contain the word password in them). Here we’ve intercepted a message from cauliflowericious to broccoliastic.

    UNIX> msgsnarf "password"

    msgsnarf: listening on ep0
    Aug 18 16:07:11 AIM cauliflowericious > broccoliastic:
    Yeah, just log in to http://www.myserver.com/myprivatefiles/. My password is xxx. You can use them for as long as you want.


    Sshmitm is one of the nastier tools that comes with dsniff. Assuming you’re running dnsspoof to forge the hostnames of a real machine, sshmitm (which stands for “SSH Monkey in the Middle”) can sniff the SSH traffic redirected to your machine. It supports only SSH version 1 (a good reason to upgrade to version 2).

    How is this done? The dnsspoof tool lets us intercept an SSH connection to another machine. All we have to do is start sshmitm on port 22 (we can change the port sshmitm uses with the -p option) and set it up to relay the SSH connection to the true host.

    If we’re running dnsspoof to tell people that we’re host foohost when actually is foohost, when somehost does an SSH to foohost, it looks up foohost first and finds it at our forged IP address. So if we run the command sshmitm –p 22 22, we can intercept the SSH connection from somehost before passing it on to foohost.

    What does this buy us? When SSH negotiates the keys to use for encrypting the data, sshmitm can intercept the key from somehost and replace it with a key that we know about. This will allow us to decrypt all information in the hijacked connection.


    This tool attempts to kill a TCP connection in progress by spoofing a reset (RST) packet and injecting it into the legitimate connection. As with many of the other tools, the -i option will choose your interface and a tcpdump packet-filter expression can be used to select the type of connections you want to kill.

    An additional option, -num, where num is any number from 1 through 9, tells tcpkill how hard it needs to try to kill the connection. Faster connections may be more difficult to inject packets in than slower connections. The default “kill” level is –3.


    So maybe you don’t want to kill a connection completely. Tcpnice will let you just slow it down a bit. You use the same options used in tcpkill, except instead of trying to inject RST packets with a varying level of severity, you use the -n increment option to specify how much you want to slow down the connection.

    An increment of 1 is the default speed and an increment of 20 is the slowest speed. The tool performs this slowdown by adjusting the amount of data that hosts say they can handle.

    Part of the TCP header is the window size, which allows a host to advertise the maximum amount of data it can handle. The tcpnice tool sniffs the traffic matching your tcpdump packet-filter expression and alters the value of the window size advertisement to be smaller than it really is. You use the -n flag to adjust how much smaller the window is made.

    This will tell the host on the other end of the conversation that it needs to stop sending so much data so quickly, and the connection will slow down. To add fuel to the fire, you can use the –I option to forge ICMP source quench replies to make the host on the other end think that it’s flooding the host with more data than it can handle. This can cause the connection to slow down even more.


    Urlsnarf works just like all the other snarf programs in this tool kit, except it works on web URLs. It stores any URLs it sniffs from HTTP traffic into a logfile that can be analyzed later. It’s a quick and easy way to see what the people on your local network are looking at when they surf the Web.


    This tool does for HTTPS (SSL-enabled web traffic) what sshmitm does for SSH. It requires the use of dnsspoof and operates in the same manner, interjecting a fake SSL certificate (that will allow the “monkey in the middle”) to decrypt all data that we pass back and forth.

    The one drawback here is that the user might be notified by the web browser that the certificate for a particular site has changed. Many users will ignore this message, however, and continue with the session.


    This final tool in the dsniff package is a bit frivolous. By specifying an IP address of a host on your LAN, webspy will sniff for web traffic originating from that host. Whenever that host surfs to a particular URL, webspy will load the same URL on your Netscape browser.

    All you need to do is have your Netscape web browser running before starting webspy. See exactly what your friend down the hall is surfing. Talk about an invasion of privacy!

    UNIX> webspy -i eth0 (victim IP address)
    UNIX> mozilla &;

    As you can see, some extremely dangerous tools have been outlined here. Although the tools’ author genuinely intended them for good use, it’s quite obvious that hackers could use these tools to sniff all kinds of secret information that doesn’t belong to them—even information that’s supposed to be encrypted!

    The drawback is, of course, as with any sniffer, you need to be on the same local network as your victim. Tools like this should make every network security manager think twice about trusting internal users.

    » Gather Table Statistics In Oracle 10g
Leave a Comment