Detect Ethernet Sniffers Remotely






Detect Ethernet Sniffers Remotely

Detect potential spies on your network without having to trust compromised machines.

Ethernet sniffers are one of the most powerful tools in your network security arsenal. However, in the wrong hands, they can be one of the biggest threats to the security of your network. Once a system has been compromised, whether by an insider or a malicious intruder, the attacker will most likely begin sniffing the local network. This network reconnaissance will help the "spy" to find his next target, or simply to collect juicy bits of information (such as usernames and passwords, emails, or other sensitive data).

Sniffing Shared Mediums

Not too long ago, it was commonly thought that only shared-medium Ethernet networks were vulnerable to being sniffed. These networks employed a central hub, which rebroadcast every transmitted packet to each port on the hub. In this configuration, every node on the local network segment receives every frame sent by any network node. Each node's network interface then performs a quick check to see if it is the node for which the frame is destined. If it is not the destination host, the frame is discarded. If it is, the frame is passed up through the operating system's protocol stack and is eventually processed by an application.

Because of this, sniffing traffic meant for other systems on the network was trivial. Since all the traffic reached each system, one needed only to disable the check that the network interface performs to grant a system access to traffic meant for others. This is usually referred to as putting the network interface into promiscuous mode, which usually can be done only by a privileged user.

Sniffing in Switched Environments

Eventually, switched Ethernet networks began to replace shared-medium networks. Thus, the main facilitator of sniffing was removed. Unlike hubs, Ethernet switches send traffic only to the device for which it is destined. To do this, an Ethernet switch learns which network device's MAC address corresponds to what port on the switch as traffic passes through the switch. When the switch sees an Ethernet frame with a certain destination MAC address, it looks up which port on the switch corresponds to it and forwards the frame to only that port. In doing this, the switch effectively creates a virtual dedicated connection from the sending station to the receiving station every time an Ethernet frame is transmitted on the network. Thus, only the machine that the frame was originally intended for is able to see it. This would be fine, but certain aspects of the Ethernet specification and TCP/IP can cause problems.

One problem is that switches can memorize only a limited number of MAC addresses. The maximum number will often be several orders of magnitude higher than the number of ports that the switch has, which allows switches to be connected to each other hierarchically. In order to do this efficiently, however, each switch must memorize the MAC addresses available on the switches to which it is connected.

For example, suppose you have a 24-port switch (switch A) with 23 machines plugged into it and the 24th port occupied by another switch. This other switch (switch B) has 48 ports, with the 47 other ports being occupied by machines. In this situation, switch A will learn the MAC addresses of the 47 systems on switch B and associate it with its 24th port, and switch B will learn the MAC addresses of the 23 systems connected directly to switch A and associate it with its own 48th port.

Even though the average switch can memorize upwards of several thousand MAC addresses, it is still possible to overflow a switch's MAC address table by generating large amounts of traffic with fake MAC addresses. This tactic is desirable for a malicious user because many switches will revert to behaving like hubs once their MAC address tables have been filled. Once this happens, the network is no different from a shared-medium segment using a hub. A malicious user can then sniff the network by simply putting her network interface into promiscuous mode.

Luckily, this approach is fairly invasive; in order for it to work, the network will need to be flooded with bogus traffic, which is something that can be detected passively with a tool such as Arpwatch [Hack #62]. A flood of bogus MAC and IP address pairings will cause Arpwatch to likewise flood your system logs. As long as you're good about monitoring your logs, this attack should be fairly easy to spot. As mentioned in "Detect ARP Spoofing" [Hack #62], Arpwatch is also capable of detecting ARP table poisoning. That makes it an effective tool for detecting the two most common types of ARP attacks that are usually precursors to data logging: ARP flooding and targeted ARP poisoning.

Another way to monitor switched networks is to simply change the MAC address of the Ethernet card in the system that is going to be used for sniffing. In Linux and many other Unix and Unix-like operating systems, this can be done with the ifconfig command:

# /sbin/ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:E0:81:03:D8:8F
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x1c80 

# /sbin/ifconfig eth0 hw ether 00:DE:AD:BE:EF:00
# /sbin/ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:DE:AD:BE:EF:00  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x1c80

The purpose of doing this is to trick the switch into forwarding the traffic to two different nodes on the segment. This is sometimes a hit-or-miss deal, since different switches will behave differently when there are duplicate MAC addresses in use on the same network. The switch might forward traffic to both ports, distribute the traffic unpredictably between them, stop passing traffic altogether, or raise an error.

All of these methods can be detected and stopped with more expensive managed switches, which allow you to specify what MAC addresses are allowed on each individual port. This feature is sometimes called port security.

However, even if attackers choose not to employ these methods, they can still gather quite a bit of information by just putting the network interface into promiscuous mode. For example, broadcast traffic such as DHCP and ARP requests will still be sent to every port on the switch.

Installing SniffDet

One tool that can help to detect promiscuous interfaces on both switched and unswitched networks is SniffDet (http://sniffdet.sourceforge.net). For a tool that really serves only a single purpose, SniffDet is fairly versatile, and it can detect sniffers in several ways. The main difference between SniffDet and a tool like Arpwatch is that SniffDet actively scans for sniffers. That is, if you suspect that a machine might be running a sniffer, you can simply run SniffDet and point it at that machine to determine whether its network device is in promiscuous mode.

To build and install SniffDet, you will first have to obtain the libnet packet injection library (http://www.packetfactory.net/projects/libnet/). Make sure to download the latest 1.0.x version; the 1.1 versions of libnet are incompatible with programs written for the 1.0.x versions.

To compile libnet, unpack the source distribution and go into the directory that it creates. Then run this command:

$ ./configure && make
            

After it has finished compiling, become root and type make install.

Building SniffDet is a similar affair. As with libnet, you will need to unpack the source distribution and change to the directory that it creates. Then, to build and install it, do the same thing you did for libnet. You'll also want to download two patches: one that fixes several compilation issues and one that fixes a bug that limits the functionality of SniffDet (the latter has been submitted to the authors of SniffDet but has not been integrated into a new release at the time of this writing). Both patches can be obtained from http://snort-wireless.org/other/patches/sniffdet-0.9.

Before compiling SniffDet, apply the patches using commands such as these:

$ tar xfz sniffdet-0.9.tar.gz
$ cd sniffdet-0.9
$ patch -p1 < sniffdet-get_mac.patch
$ patch -p1 < sniffdet-compile_fixes.patch
            

Testing with ARP Queries

SniffDet has several methods for determining whether a target machine is running a sniffer. However, only two of the methods that it employsthe ARP and DNS testswill work with repeatable and predictable results.

The ARP test relies on how the sniffing system's protocol stack deals with ARP queries while in promiscuous mode. To run this test, SniffDet sends out an ARP query to the target machine. This request has fake source and destination MAC addresses but uses the correct IP address of the machine being checked. If the target machine is in promiscuous mode, the ARP query with the fake MAC address will be passed up the protocol stack, and the target machine will send a reply. If the machine is not in promiscuous mode, this ARP query will be quietly discarded. This method is effective on both switched and unswitched networks.

The ARP test works because of the way in which network adapters implement multicast addressing. IP multicast groups have associated MAC addresses. In order to receive multicast data, a network interface will set itself to not filter out data sent to the MAC address corresponding to the multicast group to which it belongs, as well as to the broadcast address and the interface's normal address. One interesting side effect of the way this is implemented is that when a network interface is in promiscuous mode it will respond to any frame with the group bit set in the destination address, even if the address does not correspond to a multicast group to which the host belongs. This same bit will also cause the frame to be broadcast by the switch. So, one only needs to send an ARP request with a destination address like FF:00:00:00:00:00 instead of the normal broadcast address, FF:FF:FF:FF:FF:FF, to detect if the machine is in promiscuous mode.

One interesting thing to note is that different operating systems will respond to MAC addresses with the group bit set in different ways. For instance, Linux and many other Unix-like operating systems will respond to the address mentioned earlier when in promiscuous mode, but Windows systems will not. On the other hand, both Unix-like and Windows systems will respond when FF:FF:FF:FF:FF:FE is used as the destination address. However, because of a bug in SniffDet's MAC address parsing code, you won't be able to use FF:FF:FF:FF:FF:FE as a destination address unless you apply the previously mentioned patch.

Let's look at a sniffdet scan against sirius (192.168.0.2) from colossus (192.168.0.64), two machines that are on the same switched network.

Here are the results of running sniffdet against sirius:

colossus # sniffdet -i eth0 -t arp sirius
------------------------------------------------------------
Sniffdet Report
Generated on: Wed Dec 31 03:49:28 2003
------------------------------------------------------------
Tests Results for target sirius
------------------------------------------------------------
Test: ARP Test (single host)
      Check if target replies a bogus ARP request (with wrong MAC)
Validation: OK
Started on: Wed Dec 31 03:49:08 2003
Finished on: Wed Dec 31 03:49:28 2003
Bytes Sent: 252
Bytes Received: 0
Packets Sent: 6
Packets Received: 0
------------------------------------------------------------
RESULT: NEGATIVE
------------------------------------------------------------

------------------------------------------------------------
Number of valid tests: #1
Number of tests with positive result: #0
------------------------------------------------------------

Now start a sniffer on sirius and run the scan again:

sirius # tcpdump -i le0 arp
tcpdump: listening on le0
06:58:00.458836 arp who-has sirius.nnc tell colossus.nnc
06:58:00.458952 arp reply sirius.nnc is-at 8:0:20:81:a4:a3
06:58:00.466601 arp who-has sirius.nnc (ff:0:0:0:0:0) tell colossus.nnc
06:58:00.466928 arp reply sirius.nnc is-at 8:0:20:81:a4:a3

Here are the results of the scan:

------------------------------------------------------------
Sniffdet Report
Generated on: Wed Dec 31 06:58:01 2003
------------------------------------------------------------
Tests Results for target sirius
------------------------------------------------------------
Test: ARP Test (single host)
      Check if target replies a bogus ARP request (with wrong MAC)
Validation: OK
Started on: Wed Dec 31 06:58:00 2003
Finished on: Wed Dec 31 06:58:01 2003
Bytes Sent: 84
Bytes Received: 60
Packets Sent: 2
Packets Received: 1
------------------------------------------------------------
RESULT: POSITIVE
------------------------------------------------------------

------------------------------------------------------------
Number of valid tests: #1
Number of tests with positive result: #1
------------------------------------------------------------
               
            

The DNS test also works very well, particularly on shared-medium networks such as hubs or wireless LANs. However, it does rely on name resolution being enabled in the sniffer. When performing DNS tests, sniffdet will send bogus packets that contain IP addresses that are not in use on the local network segment. If name resolution is enabled, the sniffer will attempt to do a reverse lookup in order to determine the hostname that corresponds to the IP addresses. Since these addresses are not in use, sniffdet will determine that the target machine is in promiscuous mode when it sees the DNS queries.

A DNS test is performed just like an ARP test, but using -t dns instead of -t arp.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows