ALB intern amb nom DNS públic: està realment exposat?

Executeu una consulta DNS pública contra un balancejador de càrrega intern i podeu rebre una adreça privada, cosa que sembla una mala configuració fins que comproveu per a què serveix el registre. AWS documenta que els noms de balancejadors interns poden ser resolubles públicament mentre els seus nodes només tenen adreces privades. El resolutor va respondre on és el servei; no va crear cap ruta, no va obrir cap grup de seguretat ni va autenticar ningú. Si aquesta resposta és un problema depèn de fets que podeu verificar per ordre.

Pas u: llegiu l'esquema, no la IP

El camp d'esquema és la declaració del mateix balancejador sobre la seva frontera. aws elbv2 describe-load-balancers --names app-internal retorna un Scheme amb valor internal o internet-facing, més un tipus d'adreça per a IPv4 o doble pila. Un balancejador orientat a internet encara pot reenviar a objectius privats, així que veure adreces de backend privades no demostra res sobre la part frontal.

Anoteu l'esquema abans de mirar qualsevol altra cosa, perquè cada judici posterior en depèn. També us diu quins controls existeixen, des de grups de seguretat i regles d'oient fins al conjunt de funcions d'aquell tipus de balancejador. Un esquema copiat d'una captura antiga de la consola és pitjor que cap nota. Torneu-lo a llegir de l'API i enganxeu el valor al tiquet.

Pas dos: mireu a què resol el nom

Consulteu des de fora de la VPC amb dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com i fixeu-vos si les respostes són a 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16. Una resposta privada d'un resolutor públic és el comportament esperat per a un nom de balancejador intern; no és prova que l'adreça sigui encaminable des d'internet.

Resoleu el mateix nom des de dins de la VPC i compareu. Si les dues respostes difereixen, esteu davant d'un nomenclàtor split-horizon, i aquesta diferència és un detall de disseny, no una fuita.

Pas tres: llisteu els camins que hi poden arribar

Una adreça privada és abastable des d'on hi hagi una ruta i una regla de seguretat. Enumerar-les deliberadament: VPN de lloc a lloc, VPN de client, VPC peering, connexions de transit gateway, Direct Connect i qualsevol proxy o bastió dins de la VPC. Una d'elles és el camí previst, i la resta són les que buscaria un atacant.

Després comproveu els controls de cada camí: grups de seguretat al balancejador, ACL de xarxa a les subxarxes i l'encaminament que fa existir el camí. La majoria de casos denunciats de servei intern exposat es resolen aquí, o bé perquè existia un peering no previst o bé perquè el camí era previst i l'aplicació no tenia autenticació.

Pas quatre: proveu l'oient i l'aplicació per separat

Proveu de connectar des d'una xarxa que no hauria d'arribar al servei i confirmeu que no podeu. Després proveu des d'una que sí que hi hauria d'arribar i confirmeu que arribeu a un oient. Aquests dos resultats separen l'abastabilitat de xarxa del comportament de l'aplicació, i són l'única evidència que importa per a la qüestió de l'exposició.

Un oient abastable no és el mateix que una aplicació accessible. Comproveu el certificat TLS i la política de protocol, després l'autenticació i l'autorització pròpies de l'aplicació. Una eina interna que accepta qualsevol cridador a la VPN corporativa queda exposada a cada portàtil compromès en aquesta VPN, un risc diferent del d'una exposició a internet però igualment un risc.

Recordeu que els controls varien segons el tipus. Els tallafocs de capa d'aplicació s'adjunten a una família de balancejadors i no a l'altra, així que confirmeu què hi ha realment disponible per a l'esquema i el tipus que teniu al davant en lloc de suposar paritat.

Pas cinc: decidiu si el nom mateix té importància

La resolubilitat pública pot divulgar un nom de servei, una regió i un rang d'adreces. Tracteu-ho com una qüestió de divulgació d'informació amb resposta de política, no com un incident automàtic: manteniu els termes de negoci sensibles fora dels noms de recursos i anoteu la divulgació al registre de riscos si la convenció de noms revela més del que voleu.

Si l'organització vol una experiència de noms privada, una zona allotjada privada pot servir un àlies que només es resol dins de les VPC associades. Això canvia el nom que veuen els usuaris; no fa secret el nom generat pel proveïdor ni elimina cap camí de xarxa.

No intenteu fixar adreces per amagar la resposta. Les adreces del balancejador canvien, la fixació trenca els hàbits de validació TLS, i el control que de debò necessiteu és qui pot establir la connexió i què els exigeix l'aplicació. Comproveu els quatre fets, anoteu-los, i la pregunta deixa de ser ambigua.