IP & Network

Comprobación de servidor por banner-grab

Escanea qué servicios (HTTP, FTP, SSH, SMTP) están corriendo en un host.

Sobre esta herramienta

Una comprobación de servidor va un paso más allá del escaneo de puertos. Conectamos a una lista fija de puertos de servicios comunes de su host — HTTP, HTTPS, SSH, FTP, SMTP, IMAP, POP3, DNS, MySQL, PostgreSQL, Redis, RDP — y leemos lo primero que dice el demonio. La mayoría de servicios en texto plano anuncian su producto y versión en la primera línea de la conversación; los abiertos devuelven una huella real, los cerrados responden con sinceridad y los bloqueados por cortafuegos agotan el tiempo a los 3 segundos.

Para cada puerto abierto registramos el banner sin procesar, nuestro veredicto sobre el producto (p. ej. nginx/1.25.3, OpenSSH_8.9p1, vsFTPd 3.0.5) y cuánto tardó la conexión. HTTP y HTTPS se sondean con una petición real HEAD / para poder capturar la cabecera Server en lugar de adivinar desde el número de puerto; HTTPS usa TLS sin validar el certificado para que los hosts de desarrollo autofirmados también informen.

Para qué sirve

  • Ver qué está realmente expuesto. Un puerto puede estar open en un escáner, pero la comprobación de servidor le dice exactamente qué demonio escucha — que suele ser la diferencia entre «esperado» y «no autorizado».
  • Detectar versiones obsoletas en segundos. Si su nginx sigue respondiendo Server: nginx/1.18.0 tras el aviso de seguridad que leyó, tiene un problema de CI/CD que resolver.
  • Verificar un cambio de hardening. ¿Ha ajustado ServerTokens en Apache o configurado server_tokens off en nginx? Una nueva ejecución debería ahora reportar solo nginx o Apache sin versión — prueba de que la directiva ha aterrizado.

Lectura del resultado

«Open + banner» es el caso ideal: un servicio habló y lo reconocimos. «Open + sin banner» es normal para protocolos binarios (RDP, handshake de MySQL, arranque de PostgreSQL) — reportamos que el puerto es alcanzable pero no podemos identificarlo sin hablar el formato del protocolo. «Closed» significa que el kernel devolvió RST — el servicio no está funcionando. «Filtered» significa que un cortafuegos engulló el SYN — muchos de estos son intencionados (VPN de administración cerrada), algunos indican mala configuración. Los resultados se cachean 15 minutos por host, así que recargas no vuelven a marcar todo el mundo.

Preguntas frecuentes

¿En qué se diferencia esto del comprobador de puertos?

El comprobador de puertos solo pregunta «¿se completa el handshake TCP?». Server check va más allá: hace un banner-grab real — leyendo el saludo que envían SSH/FTP/SMTP/POP3/IMAP al conectar, además de una petición HEAD real para HTTP/HTTPS — para poder nombrar el producto y (cuando no está oculta) la versión. El comprobador de puertos es más rápido para una lista personalizada larga; server check es la herramienta correcta cuando quiere saber qué hay en cada puerto, no solo que hay algo.

¿Por qué algunos puertos abiertos no tienen banner?

Los protocolos binarios — RDP, handshake previo a auth de MySQL, arranque de PostgreSQL, Redis crudo sin el saludo RESP — no envían una línea legible al conectar. Los marcamos como open sin huella. Para identificar versiones de estos servicios necesita un cliente que entienda el protocolo (p. ej. mysqladmin, nmap -sV con el script adecuado). Las configuraciones que ocultan banners (Apache ServerTokens Prod, nginx server_tokens off) se muestran de forma similar como «open, solo producto, sin versión».

¿Se admiten IP privadas?

No. Los rangos privados RFC 1918, loopback, link-local (169.254/16), CGN (100.64/10) y endpoints de metadatos en la nube están rechazados — misma política SSRF que el resto de nuestras herramientas. Server check es para hosts alcanzables públicamente. Para auditar un host interno, ejecute una herramienta de banner-grab desde dentro de su red.

¿Por qué HTTPS se reporta incluso con un certificado incorrecto?

Deshabilitamos la validación de certificados a propósito. El objetivo del check es averiguar qué hay en el puerto, no validar la confianza — muchos hosts de desarrollo y autofirmados no tienen cadena pública válida pero siguen siendo objetivos legítimos. Si quiere un veredicto de confianza, la herramienta SSL Checker ejecuta validación completa de cadena, caducidad y emisor; esta herramienta solo lee la cabecera Server:.

¿Cuánto tarda un escaneo?

Peor caso aproximadamente 45 segundos — 15 servicios × 3 segundos de timeout — cuando todos los puertos están filtrados. En la práctica los hosts típicos responden en un puñado de puertos en menos de 5 segundos en total. Los resultados se reciben según va respondiendo cada servicio, así que no espera a los lentos para conocer los rápidos; el resultado se cachea durante 15 minutos por host, así que una recarga es instantánea.