Si distinguono tra sniffer detti 'stand-alone' e tutti gli altri sniffer; il primo tipo di sniffer non trasmette nulla, non genera traffico, è passivo ed è teoricamente impossibile da individuare; il secondo tipo, invece, non ha solo comportamenti passivi ma genera del traffico ben identificabile e sulla base di dei dati e delle richieste (ad es DNS reverse lookup) inviate è possibile localizzarlo.

In effetti, ciò che si vuole localizzare e' proprio lo sniffer non-standalone.
Diamo uno sguardo generali ai metodi di individuazione:

* metodo ping: molti sniffer vengono eseguiti su macchine che operano in rete secondo la gerarchia TCP/IP; in breve, se inviamo una richiesta a queste macchine esse ci forniranno un qulche tipo di risposta. Il trucco, in questo caso, è quello di inviare una richiesta all’indirizzo IP della macchina sospetta ma non al suo ethernet adapter.

1. poniamo che la macchina sospetta abbia indirizzo IP: 10.0.0.1 e MAC address: 00-40-05-A4-79-31
2. ci poniamo sullo stesso segmento di rete della macchina sospetta e inviamo un 'ICMP echo request' (ping) all'indirizzo IP della macchina e a un indirizzo MAC diverso e non assegnato, ad es.: 00-40-05-A4-79-32
3. poichè quest'indirizzo ethernet non è assegnato a nessuna delle interfacce sulla LAN, nessuno dovrebbe rispondere: l'indirizzo MAC viene confrontato con il proprio e se non corrispondente viene scartato
4. se la macchina sospetta possiede un ethernet adapter in promiscuos mode non avrà questo filtro e risponderà al ping, permettendoci di sapere che su di essa è probabile sia stato installato uno sniffer.

Questo e' un metodo così ben conosciuto che gli sniffer adottano un filtro MAC virtuale soprattutto sulle macchine (in genere Windows) che possieno driver (software) di filtro: esistono degli Exploit per Windows che permettono di generare falsi positivi che vanificano la ricerca.

* metodi ping, parte seconda: per ovviare all'inconveniente di cui sopra usate il metodo ping su ogni servizio attivo in rete che generi risposte conosciute, ad es: TCP connection request, protocollo UDP sulla porta 7 (echo); oppure utilizzate ogni protocollo che possa generare un errore sulla macchina bersaglio, ad esempio corrompendo gli header IP in modo da far nascere un ICMP error.

Ancora, l'indirizzo Broadcast (sia locale, 255.255.255.255, che diretto, es.:10.0.0.255) puo' essere utilizzato per superare le barriere/filtri ai ping su indirizzo IP ma proprio perchè il broadcast address genera risposte da tutte le interfacce potrebbe essere disabilitato (a causa di attacchi smurf).

* metodo ARP: simile al metodo ping ma si usa il protocollo ARP (Address Resolution Protocol); il metodo più semplice è inviare un ARP request a un indirizzo non broadcast sospetto: se risponde è in promiscuos mode.

Una variante si avvantaggia della cache ARP di ogni macchina, ossia l'archivio in cui vengono immagazzinati, per alcuni minuti o per un tempo più lungo, le informazioni relative sia al mittente che al destinatario del traffico generato da una determinata interfaccia.
In altre parole, quando si invia un ARP in broadcast, si include il prorpio 'IP to Ethernet address mapping' che verrà archiviato da tutte le macchine; inviando un ARP non broadcast esso verrà scartato da tutte le interfacce meno quelle in promiscuos mode, perciò al successivo invio di un ping sull'indirizzo di broadcast riceveremo risposte con ARP request e non. Ovviamente le risposte prive di ARP request provengono da interfacce che avevano sniffato l'ARP frame in precedenza.

* metodo DNS: come si suggeriva in precedenza, molti sniffer operano un reverse DNS lookup automatico sugli indirizzi IP che vedono. In questo modo, dall'osservazione del traffico DNS (Domain Name System), individueremo le interfacce in promiscuous mode.

Per aumentare tale tipo di traffico si operi un ping sweep su una lunga serie di indirizzi IP non assegnati attraverso tutti i segmenti di rete. Qualsiasi interfaccia che generi traffico di reverse DNS lookup su tali indirizzi IP ha sicuramente sniffato l'ARP frame.

* metodo 'source route': si crei un pacchetto ping introducendo il parametro loose source in modo da instradare il pacchetto attraverso una macchina ulteriore su un un segmento diverso da quello dell'interfaccia sorgente;
la macchina scelta per l'instradamento deve essere priva della possibilità di instradare tale pacchetto ping, laciandolo così cadere;
se la macchina bersaglio risponde comunque al ping è probabile che l'abbia sniffato;
se si vuole essere sicuri della mancanza di instradamento verso l'interfaccia bersaglio si controlli il TTL (Time To Live) della risposta per capire se proviene direttamente, quindi a seguito di sniffing, o a seguito di corretto instradamento.

* metodo 'decoy': questo medono funziona anche all'esterno delle reti locali.
Poichè quello che molti sniffer cercano sono password e nomi utente, il metodo decoy fornisce password ad account inesistenti che serviranno unicamente a tracciare la presenza di un eventuale sniffer.
Consiste semplicemente di un client e di un server posti ognuno ad un capo della rete locale; il client farà girare uno script che connetta, via telnet, pop o imap, comunque in chiaro, il client al server attraverso account privi di privilegi reali (gli account possono essere del tutto virtuali).
Quando verrà tentato l'accesso a questi account utilizzando tali informazioni, potranno essere utilizzati sistemi standard per la prevenzione delle intrusioni in modo da registrare tutte le attività compiute.

* metodo 'latency': questo metodo può degradare sensibilmente le performance della rete locale e genera molti 'false positive' ma riesce ad accecare un eventuale sniffer.
In poche parole, è necessario inondare la rete di traffico, generandolo come meglio si creda, e, durante l'operazione inviare dei ping all'interfaccia sospetta per verificarne un eventuale sovraccarico (che sarà determinato dal tempo di risposta all'ICMP echo request).

Come funziona il latency method? Le interfacce non promiscue non raccoglieranno tutto il traffico in passaggio, saranno solo rallentate nelle loro prestazioni dal sovraccarico generale, ma l'interfaccia che girasse in promiscuous mode verrebbe sommersa da tutti i pacchetti in passaggio, determinando un latenza rilevante nell'invio della risposta ad un ping.

Un possibile problema e' rappresentato dalla possibilità che lo sniffer faccia in modo di rispondere al ping in 'kernel mode', restando cioè indipendente dal carico sulla CPU determinato dalla raccolta di tutto il traffico. Questa funzione genera falsi negativi.