ALB interne, nom DNS public : vraiment exposé ?

Lancez une requête DNS publique contre un équilibreur de charge interne et vous pouvez recevoir une adresse privée, ce qui ressemble à une mauvaise configuration jusqu'à ce que vous vérifiiez à quoi sert l'enregistrement. AWS documente que les noms d'équilibreurs internes peuvent être résolus publiquement alors que leurs nœuds ne portent que des adresses privées. Le résolveur a répondu où se trouve le service ; il n'a pas créé de route, ouvert de groupe de sécurité ni authentifié quiconque. Que cette réponse soit un problème dépend de faits que vous pouvez vérifier dans l'ordre.

Étape un : lisez le schéma, pas l'IP

Le champ schéma est la déclaration de l'équilibreur sur sa propre frontière. aws elbv2 describe-load-balancers --names app-internal renvoie un Scheme valant internal ou internet-facing, plus un type d'adresse pour IPv4 ou double pile. Un équilibreur tourné vers internet peut encore transmettre vers des cibles privées, donc voir des adresses backend privées ne prouve rien sur le front end.

Notez le schéma avant de regarder quoi que ce soit d'autre, car chaque jugement ultérieur en dépend. Il indique aussi quels contrôles existent, des groupes de sécurité et règles d'écouteur à l'ensemble de fonctionnalités de ce type d'équilibreur. Un schéma copié d'une ancienne capture de console est pire qu'aucune note. Relisez-le depuis l'API et collez la valeur dans le ticket.

Étape deux : voyez vers quoi le nom se résout

Interrogez depuis l'extérieur du VPC avec dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com et notez si les réponses sont dans 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16. Une réponse privée d'un résolveur public est le comportement attendu pour un nom d'équilibreur interne ; ce n'est pas la preuve que l'adresse est routable depuis internet.

Résolvez le même nom depuis l'intérieur du VPC et comparez. Si les deux réponses diffèrent, vous êtes devant un nommage split-horizon, et cette différence est un détail de conception, pas une fuite.

Étape trois : énumérez les chemins qui peuvent l'atteindre

Une adresse privée est joignable partout où existent une route et une règle de sécurité. Énumérez-les délibérément : VPN site à site, VPN client, appairage VPC, rattachements de transit gateway, Direct Connect et tout proxy ou bastion à l'intérieur du VPC. L'un d'eux est le chemin prévu, et les autres sont ceux qu'un attaquant chercherait.

Vérifiez ensuite les contrôles sur chaque chemin : groupes de sécurité sur l'équilibreur, ACL réseau sur les sous-réseaux et le routage qui fait exister le chemin. La plupart des cas signalés de service interne exposé se résolvent ici, soit parce qu'un appairage non prévu existait, soit parce que le chemin était prévu et que l'application n'avait aucune authentification.

Étape quatre : testez l'écouteur et l'application séparément

Essayez de vous connecter depuis un réseau qui ne devrait pas atteindre le service et confirmez que vous ne pouvez pas. Essayez ensuite depuis un réseau qui le devrait, et confirmez que vous atteignez un écouteur. Ces deux résultats séparent la joignabilité réseau du comportement applicatif, et ce sont les seules preuves qui comptent pour la question de l'exposition.

Un écouteur joignable n'est pas la même chose qu'une application accessible. Vérifiez le certificat TLS et la politique de protocole, puis l'authentification et l'autorisation de l'application elle-même. Un outil interne qui accepte n'importe quel appelant sur le VPN d'entreprise est exposé à chaque portable compromis sur ce VPN, ce qui est un risque différent d'une exposition à internet mais reste un risque.

Rappelez-vous que les contrôles diffèrent selon le type. Les pare-feu de couche applicative s'attachent à une famille d'équilibreurs et pas à l'autre, alors confirmez ce qui est réellement disponible pour le schéma et le type devant vous au lieu de supposer une parité.

Étape cinq : décidez si le nom lui-même compte

La résolvabilité publique peut divulguer un nom de service, une région et une plage d'adresses. Traitez cela comme une question de divulgation d'information avec une réponse de politique, pas comme un incident automatique : gardez les termes métier sensibles hors des noms de ressources, et consignez la divulgation dans votre registre des risques si la convention de nommage révèle plus que vous ne le souhaitez.

Si l'organisation veut une expérience de nommage privée, une zone hébergée privée peut servir un alias qui ne se résout que dans les VPC associés. Cela change le nom que voient les utilisateurs ; cela ne rend pas secret le nom généré par le fournisseur et ne supprime aucun chemin réseau.

N'essayez pas d'épingler des adresses pour masquer la réponse. Les adresses de l'équilibreur changent, l'épinglage casse les habitudes de validation TLS, et le contrôle dont vous avez réellement besoin est qui peut établir la connexion et ce que l'application exige de lui. Vérifiez les quatre faits, notez-les, et la question cesse d'être ambiguë.