Nmap -sV: qué hay detrás de un puerto abierto

Otra cosa que me quedó clara documentándome sobre Nmap antes de usarlo de verdad: saber que un puerto está abierto es solo el primer paso, no la respuesta. El puerto 80 abierto no te dice si detrás hay Apache, Nginx, o un servidor casero programado a mano — y esa diferencia es la que de verdad importa para cualquier análisis de seguridad serio.

Lo que un escaneo normal sí te dice, y lo que no

Un escaneo de puertos básico de Nmap (como el -sS o -sT que vimos en el artículo anterior) responde a una pregunta muy concreta: ¿está el puerto abierto, cerrado, o filtrado? Eso es todo. Te da algo así:

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
22/tcp   open  ssh

Fíjate en la columna “SERVICE”: Nmap adivina qué servicio suele correr en ese puerto basándose en una lista de puertos habituales (el 80 suele ser HTTP, el 22 suele ser SSH), no porque lo haya comprobado de verdad. Es una suposición razonable basada en convención, no una confirmación.

Por qué esa suposición no es suficiente

El problema es que cualquier servicio puede correr en cualquier puerto. Nada obliga a que el puerto 80 tenga un servidor web — un administrador (o un atacante que quiere pasar desapercibido) puede poner deliberadamente un servicio SSH en el puerto 80 para intentar despistar un escaneo superficial, o viceversa. Además, incluso cuando sí es el servicio “esperado”, hay una pregunta todavía más importante sin responder: ¿qué versión exacta es?

Esto no es un detalle menor. Un Apache 2.4.49 tiene vulnerabilidades conocidas y documentadas que un Apache 2.4.54 ya tiene parcheadas. Saber “hay un servidor web” no te dice nada útil; saber “hay Apache httpd 2.4.49” sí, porque a partir de ahí se puede buscar si esa versión concreta tiene fallos de seguridad conocidos.

Cómo funciona la detección de versión con -sV

La opción -sV le dice a Nmap que vaya un paso más allá de la suposición por número de puerto: manda sondas activas al servicio y analiza cómo responde. En vez de asumir, pregunta.

$ nmap -sV 192.168.1.10

PORT     STATE SERVICE VERSION
80/tcp   open  http    Apache httpd 2.4.52 ((Ubuntu))
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu

Por debajo, Nmap tiene una base de datos enorme (el archivo nmap-service-probes) con patrones conocidos de cómo responden distintos servicios y versiones ante determinadas peticiones. Manda esas peticiones de prueba, compara la respuesta con su base de datos de firmas, y si encuentra una coincidencia, te dice exactamente qué software y qué versión hay detrás — de la misma forma que el comando file identifica un archivo por su contenido en vez de por su nombre, aquí Nmap identifica un servicio por cómo se comporta, no por el número de puerto en el que vive.

El coste de preguntar en vez de asumir

Esta precisión no es gratis: -sV tarda más que un escaneo de puertos normal, porque para cada puerto abierto tiene que mandar sondas adicionales y esperar respuesta, en vez de simplemente marcar “abierto” y pasar al siguiente. En un escaneo de una sola máquina no se nota demasiado; en un escaneo de un rango grande de direcciones IP, la diferencia de tiempo puede ser considerable.

Qué pasa cuando Nmap no consigue identificar el servicio del todo

No siempre hay una coincidencia perfecta en la base de datos de firmas. A veces la salida incluye algo como esto:

8080/tcp open  http-proxy?

El signo de interrogación es la forma que tiene Nmap de decir “esto se parece a un proxy HTTP, pero no tengo suficiente confianza para afirmarlo del todo”. En esos casos, Nmap suele sugerir que envíes la huella (fingerprint) capturada a su propio proyecto, para ayudar a ampliar la base de datos de firmas con la que trabaja — literalmente se mantiene y mejora con las respuestas que la comunidad va reportando de servicios que todavía no reconocía bien. Subir manualmente la intensidad con --version-intensity 9 en estos casos concretos es precisamente lo que se recomienda antes de darse por vencido, porque fuerza a Nmap a probar también las sondas menos comunes que por defecto se salta.

Controlando cuánto insiste: --version-intensity

Nmap no manda todas las sondas posibles por defecto — las tiene organizadas por rareza, de las más comunes (que prueba siempre) a las más raras (que solo prueba si se lo pides explícitamente). Esto se controla con --version-intensity, en una escala de 0 a 9:

nmap -sV --version-intensity 9 192.168.1.10

Subir la intensidad tiene sentido cuando el escaneo por defecto no ha identificado un servicio y quieres insistir más para intentar sacarle la versión exacta a algo poco convencional; para la mayoría de casos, el valor por defecto ya es un buen punto de partida.

Pon a prueba lo que has entendido

Resumen rápido

Un escaneo de puertos normal solo supone el servicio por el número de puerto, siguiendo convención, no confirmación real. -sV manda sondas activas y compara las respuestas contra una base de datos de firmas conocidas para identificar el software y la versión exacta, a costa de un escaneo más lento. --version-intensity controla cuánto insiste Nmap en identificar servicios poco habituales. Saber la versión exacta es lo que permite pasar de “hay algo ahí” a “esa versión concreta tiene vulnerabilidades conocidas” — el paso que separa un escaneo superficial de un análisis útil de verdad. Si todavía no tienes claro cómo se hace el escaneo de puertos que precede a todo esto, lo ves en Nmap -sS vs -sT: por qué un escaneo necesita privilegios de root y el otro no.