Cualquier tipo de ataque que se lleve a cabo contra un sistema normalmente siempre esta precedido por un ataque previo de reconocimiento del objetivo para recolectar la mayor cantidad de información posible (proceso conocido como fingerprint), para esta tarea existen diversos tipos de herramientas como Nmap, Hping, entre muchas otras. Con esto en mente Snort tiene un modulo preprocessor que es capaz de detectar este tipo de ataques para tomar medidas al respecto llamado sfPortScan.

El modo de funcionamiento de este modulo consiste en detectar las respuestas negativas (peticiones a puertos cerrados) en un periodo de tiempo determinado, dado que las respuestas negativas en peticiones legitimas son escasas y mucho mas aun, un número elevado de estas respuestas negativas, esto frecuentemente suele indicar que se esta realizando un ataque activo de reconocimiento.

En el caso de este modulo, el enfoque se centra en la detección de los diferentes tipos de escaneo utilizados por Nmap, tales como TCP Scan, UDP Scan, IP Scan, XMAS Scan, etc.

Por otro lado Nmap tiene una característica muy interesante que consiste en la generación de “Decoys” que son direcciones IP mezcladas con la dirección IP real del atacante, de esta forma es posible ocultar la dirección IP del atacante. Snort también genera alertas sobre este tipo de ataques, sin embargo, también es necesario comprender, que en algunas ocasiones, algunos host que tienen trafico legitimo, realizan un numero considerable de peticiones cuyas respuestas son negativas, estos son los casos de servidores DNS, servicios que realizan peticiones ICMP, etc. Para estos casos el modulo también permite definir una lista de direcciones IP “fiables” que no se identificarán como posibles amenazas. Aunque como seguramente el lector ya comenzará a imaginar, este tipo de relaciones de confianza en muchas ocasiones son utilizadas por atacantes con un buen nivel de habilidades, por lo tanto en este punto hay que ser precavidos, ya que si el nivel de seguridad de la maquina confiable no es adecuado, puede existir una brecha de seguridad. A continuación se procede a indicar el uso de este preprocessor y sus opciones de configuración.

sfportscan

En primer lugar, para que este modulo pueda funcionar es necesario activar el modulo stream5 visto en la entrada anterior, a continuación se listan las opciones disponibles en sfportscan

proto <protocolo>

Protocolo que el modulo analizará en búsqueda de ataques de reconocimiento.

Los valores aceptados son:
TCP, UDP, IGMP, ip_proto y all

scan_type <tipo>

Tipo de escaneo que el modulo analizará.

Los valores aceptados son:
portscan, portsweep, decoy_portscan , distributed_portscan , all

sense_level <nivel>

Se trata del nivel de alarmas generadas por este modulo, los valores son:
low: Las alertas solamente son generadas en paquetes erróneos y debido a la naturaleza de los paquetes de esta clase, es muy probable que se generen muy pocos falsos positivos, sin embargo, en este nivel nunca se generarán alertas sobre escaneo sobre puertos Filtrados, debido a que no hay errores

medium: Cuenta el numero de conexiones, por lo tanto, puede generar alertas para escaneo sobre puertos filtrados, sin embargo puede generar falsos positivos sobre hosts legítimos que tienen un nivel alto de actividad en la red (servidores DNS, proxies, NAT, caches, etc.) Por esta razón existen las propiedades ignore_* que se verán mas adelante y permiten refinar esta directiva.

high: Intenta tracear de forma continua los hosts pertenecientes al segmento de red usando el tiempo de ventana para evaluar las estadísticas de escaneo de puertos para cada host. Este tipo de directiva podrá capturar ataques de escaneo “lentos” que frecuentemente se ejecutan con Nmap para evadir IDS, sin embargo debido al continuo monitoreo de esta directiva, es altamente sensible a hosts legítimos que tengan un nivel alto de actividad en la red, con lo que se generará un alto número de falsos positivos.

watch_ip <ip1|ip2[puerto1-puerto3]>

Define una lista de direcciones IP, segmentos de red y puertos para monitorear, la lista se encuentra separada por coma.

ignore_scanners <ip1|ip2[puerto1-puerto3]>

Define una lista de direcciones IP, segmentos de red y puertos que son ignorados si el origen del paquete coincide con alguna de estas direcciones, la lista se encuentra separada por coma.

ignore_scanned <ip1|ip2[puerto1-puerto3]>

Define una lista de direcciones IP, segmentos de red y puertos que son ignorados si el destino del paquete coincide con alguna de estas direcciones, la lista se encuentra separada por coma.

logfile <fichero>

Con esta opción se declarará un fichero donde escribir los eventos relacionados con este modulo.

detect ack scans

Esta opción incluye sesiones capturadas en flujo, por el modulo stream5, el cual es necesario para detectar escaneos ACK, sin embargo esto puede llevar a alertas falsas, especialmente bajo cargas pesadas con paquetes borrados, por esta razón esta opción se encuentra desactivada por defecto.

Un ejemplo de configuración valida para activar este preprocessor puede ser:

preprocessor flow: stats_interval 0 hash 2preprocessor sfportscan:\proto { all } \

scan_type { all } \

sense_level { low } \

logfile { /home/adastra/log_sfportscan/logfile.log }

Ahora, en el momento en el que se realizan escaneos con Nmap se producen los siguientes eventos en Snort

>snort -i eth0 -A console –daq dump -l /home/adastra/logs/ -c /etc/snort/snort.conf

Commencing packet processing (pid=2489)06/19-02:51:37.767339

[**] [122:1:0] (portscan) TCP Portscan

[**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.34 06/19-02:51:57.168861

[**] [122:17:0] (portscan) UDP Portscan

[**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.34 06/19-02:53:39.663036

[**] [122:1:0] (portscan) TCP Portscan

[**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.34

Adicionalmente se genera un fichero de log donde se han almacenado los eventos que ha capturado el modulo sfportscan, las primeras lineas del fichero contienen los siguientes campos:

Time: 06/19-02:48:49.269332event_id: 2192.168.1.33 -> 192.168.1.34 (portscan) TCP Portscan

Priority Count: 5

Connection Count: 5

IP Count: 1

Scanner IP Range: 192.168.1.33:192.168.1.33

Port/Proto Count: 5

Port/Proto Range: 23:8888

………

Esta información es útil para analizar lo que ha ocurrido y determinar si se trata de un falso negativo o un ataque real, a continuación se indican algunas técnicas o tips que recomiendan los desarrolladores y expertos de Snort para optimizar sfPortscan.

Optimizando sfPortscan

Para conseguir un optimo rendimiento de este modulo y evitar falsos positivos se deben tener en cuenta las siguientes pautas de configuración

  1. Se debe utilizar watch_ip, ignore_scanners y ignore_scanned para evitar que trafico legitimo como por ejemplo el generado por proxies, NAT, DHCP, DNS y otros servicios sea tratado como un ataque de reconocimiento, posteriormente para saber en cual opción incluir un servicio dado, se debe seguir la siguiente premisa, si la alerta generada sobre el host confiable es una alerta del tipo “portsweep” la dirección IP debe incluirse en la opción ignore_scanners, si el host confiable genera una alerta del tipo “portscan” la dirección IP debe incluirse en la opción ignore_scanned
  2. Los escaneos sobre puertos filtrados son mucho mas propensos a falsos positivos, por lo tanto cuando se produce una alerta que esta asociada con escaneo de puertos filtrados, no siempre indica un ataque de reconocimiento, en ocasiones indica simplemente que un host ha estado muy activo durante un periodo de tiempo
  3. Analizar la información generada por los ficheros de log para determinar falsos positivos, frecuentemente se utilizan estimaciones en función de los campos Priority Count, Connection Count, IP Count, Port Count, IP Range, y Port Range , las estimaciones son las siguientes:
    Connection Count/IP Count: Estos valores indican un promedio estimado de conexiones por IP. Para portscans este valor debe de ser alto (entre mas alto mas probable que se trate de un ataque) para portsweeps este valor debe de ser bajo.
    Port Count/IP Count: Estos valores indican un promedio estimado de puertos conectados por dirección IP. Para portscanns este valor debe de ser alto indicando que los puertos escaneados del host han sido conectados por pocas direcciones IP (probablemente alguna o todas, direcciones del atacante) para portsweeps esta medida debe de ser baja indicando que se llevarón a cabo conexiones sobre pocos puertos pero sobre muchos host.
    Connection Count/Port Count: Indica un promedio estimado de conexiones por puerto. Para portscans este promedio debe de ser bajo indicando que cada conexión fue realizada a un puerto diferente. Para portsweeps, este promedio estimado debe ser bajo indicando que muchas conexiones fueron realizadas sobre el mismo puerto.
  4. Si las reglas anteriores han fallado y no han dado suficientes indicios sobre falsos positivos, lo mas probable es que sea necesario bajar el nivel de sensibilidad a “low” como se ha indicado anteriormente, el nivel “low” es mucho menos propenso a falsos positivos, lo que en muchos casos es deseable, dado que un analista lo que necesita es tener logs informativos, no logs “amplios” con muchos datos pero poca información valiosa.