Este escenario sería una subred o red no conmutada. Aunque más adelante nos introduciremos brevemente en la escucha en redes conmutadas o basadas en switches y herramientas de detección en este tipo de redes. 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 entender algunos conceptos de este artículo veremos como funciona, brevemente, el protocolo ARP.

¿Qué es. Para qué 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

¿Cuál es el problema entonces?

El problema radica en que sabemos la dirección IP del host de destino pero no su dirección MAC.

¿Cómo 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 conexión que pretendemos realizar.

¿Y cómo se hace?

ARP tiene dos tipos básicos de mensajes:

• Mensaje de petición 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.

Envía 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
• Envía el mensaje 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 Ethereal 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 0×1000003

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. 

Detección en sistemas UNIX/Linux

En entornos Linux o UNIX la verificación de una interfase en modo promiscuo se puede hacer usando ifconfig. Este programa configura la interfase de red instalada en un determinado host y obtiene información de la configuración en el momento de ejecutar el programa. Cuando un adaptador de red se encuentra en modo promiscuo, ifconfig nos devuelve la siguiente información:

$ ifconfig -a 

eth0 Link Encap: 10Mbps Ethernet HWaddr: xx:xx:xx:xx:xx:xx
inet addr: a.b.c.d Bcast: a.b.c.f Mask: m.m.m.m
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 (OJO: Modo
promiscuo) 

RX packets: 0 errors:0 dropped:0 overruns:0TX packets:0 errors:0
dropped:0 overruns:0 

Interrupt:15 Base Address:0x300

Este sistema no es infalible. Existen programas que pueden hacer esta labor como:

CPM (Check Promiscuous Mode)

Este pequeño programa realizado por la Universidad de Carnegie Mellon, chequea el interfaz de red de la máquina descubriendo si está siendo utilizado en modo promiscuo (escuchando todo el tráfico de la red).

$ 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:

Veamos como trabaja NEPED

Tenemos que introducir la interfase 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.

Más información en: http://www.netoptics.com/

SniffDet - Remote Sniffer Detection

sniffdet-0.9.tar.gz

Usa las técnicas test ICMP, test ARP, test DNS y test de ping de latencia.

# ./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.l0pht.com/antisniff

Esta herramienta, tanto para plataformas linux/Unix como para Win32, es muy sencilla de usar y tan sólo es necesario introducir el rango ede IPs a monitorizar en busca del posible sniffer. Usa las técnicas de ping de latencia, test DNS y test ARP.

Sentinel

http://www.packetfactory.net/Projects/sentinel/

Utiliza los métodos de: test DNS, test ARP, prueba ICMP Etherping, y ping de latencia.
Uso de sentinel:

 ./sentinel [método] [-t <destino ip>] [opciones]

Métodos:
 [ -a test ARP ]
 [ -d test DND ]
 [ -i ICMP Test ping de latencia]
 [ -e ICMP test Etherpingt ]
Opciones:
 [ -f <fichero> fichero o IP]
 [ -c <x.x.x> clase C a monitorizar]
 [ -n <número de paquetes a enviar> ]
 [ -I <dispositivo> ]

Ejemplos:
./sentinel -a -t 192.168.1.2
Optimizado para usar el test ARP host 192.168.1.2
./sentinel -d -f 1.1.1.1 -t 192.168.1.2
Optimizado para usar el test DNS host 192.168.1.2
Optimizado para escanear una red de clase c (192.168.4) 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 interfase 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)

Posee un plugin ( ArpSpoof Plugin ) que nos ayuda a detectar
incoherencias en mensajes ARP, conflictos 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=<ip> <macaddr>;
… 

* 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 promiscuo. Creamos numerosas conexiones TCP falsas en nuestro segmento de red, esperando un sniffer pobremente escrito para atrapar estas conexiones y resolver la direcció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 detecció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 confía 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 paquete "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 promiscuo, 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 promiscuo. 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 promiscuo.

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. Después 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 destino 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:

• Redes conmutadas (no siempre es efectivo)
• PGP
• SSL
• SSH
• VPN
• etc.

Aunque ya veremos más adelante que ni
siquiera el uso de SSH, por citar un ejemplo, nos puede proteger efectivamente
del uso de ciertos tipos de sniffer como ettercap.

Detección en sistemas Windows

PromiScan

"PromiScan ( http://www.securityfriday.com/) es una utilidad de distribución gratuita diseñada para dar caza a los nodos promiscuos en una LAN rápidamente y sin crear una carga pesada en la red. Hay que tener en cuenta que localizar un nodo promiscuo es una tarea ardua, y que en muchos casos el resultado es incierto; no obstante, PromiScan consigue mostrar cada uno de esos nodos de una manera transparente, claramente visible. Para usar PromiScan es necesario contar con Windows 2000 Professional y haber instalado previamente el controlador WinPcap."

PromiscDetect

promiscdetect.exe

C:\scan>promiscdetect
PromiscDetect 1.0 - (c) 2002, Arne Vidstrom
(arne.vidstrom@ntsecurity.nu)
- http://ntsecurity.nu/toolbox/promiscdetect/ 

Adapter name: 

- NIC PCI 3Com EtherLink XL 10/100 PCI para administraci¾n completa
del equipo
(3C905C-TX) 

Active filter for the adapter: 

- Directed (capture packets directed to this computer)
- Multicast (capture multicast packets for groups the computer is a
member of)
- Broadcast (capture broadcast packets)
- Promiscuous (capture all packets on the network) 

WARNING: Since this adapter is in promiscuous mode there could be a
sniffer
running on this computer!

ProDETECT 0.2
BETA

http://sourceforge.net/projects/prodetect/

Alerta de ProDETECT:

Detección en redes conmutadas

En redes conmutadas o que hagan uso de switches, la técnica de ARP poisoning o envenenamiento arp es la más efectiva. Esta técnica consiste, muy brevemente, en modificar (envenenar) la tabla ARP de los host involucrados en el ataque para que éstos envíen a la red tramas Ethernet con destino la MAC del atacante. Esto significa que el switch entregará los datos de la comunicación a dicho host. Para evitar el refresco de la caché ARP es necesario el envió constante de arp-reply.

Una posible solución o defensa sería el uso de MACs estáticas, con el fin de que no puedan ser modificadas, aunque en algunos sistemas Windows esto no es eficiente al 100 por 100.

En sistemas Linux la herramienta ARPWatch ( http://www-nrg.ee.lbl.gov/) nos puede servir para detectar el uso del envenenamiento ARP en nuestro sistema. Con ARPWatch podemos comprobar la correspondencia entre pares IP-MAC (Ethernet). En caso de que un cambio en un par se produzca (esto es, se escuche en el interfaz de red del sistema), ARPWatch envía un correo de notificación del suceso a la cuenta root o administrador del sistema con un mensaje tipo “FLIP FLOP o Change ethernet address” . También podemos monitorizar la existencia de nuevos host (aparición de una nueva MAC en la red).

# ./arpwatch -?
Version 2.1a11
usage: arpwatch [-dN] [-f datafile] [-i interface] [-n net[/width]]
[-r file]
[-u username] [-e username] [-s username] 

# cat /etc/sysconfig/arpwatch
# -u <username> : defines with what user id arpwatch should run
# -e <email> : the <email> where to send the reports
# -s <from> : the <from>-address
OPTIONS=""

Una herramienta similar a ARPwatch pero para sistemas Windows la encontramos en WinARP Watch v1.0 ( http://www.securityfocus.com/data/tools/warpwatch.zip). Esta herramienta no enviará correo alguno a ningún administrador, pero nos tendrá puntualmente informados sobre la caché ARP, las correspondencias IP/MAC, cualquier nuevo par que se añada a la caché, etc.

Una alerta de WinARP Watch:

Existe un tipo especial de switches que está preparado para que la tabla ARP no pueda ser modificada.

Hablando de herramientas, una que realiza este trabajo de escucha en redes conmutadas con gran eficacia es Ettercap. Ettercap ( http://ettercap.sourceforge.net ) es capaz de escuchar tanto redes basadas en hubs como en switches. Además puede escuchar conexiones SSH e incluso detectar otros envenenamientos o modificaciones de la tabla ARP.

Detección de envenenamiento ARP con ettercap en un sistema Windows.

C:\...\ettercap>ettercap -Nc
ettercap 0.6.b (c) 2002 ALoR & NaGA
List of available devices : 

--> [dev0] - [3Com EtherLink PCI] 

Please select one of the above, which one ? [0]:
Your IP: 192.168.4.3 with MAC: 00:04:76:F2:C9:5F on Iface: dev0
Building host list for netmask 255.255.255.0, please wait… 

Sending 255 ARP request…
* |==================================================>| 100.00 % 

Resolving 14 hostnames…
* |==================================================>| 100.00 % 

Checking for poisoners… 

MAC of 192.168.4.59 and 192.168.4.235 are identical ! 

Otra herramienta que detecta cambios
en los pares IP/MAC así como ataques tipo arp-spoofing es ACiD (ARP
Change intrusion Detection)

C:\scan\ACID>acid
ACiD - 0.0.2 - (c) 2002 Roberto Larcher - robertolarcher@webteca.port5.com
All rights reserved. 

Press CTRL+C to stop. 

Initializing default adapter. Please wait... 

IP: 0.4.168.192 Subnet Mask: 0.255.255.255
Network type: Ethernet 

ACiD: bogon 192.168.4.1 00:04:76:97:b3:a9
ACiD: bogon 192.168.5.240 00:06:5b:05:9a:e7
ACiD: bogon 192.168.4.1 00:04:76:97:b3:a9
ACiD: bogon 192.168.2.3 00:a0:24:4d:bc:69
ACiD: bogon 192.168.4.5 00:04:76:9a:66:a6
ACiD: bogon 192.168.2.3 00:a0:24:4d:bc:69
ACiD: bogon 192.168.2.3 00:a0:24:4d:bc:69
ACiD: bogon 192.168.4.3 00:04:76:f2:c9:5f
ACiD: bogon 192.168.4.3 00:04:76:f2:c9:5f
ACiD: bogon 192.168.4.20 00:a0:24:4e:4e:4e
ACiD: bogon 192.168.5.240 00:06:5b:05:9a:e7
ACiD: bogon 192.168.4.5 00:04:76:9a:66:a6
ACiD: bogon 192.168.4.1 00:04:76:97:b3:a9
ACiD: bogon 192.168.4.20 00:a0:24:4e:4e:4e
ACiD: bogon 192.168.4.15 00:01:02:e7:57:cf
ACiD: bogon 192.168.4.8 00:10:4b:4d:15:bb 

Ctrl+C detected... 

IP  MAC table: 

192.168.2.3 00:a0:24:4d:bc:69
192.168.4.1 00:04:76:97:b3:a9
192.168.4.10 00:a0:24:4e:51:6b
192.168.4.15 00:01:02:e7:57:cf
192.168.4.20 00:a0:24:4e:4e:4e
192.168.4.3 00:04:76:f2:c9:5f
192.168.4.5 00:04:76:9a:66:a6
192.168.4.8 00:10:4b:4d:15:bb
192.168.5.240 00:06:5b:05:9a:e7 

ArpCount table: 

192.168.2.3 -3
192.168.4.1 -8
192.168.4.10 1
192.168.4.15 -2
192.168.4.20 3
192.168.4.3 -2
192.168.4.5 -10
192.168.4.8 1
192.168.5.240 -6

En la consola de ACID si existe un error
en la paridad IP/MAC nos alertará de esta manera:

ACiD: bogon 192.168.4.5 00:04:76:f2:c9:5f
(00:11:22:33:44:55)
ACiD: ethernet mismatch 192.168.4.5 00:04:76:f2:c9:5f (00:11:22:33:44:55)
ACiD: bogon 192.168.4.5 00:04:76:f2:c9:5f (00:11:22:33:44:55)
ACiD: ethernet mismatch 192.168.4.5 00:04:76:f2:c9:5f (00:11:22:33:44:55)
ACiD: bogon 192.168.4.5 00:04:76:f2:c9:5f (00:11:22:33:44:55)
ACiD: ethernet mismatch 192.168.4.5 00:04:76:f2:c9:5f (00:11:22:33:44:55)
ACiD: bogon 192.168.4.5 00:04:76:f2:c9:5f (00:11:22:33:44:55)
ACiD: ethernet mismatch 192.168.4.5 00:04:76:f2:c9:5f (00:11:22:33:44:55)
ACiD: bogon 192.168.4.1 00:04:76:97:b3:a9
ACiD: bogon 192.168.4.5 00:04:76:9a:66:a6
Possible spoof 192.168.4.5 00:04:76:9a:66:a6 was at 00:04:76:f2:c9:5f

Breve introducción a los sistemas IDS y Snort

• Un IDS o Sistema de Detección de Intrusiones es una herramienta de seguridad que intenta detectar o monitorizar los eventos ocurridos en un determinado sistema informático o red informática en busca de intentos de comprometer la seguridad de dicho sistema.
• Los IDS buscan patrones previamente definidos que impliquen cualquier tipo de actividad sospechosa o maliciosa sobre nuestra red o host.
• Los IDS aportan a nuestra seguridad una capacidad de prevención y de alerta anticipada ante cualquier actividad sospechosa. No están diseñados para detener un ataque, aunque sí pueden generar ciertos tipos de respuesta ante éstos.
• Los IDS: aumentan la seguridad de nuestro sistema, vigilan el tráfico de nuestra red, examinan los paquetes analizándolos en busca de datos sospechosos y detectan las primeras fases de cualquier ataque como pueden ser el análisis de nuestra red, barrido de puertos, etc.

Tipos de IDS

1. HIDS (Host IDS)

Protege contra un único Servidor, PC o host. Monitorizan gran cantidad de eventos, analizando actividades con una gran precisión, determinando de esta manera qué procesos y usuarios se involucran en una determinada acción. Recaban información del sistema como ficheros, logs, recursos, etc, para su posterior análisis en busca de posibles incidencias.

Todo ello en modo local, dentro del propio sistema. Fueron los primeros IDS en desarrollar por la industria de la seguridad informática.

2. NIDS (Net IDS)

Protege un sistema basado en red. Actúan sobre una red capturando y analizando paquetes de red, es decir, son sniffers del tráfico de red. Luego analizan los paquetes capturados, buscando patrones que supongan algún tipo de ataque.

Bien ubicados, pueden analizar grandes redes y su impacto en el tráfico suele ser pequeño. Actúan mediante la utilización de un dispositivo de red configurado en modo promiscuo (analizan, “ven” todos los paquetes que circulan por un segmento de red aunque estos nos vayan dirigidos a un determinado equipo). Analizan el trafico de red, normalmente, en tiempo real. No sólo trabajan a nivel TCP/IP, también lo pueden hacer a nivel de aplicación.

Otros tipos son los híbridos.

Por el tipo de respuesta podemos clasificarlos en:

Pasivos: Son aquellos IDS que notifican a la autoridad competente o administrador de la red mediante el sistema que sea, alerta, etc. Pero no actúa sobre el ataque o atacante.

Activos: Generan algún tipo de respuesta sobre el sistema atacante o fuente de ataque como cerrar la conexión o enviar algún tipo de respuesta predefinida en nuestra configuración.

Snort puede funcionar de las dos maneras.

Arquitectura de un IDS

Normalmente la arquitectura de un IDS, a grandes rasgos, está formada:

1. La fuente de recogida de datos. Estas fuentes pueden ser un log, dispositivo de red, o como en el caso de los IDS basados en host, el propio sistema.
2. Reglas que contienen los datos y patrones para detectar anomalías de seguridad en el sistema.
3. Filtros que comparan los datos snifados de la red o de logs con los patrones almacenados en las reglas.
4. Detectores de eventos anormales en el tráfico de red.
5. Dispositivo generador de informes y alarmas. En algunos casos con la sofisticación suficiente como para enviar alertas vía mail, o SMS.

Esto es a modo general. Cada IDS implementa la arquitectura de manera diferente.

Dónde colocar el IDS

Una actitud paranoica por nuestra parte nos podría llevar a instalar un IDS en cada host ó en cada tramo de red. Esto último sería un tanto lógico cuando se trata de grandes redes, no es nuestro caso ahora. Lo lógico sería instalar el IDS en un dispositivo por donde pase todo el tráfico de red que nos interese.

Dificultades

Un problema de los IDS es cuando queremos implementarlos en redes conmutadas ya que no hay segmento de red por donde pase todo el tráfico. Otro problema para un IDS son las redes con velocidades de tráfico muy altas en las cuales es difícil procesar todos los paquetes.

Posición del IDS

Si colocamos el IDS antes del cortafuegos capturaremos todo el tráfico de entrada y salida de nuestra red. La posibilidad de falsas alarmas es grande.

La colocación detrás del cortafuegos monitorizará todo el tráfico que no sea detectado y parado por el firewall o cortafuegos, por lo que será considerado como malicioso en un alto porcentaje de los casos. La posibilidad de falsas alarmas muy inferior.

Algunos administradores de sistemas colocan dos IDS, uno delante y otro detrás del cortafuegos para obtener información exacta de los tipos de ataques que recibe nuestra red ya que si el cortafuegos está bien configurado puede parar o filtras muchos ataques.

En ambientes domésticos, que es el propósito de este taller sobre IDS y Snort, podemos colocar el IDS en la misma máquina que el cortafuegos. En este caso actúan en paralelo, es decir, el firewall detecta los paquetes y el IDS los analizaría.

Introducción a Snort

Snort es un IDS o Sistema de detección de intrusiones basado en red (NIDS). Implementa un motor de detección de ataques y barrido de puertos que permite registrar, alertar y responder ante cualquier anomalía previamente definida como patrones que corresponden a ataques, barridos, intentos aprovechar alguna vulnerabilidad, análisis de protocolos, etc conocidos. Todo esto en tiempo real.

Snort (http://www.snort.org/) está disponible bajo licencia GPL, gratuito y funciona bajo plataformas Windows y UNIX/Linux. Es uno de los más usados y dispone de una gran cantidad de filtros o patrones ya predefinidos, así como actualizaciones constantes ante casos de ataques, barridos o vulnerabilidades que vayan siendo detectadas a través de los distintos boletines de seguridad.

Este IDS implementa un lenguaje de creación de reglas flexibles, potente y sencillo. Durante su instalación ya nos provee de cientos de filtros o reglas para backdoor, ddos, finger, ftp, ataques web, CGI, escaneos Nmap….

Puede funcionar como sniffer (podemos ver en consola y en tiempo real qué ocurre en nuestra red, todo nuestro tráfico), registro de paquetes (permite guardar en un archivo los logs para su posterior análisis, un análisis offline) o como un IDS normal (en este caso NIDS).

En este taller daremos una importancia mayor a su funcionamiento como NIDS y, sobre todo, a la creación personalizada de reglas e interpretación de las alertas.

La colocación de Snort en nuestra red puede realizarse según el tráfico quieren vigilar: paquetes que entran, paquetes salientes, dentro del firewall, fuera del firewall… y en realidad prácticamente donde queramos.

Una característica muy importante e implementada desde hace pocas versiones es FlexResp. Permite, dada una conexión que emita tráfico malicioso, darla de baja, hacerle un DROP mediante el envío de un paquete con el flag RST activa, con lo cual cumpliría funciones de firewall, cortando las conexiones que cumplan ciertas reglas predefinidas. No sólo corta la conexiones ya que puede realizar otras muchas acciones. Veremos más adelante su funcionamiento y ejemplos.

NOTA: Todos los ejemplos, mientras no se indique lo contrario, serán válidos para win32 y Linux/UNIX.

C:\Snort20\bin>snort
-*> Snort! <*-
Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike)
1.8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com)
USAGE: snort [-options] <filter options>
snort /SERVICE /INSTALL [-options] <filter options>
snort /SERVICE /UNINSTALL
snort /SERVICE /SHOW
Options:
-A Set alert mode: fast, full, console, or none (alert file alerts only)
-b Log packets in tcpdump format (much faster!)
-c <rules> Use Rules File <rules>
-C Print out payloads with character data only (no hex)
-d Dump the Application Layer
-e Display the second layer header info
-E Log alert messages to NT Eventlog. (Win32 only)
-f Turn off fflush() calls after binary log writes
-F <bpf> Read BPF filters from file <bpf>
-h <hn> Home network = <hn>
-i <if> Listen on interface <if>
-I Add Interface name to alert output
-k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none)
-l <ld> Log to directory <ld>
-L <file> Log to this tcpdump file
-n <cnt> Exit after receiving <cnt> packets
-N Turn off logging (alerts still work)
-o Change the rule testing order to Pass|Alert|Log
-O Obfuscate the logged IP addresses
-p Disable promiscuous mode sniffing
-P <snap> Set explicit snaplen of packet (default: 1514)
-q Quiet. Don’t show banner and status report
-r <tf> Read and process tcpdump file <tf>
-R <id> Include ‘id’ in snort_intf<id>.pid file name
-s Log alert messages to syslog
-S <n=v> Set rules file variable n equal to value v
-T Test and report on the current Snort configuration
-U Use UTC for timestamps
-v Be verbose
-V Show version number
-W Lists available interfaces. (Win32 only)
-w Dump 802.11 management and control frames
-X Dump the raw packet data starting at the link layer
-y Include year in timestamp in the alert and log files
-z Set assurance mode, match on established sesions (for TCP)
-? Show this information
<Filter Options>
are standard BPF options, as seen in TCPDump

Uh, you need to tell me to do something…

: No such file or directory

Snort en modo Sniffer y registro de paquetes

El formato genérico para este modo es: snort [-opciones] < filtro >

C:\Snort20\bin>snort -v
Running in packet dump mode
Log directory = log

Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

--== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}
--== Initialization Complete ==--

-*> Snort! <*-

Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike)
1.8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com)
05/21-11:00:28.593943 ARP who-has 192.168.2.92 tell 192.168.2.60

05/21-11:00:28.594419 ARP who-has 192.168.2.8 tell 192.168.2.60

05/21-11:00:28.594544 ARP who-has 192.168.2.93 tell 192.168.2.60

05/21-11:00:30.467265 192.168.2.5:1025 -> 192.168.2.1:139
TCP TTL:128 TOS:0x0 ID:16685 IpLen:20 DgmLen:104 DF
***AP*** Seq: 0x6B703 Ack: 0x2266A0C Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:00:30.467731 192.168.2.1:139 -> 192.168.2.5:1025
TCP TTL:128 TOS:0x0 ID:47513 IpLen:20 DgmLen:1500 DF

Con esta opción -v iniciamos snort en modo sniffer visualizando en pantalla las cabeceras de los paquetes TCP/IP, es decir, en modo sniffer. Esta opción el modo verbouse y mostrará las cabeceras IP, TCP, UDP y ICMP.

Si queremos, además, visualizar los campos de datos que pasan por la interface de red, añadiremos -d.

C:\Snort20\bin>snort -vd
Running in packet dump mode
Log directory = log
Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:06:18.943887 192.168.4.5:3890 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:33216 IpLen:20 DgmLen:40 DF
***A**** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:06:18.962018 192.168.4.5:3890 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:33217 IpLen:20 DgmLen:681 DF
***AP*** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20
47 45 54 20 68 74 74 70 3A 2F 2F 77 77 77 2E 6F GET http://www.x
6D 65 6C 65 74 65 2E 63 6F 6D 2E 62 72 2F 73 75 xxxx.com.br/xx
70 65 72 6F 6D 65 6C 65 74 65 2F 64 6F 77 6E 6C xxxxxxx/downl
6F 61 64 73 2F 64 65 66 61 75 6C 74 2E 61 73 70 oads/default.asp
20 48 54 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D HTTP/1.0..User-
41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 34 Agent: Mozilla/4
2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65 3B 20 .0 (compatible;
4D 53 49 45 20 36 2E 30 3B 20 57 69 6E 64 6F 77 MSIE 6.0; Window
73 20 4E 54 20 35 2E 30 29 20 4F 70 65 72 61 20 s NT 5.0) Opera
37 2E 31 31 20 20 5B 65 6E 5D 0D 0A 48 6F 73 74 7.11 [en]..Host
3A 20 77 77 77 2E 6F 6D 65 6C 65 74 65 2E 63 6F : www.xxxxx.co
6D 2E 62 72 0D 0A 41 63 63 65 70 74 3A 20 74 65 m.br..Accept: te
78 74 2F 68 74 6D 6C 2C 20 69 6D 61 67 65 2F 70 xt/html, image/p
6E 67 2C 20 69 6D 61 67 65 2F 6A 70 65 67 2C 20 ng, image/jpeg,
69 6D 61 67 65 2F 67 69 66 2C 20 69 6D 61 67 65 image/gif, image
2F 78 2D 78 62 69 74 6D 61 70 2C 20 2A 2F 2A 3B /x-xbitmap, */*;
71 3D 30 2E 31 0D 0A 41 63 63 65 70 74 2D 4C 61 q=0.1..Accept-La
……

Añadiendo la opción -e, snort nos mostrará información más detallada. Nos mostrará las cabeceras a nivel de enlace.

Con estas opciones y dependiendo del tráfico en nuestra red, veremos gran cantidad de información pasar por nuestra pantalla, con lo cual sería interesante registrar, guardar estos datos a disco para su posterior estudio. Entraríamos entonces en snort como packet logger o registro de paquetes.

C:\Snort20\bin>snort -dev -l ./log

La opción -l indica a snort que debe guardar los logs en un directorio determinado, en este caso Error! Hyperlink reference not valid. Dentro de la carpeta log se creará una estructura de directorios donde se archivarán los logs.

Podemos indicar la ip de la red a registrar ( -h ) y que el formato de los logs sea en modo binario ( -b ), es decir, el modo que entiende TCPDump o Windump, para estudiar más a fondo con los potentes filtros de estos programas los logs de snort. La salida del logs en el caso de la opción de salida binaria ya no será una estructura de directorios, si no, un sólo archivo.

C:\Snort20\bin>snort -vde -l ./log -h 192.168.4.0/24
Running in packet logging mode
Log directory = ./log

C:\Snort20\bin>snort -l ./log -b
Running in packet logging mode
Log directory = ./log

Usando la opción -b no hará falta indicarle IP alguna de nuestra red ( -h ). Guardará todo en un mismo archivo y recogerá datos de toda nuestra red. Tampoco serán necesarias las opciones -de y por supuesto, tampoco la opción -v.

El archivo generado por snort en modo binario también podemos leerlo con este usando la opción -r nombrearchivo.log.

Otra opción a toma en cuenta es -i para indicar a snort que interface de red usar en el caso de que tengamos dos o más. Se hace de distinta forma dependiendo si usamos snort para Win32 o para Linux/UNIX. Para averiguar las interfaces de que disponemos, en Win32 usaremos la opción -W.

C:\Snort20\bin>snort -vde -i 1
# snort -vde -i eth0
C:\Snort20\bin>snort -W

Filtros

Podemos añadir, a parte de las opciones, una serie de filtros para optimizar los resultados obtenidos. Estos filtros se añadirán en el mismo formato que usa programas como TCPDump ya que usan las mismas librerías de captura de paquetes (libpcap).

C:\Snort20\bin>snort -vd host 192.168.4.5 and dst port 8080
Running in packet dump mode
Log directory = ./log

Initializing Network Interface eth0

--== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface eth0
--== Initialization Complete ==--

-*> Snort! <*-

Version 2.0.0 (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
07/15-12:34:26.059644 192.168.4.5:4533 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:16544 IpLen:20 DgmLen:40 DF
***A**** Seq: 0xC47AC53E Ack: 0xC83C2362 Win: 0xFAF0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/15-12:34:26.059880 192.168.4.5:4533 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:16545 IpLen:20 DgmLen:40 DF
***A**** Seq: 0xC47AC53E Ack: 0xC83C31E4 Win: 0xFAF0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Snort aceptará también filtros más avanzados en su modo sniffer:

C:\Snort20\bin>snort -vd icmp[0] = 8 and dst host 192.168.4.1

C:\Snort20\bin>snort -vd icmp[0] != 8 and icmp[0] != 0

C:\Snort20\bin>snort -vd ‘udp[0:2] < 1024′ and host 192.168.4.1

Snort en modo NIDS.

En este apartado es donde nos centraremos más. El modo detección de intrusos de red se activa añadiendo a la línea de comandos de snort la opción -c snort.conf. En este archivo, snort.conf, se guarda toda la configuración de las reglas, preprocesadores y otras configuraciones necesarias para el funcionamiento en modo NIDS.

C:\Snort20\bin>snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

Con al opción -D indicará a snort que corra como un servicio. Esto es sólo válido para las versiónes Linux/UNIX:

# snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -D

Para las versión win32 usaremos /SERVICE /INSTALL:

C:\Snort20\bin>snort /SERVICE /INSTALL -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

/SERVICE /UNINSTALL desinstala snort como servicio.

Snort creará, a parte de la estructura de directorios, un archivo alert.ids donde almacenará las alertas generadas.

Modos de Alerta

Hay varias maneras de configurar la salida de snort, es decir, las alertas, el modo en que se almacenarán estas en el archivo alert.ids.

Snort dispone de siete modos de alertas en la línea de ordenes, completo, rápido, socket, syslog, smb (WinPopup), consola y ninguno.

Fast: El modo Alerta Rápida nos devolverá información sobre: tiempo, mensaje de la alerta, clasificación, prioridad de la alerta, IP y puerto de origen y destino.

C:\Snort20\bin>snort -A fast -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

09/19-19:06:37.421286 [**] [1:620:2] SCAN Proxy (8080) attempt [**]
[Classification: Attempted Information Leak] [Priority: 2] …
… {TCP} 192.168.4.3:1382 -> 192.168.4.15:8080

Full: El modo de Alerta Completa nos devolverá información sobre: tiempo, mensaje de la alerta, clasificación, prioridad de la alerta, IP y puerto de origen/destino e información completa de las cabeceras de los paquetes registrados.

C:\Snort20\bin>snort -A full -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

[**] [1:620:2] SCAN Proxy (8080) attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
09/19-14:53:38.481065 192.168.4.3:3159 -> 192.168.4.15:8080
TCP TTL:128 TOS:0×0 ID:39918 IpLen:20 DgmLen:48 DF
******S* Seq: 0xE87CBBAD Ack: 0×0 Win: 0×4000 TcpLen: 28
TCP Options (4) => MSS: 1456 NOP NOP SackOK

Información de la cabecera del paquete:

TCP TTL:128 TOS:0x0 ID:39918 IpLen:20 DgmLen:48 DF
******S* Seq: 0xE87CBBAD Ack: 0x0 Win: 0x4000 TcpLen: 28
TCP Options (4) => MSS: 1456 NOP NOP SackOK

Socket: Manda las alertas a través de un socket, para que las escuche otra aplicación. Está opción es para Linux/UNIX.

# snort -A unsock -c snort.conf

Console: Imprime las alarmas en pantalla.

C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

None: Desactiva las alarmas.

# snort -A none -c snort.conf

SMB: Permite a Snort realizar llamadas al cliente de SMB (cliente de Samba, en Linux), y enviar mensajes de alerta a hosts Windows (WinPopUp). Para activar este modo de alerta, se debe compilar Snort con el conmutador de habilitar alertas SMB (enable -smbalerts). Evidentemente este modo es para sistemas Linux/UNIX. Para usar esta característica enviando un WinPopUp a un sistema Windows, añadiremos a la línea de comandos de snort: -M WORKSTATIONS.

Syslog: Envía las alarmas al syslog

C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -s 192.168.4.33:514

Eventlog: Registra las alertas para visualizarse a través del visor de sucesos de un sistema windows. Esta opción se activará mediante -E y sólo para Win32.