Ir al contenido

Nmap

Por

Madurezreviewed
Última revisión
Publicado
Última actualización

En septiembre de 1997, la primera versión pública de Nmap cabía en unas dos mil líneas de C y resolvía un problema mucho más estrecho que el actual: explorar redes desde Linux y clasificar puertos sin abrir manualmente una conexión completa con cada uno. El artículo original apareció en Phrack. Las versiones posteriores añadieron sistemas operativos, servicios, nuevas técnicas de escaneo, output estructurado y, más adelante, Nmap Scripting Engine (NSE).

Ese crecimiento puede ocultar la idea que todavía gobierna la herramienta. Nmap envía un probe, observa una respuesta o su ausencia y aplica reglas para clasificar lo ocurrido. El resultado no es una lectura directa del host. Es una inferencia realizada desde una posición de red, con una ruta, unos privilegios, un paquete y un intervalo temporal concretos.

Esta diferencia explica por qué dos escaneos correctos pueden discrepar. Un SYN enviado desde una máquina del mismo segmento puede recibir un RST. El mismo probe, atravesando un firewall, puede no recibir nada y terminar como filtered. Un servicio UDP puede responder solo cuando el payload tiene sentido para su protocolo. Cambiar el origen o la técnica cambia la observación aunque el daemon de destino permanezca igual.

Antes de elegir flags, conviene separar las preguntas que Nmap puede ayudar a responder:

  1. ¿Qué direcciones forman realmente el conjunto de objetivos?
  2. ¿Qué señal indica que una dirección está en uso?
  3. ¿Cómo respondió cada puerto al probe enviado?
  4. ¿Qué protocolo y producto parecen hablar detrás del puerto?
  5. ¿Qué características del stack permiten estimar un sistema operativo?
  6. ¿Qué interacción adicional puede ejecutar NSE?
  7. ¿Cómo se conserva el resultado para compararlo o refutarlo?

Las respuestas forman capas. El descubrimiento de host decide, de manera predeterminada, qué direcciones continúan a la fase de puertos. La clasificación de puertos selecciona dónde intentar detección de versión. La detección de servicio puede activar scripts o dirigir la enumeración manual. Saltar una capa es válido cuando se hace explícitamente, como con -Pn, pero cambia el significado de todo lo que viene después.

Los port states son el vocabulario con el que Nmap expresa esa inferencia. open significa que una aplicación aceptó la interacción utilizada. closed indica que el host respondió, pero no había un servicio escuchando de la forma esperada. filtered conserva la incapacidad de decidir debido a filtrado o pérdida. Estados como open|filtered mantienen deliberadamente dos explicaciones compatibles.

Por eso filtered no es una propiedad permanente del puerto y open tampoco identifica el servicio por sí solo. La información útil está formada por el estado, la técnica, el probe, la respuesta y el lugar desde el que se observó.

Del escáner de puertos al motor de reconocimiento

Sección titulada «Del escáner de puertos al motor de reconocimiento»

La arquitectura actual combina varios conjuntos de conocimiento. nmap-services aporta frecuencias y asociaciones de puertos. nmap-service-probes describe payloads, patrones y reglas para detección de versión. nmap-os-db contiene fingerprints de sistemas operativos. NSE añade un runtime Lua, bibliotecas y scripts que pueden descubrir, autenticar, enumerar o comprobar condiciones específicas.

Estos ficheros no son un detalle de instalación. Dos equipos con Nmap 7.99 pueden utilizar bases distintas si proceden de paquetes diferentes, si una distribución las ha modificado o si NMAPDIR y --datadir apuntan a otro directorio. El motor puede coincidir y los fingerprints no.

NSE amplió además la naturaleza de Nmap. Un escaneo ya no tiene por qué terminar al clasificar un puerto. Un script puede negociar un protocolo, enviar varias peticiones, mantener estado o ejecutar una comprobación intrusiva. Las categorías ayudan a seleccionar scripts, pero no describen por completo su impacto. La unidad que se revisa sigue siendo el script concreto, su portrule, sus argumentos y el código que se ejecutará.

Identificar el motor y la red conocida
nmap --version
nmap --iflist

La primera orden identifica la versión, las capacidades compiladas y las bibliotecas disponibles. La segunda muestra interfaces y rutas según Nmap. Antes de escanear una red remota, esa salida permite detectar que el objetivo saldría por una interfaz inesperada, que la VPN no instaló su ruta o que el origen elegido no existe.

La versión de referencia de este bundle es Nmap 7.99. Cada página explica los flags antes de combinarlos y distingue las operaciones que necesitan raw packets de las que pueden realizarse sin privilegios. Cuando un resultado dependa de bases de datos o scripts, se registrará también su procedencia.

El orden recomendado reproduce las dependencias del modelo:

  1. Objetivos y descubrimiento convierte expresiones de entrada en direcciones y explica ARP, ICMP, TCP, UDP, exclusiones y DNS.
  2. TCP y UDP relaciona paquetes con estados y desarrolla SYN, connect, ACK, UDP y cobertura.
  3. Servicios y sistema operativo explica probes de versión, CPE, fingerprints de stack y validación manual.
  4. NSE, argumentos y tracing abre el motor de scripts, sus categorías, reglas de puerto, argumentos, código y depuración.
  5. Output, XML y comparación conserva evidencia estructurada y permite comparar observaciones sin analizar texto coloreado.
  6. Timing, rutas, filtros y evasión estudia cómo paralelismo, retransmisiones, plantillas -T0 a -T5, límites de frecuencia, rutas y forma del paquete afectan precisión y visibilidad.

El playbook operativo conecta estas piezas cuando ya se entiende cada una. La checklist controla cobertura e incertidumbre. La cheatsheet recupera sintaxis previamente explicada.

Un escaneo rápido puede perder una respuesta porque el timeout expiró antes de que llegara. Un escaneo lento puede atravesar un limitador, pero aumentar el tiempo en el que cambian las condiciones del objetivo. --min-rate fuerza una frecuencia mínima de envío y puede reducir la oportunidad de retransmitir con calma. -T4 modifica un conjunto de temporizadores, no un nivel abstracto de “agresividad”. El rendimiento siempre se evalúa contra pérdida, latencia, estabilidad del servicio y cobertura obtenida.

Cuando un resultado es inesperado, -v hace visible el progreso y los hallazgos durante la ejecución. -d añade información interna para diagnóstico. --reason muestra la causa que Nmap asocia a un estado. --packet-trace permite observar paquetes enviados y recibidos. --traceroute responde una pregunta distinta y estima la ruta después del escaneo. Estas opciones no se añaden por rutina. Se utilizan para localizar la capa en la que el modelo y la observación dejaron de coincidir.

La confirmación final suele abandonar Nmap. Un banner se negocia con el cliente del protocolo. Una respuesta TLS se reproduce con OpenSSL. Una hipótesis de SMB se contrasta con smbclient o rpcclient. Nmap descubre dónde continuar y aporta evidencia sobre la red. Una versión o el nombre de un script no demuestran por sí solos una vulnerabilidad.

Cada ejecución útil conserva:

  • especificación original, objetivos expandidos y exclusiones
  • versión de Nmap, directorio de datos y privilegios efectivos
  • origen, interfaz, ruta y resolvers
  • hora de inicio y fin
  • comando exacto y cambios interactivos durante la ejecución
  • XML, output normal y errores
  • hipótesis que motivó el escaneo
  • observación, incertidumbre y siguiente acción

La validación reproducible de Nmap muestra un caso positivo, uno negativo, XML y diferencias sobre servicios desechables.

El registro permite volver a una discrepancia meses después y responder si cambió el objetivo, la ruta, la técnica o la herramienta. Sin él, dos líneas de output parecidas pueden representar experimentos distintos.