Cómo monitorizar un puerto TCP (y cuándo emitir una alerta sobre uno que esté abierto)

La monitorización de puertos son dos trabajos en uno. A veces quiere saber que un servicio está escuchando, como una base de datos o un relay SMTP. A veces quiere saber que un puerto permanece bloqueado por el firewall, como SSH en una instancia expuesta a internet. La misma sonda responde a ambas preguntas, pero usted alerta sobre resultados opuestos. Esta guía cubre cuándo usar cada modo, sobre qué alertar y los puertos que sorprenden a la gente.

Cómo funciona realmente un monitor de puertos TCP

Un monitor de puertos TCP abre un socket hacia el destino en el puerto elegido y espera a que se complete el handshake de tres vías. Si el handshake tiene éxito, el puerto está abierto. Si la conexión es rechazada, el puerto está cerrado. Si la conexión expira por tiempo, algo entre la sonda y su host está descartando el paquete, normalmente un firewall.

La sonda no habla ningún protocolo sobre el socket. No negocia TLS, no intercambia banners SSH ni ejecuta una consulta de base de datos. Solo le indica si el puerto responde. Para la salud a nivel de aplicación necesita una comprobación HTTP o personalizada por encima.

Cuándo quiere el puerto ABIERTO

Utilice la monitorización de puertos como sonda de salud del servicio cuando no pueda realizar fácilmente una comprobación HTTP. Surgen cinco casos habituales.

• Servidores de bases de datos en los puertos 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Si el listener se cae, todos los servicios dependientes se rompen, pero no puede ejecutar una sonda HTTP.
• Relays SMTP en los puertos 25 o 587. Las comprobaciones del banner SMTP detectan caídas del listener que los endpoints de salud internos pasan por alto.
• Servidores de juegos y otros protocolos TCP personalizados que no hablan HTTP.
• Balanceadores de carga internos que exponen un puerto de salud no HTTP a servicios upstream.
• Endpoints VPN en puertos UDP-pero-también-TCP como el 443 para OpenVPN-TCP y WireGuard.

Cuándo quiere el puerto CERRADO

La monitorización de puertos invertida es una salvaguarda de seguridad. Configura el monitor para que alerte cuando el puerto se abra, porque nunca debería estar abierto desde la internet pública. Este patrón detecta las cosas que salen mal durante una semana normal de cambios de infraestructura.

Alguien abre temporalmente una regla de firewall para depurar y se olvida de revertirla. Un servicio de Kubernetes recibe un tipo LoadBalancer por accidente. Una nueva instancia obtiene el grupo de seguridad incorrecto. Un cambio en un módulo de Terraform expone un puerto que se suponía interno. En todos los casos, el monitor de puertos invertido detecta la exposición dentro de un intervalo de comprobación.

Los puertos de alto valor para monitorizar de forma invertida ahora mismo

Vale la pena configurar una comprobación invertida en cinco puertos para cualquier host expuesto a internet que no debería estar exponiéndolos.

• 22 (SSH) en servidores de aplicaciones de producción. El acceso solo a través de bastión es la norma, y un puerto SSH abierto por accidente aparece en los registros de escaneos masivos en cuestión de horas.
• 3306 (MySQL) y 5432 (Postgres). Los puertos públicos de bases de datos son responsables de una parte significativa de los ataques de credential stuffing.
• 6379 (Redis). Redis abierto sin autenticación es una de las configuraciones erróneas más explotadas del sector.
• 27017 (MongoDB). La misma historia que Redis. Configuración por defecto, sin autenticación, puerto público equivale a pérdida de datos.
• 9200 (Elasticsearch). Los clústeres abiertos son raspados, minados y secuestrados en cuestión de horas.

Umbrales de alerta para la monitorización de puertos

La salud del servicio (el puerto debería estar ABIERTO) requiere el mismo patrón de umbral que HTTP: alertar tras 3 fallos consecutivos, suprimir oscilaciones cortas. Los cortes de red que cierran una sola sonda son ruido.

La seguridad (el puerto debería estar CERRADO) quiere lo contrario. Alerte ante la primera detección. Un puerto SSH o Redis abierto por accidente es un evento de máxima alarma. Los bots escanean la internet pública constantemente, y la ventana entre la exposición y el compromiso en un puerto bien conocido se mide en minutos.

Una lista de comprobación inicial de monitorización de puertos de seguridad

Para cada IP expuesta a internet que opere su equipo, configure monitores invertidos en los puertos 22, 3306, 5432, 6379 y 27017 con un intervalo de 60 segundos. Enrute las alertas a su canal de seguridad de forma separada a las alertas de salud del servicio. Una vez por trimestre, ejecute un escaneo de puertos real contra sus propias IPs como control. El coste es pequeño, la cobertura es amplia y los modos de fallo que detecta son catastróficos.