Inicio > Hacking, Networking, Services - Software > Intentando evadir mecanismos y restricciones de Seguridad – Burlando reglas de detección de Snort con NMAP – Parte VIII

Intentando evadir mecanismos y restricciones de Seguridad – Burlando reglas de detección de Snort con NMAP – Parte VIII


En la entrada anterior se han establecido las bases para utilizar Nmap y ejecutar un ataque de reconocimiento de forma “sigilosa”, evadiendo mecanismos de seguridad en el objetivo y evitando ser detectados en nuestras acciones, en este orden de ideas, anteriormente se han definido algunas de las opciones disponibles en Nmap para este propósito, inclusive se utilizó una técnica muy efectiva conocida como Idle Scan.

En esta ocasión, se intentará evadir las reglas y preprocessors de Snort para que de este modo, el escaneo efectuado contra el objetivo, sea lo mas silencioso posible, tratando de no despertar sospechas ni levantar ninguna alarma de las definidas en Snort (con las reglas y opciones de los preprocessors correctamente configuradas). Con esto en mente, se intenta utilizar diferentes opciones de Nmap para realizar el escaneo a diferentes máquinas en el segmento de red (Snort se ejecutará como NIDS) de esta forma se medirá el nivel de eficiencia de Snort y las opciones de configuración disponibles ante las diferentes técnicas de evasión existentes en NMAP.

Partiendo de la base que Snort se encuentra en ejecución con los preprocessors HTTP Inspect, Frag3, Stream5, sfPortScan, entre otros más, se intenta ejecutar comandos Nmap contra máquinas pertenecientes al segmento de red inspeccionado y se detalla el comportamiento de Snort.

Se inicia Snort de la siguiente forma:

>snort -i eth0 -A console –daq dump -c /etc/snort/snort.conf

Posteriormente, las siguientes pruebas determinan el comportamiento de Snort ante ataques de reconocimiento utilizando Nmap

DECOY SCAN CON NMAP

Se intenta ejecutar un escaneo Stealthy con 7 “señuelos”

nmap -sS -D 192.168.1.30,192.168.1.31,192.168.1.32,192.168.1.35,192.168.1.36,192.168.1.37,ME 192.168.1.34

Snort identifica el ataque y genera una alerta:

06/26-18:05:39.953695 [**] [122:2:0] (portscan) TCP Decoy Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.30 -> 192.168.1.34

FRAGMENTACION DE PAQUETES NMAP

Se ejecuta un escaneo TCP sin ejecutar ICMP_REPLY/ICMP_ECHO y fragmentando los paquetes a 8 bytes

nmap -PN -P0 -f 192.168.1.34

El preprocessor Frag3 de Snort identifica un ataque de fragmentación de paquetes y genera una alarma, ademas, el preprocessor sfPortScan identifica que se intenta realizar un escaneo de puertos TCP.

06/26-18:29:02.793913 [**] [123:13:1] (spp_frag3) Tiny fragment [**] [Priority: 3] {TCP} 192.168.1.33 -> 192.168.1.34

06/26-18:29:02.794002 [**] [123:13:1] (spp_frag3) Tiny fragment [**] [Priority: 3] {TCP} 192.168.1.33 -> 192.168.1.34

06/26-18:29:02.794086 [**] [123:13:1] (spp_frag3) Tiny fragment [**] [Priority: 3] {TCP} 192.168.1.33 -> 192.168.1.34

06/26-18:29:02.794108 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.34

06/26-18:29:02.794221 [**] [123:13:1] (spp_frag3) Tiny fragment [**] [Priority: 3] {TCP} 192.168.1.33 -> 192.168.1.34

HOSTS ALEATORIOS CON NMAP

Se intenta ejecutar un escaneo de puertos generando un grupo de direcciones aleatorias y cambiando el puerto origen de la petición.

nmap –source-port 80 -sS -n –randomize-hosts -PN 192.168.1.34

Snort solamente consigue obtener una alarma relacionada con el Escaneo

06/26-18:49:36.255313 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.34

ESCANEO NMAP REALIZANDO SPOOFING SOBRE LA IDENTIDAD DEL ATACANTE

Con NMAP es posible definir una dirección IP falsa, puertos falsos y MAC falsa para realizar un escaneo contra una máquina objetivo, de esta forma, aunque exista un sistema de detección de intrusos establecido en la red donde se localiza el objetivo y este detecta que se esta realizando un escaneo de puertos, los logs se verán alterados indicando la dirección origen que el atacante ha querido. Se trata de una técnica muy útil, sin embargo no es muy sutil, ya que aunque la identidad del atacante no se ve comprometida (en teoría), es posible que se disparen todas las alarmas en el objetivo por un posible ataque de reconocimiento.

nmap -PN –spoof-mac 00:11:22:33:44:55 –source-port 80 -n -e eth0 -S 192.168.1.22 192.168.1.34

La dirección 192.168.1.22 no existe, sin embargo, Snort simplemente ha alertado que se esta llevando a cabo un escaneo de puertos desde la máquina con dirección IP 192.168.1.22

07/01-18:43:59.477619 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.22 -> 192.168.1.34

Como puede apreciarse, la alerta generada no contiene trazas relacionadas con la dirección IP real del atacante. Como nota adicional, se debe tener en cuenta desactivar consultas DNS reversas (-n) y no ejecutar un ping antes del escaneo (-PN) y no se debe utilizar un escaneo TCP (-sT) ya que en dicho caso Snort detectará la dirección real del atacante.

nmap -sT -PN –spoof-mac 00:11:22:33:44:55 –source-port 80 -n -e eth0 -S 192.168.1.22 192.168.1.34

WARNING: -S will only affect the source address used in a connect() scan if you specify one of your own addresses. Use -sS or another raw scan if you want to completely spoof your source address, but then you need to know what you’re doing to obtain meaningful results.

WARNING: -g is incompatible with the default connect() scan (-sT). Use a raw scan such as -sS if you want to set the source port.

El resultado en la traza de Snort.

07/01-19:53:30.908484 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.34

Como se puede apreciar, Snort ha identificado la dirección IP real del atacante.

ESCANEO CONTROLANDO DEL TIEMPO DE ENTEGA DE PAQUETES CON NMAP

Se ejecuta un escaneo con Nmap utilizando control de tiempo de entrega de los paquetes a la máquina objetivo, de esta forma, es mucho más difícil que Snort pueda identificar el ataque, para conseguir esto se utiliza la opción -T como se ha indicado en la entrada anterior, dependiendo del mecanismo utilizado (T1, T2, T3, etc.) el tiempo del escaneo puede variar considerablemente.

T0:

nmap -T0 192.168.1.34

Snort no ha conseguido identificar el ataque de escaneo de puertos sin embargo, el tiempo empleado en el escaneo fue bastante alto, entre 2 y 4 horas.

T1:

nmap -T1 192.168.1.34

Snort no ha conseguido identificar el ataque de escaneo de puertos sin embargo, el tiempo empleado en el escaneo fue bastante alto, entre 30 y 45 minutos.

T2:

nmap -T2 192.168.1.34

Snort no ha podido identificar que se trata de un ataque de reconocimiento, por otro lado, el escaneo ha tardado aproximadamente 20 minutos.

T3:

nmap -T3 192.168.1.34

Snort no ha identificado el ataque de reconocimiento llevado a cabo por Nmap, ademas, ha tardado aproximadamente 10 minutos.

T4:

nmap -T4 192.168.1.34

Snort ha identificado el ataque de reconocimiento y ha generado una alarma relacionada con el escaneo realizado.

06/26-19:24:49.419571 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.34

T5:

nmap -T5 192.168.1.41

Snort detecta el ataque y genera tres alarmas por el escaneo, la ejecución de Nmap ha tardado menos de un minuto.

06/26-19:10:54.275733 [**] [122:3:0] (portscan) TCP Portsweep [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.41

06/26-19:10:54.275733 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.41

06/26-19:11:09.100088 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} 192.168.1.33 -> 192.168.1.41

NOTA: Aunque los tiempos tomados y las alarmas generadas son un indicativo más o menos fiable, dependiendo del entorno que se desee escanear, es posible que Snort pueda detectar el ataque, en un entorno real con unos niveles de seguridad óptimos, probablemente sea conveniente utilizar valores mas bajos (-T0, -T1) aunque el escaneo puede llevar incluso horas, sin embargo si es prioritario no despertar ninguna sospecha, esta es la mejor opción.

ESCANEO NMAP CON OPCIONES DE PROTOCOLO IP INVALIDAS Y CONTROL DE TIEMPO

En la entrada anterior se realizaba un escaneo con Nmap utilizando una opción IP invalida que dependiendo del sistema operativo, el objetivo era capaz de procesarlo o no, de esta forma era posible distinguir entre un sistema Windows y un sistema GNU/Linux, sin embargo cuando se ejecuta sin mas opciones, Snort identifica el ataque y el preprocessor Frag3 genera las alarmas correspondientes, sin embargo utilizando la opción de control de tiempo de envió de paquetes, Snort no identifica el ataque de reconocimiento que se esta llevando a cabo

nmap -T3 -PN –ip-options “\1\8\3\4″ 192.168.1.34

Ademas de que Snort no ha conseguido identificar el ataque, se ha logrado distinguir el sistema operativo en función a la respuesta generada.

Finalmente, como conclusión, se ha podido apreciar que una de las mejores formas de evadir las restricciones de seguridad definidas en Snort, es precisamente controlar el tiempo de envío de paquetes fragmentados al objetivo, aunque en contrapartida el escaneo sera muchísimo mas lento, los resultados serán por otro lado mucho mas fiables y existe una probabilidad mayor de que el escaneo no sea identificado por Snort.

  1. Aún no hay comentarios.
  1. No trackbacks yet.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 921 seguidores

%d personas les gusta esto: