Interner ALB, öffentlicher DNS-Name: wirklich exponiert?

Führen Sie eine öffentliche DNS-Abfrage gegen einen internen Loadbalancer aus, und Sie erhalten möglicherweise eine private Adresse zurück, was wie eine Fehlkonfiguration aussieht, bis Sie prüfen, wofür der Eintrag gedacht ist. AWS dokumentiert, dass interne Loadbalancer-Namen öffentlich auflösbar sein können, während ihre Knoten nur private Adressen halten. Der Resolver beantwortete, wo der Dienst liegt; er legte keine Route an, öffnete keine Sicherheitsgruppe und authentifizierte niemanden. Ob diese Antwort ein Problem ist, hängt von Fakten ab, die Sie der Reihe nach prüfen können.

Schritt eins: Lesen Sie das Schema, nicht die IP

Das Schema-Feld ist die eigene Aussage des Loadbalancers über seine Grenze. aws elbv2 describe-load-balancers --names app-internal liefert ein Scheme mit dem Wert internal oder internet-facing sowie einen Adresstyp für IPv4 oder Dual-Stack. Ein internetzugewandter Loadbalancer kann dennoch an private Ziele weiterleiten, daher beweist der Anblick privater Backend-Adressen nichts über das Frontend.

Notieren Sie das Schema, bevor Sie irgendetwas anderes ansehen, denn jede spätere Bewertung hängt davon ab. Es sagt auch, welche Kontrollen existieren, von Sicherheitsgruppen und Listener-Regeln bis zum Funktionsumfang dieses Loadbalancer-Typs. Ein aus einem alten Konsolen-Screenshot kopiertes Schema ist schlimmer als gar keine Notiz. Lesen Sie es erneut aus der API und fügen Sie den Wert ins Ticket ein.

Schritt zwei: Sehen Sie, worauf der Name auflöst

Fragen Sie von außerhalb der VPC mit dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com ab und notieren Sie, ob die Antworten in 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 liegen. Eine private Antwort von einem öffentlichen Resolver ist das erwartete Verhalten für einen internen Loadbalancer-Namen; sie ist kein Beweis, dass die Adresse aus dem Internet routbar ist.

Lösen Sie denselben Namen aus dem Inneren der VPC auf, und vergleichen Sie. Unterscheiden sich die beiden Antworten, sehen Sie Split-Horizon-Namensgebung, und dieser Unterschied ist ein Designdetail, kein Leck.

Schritt drei: Listen Sie die Pfade auf, die ihn erreichen können

Eine private Adresse ist von überall erreichbar, wo eine Route und eine Sicherheitsregel existieren. Zählen Sie diese bewusst auf: Site-to-Site-VPN, Client-VPN, VPC-Peering, Transit-Gateway-Anhänge, Direct Connect sowie jeden Proxy oder Bastion innerhalb der VPC. Einer davon ist der beabsichtigte Pfad, und die übrigen sind die, nach denen ein Angreifer suchen würde.

Prüfen Sie dann die Kontrollen auf jedem Pfad: Sicherheitsgruppen am Loadbalancer, Netzwerk-ACLs an den Subnetzen und das Routing, das den Pfad überhaupt entstehen lässt. Die meisten gemeldeten Fälle eines exponierten internen Dienstes lösen sich hier, sei es, weil ein unbeabsichtigtes Peering bestand, oder weil der Pfad beabsichtigt war und die Anwendung keine Authentifizierung hatte.

Schritt vier: Testen Sie Listener und Anwendung getrennt

Versuchen Sie, sich aus einem Netz zu verbinden, das den Dienst nicht erreichen sollte, und bestätigen Sie, dass es nicht geht. Versuchen Sie es dann aus einem, das ihn erreichen sollte, und bestätigen Sie, dass Sie einen Listener erreichen. Diese beiden Ergebnisse trennen Netzwerkerreichbarkeit vom Anwendungsverhalten, und sie sind der einzige Beweis, der für die Expositionsfrage zählt.

Ein erreichbarer Listener ist nicht dasselbe wie eine zugängliche Anwendung. Prüfen Sie das TLS-Zertifikat und die Protokollrichtlinie, dann Authentifizierung und Autorisierung der Anwendung selbst. Ein internes Werkzeug, das jeden Aufrufer im Firmen-VPN akzeptiert, ist jedem kompromittierten Laptop in diesem VPN ausgesetzt, was ein anderes Risiko als eine internetzugewandte Anwendung ist, aber immer noch ein Risiko.

Denken Sie daran, dass Kontrollen je nach Typ variieren. Firewalls der Anwendungsschicht hängen an einer Loadbalancer-Familie und nicht an der anderen, also bestätigen Sie, was für das Schema und den Typ vor Ihnen tatsächlich verfügbar ist, statt Gleichheit anzunehmen.

Schritt fünf: Entscheiden Sie, ob der Name selbst zählt

Öffentliche Auflösbarkeit kann einen Dienstnamen, eine Region und einen Adressbereich offenlegen. Behandeln Sie das als Frage der Informationsoffenlegung mit einer Richtlinienantwort, nicht als automatischen Vorfall: halten Sie sensible Geschäftsbegriffe aus Ressourcennamen heraus, und vermerken Sie die Offenlegung in Ihrem Risikoregister, wenn die Namenskonvention mehr verrät, als Ihnen lieb ist.

Will die Organisation eine private Namenserfahrung, kann eine private gehostete Zone einen Alias bereitstellen, der nur innerhalb der zugeordneten VPCs auflöst. Das ändert den Namen, den Nutzer sehen; es macht den vom Anbieter erzeugten Namen nicht geheim und entfernt keinen Netzwerkpfad.

Versuchen Sie nicht, Adressen festzunageln, um die Antwort zu verbergen. Loadbalancer-Adressen ändern sich, Festnageln bricht TLS-Validierungsgewohnheiten, und die Kontrolle, die Sie wirklich brauchen, ist, wer die Verbindung aufbauen kann und was die Anwendung von ihm verlangt. Prüfen Sie die vier Fakten, schreiben Sie sie auf, und die Frage ist nicht mehr mehrdeutig.