NMAP (-sn) NO PORT SCAN
Nmap cuenta con una gran cantidad de opciones para realizar diferentes tipos de escaneo. Sin embargo, esto provoca que resulte complicado para las personas que comienzan a utilizar la herramienta. Así que resulta conveniente conocer cuáles son los comandos comunes y los que son más útiles en un ambiente de seguridad. A continuación, examinemos uno de los comandos básicos que permitirán trabajar de manera eficiente con el programa.
NO PORT SCAN (OPCIÓN -sn)
Uno de los comandos básico de Nmap es la opción “no port scan”. Este comando permitirá conocer cuáles son los dispositivos que se encuentran activos en una determinada subred. Para esto, bastará con colocar:
nmap -sn [subred]En este caso, se utiliza un rango de red del que se desea conocer cuáles son los dispositivos activos. Por ejemplo, en la siguiente imagen se muestra la aplicación del comando sobre una subred:
Este escaneo nos presenta los siguientes resultados:
Gracias a este comando es posible conocer cuáles son los dispositivos activos, o al menos, aquellos que están configurados para responder a las pruebas realizadas por el programa. Por lo tanto, el comando resulta de utilidad para mapear una subred.
En este punto se invita a probar el comando en una subred para conocer los resultados obtenidos. El programa funcionará de la manera esperada mostrando todos aquellos dispositivos conectados configurados para responder. Sin embargo, existen algunas consideraciones muy importantes a tener en cuenta al utilizar este comando.
CONSIDERACIONES IMPORTANTES SOBRE EL COMANDO –sn
Resulta importante señalar que el comando No port scan “–sn” se comporta de manera diferente dependiendo de dos condiciones:
- Si el sistema desde el que se ha emitido es parte de la subred o si se encuentra escaneando desde una red externa.
- Si el comando se emite con privilegios de super usuario o sin estos.
La siguiente tabla muestra el tipo de comportamiento esperado según las condiciones señaladas:
| Comando | Privilegios | Ubicación Nmap | Paquetes enviados | A notar | Resultado para descubrir host activos |
|---|---|---|---|---|---|
| nmap -sn [subred] | Sin privilegios | En la misma subred | Intento de conexión en puertos 80 y 443. | No se utilizan paquetes ICMP | Menos preciso |
| sudo nmap –sn [subred] | Con privilegios | En la misma subred | Solo se utilizan ARP request | No se utilizan paquetes ICMP | Más Preciso |
| nmap -sn [subred] | Sin privilegios | Red Externa | Intento de conexión en puertos vía SYN a 80 y 443 | Cuando se utiliza el comando sin privilegios no se envían paquetes ICMP | Menos preciso |
| sudo nmap -sn [subred] | Con privilegios | Red Externa | Envío de mensajes ICMP request, intento de conexión SYN a 443, paquete TCP ACK a puerto 80 y envío de paquetes ICMP Time Stamp request | Se utiliza ICMP ping, pero, además, otro tipo de mensajes de pruebas | Más preciso |
A continuación, exploraremos cada uno de estos casos.
-SN SIN PRIVILEGIOS DESDE LA MISMA SUBRED
Cuando se utiliza el comando dentro de la misma subred, y sin privilegios, el programa envía paquetes de conexión para los servicios en puertos 80 y 443. Vamos a comprobar este comportamiento obteniendo la captura de los paquetes en Wireshark que han sido enviados a una máquina Metasploitable2 que se encuentra en la subred con IP 10.38.1.112.
Efectivamente, el programa ha intentado establecer conexión con los puertos 80 y 443. Al encontrarse con el puerto 80 abierto ha realizado la conexión completa.
Esto es muy importante porque en muchos documentos se presenta la opción –sn como un escaneo de ping, sin embargo, como se puede observar NO se utilizan paquetes ICMP si los equipos objetivos se encuentran dentro de la subred y el comando se utiliza sin privilegios.
Más importante aún es el hecho de que con esta configuración, no se están obteniendo resultados precisos, pues en la misma subred estoy ejecutando tres máquinas virtuales:
Pero en el reporte de Nmap solo aparecen dos:
Esto puede servir para considerar que no se están obteniendo los datos verdaderos en una auditoría interna.
¿Pero por qué Nmap no es capaz de registrar la tercera máquina?
Porque, en este caso particular, la máquina Ubuntu no cuenta con el servicio del puerto 80 abierto, por lo tanto, no aparecerá como resultado en el reporte de la prueba. Esto es importante a la hora en la que se está determinando qué dispositivos se encuentran activos en la red. Es decir, si se utiliza el comando sin privilegios dentro de una subred, NO se obtendrán las respuestas de aquellos que no presenten el servicio en puerto 80 o 443. Esto puede provocar errores y dejar de lado algunos equipos en una auditoría interna.
-SN CON PRIVILEGIOS SOBRE LA MISMA SUBRED
Ahora, observaremos lo que sucede cuando se utiliza el mismo comando, pero esta ocasión con sudo:
sudo nmap –sn [subred]
En esta ocasión, se puede observar que el programa solo envía una serie de pruebas ARP. Esto es lógico ya que al usar Nmap con privilegios dentro de una misma red se tiene permiso para enviar paquetes en la capa de enlace (capa 2), por esta razón NO podían ser utilizados cuando empleamos el comando sin privilegios.
¿Pero por qué en este caso Nmap utiliza ARP en lugar de ICMP pings?
ARP es un protocolo de red necesario para el correcto funcionamiento de una red y, por lo tanto, en la mayoría de escenarios NO estará bloqueado. Así, cuando Nmap se ejecuta dentro de la misma red, la respuesta a ARP está prácticamente garantizada.
Por otro lado, también es más eficiente ya que para poder enviar un ICMP ping, primero se necesita utilizar ARP para conocer la dirección física del objetivo. Con esta información el programa logra determinar las máquinas:
Así, ya que en esta ocasión las pruebas no son dependientes de los servicios HTTP y HTTPS, en el reporte aparece ya el tercer equipo correspondiente a la máquina virtual Ubuntu, así como el router virtual del laboratorio. Por lo tanto, resulta más acertado utilizar la opción con privilegios dentro de la subred para conocer los dispositivos que se encuentran disponibles pues los resultados serán más precisos. Aunque esto puede resultar obvio para algunos, conviene conocer el funcionamiento a profundidad del comando para conocer qué tipo de información y paquetes está enviando.
-SN SIN PRIVILEGIOS DIFERENTE RED
Vamos a observar el comportamiento cuando se utiliza el programa para analizar una red externa. Como se ha mencionado, al igual que para una red interna, cuando se utiliza –sn sin privilegios, Nmap envía una serie de paquetes de conexión SYN a los puertos 80 y 443.
En este ejemplo, en el laboratorio se cuenta con una máquina activa en la red externa con la IP 192.168.4.5. En la imagen vemos cómo Nmap envía el intento de conexión al puerto 80 y 443 a cada una de las direcciones de la subred.
Nmap solicita la conexión a la máquina activa, pero la máquina NO responde. Tal y como se puede observar en la siguiente captura con la dirección filtrada de Wireshark:
Por lo tanto, al no recibir respuesta, Nmap sin privilegios no la detecta:
En este caso, solo detecta la dirección activa 192.168.4.1 que corresponde al router. Esta detección se da porque el router ha respondido con [RST ACK] a la solicitud de Nmap. Esta negación de servicio es la que da la pista a Nmap de que hay un dispositivo. Sin embargo, NO pudo determinar que existe otro dispositivo activo en la subred.
-SN CON PRIVILEGIOS DIFERENTE RED
Vamos a utilizar ahora el comando con los privilegios de superusuario. En esta ocasión Nmap sí envía una serie de paquetes pings (ICMP type 8) ya que tiene acceso al envío de paquetes de capa de enlace. Con esto bastaría para la identificación de los host activos (o al menos aquellos que estuvieran configurados para responder al ping). Sin embargo, Nmap va más allá y envía solicitudes SYN al puerto 443, solicitudes ACK al puerto 80 y mensajes ICMP Timestamp request (ICMP type 13) a las direcciones de la subred.
Envío de paquetes ping request:
Envío de solicitudes TCP SYN al puerto y 443:
Envío de mensajes TCP ACK al puerto 80:
Envío de mensajes ICMP Timestamp request:
¿Pero por qué Nmap envía mensajes TCP ACK?
Nmap realiza ambos tipos de pruebas para obtener los mejores resultados en caso de encontrarse con un Firewall en su camino. Es posible que los administradores de un Firewall hayan bloqueado los intentos de conexión SYN, pero no los intentos de conexión ACK que no son un tipo común. Al recibir un paquete ACK un host normalmente respondería con RST y esta respuesta daría pie a Nmap para descubrir que está activo. Sin embargo, hoy en día se cuenta con Firewalls que son capaces de aprender de su contexto (stateful) por lo que pueden identificar y bloquear este tipo de pruebas. Aun así, Nmap hace su mejor esfuerzo para obtener los resultados más precisos posibles.
Otro punto importante a tomar en cuenta para este escaneo con privilegios es que también se agrega mensajes Timestamp request.
¿Qué son las Timestamp request?
Los paquetes ICMP Timestamp request/reply pueden ser utilizados, en caso de que el OS del sistema esté habilitado, para conocer la hora y fecha que el sistema objetivo está utilizando. Sin embargo, lo más común es que no se presente respuesta para estos paquetes ya que la mayoría de sistemas no usan este tipo de mensajes en operaciones normales.
Resultados con este tipo de escaneo
En este caso particular, podemos observar que el sistema objetivo (192.168.4.5) ha contestado al ping con un ECHO reply, razón suficiente para demostrar que está activo. Aquí es importante recordar, una vez más, que solo los dispositivos configurados para dar respuesta a ICMP ping serán los que sean detectados. Este es el caso en nuestra configuración y Nmap lo reporta como activo:
CONCLUSIONES
El comando «no port scan -sn» de Nmap permitirá conocer cuáles sistemas se encuentran activos en una determinada red. Sin embargo, tenemos que tener en consideración que es posible obtener resultados imprecisos si no se utiliza bajo las condiciones adecuadas y que el comando se comporta de diferente manera al utilizarse en una misma red, sin y con privilegios, que cuando se utiliza en una red externa con y sin privilegios.
Por otro lado, en algunos apuntes el comando aparece como un ping sweep (barrido de ping), pero hemos comprobado que existen una serie de condiciones para que se utilicen paquetes ICMP ping como prueba con este comando.
Además, desde una perspectiva de equipo rojo resulta importante conocer que cuando utilizamos este comando estamos enviando más que un simple ping. En diferentes escenarios esto podría provocar la detección del uso de la herramienta para el reconocimiento de una red.
Finalmente, desde la perspectiva de equipo azul, conocer estos paquetes nos ayudará a filtrar y reconocer estos intentos de exploración. Además, es importante notar que, si bien en administración se pueden bloquear las respuestas a ICMP ping, es posible que las herramientas de los atacantes utilicen otros tipos de pruebas para el reconocimiento de equipos activos.
