Una nueva VM se lanzó con SSH (22) y RDP (3389) abiertos a 0.0.0.0/0. ¿Cuál es la remediación correcta?
Respuesta breve
Los puertos de administración abiertos a todo Internet se escanean y atacan por fuerza bruta en minutos, así que la solución es reducir la superficie de ataque: restringe el ingreso del security group a CIDR de administración conocidos o VPN, o elimina por completo el tráfico entrante usando un bastión o SSM Session Manager. Mover SSH a un puerto no estándar es seguridad por oscuridad que los escáneres vencen de forma trivial. Una contraseña más fuerte no reduce la superficie expuesta ni detiene el credential stuffing. Confiar en un firewall de host ignora la superficie de ataque que el security group anuncia abiertamente a Internet.
Los puertos de administración abiertos a 0.0.0.0/0 son una de las malas configuraciones de nube más explotadas. El entrevistador quiere ver que reduces la superficie de ataque en sí, y no solo que haces la superficie expuesta marginalmente más difícil de abusar.
Por qué restringir el ingreso es lo correcto
Internet se escanea continuamente; una VM nueva con 22 y 3389 abiertos al mundo verá intentos de fuerza bruta y credential stuffing en minutos. La solución correcta es dejar de anunciar esos puertos a todos. Restringe el ingreso del security group a un pequeño conjunto de CIDR de administración de confianza o a un rango de VPN, o —mejor— elimina por completo el acceso de administración entrante y alcanza el host a través de un bastión o AWS SSM Session Manager. SSM es especialmente sólido porque no necesita ningún puerto entrante abierto: el acceso pasa por la API de AWS con autorización IAM y registro de auditoría completo.
Por qué fallan los distractores
- Mover SSH a un puerto no estándar. Esto es seguridad por oscuridad. Los escáneres masivos barren todos los puertos, así que el servicio se encuentra en segundos; no has ganado nada real mientras complicas la operación.
- Establecer una contraseña más fuerte. Una mejor contraseña puede ralentizar un vector de fuerza bruta, pero el puerto sigue abierto a todo Internet, sigue atrayendo tráfico constante y sigue expuesto a cualquier futura vulnerabilidad de autenticación o filtración de clave/contraseña. Trata un problema de exposición de red como un problema de credenciales.
- Dejarlo así: la VM tiene un firewall de host. Confiar en un firewall de host mientras el security group de la nube anuncia el puerto al mundo es defensa en profundidad hecha al revés: un firewall de host mal configurado, y quedas totalmente expuesto. Ciérralo en el borde de la red.
Qué buscan los entrevistadores
Nombrar el security group como el control, restringir los CIDR de origen e, idealmente, eliminar el puerto abierto con un bastión o SSM. Los buenos candidatos también mencionan encontrar todos los security groups infractores en toda la organización, porque una VM abierta suele significar que falta la salvaguarda (una SCP o regla de Config que bloquee 0.0.0.0/0 en 22/3389).
Posibles preguntas de seguimiento
- ¿Por qué SSM Session Manager suele ser mejor que incluso un bastión bien restringido?
- ¿Cómo encontrarías cada security group que expone 22 o 3389 a 0.0.0.0/0 en toda la organización?
- ¿Contra qué falla en protegerte aquí una contraseña más fuerte?