 The article "How can I detect a protocol analyzer" is extracted by Jason Lee from www.Colasoft.com  for knowledge sharing. For complete copy on this topic, please visit Sniffing (network wiretap, sniffer) FAQ.
The article "How can I detect a protocol analyzer" is extracted by Jason Lee from www.Colasoft.com  for knowledge sharing. For complete copy on this topic, please visit Sniffing (network wiretap, sniffer) FAQ.In theory, it is impossible to detect packet sniffing  programs because they are passive: they only collect packets, they don't  transmit anything. However, in practice it is sometimes possible  to detect sniffing programs. It is similar to how in theory it is impossible to  detect radio/TV receivers, but European countries do it all the time in order  to catch people avoiding the radio/TV tax.
 
 
A stand-alone protocol analyzer doesn't transmit any packets, but when installed non-standalone on a normal computer, the sniffing program will often generate traffic. For example, it might send out DNS reverse lookups in order to find names associated with IP addresses.
 
Non-standalone protocol analyzers are indeed what you want to detect. When crackers/hackers invade machines, they often install sniffing programs. You want to be able to detect this happening.
General Overview of Detection Method
 
Ping method
 
 
Most "protocol analyzers" run on normal machines  with a normal TCP/IP stack. This means that if you send a request to these  machines, they will respond. The trick is to send a request to IP address of  the machine, but not to its Ethernet adapter.
 
To illustrate:
- The machine suspected of running the protocol analyzer has an IP address 10.0.0.1, and an Ethernet address of 00-40-05-A4-79-32.
- You are on the same Ethernet segment as the suspect (remember, the Ethernet is used only to communicate locally on a segment, not remotely across the Internet).
- You change the MAC address slightly, such as 00-40-05-A4-79-33.
- You transmit an "ICMP Echo Request" (ping) with the IP address and this new MAC address.
- Remember that NOBODY should see this packet, because as the frame goes down the wire, each Ethernet adapter matches the MAC address with their own MAC address. If none matches, then they ignore the frame.
- If you see the response, then the suspect wasn't running this "MAC address filter" on the card, and is hence sniffing on the wire.
There are ways defending against this. Now that this  technique is widely publicized, newer hackers will enabled a virtual MAC  address filter in their code. Many machines (notably Windows) have MAC  filtering in drivers. (There is a hack for Windows: most drivers just check the  first byte, so a MAC address of FF-00-00-00-00-00 looks like FF-FF-FF-FF-FF-FF  (the broadcast address which all adapters accept). However, some adapters  implement multicast in such as way that this address will match as a multicast,  which is any address whose first byte is an odd number. Thus, this can result  in false positives).
 
This technique will usually work on switched/bridged  Ethernets. When switches see an unknown MAC address for the first time, they  will "flood" the frame to all segments.
 
Ping method, part 2
 
The ping method can be enhanced in a number of ways: 
- Any protocol that generates a response can be used, such as a TCP connection request or a UDP protocol such as port 7 (echo).
- Any protocol that might generate an error on the target machine might be used. For example, bad IP header values might be used to generate an ICMP error.
- Sometimes a broadcast address (either a "local broadcast" like 255.255.255.255 or a "directed broadcast" like 10.0.0.255) needs to be used in order to bypass software IP address filtering. This then encounters another problem in that many machines do not respond to broadcast requests (responses to broadcasts causes network problems, such as the 'smurf' hack).
ARP method
 
 
The ARP method is similar to the ping method, but an ARP  packet is used instead. An explanation (in Spanish) is given at http://www.apostols.org/projectz/neped/ which  includes a program called neped to do this detection.
 
The simplest ARP method transmits an ARP to a  non-broadcast address. If a machine responds to such an ARP of its IP address,  then it must be in promiscuous mode.
 
A variation of this technique takes advantage of the fact  that machines "cache" ARPs. Each ARP contains the complete  information of both the sender as well as the desired target information. In  other words, when I send out a single ARP to the broadcast address, I include  my own IP-to-Ethernet address mapping. Everyone else on the wire remembers this  information for the next few minutes. Therefore, you could do something like  sending out a non-broadcast ARP, then a broadcast ping. Anybody who responds to  your ping without ARPing you could only have gotten the MAC address from a  sniffed ARP frame. (To make double-sure, use a different source MAC address in  the ping).
 
DNS method
 
 
Many sniffing programs do automatic reverse-DNS lookups  on the IP addresses they see. Therefore, a promiscuous mode can be detected by  watching for the DNS traffic that it generates.
 
This method can detect dual-homed machines and can work  remotely. You need to monitor incoming inverse-DNS lookups on the DNS server in  your organization. Simply do a ping sweep throughout the company against  machines that are known not to exist. Anybody doing reverse DNS lookups on  those addresses are attempting to lookup the IP addresses seen in ARP packets,  which only sniffing programs do.
 
This same technique works locally. Configure the detector  in promiscuous mode itself, then send out IP datagrams to bad addresses and  watch for the DNS lookups.
 
One interesting issue with this technique is that hacker-based  sniffing programs tend to resolve IP addresses as soon as they are found,  whereas commercial programs tend to delay resolution until the point where the  protocol analyzer user views the protocol decodes.
 
Source-route method
 
 
Another technique involves configuring the source-route  information inside the IP header. This can be used to detect protocol analyzers on  other, nearby segments. 
- Create a ping packet, but put a loose-source route to force it by another machine on the same segment. This machine should have routing disabled, so that it will not in fact forward it to the target.
- If you get a response, then it is likely the target sniffed the packet off the wire.
- In the response, doublecheck the TTL field to find out if it' came back due to sniffing (rather than being routed correctly)
Details:
 
In loose source-routing, an option is added to the IP  header. Routers will ignore the destination IP address and instead forward to  the next IP address in the source-route option. This means when you send the  packet, you can say "please send packet to Bob, but route it through Anne  first".
 
In this scenario, both "Anne" and  "Bob" are on the segment. Anne does not route, and therefore will  drop the packet when received. Therefore, "Bob" will only respond if he  has sniffed the packet from the wire.
 
On the off chance that Anne does indeed route (in which  case Bob will respond), then the TTL field can be used to verify that Bob  responded from routing through Anne, or answering directly.
 
The decoy method
 
 
Whereas the ping and ARP methods only work on the local  network, the decoy method works everywhere.
 
Since so many protocols allow "plain text"  passwords, and hackers run sifters looking for those passwords, the decoy  method simply satisfies that need. It consists simply of setting up a client  and a serve on either side of the network, which the client runs a script to  logon to the server using Telnet, POP, IMAP, or some other plain-text protocol.  The server is configured with special accounts that have no real rights, or the  server is completely virtual (in which case, the accounts don't really exist).
 
Once a hacker sifts the usernames/passwords from the  wire, he/she will then attempt to log on using this information. Standard  intrusion detection systems or audit trails can be configured to log this  occurance, alerting the fact that a sniffing hacker has found the traffic and  attempted to use the information.
 
http://www.zurich.ibm.com/~dac/Prog_RAID98/Full_Papers/sniffer_detector.html/index.htm
 
Host method 
 
 
When hackers break into your systems, they will often  leave behind wiretap programs running in the background in order to sniff  passwords and user accounts off the wire. These are often imbedded (as a  trojan) in other programs, so the only way to find if something like this is  running is to query the interfaces to see if they are running in promiscuous  mode.
 
The most technique is to run the program "ifconfig  -a". On my computer (Solaris 2.6) the output looks like:
 
# ifconfig -a
 
lo0:  flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
 
inet  127.0.0.1 netmask ff000000
 
hme0:  flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,MULTICAST> mtu  1500
 
inet  192.0.2.99 netmask ffffff00 broadcast 192.0.2.255
 
ether  8:0:20:9c:a2:98
 
 
 
Of course, the  first thing a hacker will do is replace the 'ifconfig' program to hide this.  There are other utilities you can download from the net that will query the  hardware directly in order to discover this information, or you could run the  'ifconfig' program directly from a CD-ROM distribution.
 
Latency method
 
 
This is a more evil method. On one hand, it can  significantly degrade network performance. On the other hand, it can 'blind'  protocol analyzers by sending too much traffic.
 
This method functions by sending huge quantities of  network traffic on the wire. This has no effect on non-promiscuous machines,  but has a huge effect on sniffing machines, especially those parsing  application layer protocols for passwords. Simply ping the machine before the  load and during the load and testing the difference in response time can  indicate if the machine is under load.
 
One problem with this technique is that packets can be  delayed simply because of the load on the wire, which may case timeouts and  therefore false positives. On the other hand, many sniffing programs are  "user mode" whereas pings are responded to in "kernel mode",  and are therefore independent of CPU load on a machine, thereby causing false  negatives.
 
TDR (Time-Domain Reflectometers)
 
 
A TDR is basically RADAR for the wire. It sends a pulse  down the wire, then graphs the reflections that come back. An expert can look  at the graph of the response and figure out if any devices are attached to the  wire that shouldn't be. They also roughly tell where, in terms of distance  along the wire, the tap is located.
 
This can detect hardware protocol analyzers that might be  attached to the wire, but which are completely silent otherwise.
 
TDRs used to be used a lot in the old days of coax  Ethernet in order to detect vampire taps, but these days with star topologies,  they are used very rarely.
 
There also exist OTDR equipment, but this is really only  for the truely paranoid.
 
Hub lights
 
 
You can manually check hub-lights to see if there are any  connections you don't expect. It helps to have labeled cables to figure out  where (physically) a protocol analyzer might be located.
 
SNMP monitoring
 
 
Smart hubs with SNMP management can provide automated  monitroning of Ethernet (and other) hubs. Some management consoles will even  let you log connections/disconnections to all your ports. If you've configured  the system with the information where all the cables terminate, you can  sometimes track down where a protocol analyzer might be hiding. 


 
 












