ALB interno con nome DNS público: está realmente exposto?

Execute unha consulta DNS pública contra un balanceador de carga interno e pode recibir un enderezo privado, algo que parece unha mala configuración ata que comproba para que serve o rexistro. AWS documenta que os nomes de balanceadores internos poden ser resolubles publicamente mentres os seus nodos só teñen enderezos privados. O resolutor respondeu onde está o servizo; non creou unha ruta, non abriu un grupo de seguridade nin autenticou a ninguén. Se esa resposta é un problema depende de feitos que pode comprobar por orde.

Paso un: lea o esquema, non o IP

O campo de esquema é a propia declaración do balanceador sobre o seu límite. aws elbv2 describe-load-balancers --names app-internal devolve un Scheme con valor internal ou internet-facing, máis un tipo de enderezo para IPv4 ou dobre pila. Un balanceador orientado a internet pode seguir reenviando a destinos privados, así que ver enderezos de backend privados non demostra nada sobre o front end.

Anote o esquema antes de mirar calquera outra cousa, porque cada xuízo posterior depende del. Tamén indica que controis existen, desde grupos de seguridade e regras de listener ata o conxunto de funcións dese tipo de balanceador. Un esquema copiado dunha captura antiga da consola é peor que ningunha nota. Volva lelo da API e pegue o valor no ticket.

Paso dous: vexa a que resolve o nome

Consulte desde fóra da VPC con dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com e anote se as respostas están en 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16. Unha resposta privada dun resolutor público é o comportamento esperado para un nome de balanceador interno; non é proba de que o enderezo sexa enrutable desde internet.

Resolva o mesmo nome desde dentro da VPC e compare. Se as dúas respostas difiren, está ante un nomeado split-horizon, e esa diferenza é un detalle de deseño, non unha fuga.

Paso tres: enumere as rutas que poden chegar a el

Un enderezo privado é alcanzable desde onde exista unha ruta e unha regra de seguridade. Enuméreas a propósito: VPN de sitio a sitio, VPN de cliente, VPC peering, conexións de transit gateway, Direct Connect e calquera proxy ou bastión dentro da VPC. Unha delas é a ruta prevista, e o resto son as que buscaría un atacante.

Despois comprobe os controis de cada ruta: grupos de seguridade no balanceador, ACL de rede nas subredes e o enrutamento que fai existir a ruta. A maioría dos casos denunciados de servizo interno exposto resólvense aquí, ou ben porque existía un peering non previsto ou porque a ruta era prevista e a aplicación non tiña autenticación.

Paso catro: probe o listener e a aplicación por separado

Intente conectar desde unha rede que non debería chegar ao servizo e confirme que non pode. Logo intente desde unha que si debería e confirme que chega a un listener. Esos dous resultados separan a alcanzabilidade de rede do comportamento da aplicación, e son a única evidencia que importa para a cuestión da exposición.

Un listener alcanzable non é o mesmo que unha aplicación accesible. Comprobe o certificado TLS e a política de protocolo, despois a autenticación e autorización propias da aplicación. Unha ferramenta interna que acepta a calquera chamante na VPN corporativa queda exposta a cada portátil comprometido nesa VPN, o que é un risco distinto ao dunha exposta a internet pero segue sendo un risco.

Lembre que os controis varían segundo o tipo. As devasas de capa de aplicación asócianse a unha familia de balanceadores e non á outra, así que confirme que hai realmente dispoñible para o esquema e o tipo que ten diante en lugar de supoñer paridade.

Paso cinco: decida se o nome en si importa

A resolubilidade pública pode revelar un nome de servizo, unha rexión e un rango de enderezos. Tráteo como unha cuestión de divulgación de información con resposta de política, non como un incidente automático: manteña os termos de negocio sensibles fóra dos nomes de recursos e anote a divulgación no seu rexistro de riscos se a convención de nomes revela máis do que desexa.

Se a organización quere unha experiencia de nomes privada, unha zona aloxada privada pode servir un alias que só se resolve dentro das VPC asociadas. Iso cambia o nome que ven os usuarios; non fai secreto o nome xerado polo provedor nin elimina ningunha ruta de rede.

Non intente fixar enderezos para ocultar a resposta. Os enderezos do balanceador cambian, a fixación rompe os hábitos de validación TLS, e o control que realmente necesita é quen pode establecer a conexión e que lles esixe a aplicación. Comprobe os catro feitos, anóteos, e a pregunta deixa de ser ambigua.