ALB interno con nombre DNS público: ¿está realmente expuesto?

Ejecute una consulta DNS pública contra un balanceador de carga interno y puede recibir una dirección privada, algo que parece una mala configuración hasta que comprueba para qué sirve el registro. AWS documenta que los nombres de balanceadores internos pueden ser resolubles públicamente mientras sus nodos solo tienen direcciones privadas. El resolutor respondió dónde está el servicio; no creó una ruta, no abrió un grupo de seguridad ni autenticó a nadie. Si esa respuesta es un problema depende de hechos que puede comprobar en orden.

Paso uno: lea el esquema, no la IP

El campo de esquema es la propia declaración del balanceador sobre su límite. aws elbv2 describe-load-balancers --names app-internal devuelve un Scheme con valor internal o internet-facing, más un tipo de dirección para IPv4 o pila doble. Un balanceador orientado a internet puede seguir reenviando a destinos privados, así que ver direcciones de backend privadas no demuestra nada sobre el front end.

Anote el esquema antes de mirar cualquier otra cosa, porque cada juicio posterior depende de él. También indica qué controles existen, desde grupos de seguridad y reglas de listener hasta el conjunto de funciones de ese tipo de balanceador. Un esquema copiado de una captura antigua de la consola es peor que ninguna nota. Vuelva a leerlo de la API y pegue el valor en el ticket.

Paso dos: vea a qué resuelve el nombre

Consulte desde fuera de la VPC con dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com y anote si las respuestas están en 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16. Una respuesta privada de un resolutor público es el comportamiento esperado para un nombre de balanceador interno; no es prueba de que la dirección sea enrutable desde internet.

Resuelva el mismo nombre desde dentro de la VPC y compare. Si las dos respuestas difieren, está ante un nombrado split-horizon, y esa diferencia es un detalle de diseño, no una fuga.

Paso tres: enumere las rutas que pueden llegar a él

Una dirección privada es alcanzable desde donde exista una ruta y una regla de seguridad. Enumérelas a propósito: VPN de sitio a sitio, VPN de cliente, VPC peering, conexiones de transit gateway, Direct Connect y cualquier proxy o bastión dentro de la VPC. Una de ellas es la ruta prevista, y el resto son las que buscaría un atacante.

Después compruebe los controles de cada ruta: grupos de seguridad en el balanceador, ACL de red en las subredes y el enrutamiento que hace existir la ruta. La mayoría de los casos denunciados de servicio interno expuesto se resuelven aquí, o bien porque existía un peering no previsto o porque la ruta era prevista y la aplicación no tenía autenticación.

Paso cuatro: pruebe el listener y la aplicación por separado

Intente conectar desde una red que no debería llegar al servicio y confirme que no puede. Luego intente desde una que sí debería y confirme que llega a un listener. Esos dos resultados separan la alcanzabilidad de red del comportamiento de la aplicación, y son la única evidencia que importa para la cuestión de la exposición.

Un listener alcanzable no es lo mismo que una aplicación accesible. Compruebe el certificado TLS y la política de protocolo, después la autenticación y autorización propias de la aplicación. Una herramienta interna que acepta a cualquier llamante en la VPN corporativa queda expuesta a cada portátil comprometido en esa VPN, lo que es un riesgo distinto al de una expuesta a internet pero sigue siendo un riesgo.

Recuerde que los controles varían según el tipo. Los cortafuegos de capa de aplicación se asocian a una familia de balanceadores y no a la otra, así que confirme qué hay realmente disponible para el esquema y el tipo que tiene delante en lugar de suponer paridad.

Paso cinco: decida si el nombre en sí importa

La resolubilidad pública puede revelar un nombre de servicio, una región y un rango de direcciones. Trátelo como una cuestión de divulgación de información con respuesta de política, no como un incidente automático: mantenga los términos de negocio sensibles fuera de los nombres de recursos y anote la divulgación en su registro de riesgos si la convención de nombres revela más de lo que desea.

Si la organización quiere una experiencia de nombres privada, una zona alojada privada puede servir un alias que solo se resuelve dentro de las VPC asociadas. Eso cambia el nombre que ven los usuarios; no hace secreto el nombre generado por el proveedor ni elimina ninguna ruta de red.

No intente fijar direcciones para ocultar la respuesta. Las direcciones del balanceador cambian, la fijación rompe los hábitos de validación TLS, y el control que realmente necesita es quién puede establecer la conexión y qué les exige la aplicación. Compruebe los cuatro hechos, anótelos, y la pregunta deja de ser ambigua.