Las técnicas de escaneo pueden dividirse en dos grupos: Open scanning (escaneo abierto), Halfopen scanning (escaneo a medio abrir) y Stealth scanning (escaneo sigiloso). Esta división se hace en función del grado de conexión realizada contra la máquina destino y en función de las
características de los paquetes enviados. Conocer qué técnica es la más adecuada depende de la topología de la red, de si existe o no un IDS detrás, del grado de “logueo” del sistema.
El empleo de un escaneo de tipo Open scanning nos proporciona un nivel de fiabilidad muy levado y conveniente, pero hay que tener en cuenta que los logs dejados son altos y harían saltar a cualquier sistema IDS y el escaneo sería conocido. Por otra parte, si usamos Stealth scanning, podremos evitar determonados sistemas IDS y sobrepasar ciertas reglas de cortafuegos. Sin embargo, un inconveniente de esta técnica es que determinadas circunstancias, suele proveer de falsos positivos, por lo que deberemos saber cómo interpretar los resultados.
Full TCP Connection
Si deseamos una fiabilidad del 100% en los resultados devueltos, ésta es la técnica que debemos aprovechar, siempre teniendo en mente que es la que más rastros deja en el log del sistema remoto y la más sencilla de filtrar. Si no nos importa que nos detecten, ya sea porque se trata de un sistema al que estemos haciendo una auditoría, porque es un equipo de nuestra propiedad o cualquier otra razón, ésta técnica es la más efectiva y rápida.
Figura N°1 Full TCP Connection: Puerto Abierto
La técnica del Full TCP Connection implica abrir una conexión completa con el equipo remoto con el modo de conexión normal, conocido como three-way TCP/IP handshake29. En la figura 1 podemos ver el proceso llevado a cabo para crear y establecer la conexión. Se hace uso de los siguientes flags para crear y establecer la conexión: SYN, SYN/ACK, ACK.
Inicialmente la máquina origen (cliente) envía un paquete con el flag SYN activado a la máquina destino (servidor). El servidor responde con los flags SYN/ACK activados, lo que indica que el puerto al que nos hemos intentado conectar se encuentra abierto. Después de que el cliente envía el ACK de confirmación, se completa el Three-way TCP/IP handshake y la conexión es terminada por el cliente, volviendo a realizar el mismo proceso para el resto de los puertos que deseemos escanear.
En la figura dos podemos apreciar lo que sucedería si el puerto del servidor se encontrara cerrado.
Figura N°2 Full TCP Connection: Puerto Cerrado
Aquí, el servidor devuelve un RST/ACK. El servidor informa al cliente que debe terminar la conexión debido a que el puerto se encuentra cerrado. Ésta técnica es muy fácil de identificar, ya que al realizar una conexión completa, los logs del sistema y un IDS lo detectarían. Una vez detectado, un cortafuegos bloquearía el resto de las peticiones.
Half Open Scan Method
Éste método se llama Half open porque el cliente termina la conexión antes de que se haya completado el proceso de intercambio Three-way TCP/IP Handshake, por lo que pasará inadvertido a los IDS basados en conexión, aunque es muy probable que devuelva falsos positivos.
Figura N°3 Half Open Scan Method
SYN Scanning
Ésta técnica es exactamente igual al Full TCP conection, excepto que en el último paso el envío del ACK por parte de la máquina cliente no se lleva a cabo y en su lugar, el cliente termina la conexión mediante el envío de un RST. En realidad, es el sistema operativo quien se toma la tarea de enviar el RST. En la figura tres se esquematiza este tipo de escaneo.
Si en respuesta a nuestro SYN el servidor envía un SYN/ACK, nos está informando que el puerto está abierto. Si lo que envía es un RST/ACK, significa que el puerto está cerrado. Ésta técnica es muy fácil de identificar por un IDS, ya sea el Snort, TCPWrappers o IPLog. El hecho de que éste método haya sido utilizado para generar DoS (denial of service – Denegación de servicios que veremos más adelante en este documento) SYN Flood es un inconveniente ya que provocó que muchos cortafuegos tengan reglas específicas para prevenir este tipo de escaneos. Mediante ésta técnica podemos realizar rápidos escaneos que puedan pasar inadvertidos a los IDS débiles, pero la desventaja es que debe ser ejecutado con privilegios de administrador.
Stealth Scanning
Ésta técnica se denominó así debido a que permitía evitar los sistemas de detección y logeo de los IDS. Hoy día, este tipo de escaneo tiene que ver con algunas de las técnicas siguientes: uso de determinados flags, técnicas de sobrepasar filtros, cortafuegos, routers, casual network traffic, etc.
SYN/ACK Scanning
Ésta técnica tiene la característica de eliminar la primera parte del Three-way TCP/IP Handshake. Se envía el SYN/ACK y en función de la respuesta podremos saber el estado en que se encuentra el puerto. El servidor termina la conexión pensando que se ha producido algún tipo de fallo en las transacciones con este puerto, en el que no se ha producido un SYN previo.
En el caso de que el puerto se encontrase abierto, no recibiríamos ninguna respuesta por parte del servidor. Hay que saber leer con detenimiento este resultado, porque los falsos positivos en este tipo de escaneo son muy probables. La ausencia de respuesta puede deberse a algún tipo de filtrado, por ejemplo, de un cortafuegos de tipo stateless.
FIN Scanning
Desafortunadamente esta técnica se aprovecha de una mala implementación del código de los BSD, que han usado muchos sistemas operativos para construir su pila TCP/IP. En teoría, cuando se envía un paquete con el flag FIN activo, un puerto cerrado responderá con un RST, mientras que los puertos abiertos se quedarán “callados” (RFC 793, pp64). Véase la figura 4.
Figura N°4 FIN Scanning
En éste caso hay que mencionar que los sistemas de Microsoft han decidido ignorar completamente los estándares e implementar lo que a ellos les ha parecido mejor. De modo que ésta técnica, junto con XMAS scanning y Null scanning no son válidas para sistemas ejecutando Win95/NT.
Por otra parte podemos aprovechar esta característica para identificar si el sistema se trata de un Windows. Si mediante ésta técnica encontramos puertos abiertos, sabremos que no se trata de un sistema Windows, pero si no encontramos ningún puerto abierto y por medio de un SYN scanning sí encontramos puertos abiertos, entonces sabremos que se trata de un sistema Windows. Existen otros sistemas que responden con un RST cuando el puerto está abierto, en vez de desechar el paquete (que es lo que el estándar dispone que debe hacerse). Algunos de estos sistemas son Cisco, Solaris, BSDI, MVS e IRIX.
Ésta técnica también nos devuelve falsos positivos por lo que debemos interpretar los resultados.
Cualquier sistema de filtrado puede estar bloqueando los RST de los puertos cerrados. Como resultado obtendríamos un escaneo erróneo y deberemos aplicar otras técnicas o bien, comparar los resultados obtenidos mediante esta técnica con los que obtenemos con otras diferentes como los escaneos SYN o SYN/ACK.
ACK Scanning
Éste método, utilizando el programa Nmap con la opción -sA, se usa generalmente para poder averiguar las reglas de filtrado de los cortafuegos. Concretamente nos permite indagar si el cortafuegos es stateful o sencillamente un sistema de filtrado simple que bloquea los paquetes SYN entrantes.
En ésta técnica enviamos un paquete ACK con un ID de secuencia aleatoria al puerto especificado. Cuando recibimos paquetes con flags RST activados los puertos son clasificados como “no filtrados”, mientras que si no recibimos ninguna respuesta o se nos envía un ICMP Unreachable, se clasificarán los puertos como “filtrados”. Una característica del Nmap y de este tipo de filtrado reside en que los puertos que deberían aparecer como “no filtrados” no aparecen. Sólo obtendremos aquellos puertos que que hemos detectado como “filtrados”. Otra técnica empleando el envío de ACK fue descrita utilizando un bug30 (error en software o hardware) que existía en la capa IP de los sistemas operativos. Mediante el envío de ACK, teníamos dos técnicas para detectar el estado de los puertos atacados. El primer método implica evaluar el campo TTL (Time To Live) del paquete, mientras que en el segundo debemos analizar el campo WINDOW de éste. En ambos es imperativo analizar los paquetes que recibamos con el flag RST activado.
En el primer caso, un análisis de la cabecera IP de los paquetes, para determinados sistemas operativos, nos descubre que el valor de TTL de los paquetes que nos retorna un puerto abierto es menor que el del TTL que se obtiene como respuesta de puertos cerrados.
Esto se explica mejor con el ejemplo siguiente: esto es en backtrack
Packet 1: host XXX.XXX.XXX.XXX port 20:1RST -> ttl: 70 win:0 => closed
Packet 2: host XXX.XXX.XXX.XXX port 21:1RST -> ttl: 70 win:0 => closed
Packet 3: host XXX.XXX.XXX.XXX port 22:1RST -> ttl: 40 win:0 => open
Packet 4: host XXX.XXX.XXX.XXX port 23:1RST -> ttl: 70 win:0 => closed
Vemos en el paquete de respuesta del puerto 22, el valor TTL es menor que en los puertos que se hallan cerrados.
Éste es dependiente del sistema operativo de la versión de éste, ya que en versiones recientes este bug ha sido parchado y no puede emplearse como método de detección de puertos abiertos o cerrados.
NULL Scanning
En éste método dejamos inactivos todos los flags del paquete (ACK, FIN, RST, URG, SYN, PSH).
Cuando un paquete de ésta clase llega a un servidor, si el puerto se encuentra cerrado se enerará un RST por parte del servidor. Sin embargo, si el puerto se encuentra abierto, éste desechará el paquete y no responderá de ninguna manera. Esta forma de escaneo queda esquematizado en la figura 5.
Los estándares RFC no marcan ninguna clase de respuesta especifica con respecto de este tipo de paquetes por lo que el escaneo es dependiente del sistema operativo que está siendo escudriñado, como siempre confrontando Window Vs. UNIX.
Figura N°5 NULL Scanning
XMAS Scanning
Ésta técnica es todo lo contrario a la anterior y no tiene nada que ver con la navidad. En éste método activamos todos los flags presentes en la cabecera TCP (ACK, FIN, RST, URG, SYN, PSH). Al igual que en los casos anteriores, ésta técnica es dependiente de que la pila TCP/IP del equipo remoto esté basada en el código BSD, por lo que se limita a sistemas UNIX.
En éste proceso, cuando el servidor recibe un paquete con estas características, si el puerto se encuentra abierto, el kernel desechará el paquete, mientras que responderá con un RST si el puerto se encuentra cerrado. Todo lo demás es igual al NULL scanning con respecto de la respuesta del servidor.
IDLE Scanning
Éste procedimiento fue publicado en Bugtraq hace ya algunos años. Es la técnica más interesante y de gran utilidad. Hay que tener dos cosas en mente: siempre se debe efectuar de manera adecuada y tenemos que conocer la forma de interpretar los resultados que se obtienen. El método nos permite escanear una máquina remota utilizando paquetes “spoofeados” (es decir, con una dirección IP diferente de la nuestra) y una máquina zombie, que una computadora que se emplea como intermediaria para realizar ataques a una computadora víctima sin que ella tenga conciencia del procedimiento.
La idea es que nuestra computadora no pueda ser detectada desde la máquina atacada. En el IDLE scanning se usa una zombie para cuestiones de escaneo en nuestra red local propia. Para llevar a cabo este escaneo se aprovechara uno de los puntos débiles que se han descubierto al TCP/IP: números de secuencia IPID predecibles.
Los aspectos de TCP/IP básicos a tener en cuenta para llevar a cabo éste escaneo son los siguientes:
1. Una máquina responde con un SYN/ACK a un SYN si el puerto se encuentra abierto.
2. Una máquina responde con un RST a un SYN si el puerto se encuentra cerrado.
3. Una máquina responde con un RST a un SYN/ACK.
4. Una máquina no responde con nada a un RST.
5. Podemos conocer el número de paquetes que la máquina remota está enviando mediante el
campo IDIP de la cabecera IP.
Para explicar éste procedimiento, chequemos la figura 6.
Figura N°6 IDLE Scanning : Paso 1
En el paso uno debemos encontrar una máquina que no tenga mucho tráfico y en la que podamos controlar las variaciones de la secuencia IPID. Para ello podemos utilizar la herramienta Hping2 y comprobar la variación de este valor.
Shell-console
hping2 -i u1000 -p 80 -r -S -A zombie
shell-console
HPING zombie (eth0 zombie): S set, 40 headers + 0 data bytes
60 bytes from zombie: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2ms
60 bytes from zombie: flags=RA seq=1 ttl=64 id=+1 win=0 time=75ms
60 bytes from zombie: flags=RA seq=2 ttl=64 id=+1 win=0 time=91ms
60 bytes from zombie: flags=RA seq=3 ttl=64 id=+1 win=0 time=90ms
60 bytes from zombie: flags=RA seq=4 ttl=64 id=+1 win=0 time=91ms
60 bytes from zombie: flags=RA seq=5 ttl=64 id=+1 win=0 time=87ms
Con la opción -r obtenemos el valor relativo del campo id, es decir, la diferencia entre el id anterior y el nuevo id. Mediante esta variación podemos conocer si la máquina está enviando mucho o poco tráfico. Éste será el valor que nosotros utilizaremos para realizar el escaneo.
En el siguiente paso, una vez conocido el id de la respuesta al SYN que hemos enviado, será enviar un SYN a la máquina destino, pero con la IP spoofeada a la máquina zombie. Tecleamos:
Shell-console
hping2 -i -u1000 -p 22 -S -a zombie www.xxx.yyy.zzz
Figura N°6 IDLE Scanning : Paso 2
Enviamos a la máquina destino paquetes SYN diciendo que somos la máquina zombie. Si el puerto estuviese abierto en la máquina destino, ésta respondería al zombie con un SYN/ACK. El zombie, al recibir un SYN/ACK que no se corresponde con un SYN previo, envía un RST. De ésta forma, al enviar paquetes el zombie, el número de secuencia aumenta. Si el puerto estuviese cerrado, la máquina destino enviaría un RST al zombie. Al tratarse de un RST, la máquina no responde de ninguna forma y desecha el paquete.
En el paso 3, y último, se comprueba si el id de la máquina zombie se ha modificado o no. Como cualquier máquina genera suficiente tráfico como para que éste valor varíe frecuentemente, en vez mde tener en cuenta si el valor id ha variado en una o dos unidades, como se representa en la figura 6 paso 1 y 2, lo que haremos es lanzar dos procesos: uno que envía SYN/ACK a la máquina zombie (para controlar la variación del campo id) y otro que enviará los SYN spoofeados a la máquina destino. De esta forma podremos comprobar en tiempo real si al lanzar el segundo proceso (paquetes spoofeados, el valor del id devuelto por la máquina zombie varía o permanece dentro de unos límites).
Figura N°6 IDLE Scanning : Paso 3
Una buena opción para asegurarnos de que esta variación es consecuencia de nuestro envío de paquetes, es enviar una gran cantidad de paquetes, de esta manera, si vemos el valor del id presentará saltos en la misma proporción que el número de paquetes enviado por segundo. Para hacer pruebas es sugerible que se lancen los siguientes procesos en dos terminales diferentes. Debemos adecuar los puertos según la intención del escaneo:
Terminal 1
Shell-console
hping2 -i -u10 -p 80 -r -S -A zombie
www.xxx.yyy.zzz
Terminal 2
Shell-console
hping2 -i -u10 -p 22 -S -A zombie
Con el parámetro -i controlamos el tiempo de espera entre el envío de cada paquete. En este caso, enviamos un paquete cada 10 microsegundos. Como el tráfico generado va a ser muy abundante, si el puerto 22 de la máquina www.xxx.yyy.zzz se encuentra abierto, enviará el mismo número de paquetes SYN/ACK a la máquina zombie, que responderá con el mismo número de paquetes RST, produciéndose un incremento en el valor del campo id que será fácilmente apreciable.
Fuente: taringa.net
No hay comentarios:
Publicar un comentario