Documente Academic
Documente Profesional
Documente Cultură
“Vamos a tratar aquí, principalmente, la detección de sniffers en nuestra red desde el escenario
más básico posible. Este escenarío sería una subred o red no conmutada. Aunque más adelante
nos introduciremos brévemente en la escuha en redes conmutadas o basadas en switches y
herramientas de detección en este tipo de redes……. “
Sobre posicionamiento de un sniffer en nuestra red, conmutada o no
conmutada:
Posición del sniffer en nuestra red. Redes conmutadas y no conmutadas.
Antes que nada, decir que los sniffers no son fáciles de detectar y combatir, ya que
se trata de programas que trabajan en modo pasivo. Las técnicas que se tratan aquí,
por tanto, no son totalmente fiables, aunque en algunos casos si suponen una gran
aproximación al descubrimiento de este tipo de software. Antes que nada y para
enteder algunos coneceptos de este artículo veremos como funciona, brevemente,
el protocolo ARP
Que es. Para que sirve ARP ?
En una red Ethernet cuando queremos enviar un paquete IP entre dos hosts
conectados, las únicas direcciones válidas son las MAC, y lo que circula son tramas
Ethernet. Entonces, y volviendo al ejemplo de antes, cuando queremos enviar un
paquete IP lo que se hace es “meter” el paquete dentro de una trama Ethernet y
enviar.
Formato de una cabecera ARP:
HLEN Longitud dirección hardware
PLEN Longitud dirección del protocolo
OPERACION Código de operación (ARPreques ó ARPreply)
SENDER HA Dirección de origen hardware
SENDER IP Dirección de origen del protocolo
TARGET HA Dirección de destino hardware
Cual es el problema entonces ?
El problema radica en que que sabemos la dirección IP del host de destino
pero no su dirección MAC.
Como se soluciona esto ?
La solución está en que antes de enviar el paquete IP se debe usar ARP para
averiguar cual es la dirección MAC del host destino de la conección que
pretendemos realizar.
Y como se hace ?.
ARP tiene dos tipos básicos de mensajes:
mensaje de peticion o ARPrequest
mensaje de respuesta o ARPreply
los dos viajan por nuestra red dentro de tramas Ethernet.
Cuando queremos enviar un paquete IP desde un host origen (A)
hacia un host destino (B) sucede:
(A) crea un mensaje o petición ARPrequest indicando:
su dirección IP
su dirección MAC
dirección IP del host (B)
campo de dirección MAC host (B) sin rellenar.
envia el ARPrequest a la dirección broadcast (todos los hosts de la red)
pero sólo contesta uno de ellos (B). Entonces:
(B) crea un mensaje ARPreply:
rellena el campo de dirección MAC con su MAC
intercambia las direcciones origen y destino
cambia el tipo de mensaje de ARPreques a ARPreply
envia el mesnaje ARPrpely a (A).
Ya hay entonces información suficiente para establecer cualquier
comunicación entre (A) y (B).
Esto lo podemos comprobar utilizando un sniffer de red
como Wireshark, Windump… y filtrando por protocolos, en este caso ARP:
C:\scan>windump -qtn arp
windump: listening on \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
arp who-has 192.168.5.241 tell 192.168.5.240
arp who-has 192.168.4.234 tell 192.168.4.1
arp who-has 192.168.4.234 tell 192.168.4.1
arp who-has 192.168.4.234 tell 192.168.4.1
arp who-has 192.168.5.4 tell 192.168.5.240
arp who-has 192.168.5.6 tell 192.168.5.240
arp who-has 192.168.5.44 tell 192.168.5.240
arp who-has 192.168.5.14 tell 192.168.5.240
arp who-has 192.168.4.234 tell 192.168.4.1
arp who-has 192.168.4.15 tell 192.168.4.10
arp reply 192.168.4.15 is-at 0:1:2:e7:57:cf
arp who-has 192.168.4.234 tell 192.168.4.1
arp who-has 192.168.4.15 tell 192.168.4.1
arp reply 192.168.4.15 is-at 0:1:2:e7:57:cf
arp who-has 192.168.4.234 tell 192.168.4.1
arp who-has 192.168.4.15 tell 192.168.4.13
arp reply 192.168.4.15 is-at 0:1:2:e7:57:cf…..
Toda la información de las relaciones IP/MAC se guarda en la cache ARP. En un
sistema Windows:
C:\>arp -a
Interfaz: 192.168.4.3 on Interface 0x1000003
Dirección IP Dirección física Tipo
192.168.4.1 00-04-76-97-b3-a9 dinámico
192.168.4.20 00-a0-24-4e-4e-4e dinámico
Sistemas Linux:
$ arp -a
serprint (192.168.4.2) at 52:54:05:fd:de:e5
infografia3 (192.168.4.3) at 00:90:27:6a:58:74
Una vez visto como funciona el protocolo ARP, seguimos con la detección de los
sniffers.
$ cpm
4 network interfaces found:
eth0:5: Normal
eth0:3: Normal
eth0:2: Normal
eth0:1: Normal
eth0: *** IN PROMISCUOUS MODE ***
Existen otros programas como Antisniff, Sentinel, SniffDet, ifstatus o NEPED:
NEPED. Modo de trabajo.
http://downloads.securityfocus.com/tools/neped.c
Tenemos que introducir la interface de red:
$ neped eth0
———————————————————-
> My HW Addr: 00:50:BF:1C:41:59
> My IP Addr: 192.168.0.1
> My NETMASK: 255.255.255.0
> My BROADCAST: 192.168.1.255
———————————————————-
Scanning ….
* Host 192.168.0.3, 00:C2:0F:64:05:FF **** Promiscuous mode
detected !!!
End.
NEPED utiliza la técnica de realizar una simple petición ARP para cada una de las
IPs de la red a diagnosticar, pero ojo, los paquetes no van destinados a broadcast
(FF:FF:FF:FF:FF:FF), sino a una dirección aleatoria e inexistente. Sólo las
interfaces en modo promiscuo verán estos paquetes, y de esta
manera, sólo estas interfaces contestarán a estas peticiones.
Existe también un dispositivo de hardware llamado Tap. Este dispositivo permite
conectarse a un Hub o incluso a un switch de red al cual conectásemos un
dispositivo (ordenador) para monitorizar la red. Existen tipos de Taps para cada
tipo de red Ethernet 10 Mbps, 100 Mbps y 1 Gbps.
SniffDet – Remote Sniffer Detection
http://prdownloads.sourceforge.net/sniffdet/sniffdet-0.9.tar.gz
Usa lás técnicas test ICMP, test ARP, test DNS y test de ping de latencia.
NOTA: Veremos estos test mas abajo.
Vemos un ejemplo con SniffDet:
# ./sniffdet 0.9
A Remote sniffer Detection Tool
Copyright (c) 2003
Ademar de Souza Reis Jr.
Milton Soares Filho
Usage: ./sniffdet [options] TARGET
Where:
TARGET is a canonical hostname or a dotted decimal IPv4
address
-i –iface=DEVICE Use network DEVICE interface for tests
-c –configfile=FILE Use FILE as configuration file
-l –log=FILE Use FILE for tests log
-f –targetsfile=FILE Use FILE for tests target
–pluginsdir=DIR Search for plugins in DIR
-p –plugin=FILE Use FILE plugin
-u –uid=UID Run program with UID (after dropping root)
-g –gid=GID Run program with GID (after dropping root)
-t –test=[testname] Perform specific test
Where [testname] is a list composed by:
dns DNS test
arp ARP response test
icmp ICMP ping response test
latency ICMP ping latency test
-v –verbose Run in verbose mode
-h, –help Show this help screen and exit
–version Show version info and exit
Defaults:
Interface: “eth0”
Log file: “sniffdet.log”
Config file: “/etc/sniffdet.conf”
Plugins Directory: “/usr/lib/sniffdet/plugins”
Plugin: “stdout.so”
You have to inform at least one test to perform
vemos un ejemplo resultado de este software:
————————————————————
Sniffdet Report
Generated on: xxxxxxxxx 2003
————————————————————
Tests Results for target 192.168.2.1
————————————————————
Test: ARP Test
Check if target replies a bogus ARP request (with wrong MAC)
Validation: OK
Started on: xxxx
Finished on: Mxxxxx
Bytes Sent: 84
Bytes Received: 60
Packets Sent: 2
Packets Received: 1
————————————————————
RESULT: POSITIVE
————————————————————
————————————————————
Number of tests with positive result: #1
————————————————————
AntiSniff_v1.3
http://www.packetstormsecurity.org/sniffers/antisniff/as-1021.zip
Esta herramienta, tanto para plataformas linux/Unix como para Win32, es muy
sencilla de usar y tan sólo es necesario inroducir el rango ede IPs a monitorizar en
busca del posible sniffer.
Usa las técnicas de ping de latencia, test DNS y test ARP.
Actualmente no está soportado.
Sentinel
http://packetstorm.linuxsecurity.com/UNIX/IDS/sentinel/sentinel-1.0.tar.gz
Utiliza los métodos de: test DNS, test ARP, prueba ICMP Etherping, y ping de
latencia.
Uso de sentinel:
./sentinel [método] [-t ] [opciones]
Métodos:
[ -a test ARP ]
[ -d test DND ]
[ -i ICMP Test ping de latencia]
[ -e ICMP test Etherpingt ]
Opciones:
[ -f fichero o IP]
[ -c clase C a monitorizar]
[ -n ]
[ -I ]
Ejemplos:
./sentinel -a -t 192.168.1.2
Optimizado para usar el test ARP host 192.168.1.2
./sentinel -aed -f ./()
Optimizado para usar el test DNS host 192.168.1.2
./sentinel -aed -f ./fichero_lista_IPs testo ARP, DND, Etherping para una lista
de IPs
./sentinel -aed -c 10.2.2
Optimizado para escanear una red de clase c (10.2.2) usando el test ARP, DNS
y test Etherping
Otras formas de detectar posibles sniffers
Detectar y controlar los logs que suelen generar los sniffers.
Detectar y controlar las conexiones al exterior.
Monitorizados los programas que acceden al dispositivo de red.
Normalmente una interface en modo promiscuo, queda reflejada en el fichero
de logs:
* $ cat /var/log/messages
Otras técnicas de detección
Sólo por nombrar algunas, son usadas por los programas anti-sniffers.
Comentaremos la última:
Ping de latencia
Test ARP
Uso de un IDS. Por ejemplo Snort que contiene un preprocesador (arpspoof)
que nos puede servir. Aquí las líneas de snort.conf configurando el
preprocesador:
# arpspoof
#—————————————-
# Experimental ARP detection code from Jeff Nathan, detects
ARP attacks,
# unicast ARP requests, and specific ARP mapping monitoring.
To make use
# of this preprocessor you must specify the IP and hardware
address of hosts on # the same layer 2 segment as you.
Specify one host IP MAC combo per line.
# Also takes a “-unicast” option to turn on unicast ARP
request detection.
# Arpspoof uses Generator ID 112 and uses the following SIDS
for that GID:
# SID Event description
# —– ——————-
# 1 Unicast ARP request
# 2 Etherframe ARP mismatch (src)
# 3 Etherframe ARP mismatch (dst)
# 4 ARP cache overwrite attack
preprocessor arpspoof
preprocessor arpspoof_detect_host: 192.168.2.1
f0:0f:00:f0:0f:00
Otro IDS para sistemas Linux como Prelude Hybrid
IDS(http://www.preludeids.org/rubrique.php3?id_rubrique=13), poseee un
plugin ( ArpSpoof Plugin ) que nos ayuda a detectar incoherencias en mensajes
ARP, conflicos con una base de datos ARPwatch (veremos esto más adelante), etc:
Configuración de plugin: /usr/local/etc/prelude-nids/prelude-nids.conf
…
[ArpSpoof]
#
# Search anomaly in ARP request.
#
# The “directed” option will result in a warn each time an ARP
# request is sent to an address other than the broadcast address.
#
# directed;
# arpwatch= ;
…
* Test DNS
Las técnicas de detección. Breve explicación.
El test DNS En este método, la herramienta de detección en sí misma está en
modo promíscuo. Creamos numerosas conexiones TCP falsas en nuestro segmento
de red, esperando un sniffer pobremente escrito para atrapar estas conexiones y
resolver la direción IP de los inexistentes hosts. Algunos sniffers realizan
búsquedas inversas DNS en los paquetes uqe capturan. Cuando se realiza una
búsqueda inversa DNS, un utilidad de deteción de sniffers “huele” la petición de las
operaciones de búsqueda para ver si el objetivo es aquel que realiza la petición del
host inexistente.
El Test del Ping Este método confia en un problema en el núcleo de la
máquina receptora. Podemos construir una petición tipo “ICMP echo” con la
dirección IP de la máquina sospechosa de hospedar un sniffer, pero con una
dirección MAC deliberadamente errónea. Enviamos un un pacquete “ICMP echo” al
objetivo con la dirección IP correcta, pero con una dirección de hardware de
destino distinta. La mayoría de los sistemas desatenderán este paquete ya que su
dirección MAC es incorrecta. Pero en algunos sistemas Linux, NetBSD y NT, puesto
que el NIC está en modo promíscuo, el sniffer asirá este paquete de la red como
paquete legítimo y responderá por consiguiente. Si el blanco en cuestión responde
a nuestra petición, sabremos que está en modo promíscuo. Un atacante avanzado
puede poner al día sus sniffers para filtrar tales paquetes para que parezca que el
NIC no hubiera estado en modo promíscuo.
El Test ICMP Ping de Latencia. En éste método, hacemos ping al blanco y
anotamos el Round Trip Time (RTT, retardo de ida y vuelta o tiempo de latencia)
Creamos centenares de falsas conexiones TCP en nuestro segmento de red en un
período de tiempo muy corto. Esperamos que el sniffer esté procesando estos
paquetes a razón de que el tiempo de latencia incremente. Entonces hacemos ping
otra vez, y comparamos el RTT esta vez con el de la primera vez. Despues de una
serie de tests y medias, podemos concluir o no si un sniffer está realmente
funcionando en el objetivo o no.
El test ARP Podemos enviar una petición ARP a nuestro objetivo con toda la
información rápida excepto con una dirección hardware de destino errónea. Una
máquina que no esté en modo promíscuo nunca verá este paquete, puesto que no
era destinado a ellos, por lo tanto no contestará. Si una máquina está en modo
promiscuo, la petición ARP sería considerada y el núcleo la procesaría y
contestaría. Por la máquina que contesta, la sabemos estamos en modo promiscuo.
El test Etherping Enviamos un “ping echo” al host a testear con una IP de
destivo correcta y dirección MAC falseada. Si el host responde, es que su interfaz
está en modo promiscuo, es decir, existe un sniffer a la escucha y activo.
Protegerse contra la acción de los Sniffers
A grandes rasgos para protegernos de los sniffers y para que éstos no cumplan sus
objetivos de olfateo de contraseñas y en general nos “lean datos sensibles” en texto
plano -sin cifrado fuerte-, podemos hacer uso de diversas técnicas o utilizar
sistemas como:
Existe en el mercado un tipo especial de switches que está preparados para que la
tabla ARP no pueda ser modificada.
Escenario A:
Obervad como wireshark nos muestra un mensaje: “(duplicate use of
192.168.1.11 detect!)”.
Escenario B:
¿ Esta claro no ? .
← Wireshark. Tshark. Detectando tráfico P2P en nuestra red.
Soluciones.
Solución 1
Una posible solución podría ser el envenenamiento ARP, un Arp Poison. Pero esto
es totalmente desaconsejable porque podemos “destabilizar” la red y crear mayores
problemas.
Solución 2
Podríamos también colocar el sniffer en el gateway de salida a internet, ó en
un host firewall de varias tarjetas, indicar cual de las interfaces nos interesa
“olfatear”, de esta forma veremos algo más de tráfico que no sea el
broadcast/multicast.
Pero para ver todo el tráfico entre dos hosts las soluciones más eficaces son otras.
Solución 3
Una de ellas es aprovechar alguna de las características de un switch administrable
como el SPAN (Switch Port Analysis) o llamado de otra forma el Port
Mirroring. Esta es una caraterística que lo que hace es, básicamente, copiar el
tráfico entre dos puertos a un tercero (ubicación del host sniffer) del
switch. Eel Port mirroring tiene el problema que multiplica la carga del switch.
Solución 4
Pero ¿ que pasa si el switch es antiguo y/o no administrable, o simplemente no
soporta Port Mirroring ?.
Para este caso tenemos otra opción. Se trata de conectar un hub a una de las
salidas o puerto del switch y a este hub conectar el host sniffer (C) y
uno de los host a capturar el tráfico (B). El otro host llamémosle (B)
sigue en su ubicación del switch . De esta forma C puede ver el tráfico
entre A y B. ( B puede ser cualquier otro host conectado al switch o un servidor ).
Esta opción, al igual que el Arp Poison, es algo problemática y desaconsejable.
Solución 5
Otra opción de la que disponemos es instalar otra interface de red en el host
sniffer de forma que tenga dos interfaces de red. Una de las tarjetas la
conectamos al switch y la otra a uno de los hosts a analizar. Esta opción se
considera pasiva, pero necesita de configuración del host sniffer a nivel de
interfaces de red para establecer el modo Bridge.
(http://technet.microsoft.com/en-us/library/bb457038(TechNet.10).aspx).
Solución 6
Est solución, quizá la más eficiente y aconsejable aunque también más costosa y
quizás más incomoda. Consiste en hacer uso de un Network TAP o “Test Access
Port” (Puerto de acceso de pruebas). Con este dispositivo podemos capturar el
tráfico de una red conmutada de forma pasiva, es decir, no interfiere en el
flujo o tráfico de nuestra red.