9. Escaneo de puertos, detección de servicios y fingerprinting

9.1 Introducción

Una vez descubiertos los hosts activos, el siguiente paso es determinar qué puertos están abiertos y qué servicios escuchan en ellos. Esta información define el camino de enumeración: no se analiza igual un servidor web, un servicio SSH, un recurso SMB, una base de datos o un portal VPN.

El escaneo de puertos debe ejecutarse dentro del alcance autorizado y con intensidad adecuada. Un escaneo mal configurado puede generar ruido, alertas, bloqueos, falsos resultados o impacto operativo.

En este tema veremos estados de puertos, diferencias entre TCP y UDP, detección de versiones, fingerprinting, banners, interpretación de filtrado y documentación de resultados.

9.2 Qué es un puerto abierto

Un puerto abierto indica que un proceso está escuchando conexiones o paquetes en una dirección IP y protocolo determinados. No significa automáticamente que exista una vulnerabilidad, pero sí que hay una superficie que puede estudiarse.

Un puerto puede representar:

• Un servicio de administración, como SSH, RDP o WinRM.
• Una aplicación web, API o panel.
• Un servicio de red, como DNS, SMB, LDAP o SMTP.
• Una base de datos.
• Un proxy, balanceador, WAF o intermediario.
• Un servicio interno publicado por error.

9.3 Estados de puertos

Las herramientas de escaneo suelen clasificar puertos según la respuesta recibida. Interpretar esos estados evita conclusiones equivocadas.

9.4 Escaneo TCP

TCP permite observar respuestas más claras que UDP porque usa establecimiento de conexión. En pentesting, los escaneos TCP suelen ser el punto de partida para identificar servicios expuestos.

Conceptos importantes:

• SYN: inicio de conexión TCP.
• SYN/ACK: respuesta típica de puerto abierto.
• RST: rechazo o cierre, frecuente en puertos cerrados.
• Timeout: posible filtrado, pérdida o falta de respuesta.

El escaneo TCP puede variar en velocidad y precisión. En producción, conviene priorizar estabilidad y claridad sobre rapidez agresiva.

9.5 Escaneo UDP

UDP no establece conexión como TCP, por eso es más difícil de interpretar. Algunos servicios responden solo si reciben una solicitud válida; otros permanecen silenciosos.

Servicios UDP comunes:

• DNS en 53/UDP.
• SNMP en 161/UDP.
• NTP en 123/UDP.
• DHCP en 67/68/UDP.
• VoIP y SIP en distintos puertos.
• Protocolos de descubrimiento o administración en redes internas.

9.6 Selección de puertos

No siempre conviene escanear todos los puertos con la misma intensidad. La estrategia depende del tiempo, el alcance, la criticidad del entorno y el objetivo de la prueba.

9.7 Timing, velocidad y estabilidad

El timing controla la velocidad y paralelismo del escaneo. Una velocidad excesiva puede generar pérdida de paquetes, bloqueos, alertas o resultados incompletos. Una velocidad demasiado baja puede consumir demasiado tiempo.

• Comenzar con perfiles moderados.
• Reducir intensidad en redes sensibles o sistemas legados.
• Aumentar cobertura solo dentro de ventanas autorizadas.
• Registrar si hubo timeouts, bloqueos o rate limiting.
• No confundir rapidez con calidad de resultados.

9.8 Detección de servicios

Detectar un puerto abierto es solo el primer paso. Hay que identificar qué servicio responde realmente. Un puerto 443 no siempre es una aplicación web común, y un servicio puede ejecutarse en un puerto no estándar.

La detección de servicios puede usar:

• Banners enviados al conectar.
• Respuestas a probes específicas.
• Protocolos esperados para cada puerto.
• Cabeceras y códigos de estado.
• Certificados TLS.
• Mensajes de error o negociación inicial.

9.9 Banners y versiones

Un banner es información que un servicio entrega sobre sí mismo. Puede incluir nombre, versión, sistema operativo, módulo o configuración. Es útil, pero no siempre confiable.

9.10 Fingerprinting

Fingerprinting es el proceso de identificar tecnologías, sistemas o servicios por su comportamiento. No depende solo de banners; también analiza respuestas, tiempos, errores, opciones soportadas, cabeceras y detalles de protocolo.

Tipos comunes:

• Fingerprinting de servicio: identificar protocolo y versión aproximada.
• Fingerprinting de sistema operativo: inferir plataforma por comportamiento de red.
• Fingerprinting web: detectar frameworks, CMS, servidores, librerías y WAF.
• Fingerprinting TLS: analizar certificados, protocolos y suites soportadas.

9.11 Fingerprinting de sistema operativo

Algunas herramientas intentan inferir el sistema operativo observando detalles de red: TTL, tamaño de ventana, opciones TCP, respuestas a paquetes específicos y comportamiento ante puertos abiertos o cerrados.

La detección puede fallar por:

• Firewalls que modifican respuestas.
• Balanceadores o proxies intermedios.
• Sistemas endurecidos.
• Virtualización o contenedores.
• Rutas asimétricas o pérdida de paquetes.

Por eso conviene tratar el resultado como estimación, no como certeza absoluta.

9.12 Fingerprinting web

En servicios web, el fingerprinting puede revelar servidor, framework, lenguaje, CMS, librerías, WAF, CDN y tecnologías de frontend. Estas señales ayudan a planificar enumeración y pruebas específicas.

• Cabeceras HTTP como Server, X-Powered-By o Set-Cookie.
• Rutas comunes de frameworks o CMS.
• Archivos estáticos y nombres de bundles.
• Cookies con nombres característicos.
• Errores que revelan stack tecnológico.
• Certificados y dominios alternativos.

Ocultar cabeceras ayuda, pero no elimina todas las señales. El comportamiento de la aplicación también revela información.

9.13 TLS y servicios cifrados

Cuando un servicio usa TLS, el escaneo debe considerar certificado, nombres alternativos, versiones de protocolo, suites de cifrado y configuración. Además, el certificado puede revelar dominios relacionados.

• Nombre común y SAN del certificado.
• Fecha de emisión y expiración.
• Autoridad certificadora.
• Protocolos TLS soportados.
• Cifrados débiles o versiones obsoletas.
• Coincidencia entre nombre consultado y certificado presentado.

9.14 Servicios en puertos no estándar

No todos los servicios usan su puerto habitual. Una aplicación web puede estar en 8080, 8443 o 8000; SSH puede estar en otro puerto; una base de datos puede exponerse en un puerto cambiado.

Por eso es importante detectar el servicio real y no asumirlo solo por número de puerto.

• Probar identificación de servicio en puertos abiertos.
• Observar respuestas iniciales.
• Comparar con protocolos esperados.
• Registrar puertos no estándar porque suelen indicar aplicaciones internas o configuraciones especiales.

9.15 Intermediarios: WAF, CDN, proxies y balanceadores

Durante el escaneo, puede que no estés interactuando con el servidor final sino con una capa intermedia. Esto afecta resultados, fingerprinting y conclusiones.

9.16 Priorización de servicios

Después de detectar servicios, hay que decidir qué enumerar primero. La prioridad depende de exposición, criticidad, tipo de servicio, autenticación y relación con el negocio.

• Servicios administrativos expuestos a internet.
• Aplicaciones web con login o datos sensibles.
• APIs públicas o móviles.
• Servicios con versiones antiguas o banners inusuales.
• Bases de datos accesibles desde redes no esperadas.
• SMB, LDAP, RDP, WinRM o VPN en entornos corporativos.
• Servicios de staging, dev o test expuestos públicamente.

9.17 Escaneo autenticado y no autenticado

Algunas evaluaciones permiten usar credenciales. Esto cambia el tipo de información disponible. Un escaneo no autenticado muestra lo que ve un actor externo; uno autenticado puede revelar servicios internos, versiones exactas o configuraciones.

• No autenticado: útil para superficie externa y exposición inicial.
• Autenticado: útil para cobertura interna, revisión de configuración y validación con menos inferencias.
• Con roles distintos: permite comparar exposición según permisos.

El uso de credenciales debe estar documentado y limitado a cuentas de prueba o cuentas autorizadas para la evaluación.

9.18 Interpretación de filtrado

El filtrado puede provenir de firewalls, ACL, WAF, IPS, reglas cloud, políticas locales o listas de bloqueo. Interpretarlo correctamente evita conclusiones falsas.

• Timeouts repetidos pueden indicar descarte silencioso.
• Respuestas RST pueden indicar puertos cerrados o reglas activas.
• Bloqueos después de varias solicitudes pueden indicar rate limiting o IPS.
• Diferencias entre redes de origen pueden indicar listas de permisos.
• Resultados distintos por horario pueden indicar reglas dinámicas o cambios operativos.

9.19 Evitar impacto operativo

Los escaneos pueden afectar sistemas frágiles si se ejecutan con alta intensidad o con probes inadecuadas. Esto es especialmente importante en sistemas legados, dispositivos embebidos, equipos de red, impresoras, cámaras, sistemas industriales o aplicaciones críticas.

Buenas prácticas:

• Comenzar con intensidad baja.
• Separar sistemas sensibles del resto.
• Evitar scripts intrusivos si no fueron aprobados.
• Coordinar ventanas para servicios críticos.
• Monitorear si aparecen errores o degradación.
• Pausar si se detecta comportamiento inesperado.

9.20 Documentación de resultados

El resultado del escaneo debe quedar documentado de forma ordenada. Esto permite reproducir hallazgos y preparar la enumeración posterior.

9.21 Validación manual

Las herramientas pueden equivocarse. La validación manual ayuda a confirmar servicios importantes antes de pasar a análisis de vulnerabilidades.

• Conectarse al servicio con clientes adecuados.
• Revisar cabeceras y respuestas directamente.
• Confirmar si el servicio requiere TLS o SNI.
• Comparar resultados desde distintas herramientas si hay dudas.
• Repetir pruebas con baja intensidad ante resultados inconsistentes.
• Registrar cualquier diferencia entre detección automática y observación manual.

9.22 De escaneo a enumeración

El escaneo indica qué mirar. La enumeración profundiza en cada servicio. Por ejemplo, encontrar 445/TCP abierto conduce a enumeración SMB; encontrar 443/TCP conduce a revisión web; encontrar 53/UDP conduce a pruebas DNS autorizadas.

9.23 Errores frecuentes

• Escanear todos los puertos a máxima velocidad sin considerar impacto.
• Ignorar UDP por ser más lento.
• Reportar una versión detectada como vulnerable sin validar parches o contexto.
• Asumir que el número de puerto identifica el servicio real.
• No documentar si el resultado tiene baja confianza.
• Confundir un intermediario con el servidor final.
• No repetir resultados inconsistentes.
• Usar scripts intrusivos sin autorización explícita.

9.24 Flujo práctico de escaneo

Un flujo ordenado para esta fase puede ser:

1. Partir de hosts confirmados en el reconocimiento activo.
2. Ejecutar escaneo inicial de baja o moderada intensidad.
3. Identificar puertos TCP abiertos, cerrados y filtrados.
4. Revisar UDP selectivo según contexto.
5. Detectar servicios y versiones con probes controladas.
6. Validar manualmente servicios críticos o ambiguos.
7. Identificar intermediarios como WAF, CDN o balanceadores.
8. Documentar confianza, observaciones y limitaciones.
9. Priorizar servicios para enumeración detallada.

9.25 Qué debes recordar de este tema

• El escaneo de puertos identifica superficie de servicio, no vulnerabilidades por sí solo.
• TCP y UDP requieren interpretación distinta.
• Los estados filtrados son señales de control, no ausencia de servicios.
• La detección de versiones debe validarse antes de concluir riesgo.
• Fingerprinting produce hipótesis que deben documentarse con nivel de confianza.
• La intensidad del escaneo debe adaptarse al alcance, la ventana y la sensibilidad del entorno.

9.26 Conclusión

El escaneo de puertos y la detección de servicios permiten entender qué superficie técnica ofrece cada host. Cuando se ejecutan con criterio, producen una base confiable para la enumeración profunda y el análisis de vulnerabilidades.

En el próximo tema avanzaremos sobre enumeración de servicios específicos como DNS, SMB, FTP, SSH, SMTP, HTTP y bases de datos, donde cada protocolo requerirá preguntas y técnicas propias.