Often, things are not what they appear to be. To hear the media tell it, the worst fate a system administrator can suffer is for his Web server to be hacked and his Web page altered. Not true.
In fact, although these in-your-face hack attacks seem dramatic and often command screaming headlines, they're nothing compared to a real attack. Real crackers generally don't announce their presence or flaunt their achievements. Instead, they install surreptitious monitoring devices that stealthily gather information on your network.
Such tools are called protocol analyzers and are otherwise known as sniffers. This chapter will look at sniffers, what they do, and how they're designed. You'll also use some sniffers, examine their output, and explore how you can use them to bolster your security.
By default, workstations (even those housed on the same network) listen and respond only to packets addressed to them. However, it is possible to fashion software that throws a workstation's network interface into something called promiscuous mode. In this condition, the workstation can monitor and capture all network traffic and packets passing by, no matter what their legitimate destination may be.
To understand how programmers accomplish this, you must examine the header files (or building blocks) of sniffer programs. Programmers generally write sniffers in C, although Perl is also suitable, and with rare exception, they open their source with include directives like these:
#include <linux/if.h> #include <linux/if_ether.h> #include <linux/ip.h> #include <linux/socket.h> #include <linux/tcp.h> #include <netinet/in.h> #include <signal.h> #include <stdio.h> #include <sys/socket.h> #include <sys/time.h> #include <sys/types.h>
I won't assume that you have Linux's source code handy. So, when referring to a header file, I'll point to its location in the LXR Engine at http://lxr.linux.no. The LXR engine is a hypertext version of Linux source code that offers maximum browseability. The LXR is so hardcore that it cross-references every header file, every system call, most functions, and so on. Using it, you can access any point in Linux's source from any other point. This way, no matter what your situation, as long as you have Web access, we'll be on the same page.
Let's quickly run through some of the header files mentioned above and their purposes:
linux/if.h—Contains definitions for control of the Ethernet interface. Find it in the LXR engine at http://lxr.linux.no/source/include/linux/if.h.linux/if_ether.h—Contains definitions for the Ethernet IEEE 802.3 interface and various Ethernet protocols like AppleTalk, Ethernet Loopback, and Internet Protocol. Findif_ether.hin the LXR engine at http://lxr.linux.no/source/include/linux/if_ether.h.linux/in.h—Contains definitions for Internet address structure. Find it in the LXR engine at http://lxr.linux.no/source/include/linux/in.h.linux/ip.h—An implementation of IP for Linux. Find it in the LXR engine at http://lxr.linux.no/source/include/linux/ip.h.stdio.h—Handles standard input, standard output, and standard error output.sys/socket.h—Handles socket operations, includinglisten,bind,connect,accept,send, and so forth. It also contains definitions for various types of sockets (including AppleTalk, IPX, and on), the most important of which areAF_UNIX, or UNIX sockets. Findsys/socket.hin the LXR engine at http://lxr.linux.no/source/include/linux/socket.h.tcp.h—Contains definitions for various TCP connection states, such asTCP_ESTABLISHED(connection established),TCP_LISTEN(listening),TCP_CLOSE(closing), and so forth. Find it in the LXR engine at http://lxr.linux.no/source/include/linux/tcp.h.
Most sniffers are designed with these building blocks. Each handles a different aspect of listening, recording, and reporting TCP/IP traffic. However, hackers put the network interface into promiscuous mode using a flag from if.h (currently, on line 34) that looks like this:
#define IFF_PROMISC 0x100 /* receive all packets*/
In linsniffer (a tool we'll later use in this chapter), author Mike Edulla opens the interface in promiscuous mode like this:
int openintf(char *d)
{
int fd;
struct ifreq ifr;
int s;
fd=socket(AF_INET, SOCK_PACKET, htons(0x800));
if(fd < 0)
{
perror("cant get SOCK_PACKET socket");
exit(0);
}
strcpy(ifr.ifr_name, d);
s=ioctl(fd, SIOCGIFFLAGS, &ifr);
if(s < 0)
{
close(fd);
perror("cant get flags");
exit(0);
}
ifr.ifr_flags |= IFF_PROMISC;
s=ioctl(fd, SIOCSIFFLAGS, &ifr);
if(s < 0) perror("cant set promiscuous mode");
return fd;
}
Once the interface is in promiscuous mode and is therefore hearing all packets on the network, what remains is to listen for TCP/IP traffic and format it into human-readable form on standard output, or by writing it to a file.
Is promiscuous mode necessary? That depends on what you're trying to accomplish. Certainly, you can write a tool that will listen to all packets on the local host without throwing the interface into promiscuous mode. However, to catch all traffic on the local network segment, promiscuous mode is a requisite.
Different sniffers perform different tasks, ranging from the simple (capturing usernames and passwords) to the extreme (recording all network interface traffic). In this section, we'll test out several sniffers, including:
linsnifferlinuxsnifferhuntsniffit
linsniffer is simple and to the point. Its main purpose is to capture usernames and passwords, and it excels at this.
Application: linsniffer by Mike Edulla
Required: C and IP header files
Config Files: None
Location: http://agape.trilidun.org/hack/network-sniffers/linsnifferc
Security History: linsniffer has no significant security history.
Notes: linsniffer is easy to use. However, some installation notes: You'll need the full complement of IP header files, including those normally stored in /usr/include/net and /usr/include/netinet. Additionally, ensure that your PATH variable includes /usr/include.
To compile linsniffer, issue the following command:
$cc linsniffer.c –o linsniffer
To run linsniffer, issue the linsniffer command at a prompt:
$linsniffer
At this point, linsniffer creates an empty file named tcp.log. This is where linsniffer writes its output.
For this example, I created a user named hapless with a login password of unaware. I then logged in from the SGI as hapless and generated some basic user activity. Here's a transcript of the session from the SGI:
GNSS $ ftp 172.16.0.2 Connected to 172.16.0.2. 220 linux2.samshacker.net FTP server (Version wu-2.4.2-academ [BETA-17](1) Wed Aug 19 02:55:52 MST 1998) ready. Name (172.16.0.2:root): hapless 331 Password required for hapless. Password: 230 User hapless logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -al 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 14 drwxrwxr-x 4 hapless hapless 1024 May 20 19:35 . drwxr-xr-x 6 root root 1024 May 20 19:28 .. -rw-rw-r-- 1 hapless hapless 96 May 20 19:56 .bash_history -rw-r--r-- 1 hapless hapless 49 Nov 25 1997 .bash_logout -rw-r--r-- 1 hapless hapless 913 Nov 24 1997 .bashrc -rw-r--r-- 1 hapless hapless 650 Nov 24 1997 .cshrc -rw-r--r-- 1 hapless hapless 111 Nov 3 1997 .inputrc -rwxr-xr-x 1 hapless hapless 186 Sep 1 1998 .kshrc -rw-r--r-- 1 hapless hapless 392 Jan 7 1998 .login -rw-r--r-- 1 hapless hapless 51 Nov 25 1997 .logout -rw-r--r-- 1 hapless hapless 341 Oct 13 1997 .profile -rwxr-xr-x 1 hapless hapless 182 Sep 1 1998 .profile.ksh drwxr-xr-x 2 hapless hapless 1024 May 14 12:16 .seyon drwxr-xr-x 3 hapless hapless 1024 May 14 12:15 lg 226 Transfer complete. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 14 drwxrwxr-x 4 hapless hapless 1024 May 20 19:35 . drwxr-xr-x 6 root root 1024 May 20 19:28 .. -rw-rw-r-- 1 hapless hapless 96 May 20 19:56 .bash_history -rw-r--r-- 1 hapless hapless 49 Nov 25 1997 .bash_logout -rw-r--r-- 1 hapless hapless 913 Nov 24 1997 .bashrc -rw-r--r-- 1 hapless hapless 650 Nov 24 1997 .cshrc -rw-r--r-- 1 hapless hapless 111 Nov 3 1997 .inputrc -rwxr-xr-x 1 hapless hapless 186 Sep 1 1998 .kshrc -rw-r--r-- 1 hapless hapless 392 Jan 7 1998 .login -rw-r--r-- 1 hapless hapless 51 Nov 25 1997 .logout -rw-r--r-- 1 hapless hapless 341 Oct 13 1997 .profile -rwxr-xr-x 1 hapless hapless 182 Sep 1 1998 .profile.ksh drwxr-xr-x 2 hapless hapless 1024 May 14 12:16 .seyon drwxr-xr-x 3 hapless hapless 1024 May 14 12:15 lg 226 Transfer complete. ftp> ls -F 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 14 drwxrwxr-x 4 hapless hapless 1024 May 20 19:35 ./ drwxr-xr-x 6 root root 1024 May 20 19:28 ../ -rw-rw-r-- 1 hapless hapless 96 May 20 19:56 .bash_history -rw-r--r-- 1 hapless hapless 49 Nov 25 1997 .bash_logout -rw-r--r-- 1 hapless hapless 913 Nov 24 1997 .bashrc -rw-r--r-- 1 hapless hapless 650 Nov 24 1997 .cshrc -rw-r--r-- 1 hapless hapless 111 Nov 3 1997 .inputrc -rwxr-xr-x 1 hapless hapless 186 Sep 1 1998 .kshrc* -rw-r--r-- 1 hapless hapless 392 Jan 7 1998 .login -rw-r--r-- 1 hapless hapless 51 Nov 25 1997 .logout -rw-r--r-- 1 hapless hapless 341 Oct 13 1997 .profile -rwxr-xr-x 1 hapless hapless 182 Sep 1 1998 .profile.ksh* drwxr-xr-x 2 hapless hapless 1024 May 14 12:16 .seyon/ drwxr-xr-x 3 hapless hapless 1024 May 14 12:15 lg/ 226 Transfer complete. ftp> cd lg 250 CWD command successful. ftp> ls -F 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 8 drwxr-xr-x 3 hapless hapless 1024 May 14 12:15 ./ drwxrwxr-x 4 hapless hapless 1024 May 20 19:35 ../ -rw-r--r-- 1 hapless hapless 70 Aug 22 1998 lg3_colors -rw-r--r-- 1 hapless hapless 629 Aug 22 1998 lg3_prefs -rw-r--r-- 1 hapless hapless 728 Aug 22 1998 lg3_soundPref -rw-r--r-- 1 hapless hapless 2024 Aug 22 1998 lg3_startup drwxr-xr-x 2 hapless hapless 1024 May 14 12:15 lg_layouts/ 226 Transfer complete. ftp> cd lg_layouts 250 CWD command successful.
My activity was typical: I logged in via FTP and browsed a directory or two. Now, let's look at the output linsniffer generated on the Linux box:
gnss => linux2.samshacker.net [21] USER hapless PASS unaware SYST PORT 172,16,0,1,4,192 LIST -al PORT 172,16,0,1,4,193 LIST PORT 172,16,0,1,4,194 LIST -F CWD lg PORT 172,16,0,1,4,195 LIST –F
The output is straightforward. First, it logged a connection to port 21 from host GNSS to linux1.samshacker.net:
gnss => linux2.samshacker.net [21]
Next, linsniffer grabbed hapless' username and password:
USER hapless PASS unaware
And finally, linsniffer recorded every command that hapless issued:
SYST PORT 172,16,0,1,4,192 LIST -al PORT 172,16,0,1,4,193 LIST PORT 172,16,0,1,4,194 LIST -F CWD lg PORT 172,16,0,1,4,195 LIST –F
The output is concise; excellent for stealing passwords and logging general activity, but not suitable for more detailed analysis. For this, you might use linux_sniffer.
linux_sniffer provides a slightly more detailed view.
Application: linux_sniffer by loq
Required: C and IP header files
Config Files: None
Location: http://www.ryanspc.com/sniffers/linux_sniffer.c.
Security History: linux_sniffer has no significant security history.
Notes: linux_sniffer is easy to use. However, you'll need the full complement of IP header files.
To compile linux_sniffer, issue the following command:
$cc linux_sniffer.c –o linuxsniff
Note
linsniffer.c compiles well on Red Hat 5.1 and OpenLinux 1.2 and 1.3. However, in later Red Hat distributions, you may experience problems. If so, choose another sniffer discussed later in this chapter.
Here's a transcript of a telnet session (again from the SGI to the Linux box) that was simultaneously recorded by linux_sniffer:
GNSS 2# telnet 172.16.0.1 Connected to 172.16.0.1. login: hapless password: [hapless@linux2 hapless]$ w 19:55:29 up 58 min, 4 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root tty1 7:44pm 27.00s 0.17s 0.06s -bash root tty2 7:46pm 1:56 0.24s 0.01s linuxsniff root tty3 7:44pm 10:43 0.17s 0.07s -bash hapless ttyp0 gnss 7:55pm 1.00s 0.26s 0.04s w [hapless@linux2 hapless]$ who root tty1 May 20 19:44 root tty2 May 20 19:46 root tty3 May 20 19:44 hapless ttyp0 May 20 19:55 (gnss) [hapless@linux2 hapless]$ finger -l Login: root Name: root Directory: /root Shell: /bin/bash On since Thu May 20 19:44 (PDT) on tty1 35 seconds idle On since Thu May 20 19:46 (PDT) on tty2 2 minutes 4 seconds idle On since Thu May 20 19:44 (PDT) on tty3 10 minutes 51 seconds idle No mail. No Plan. Login: hapless Name: Caldera OpenLinux User Directory: /home/hapless Shell: /bin/bash On since Thu May 20 19:55 (PDT) on ttyp0 from gnss No mail. No Plan.
Again, my activity was typical: I logged in, checked out who was currently logged in, and so on. linux_sniffer recorded additional address data, but it essentially captured the same vital information as linsniffer. First, it recorded the connection:
eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 ff fc 27 - ..' eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 ff fa 1f 00 50 00 28 ff - f0 ….P.(.. eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 ff fa 20 00 33 38 34 30 - 30 2c 33 38 34 30 30 ff .. .38400,38400. 0010 f0 ff fa 23 00 47 4e 53 - 53 3a 30 2e 30 ff f0 ff …#.GNSS:0.0… 0020 fa 18 00 49 52 49 53 2d - 41 4e 53 49 2d 4e 45 54 …IRIS-ANSI-NET 0030 ff f0 - .. eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 ff fc 01 - … eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 ff fd 01 - … eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23]
Next, linux_sniffer recorded the login. I've boldfaced the recorded keystrokes:
eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 68 - h eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 61 - a eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 70 - p eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 6c - l eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 65 - e eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 73 - s eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 73 - s eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 0d 00 - .. eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 75 - u eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 6e - n eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 61 - a eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 77 - w eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 61 - a eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 72 - r eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 65 - e eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23]
And finally, linux_sniffer recorded every command that hapless issued:
eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 77 - w eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 0d 00 - .. eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 77 - w eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 68 - h eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 6f - o eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 0d 00 - .. eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 66 - f eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 69 - i eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 6e - n eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 67 - g eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 65 - e eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23] 0000 72 - r eth proto: 080008:00:69:07:3e:db->00:e0:29:19:4a:68 172.16.0.1[1239] ->172.16.0.2[23]
linux_sniffer is a good choice if you want slightly more detailed information.
hunt is another choice that's suitable when you need less raw output and more easy-to-read, straight-ahead command tracking and session snooping.
Application: hunt by Pavel Krauz
Required: C, IP headers, and Linux 2.0.35+, GlibC 2.0.7 with LinuxThreads. (Or not.)
Config Files: None
Location: http://ww.cri.cz/kra/index.html
Security History: hunt has no significant security history.
Notes: hunt's author has generously provided both dynamically and statically linked binaries for folks who don't have the time (or the inclination) to compile the package.
hunt comes tarred and zipped. The current version and file name is hunt-1_3bin.tgz. To get started, first unzip the compressed archive, like this:
$gunzip hunt*tgz
This will unpack to the file hunt-1_3bin.tar. Unpack this tar archive, like this:
$tar -xvf hunt-1_3bin.tar
Here, hunt will unpack itself into a directory /root/hunt-1.3, which will contain the following files:
-rw-r--r-- 1 206 users 1616 Apr 2 03:54 CHANGES -rw-r--r-- 1 206 users 17983 Oct 25 1998 COPYING -rw-r--r-- 1 206 users 312 Jan 16 04:54 INSTALL -rw-r--r-- 1 206 users 727 Feb 21 11:22 Makefile -rw-r--r-- 1 206 users 27373 Feb 15 12:44 README -rw-r--r-- 1 206 users 167 Dec 4 14:29 TODO -rw-r--r-- 1 206 users 5067 Feb 13 04:23 addpolicy.c -rw-r--r-- 1 206 users 7141 Feb 21 23:44 arphijack.c -rw-r--r-- 1 206 users 25029 Apr 2 03:26 arpspoof.c drwxr-xr-x 2 206 users 1024 Apr 9 02:03 c -rw-r--r-- 1 206 users 7857 Nov 9 1998 hijack.c -rw-r--r-- 1 206 users 5066 Dec 2 12:55 hostup.c -rwxr-xr-x 1 206 users 84572 Apr 9 02:03 hunt -rw-r--r-- 1 206 users 24435 Apr 2 03:26 hunt.c -rw-r--r-- 1 206 users 16342 Mar 30 01:56 hunt.h -rwxr-xr-x 1 206 users 316040 Apr 9 02:03 hunt_static -rw-r--r-- 1 root root 265 May 20 22:22 huntdir.txt -rw-r--r-- 1 root root 2517 May 20 22:19 huntlog.txt -rw-r--r-- 1 206 users 6249 Feb 21 11:21 macdisc.c -rw-r--r-- 1 206 users 12105 Feb 21 11:35 main.c -rw-r--r-- 1 206 users 12000 Feb 6 02:27 menu.c -rw-r--r-- 1 206 users 7432 Apr 2 03:53 net.c -rw-r--r-- 1 206 users 5799 Feb 11 04:21 options.c -rw-r--r-- 1 206 users 11986 Feb 14 04:59 resolv.c -rw-r--r-- 1 206 users 1948 Oct 25 1998 rst.c -rw-r--r-- 1 206 users 9545 Mar 30 01:48 rstd.c -rw-r--r-- 1 206 users 21590 Apr 2 03:58 sniff.c -rw-r--r-- 1 206 users 14466 Feb 21 12:04 synchijack.c -rw-r--r-- 1 206 users 2692 Feb 19 00:10 tap.c -rw-r--r-- 1 206 users 4078 Feb 15 05:31 timer.c -rw-r--r-- 1 206 users 2023 Oct 25 1998 tty.c -rw-r--r-- 1 206 users 7871 Feb 11 02:58 util.c
The static binary is hunt_static. I suggest that you use it, because compilation from source can be a problem if you don't have the necessary libraries.
To start hunt, execute hunt_static at a prompt, like this:
$hunt_static
You'll be pleasantly surprised to find that hunt is curses-based and therefore nominally user-friendly. The opening menu looks like this:
--- Main Menu --- rcvpkt 0, free/alloc 63/64 ------ l/w/r) list/watch/reset connections u) host up tests a) arp/simple hijack (avoids ack storm if arp used) s) simple hijack d) daemons rst/arp/sniff/mac o) options x) exit * >
In this example, I logged into linux1.samshacker.net from GNSS as hapless and did some mundane snooping on root:
GNSS 3% telnet 172.16.0.2 Trying 172.16.0.2… Connected to 172.16.0.2. Escape character is '^]'. Caldera OpenLinux(TM) Version 1.3 Copyright 1996-1998 Caldera Systems, Inc. login: [hapless@linux2 hapless]$ finger root Login: root Name: root Directory: /root Shell: /bin/bash On since Thu May 20 21:57 (PDT) on tty1 1 minute idle On since Thu May 20 22:02 (PDT) on tty2 7 minutes 19 seconds idle On since Thu May 20 21:59 (PDT) on tty3 15 seconds idle No mail. No Plan. [hapless@linux2 hapless]$ last root root tty2 Thu May 20 22:02 still logged in root tty3 Thu May 20 21:59 still logged in root tty1 Thu May 20 21:57 still logged in root tty2 Thu May 20 19:46 - down (00:26) root tty1 Thu May 20 19:44 - 20:12 (00:27) root tty3 Thu May 20 19:44 - down (00:28) root tty3 Thu May 20 19:42 - 19:44 (00:01) root tty1 Thu May 20 19:41 - 19:42 (00:00) root tty3 Thu May 20 19:28 - 19:41 (00:12) root tty2 Thu May 20 19:11 - 19:42 (00:31) root tty1 Thu May 20 19:07 - 19:40 (00:32) root tty1 Thu May 20 18:57 - 19:07 (00:09) root tty1 Mon May 17 22:32 - down (00:29)
Eventually, I examined the /etc/passwd file. In the meantime, I fired up hunt to log the activity:
--- Main Menu --- rcvpkt 0, free/alloc 63/64 ------ l/w/r) list/watch/reset connections u) host up tests a) arp/simple hijack (avoids ack storm if arp used) s) simple hijack d) daemons rst/arp/sniff/mac o) options x) exit *> w 0) 172.16.0.2 [1049] --> 172.16.0.1 [23] choose conn> 0 dump [s]rc/[d]st/[b]oth [b]> b
Note
The preceding input (represented in bold) instructed hunt to log connection 0 (172.16.0.2) and to dump both source and destination information.
In response, hunt displayed a terminal screen (reminiscent of Telix or MTEZ) in which it echoed all of hapless' activity:
22:18:43 up 21 min, 4 users, load average: 0.00, 0.01, 0.00 TRL-C to break hhaapplleessss Password: unaware [hapless@linux2 hapless]$ cclleeaarr [hapless@linux2 hapless]$ wwhhoo root tty1 May 20 21:57 ww 22:18:43 up 21 min, 4 users, load average: 0.00, 0.01, 0.00 [hapless@linux2 hapless]$ mmoorree //eettcc//ppaasssswwdd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: lp:x:4:7:lp:/var/spool/lpd: sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:11:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail: news:x:9:13:news:/var/spool/news: uucp:x:10:14:uucp:/var/spool/uucp: operator:x:11:0:operator:/root: games:x:12:100:games:/usr/games: gopher:x:13:30:gopher:/usr/lib/gopher-data: ftp:x:14:50:FTP User:/home/ftp: man:x:15:15:Manuals Owner:/: majordom:x:16:16:Majordomo:/:/bin/false postgres:x:17:17:Postgres User:/home/postgres:/bin/bash nobody:x:65534:65534:Nobody:/:/bin/false anon:x:100:100:Anonymous:/home/anon:/bin/bash hapless:x:500:500:Caldera OpenLinux User:/home/hapless:/bin/bash [hapless@linux2 hapless]$
As you can see, hunt's output is easy to read. However, that's not the only amenity it offers. hunt also sports the following utilities:
It allows you to specify particular connections you are interested in, rather than having to watch and log everything.
It detects already-established connections, and not simply SYN-started or freshly started connections.
It offers spoofing tools.
It offers active session hijacking.
These features, and its easy interface, make hunt a good choice for Linux newcomers. It's a great learning tool.
sniffit is for folks who need just a little more.
Application: sniffit by Brecht Claerhout
Required: C, IP headers
Config Files: See the following section.
Location: http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
Security History: sniffit has no significant security history.
Notes: sniffit brings out the big guns. It's highly configurable, but be forewarned: It has a considerable learning curve.
sniffit comes tarred and zipped (as of this writing, the current version was sniffit_0_3_0_tar.gz). To unzip it, issue this command:
$gunzip sniffit*gz
This will unzip to sniffit_0_3_0_tar. Un-tar this archive, like this:
$tar –xvf sniffit_0_3_0_tar
In response, sniffit will unpack to sniffit.0.3.5/. Change to that directory (cd sniffit.0.3.5) and run the configurescript:
$./configure
At this point, you'll see several messages scroll by. Here, sniffit is using autoconf to test if your system meets the minimum requirements. When configure is finished, issue this command:
$make
Linux will now build sniffit. This process could take several minutes, depending on your machine, the speed of its processor, and available memory. Ultimately, it will finish and you'll see this message:
strip sniffit
At this point, you're ready to begin. For this example (we'll discuss configuration at length below), I initiated a telnet session from GNSS to linux1.samshacker.net and specified that sniffit should watch port 23 (telnet) between 172.16.0.1 and 172.16.02. Here's the gist of that session from the client end:
GNSS 70% telnet 172.16.0.2 Trying 172.16.0.2… Connected to 172.16.0.2. Escape character is '^]'. Caldera OpenLinux(TM) Version 1.3 Copyright 1996-1998 Caldera Systems, Inc. login: hapless Password: Last login: Fri May 21 00:51:38 1999 from gnss on ttyp0 [hapless@linux2 hapless]$ who root tty1 May 21 00:01 root tty2 May 21 00:09 hapless ttyp0 May 21 00:53 (gnss) [hapless@linux2 hapless]$ w 00:53:12 up 53 min, 3 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root tty1 12:01am 16.00s 0.43s 0.04s sniffit -cmycon root tty2 12:09am 37.00s 0.71s 0.16s more README.FIR hapless ttyp0 gnss 12:53am 0.00s 0.24s 0.04s w [hapless@linux2 hapless]$ ps a PID TTY STAT TIME COMMAND 531 1 S 0:00 login ot 532 2 S 0:00 login root 535 5 S 0:00 /sbin/getty tty5 VC linux Connection closed by foreign host.
Here's what sniffit offered on standard output:
sniffit.0.3.5]# sniffit -d -p 21 -s 172.16.0.2 -t 172.16.0.1 -L1 sniffit.0.3.5]# sniffit -d -p 21 -s 172.16.0.2 -t 172.16.0.1 -L1 Supported ethernet device found. (eth0) Sniffit.0.3.5 is up and running…. (172.16.0.1) P 18 . EF . 88 . EA . 02 . 00 . 00 . FF . FA . 1F . 00 . 50 P 00 . 28 ( FF . F0 . Packet ID (from_IP.port-to_IP.port): 172.16.0.1.1345-172.16.0.2.23 45 E 10 . 00 . 5A Z 54 T 74 t 40 @ 00 . 3C < 06 . 91 . F6 . AC . 10 . 00 . 01 . AC . 10 . 00 . 02 . 05 . 41 A 00 . 17 . 2A * 97 . 52 R 28 ( 3C < BE . 37 7 5E ^ 50 P 18 . EF . 88 . 9B . 99 . 00 . 00 . FF . FA . 20 00 . 33 3 38 8 34 4 30 0 30 0 2C , 33 3 38 8 34 4 30 0 30 0 FF . F0 . FF . FA . 23 # 00 . 47 G 4E N 53 S 53 S 3A : 30 0 2E . 30 0 FF . F0 . FF . FA . 18 . 00 . 49 I 52 R 49 I 53 S 2D - 41 A 4E N 53 S 49 I 2D - 4E N 45 E 54 T FF . F0 .
Like its counterparts, sniffit detected the connection. However, I wanted more detailed information. For this, I created a sniffit configuration file and specified additional parameters for verbose output. (In a moment, we'll cover configuration.) The results were markedly different. sniffit ran a log file and offered output on STDOUT.
Here's what the log file recorded:
[Fri May 21 00:52:56 1999] - Sniffit session started. [Fri May 21 00:52:59 1999] - 172.16.0.2.23-172.16.0.1.1353: Connection closed. [Fri May 21 00:53:03 1999] - 172.16.0.1.1355-172.16.0.2.23: Connection initiated. [Fri May 21 00:53:06 1999] - 172.16.0.1.1355-172.16.0.2.23: login [hapless] [Fri May 21 00:53:08 1999] - 172.16.0.1.1355-172.16.0.2.23: password [unaware] [Fri May 21 00:53:53 1999] - 172.16.0.2.23-172.16.0.1.1355: Connection closed. [Fri May 21 00:59:14 1999] - 172.16.0.1.1358-172.16.0.2.23: Connection initiated. (SYN) [Fri May 21 00:59:14 1999] - 172.16.0.2.23-172.16.0.1.1358: Connection initiated. (SYN)
sniffit generated nicely formatted output that included the date and time of each connection, and naturally, it recorded the username and password. However, it also provided additional diagnostic data about TCP packets on STDOUT:
TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.2.23-172.16.0.1.1358 SEQ (hex): 7352027D ACK (hex): 34C5C478 FLAGS: -AP--- Window: 3FE0 TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.1.1358-172.16.0.2.23 SEQ (hex): 34C5C478 ACK (hex): 7352027E FLAGS: -A---- Window: EF88 TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.1.1358-172.16.0.2.23 SEQ (hex): 34C5C478 ACK (hex): 7352027E FLAGS: -AP--- Window: EF88 TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.2.23-172.16.0.1.1358 SEQ (hex): 7352027E ACK (hex): 34C5C47A FLAGS: -AP--- Window: 3FE0 TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.1.1358-172.16.0.2.23 SEQ (hex): 34C5C47A ACK (hex): 73520280 FLAGS: -A---- Window: EF88 TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.2.23-172.16.0.1.1358 SEQ (hex): 73520280 ACK (hex): 34C5C47A FLAGS: -AP--- Window: 3FE0 TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.1.1358-172.16.0.2.23 SEQ (hex): 34C5C47A ACK (hex): 73520622 FLAGS: -A---- Window: EF88
When you're running sniffit from a command line, you must explicitly define several options, including target and source addresses, output format, and so forth. Table 7.1 lists the important options.
Table 7.1. Various sniffit Command-Line Options
Configuration files can give you much more incisive control over your sniffit session (and help you avoid 200-character command lines). Configuration file format consists of five possible fields:
Field 1—
selectanddeselect. Here, you tellsniffitto capture packets from the following hosts (select) or not (deselect).Field 2—
from,to, orboth. Here, you tellsniffitto capture packets coming from or going to the specified host (or both).Field 3—
host,port, ormultiple-hosts. Here, you specify either a single host target or many. Themultiple-hostsoption supports standard wildcards.Field 4—
hostname,port number, ormultiple-hostlisting.Field 5—
port number.
Here's an example:
select from host 172.16.0.1 select from host 172.16.0.1 80 select both port 23
This would capture all telnet and Web traffic sent from both hosts.
sniffit allows you wide latitude to monitor multiple hosts, on different ports, for different packets. It's really a very nice tool. Check it out.
Now that you've seen how sniffers work and what they can do, let's expand our view. Many other sniffers, network monitors, and proper protocol analyzers exist. Some perform the same essential tasks as those mentioned, while others perform either additional or more specialized tasks. Table 7.2 below lists a few of these tools, their features, and their locations.
Table 7.2. Other Useful Network Monitoring Tools
| Tool | Purpose, Description, and Location |
|---|---|
| ANM | The Angel Network Monitor is not a protocol analyzer per se, but rather a system monitor. ANM will monitor all standard services (FTP, HTTP, SMTP, etc.) for connection timeouts, connection refused messages, and so on. ANM also monitors disk usage. Output is in HTML and color-coded to highlight the alerts. This package requires Perl. Check it out at http://www.ism.com.br/~paganini//angel/. |
| Ethereal | This is a GUI-based sniffer for Linux (and UNIX in general) that offers some nice amenities. One is that Ethereal's GUI allows easy browsing of sniffer data, either from a real-time capture or from previously generated tcpdump capture files. This, coupled with runtime filtering for more incisive browsing, as well as SNMP support and the ability to capture over standard Ethernet, FDDI, PPP, and token ring, makes Ethereal a good choice. However, its authors warn that Ethereal is a work in progress. Note that you'll need both GTK and libpcap installed. Find Ethereal at http://ethereal.zing.org/. |
icmpinfo | This watches ICMP traffic and is useful for detecting ICMP bomb attacks. icmpinfo reports include the date and time, the type of packet, the source IP, offered unreachable IP, source port, destination port, sequence, and packet size. Get icmpinfo at ftp://ftp.cc.gatech.edu/pub/linux/system/network/admin/icmpinfo-1.11.tar.gz. |
IPAC | The IP Accounting Package is an IP monitor for Linux. IPAC runs on top of ipfwadm or ipchains and generates detailed graphs of IP traffic (reporting bytes per second per hour and so forth). Get IPAC at http://www.comlink.apc.org/~moritz/ipac.html. |
IPtraf | This is a console-based network statistics utility that gathers TCP connection packet and byte counts, interface statistics and activity indicators, TCP/UDP traffic breakdowns, and LAN station packet and byte counts. In addition to standard interfaces (FDDI/Ethernet), it can monitor SLIP, PPP, and ISDN traffic. If you're running Trinux, SuSE, or Debian, you probably already have Iptraf installed. If not, get Iptrafat http://cebu.mozcom.com/riker/iptraf/about.html. |
| Ksniffer | Also known as the KDE Network Statistics Utility, this is a network-monitoring tool that runs in K Desktop Environment. Ksniffer monitors all standard network traffic, including TCP, IP, UDP, ICMP, ARP, RARP, and some IPX. As a work in progress, Ksniffer does not yet offer logging support but is quite useful for watching network activity while in KDE. Find Ksniffer at http://ksniffer.veracity.nu/. |
lsof | List Open Files, by Vic Abell, is a tool that reports information on files opened by currently running processes. If you have SuSE, Debian GNU/Linux 2.0, or Red Hat Linux 5.2, you have lsof but need to upgrade. (Version 4.40 had a buffer overflow.) Files on which lsof reports include regular files, directories, block devices, character special files, libraries, sockets, and so forth. lsof is therefore very useful for sniffing out unauthorized activity that may not appear in standard ps queries. If you don't already have lsof, you should get it at ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/. |
ntop | Network top, based on libpcap, displays the current network usage statistics. It handles all the standard protocols and even a few not supported by other network monitoring tools, including DNS, X, NFS, NetBIOS, and AppleTalk. Also, ntop has a noteworthy function that can turn a Web browser into a view-and-control console for network statistics. Find ntop at http://www-serra.unipi.it/~ntop/. |
tcpdump | This prints out packet headers on a network interface that matches a user-supplied boolean expression. tcpdump is useful for diagnosing network problems and forensically examining network attacks. It's highly configurable: You can specify which hosts, which services, and which kind of traffic to monitor. Like sniffit, tcpdump allows you to perform packet capture incisively on incoming and outgoing traffic by network, host, port, and protocol. tcpdump will handle ARP, Ethernet, IP, RARP, TCP, and UDP. Some recent Linux distributions come with tcpdump already installed. If you don't have it, go here to get it: http://sunsite.auc.dk/linux/RPM/tcpdump.html. |
traffic-vis | This monitors TCP/IP traffic and graphs out this information in ASCII, HTML, or PostScript. traffic-vis also allows you to analyze traffic between hosts to determine which hosts have communicated, and the volume of their exchange. (Note that you'll need libpcap.) Get traffic-vis at http://www.ilogic.com.au/~dmiller/traffic-vis.html. |
ttysnoop | This is a tool that lets you monitor telnet and serial connections. Use ttysnoop to snoop on another user's current tty. Linux comes with this package installed. Please see the man page for details. |
Sniffers represent a high level of risk because
They can capture passwords.
They can capture confidential or proprietary information.
They can be used to breach security of neighboring networks, or gain leveraged access.
In fact, pound for pound, sniffer attacks have led to more serious compromises than any other type of attack. To stress that point, I'll quickly take us down memory lane. In 1994, a massive sniffer attack led a naval research center to post the following advisory:
In February 1994, an unidentified person installed a network sniffer on numerous hosts and backbone elements collecting over 100,000 valid user names and passwords via the Internet and Milnet. Any computer host allowing FTP, Telnet or remote log in to the system should be considered at risk… All networked hosts running a UNIX derivative operating system should check for the particular promiscuous device driver that allows the sniffer to be installed.
(From the Naval Computer&Telecommunications Area Master Station LANT advisory at http://www.chips.navy.mil/chips/archives/94_jul/file14.html.)
The attack on Milnet was so serious that the issue was brought before the Subcommittee on Science, Space, and Technology at the U.S. House of Representatives. F. Lynn McNulty, Associate Director for Computer Security at the National Institute of Standards and Technology, gave this testimony:
The recent incident involved the discovery of "password sniffer" programs on hundreds of systems throughout the Internet… The serious impact of the recent incident should be recognized; log-in information (i.e., account numbers and passwords) for potentially thousands of host system user accounts appear to have been compromised. It is clear that this incident had a negative impact on the operational missions of some government agencies. Moreover, this should be viewed as ongoing incident, not an incident that has happened and been dealt with. Indeed, administrators of systems throughout the Internet were advised, in turn, to direct their users to change their passwords. This is, indeed, very significant, and we may be seeing its effects for some time to come. Not only is it difficult, if not impossible, to identify and notify every user whose log-in information might have been compromised, it is unlikely that everyone, even if notified, will change his or her passwords.
(You can access McNulty's full testimony at http://www-swiss.ai.mit.edu/6.805/articles/mcnulty-internet-security.txt)
That attack is universally recognized as the worst in recorded history. But it was rivaled only months later at Rahul.net. In that case, a sniffer ran for only 18 hours. During that time, hundreds of hosts were compromised. As reported by Sarah Gordon and I. Nedelchev, in their article "Sniffing in the Sun: History of a Disaster":
The list contained 268 sites, including hosts belonging to MIT, the U.S. Navy and Air Force, Sun Microsystems, IBM, NASA, CERFNet, and universities in Canada, Israel, the Netherlands, Taiwan and Belgium…
(You can see the list of affected servers at http://idea.sec.dsi.unimi.it/cert-it/firewall-L/9407/0145.html.)
Until recently, it was mostly hackers and crackers who performed these attacks, and they did so out of curiosity, fun, or malicious mischief. Any harm that resulted was probably confined to still further attacks and the pilfering of logins and passwords. Those were the good old days, and they're gone forever. Today, more unsavory societal elements have learned the subtle art of sniffing.
For example, consider the case of Carlos Felipe Salgado, who used a sniffer to steal thousands of credit card numbers off the Net. In their affidavit, FBI agents explained:
Between, on or about May 2, 1997, and May 21, 1997, within the State and Northern District of California, defendant CARLOS FELIPE SALGADO, JR., a.k.a. "Smak," did knowingly, and with intent to defraud, traffic in unauthorized access devices affecting interstate commerce, to wit, over 100,000 stolen credit card numbers, and by such conduct did obtain in excess of $1000; in violation of Title 18, United States Code, Section 1029(a)(2).
Salgado's method was a familiar one:
While performing routine maintenance on the Internet servers on Friday, March 28, 1997, technicians discovered that the servers had been broken into by an intruder. Investigation by technicians revealed a "packet sniffer" installed on the system. The packet sniffer program was being used to capture user ID's and passwords of the authorized users… the FBI met "Smak" at the appointed hour and place. "Smak" delivered an encrypted CD containing over 100,000 stolen credit card numbers. After the validity of the credit card information was confirmed through decryption of the data on the CD, "Smak" was taken into custody by the FBI.
We can expect more incidents like the Salgado case in the near future. In the interim, you should take a twofold approach to sniffers. On the one hand, you should exploit their value. Sniffers are indispensable tools for diagnosing network problems or keeping tabs on your users. On the other hand, you should employ every means possible to ensure that malicious users don't install sniffers on your drives. Let's discuss how to do that now.
As you've probably guessed, sniffer attacks are difficult to detect and thwart because sniffers are passive programs. They don't generate an evidence trail (logs), and when used properly, they don't use a lot of disk and memory resources.
The answer is to go directly to the source. Hence, conventional wisdom dictates that to hunt down a sniffer, you must ascertain whether any network interfaces on your network are in promiscuous mode. For this, try these tools:
ifconfigifstatus
Let's take a quick look at each program now.
You can quickly detect an interface in promiscuous mode on your local host by using ifconfig, a tool for configuring network interface parameters. To run ifconfig, issue the ifconfig command at a prompt, like this:
$ifconfig
In response, ifconfig will report the status of all interfaces. For example, when I started up sniffit and ran ifconfig, this is the report I got:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0
TX packets:40 errors:0 dropped:0 overruns:0
eth0 Link encap:Ethernet HWaddr 00:E0:29:19:4A:68
inet addr:172.16.0.2 Bcast:172.16.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:22 errors:0 dropped:0 overruns:0
TX packets:23 errors:0 dropped:0 overruns:0
Interrupt:3 Base address:0x300
ifconfig detected the Ethernet interface in promiscuous mode:
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
ifstatus checks all network interfaces on the system and reports any that are in debug or promiscuous mode.
Application: ifstatus by David A. Curry
Required: C, IP headers
Config Files: None
Location: ftp://coast.cs.purdue.edu/pub/tools/unix/ifstatus/
Security History: ifstatus has no significant security history.
Notes: To get it working, you need to tweak Makefile.
ifstatus detects sniffers on the local host. After downloading it, unzipping it, and un-tarring it, you'll need to edit the first few operative lines of ifstatus' Makefile. (By default, ifstatus is set to compile for Solaris.)
Here's the top of the ifstatus Makefile:
# To build "ifstatus", you need to edit the OSNAME and LIBS variables # below, as follows: # # Define OSNAME to one of the following: # # OSNAME Operating System # ------ ----------------- # BSD 4.3BSD or similar (try this if your o/s is not listed) # HPUX Hewlett-Packard HP-UX 9.0x (may work on 8.0x too) # SUNOS4 Sun Microsystems SunOS 4.1.x (may work on 4.0.x too) # SUNOS55 Sun Microsystems SunOS 5.5 (Solaris 2.5) # SUNOS56 Sun Microsystems SunOS 5.6 (Solaris 2.6) # # Define LIBS to one of the following: # # OSNAME LIBS # ------ ----------------- # BSD (empty) # HPUX (empty) # SUNOS4 (empty) # SUNOS55 -lkvm -lelf -lnsl -lsocket # SUNOS56 -lkvm -lelf -lnsl -lsocket # OSNAME= SUNOS55 LIBS= -lkvm -lelf -lnsl -lsocket
OSNAME= SUNOS55 LIBS= -lkvm -lelf -lnsl -lsocket
to this:
OSNAME= BSD #LIBS= -lkvm -lelf -lnsl -lsocket
After making these changes, save Makefile, exit your text editor, and type make. ifstatus should then build without problems.
For this example, I started linux_sniffer on the local host and invoked ifstatus. Here's the ifstatus output:
WARNING: LINUX2.SAMSHACKER.NET INTERFACE eth0 IS IN PROMISCUOUS MODE.
You can't ask for anything easier or clearer than that!
So, ifconfig and ifstatus are fine for detecting sniffers on your local host. But what if you have a large network? Short of checking each machine individually, you need a tool that can detect sniffers across a subnet. Tools exist that were designed specifically for this purpose, and the most recent contender is NEPED.
NEPED can detect sniffer activity on a subnet.
Application: NEPED by [email protected]
Required: C, IP headers, Linux 2.0.x+, libc5, and GlibC
Config Files: None
Location: http://metalab.unc.edu/pub/Linux/distributions/trinux/src/netmap/NEPED.c
Security History: NEPED has no significant security history. However, independent reports indicate that NEPED can be fooled.
Notes: NEPED works only on Linux kernels before 2.0.36.
NEPED will scan your subnet, looking for interfaces in promiscuous mode. In Linux kernels before 2.0.36, NEPED ferrets out these interfaces by exploiting a flaw in Linux's arp implementation (in arp.c, which you can find in the LXR engine at http://lxr.linux.no/source/net/ipv4/arp.c). NEPED sends an arp request and elicits a response from the sniffing work- station. Clever.
Unfortunately, NEPED has limitations. First, in later kernels, Linux's arp implementation was patched, so sniffing workstations will no longer respond to errant arp requests. Moreover, independent researcher Seth M. McGann has pointed out that you can configure your system to ignore arp requests, and in this state, it will slip through a NEPED scan. These things aside, however, NEPED is still quite a useful tool.
Finding a sniffer on your network is a worst-case scenario; if it's there, your network is already compromised. But you don't have to wait until this happens to combat sniffer attacks. In fact, you can take one very effective preventative measure right from the start, when you establish your network: employ encryption.
Encrypted sessions greatly reduce your risk. Instead of worrying about data being sniffed, you simply scramble it beyond recognition. The advantages to this approach are obvious: Even if an attacker sniffs data, it will be useless to him. However, there are disadvantages to this approach, too.
Your users may resist using encryption. They may find it too troublesome. For example, it's difficult to get users to use S/Key (or another one-time-password system) every time they log in to the server. You may have to find a happy medium: applications that support strong, two-way encryption and also offer some level of user-friendliness. For more information, check Chapter 10, "Protecting Data in Transit."
The following online documents offer further information about sniffers and the threats they pose.
The ISS Sniffer FAQ, Christopher Klaus. This document, from Internet Security Systems, gives a good overview of different sniffers, how they work, ad possible defenses.
"Sniffers and Spoofers,"Internet Worldarticle.
Computer Hacker Charged with Credit Card Theft, Renee Deger,ZDNET. This article covers the Salgado sniffer case.
Privacy andSecurity on the Internet, Lawrence E. Widman, M.D., Ph.D., with editorial contributions by David A. Tong, Ph.D., University of Texas Health Science Center, Division of Cardiology, Department of Medicine, San Antonio, Texas. This document gives good general coverage of privacy threats posed by sniffers and similar devices.
Gobbler: An Ethernet Troubleshooter/Protocol Analyzer, Tirza van Rijn and Jan Van Oorschot, Delft University of Technology, Faculty of Electrical Engineering, The Netherlands. This paper describes the design of Gobbler, a PC-based sniffer, and the authors' experiences with deploying it. This is a valuable document because it provides a rare inside look at a sniffer's development and testing. To download the paper, you need to also download the tool. It's at http://www.computercraft.com/noprogs/gobbler.zip.
Network Sniffers and You, Dave Dittrich,Washington University. This document is an advisory issued after a major sniffer attack at
washington.edu. Dittrich provides some plain talk about sniffers .
Sniffers represent a significant security risk, mainly because they are not easily detected. You would benefit tremendously by learning how to use sniffers and understanding how others can employ them against you. Lastly, the best defenses against sniffing are secure topology and strong encryption.