Nmap contra un perímetro cloud: qué merece la pena escanear y qué es ruido

Nmap tiene treinta años y sigue siendo la primera herramienta a la que recurrimos cuando un cliente pregunta qué aspecto tiene su perímetro desde fuera. No porque escanear puertos sea sofisticado, sino porque casi todo entorno cloud tiene algo escuchando que nadie recuerda haber desplegado, y nada lo encuentra más rápido.

Lo difícil no es ejecutar Nmap. Es decidir a qué apuntarlo.

Construye la lista de objetivos desde la nube, no desde el DNS

Un escaneo de la zona DNS del cliente se deja fuera todo lo que nunca tuvo nombre: balanceadores creados para una demo, una instancia con IP pública puesta por el valor por defecto de un módulo de Terraform, una NAT gateway que además acepta tráfico entrante porque un grupo de seguridad lo permite.

Construye la lista desde la propia API del proveedor. En AWS eso significa las IP públicas de instancias EC2, ELB, NAT gateways, Global Accelerator e instancias RDS con PubliclyAccessible activo, en todas las cuentas de la organización y en todas las regiones habilitadas. Las regiones importan: la instancia que alguien levantó en ap-southeast-2 durante una prueba de concepto es justo la que nadie ha parcheado.

aws ec2 describe-network-interfaces \
  --query 'NetworkInterfaces[?Association.PublicIp].Association.PublicIp' \
  --output text | tr '\t' '\n' > objetivos.txt

Hazlo por cuenta y por región, y añade encima la zona DNS. La diferencia entre las dos listas suele ser la página más interesante del informe: activos que existen pero no están en el inventario de nadie.

El escaneo que compensa

Un escaneo TCP completo de todos los puertos en todos los hosts es un día entero para encontrar tres servicios. En la práctica funcionan mejor dos pasadas.

La primera, amplia y superficial, para ver qué está vivo:

nmap -sS -Pn --top-ports 1000 --open -T4 -iL objetivos.txt -oA pasada1

-Pn porque los hosts cloud descartan ICMP con frecuencia y si no te saltarás objetivos vivos. --open porque a estas alturas los resultados cerrados y filtrados son ruido. -T4 va bien contra infraestructura cloud; -T5 empieza a perder resultados.

La segunda, estrecha y profunda, solo contra los hosts que respondieron:

nmap -sS -sV -sC -p- --open -T4 -iL vivos.txt -oA pasada2

Aquí sí, rango completo de puertos, con detección de versión y el conjunto de scripts por defecto. De aquí salen los hallazgos: el Elasticsearch en el 9200 sin autenticación, el Redis en el 6379 respondiendo PING, la interfaz de administración en el 8443 con un certificado autofirmado de 2019.

Leer la salida sin ahogarse

Merece la pena separar tres categorías en el informe, porque cada una se corrige de forma distinta.

Servicios que no deberían ser accesibles desde internet en absoluto. Bases de datos, cachés, colas de mensajes, servidores de API de Kubernetes, registros de contenedores, cualquier cosa en un puerto por encima del 1024 que responda a un saludo de protocolo. La corrección es un cambio de grupo de seguridad y, normalmente, una pregunta sobre cómo llegó ahí.

Servicios que sí deben ser accesibles pero exponen de más. Versiones antiguas de TLS, banners con la versión exacta del software, rutas de administración por defecto. --script ssl-enum-ciphers en el 443 te da el conjunto de hallazgos de TLS en una pasada, y encaja directamente con los controles de casi todos los marcos de cumplimiento.

Servicios que respondieron pero no deberían existir. Entornos de prueba con IP pública, la copia de staging de la API con credenciales de producción en su entorno, el bastión olvidado. Suelen ser los hallazgos de mayor impacto y nunca aparecen en un diagrama de arquitectura.

Lo que Nmap no te va a decir

No te va a decir si la exposición importa. Un 22 abierto en un bastión detrás de un proxy con identidad y un 22 abierto en una instancia con autenticación por contraseña son la misma línea de salida. La severidad viene de lo que hay detrás del puerto, y eso requiere la revisión de configuración, no el escaneo.

No va a encontrar las exposiciones que no son puertos. Almacenamiento de objetos público, una política de URL prefirmadas demasiado laxa, una Lambda con URL de función y AuthType: NONE: nada de eso aparece en un escaneo de puertos. Ejecuta el utillaje de postura en paralelo; los dos conjuntos apenas se solapan.

Y no va a sobrevivir en silencio a las protecciones del propio proveedor. Tanto AWS como Google Cloud aceptan que escanees tus propios activos sin autorización previa, pero la limitación de tasa, Shield y cualquier WAF delante de un ALB van a distorsionar los resultados. Si un host aparece uniformemente filtrado, comprueba si estás escaneando el host o la protección que tiene delante.

Autorización, por escrito

Escanea solo espacio de direcciones que el cliente posea o sobre el que tenga potestad contractual. Las IP cloud se reciclan: una IP elástica liberada la semana pasada es hoy de otro, y escanearla es escanear la infraestructura de un desconocido. Vuelve a resolver la lista de objetivos al principio de cada trabajo en lugar de reutilizar el fichero del trimestre pasado, y guarda la carta de autorización con el alcance junto a los registros del escaneo.

Esa disciplina es además lo que hace útil la salida seis meses después, cuando alguien pregunta si cierto host estaba expuesto entonces. La salida de -oA, la lista de objetivos y la fecha son la evidencia.

Si lo que quieres es el perímetro mapeado y priorizado, y no solo escaneado, eso es lo que hace nuestra revisión de seguridad.