Interne ALB met publieke DNS-naam: echt blootgesteld?

Voer een publieke DNS-query uit tegen een interne loadbalancer en u krijgt mogelijk een privéadres terug, wat op een verkeerde configuratie lijkt tot u controleert waarvoor de record dient. AWS documenteert dat namen van interne loadbalancers publiek resolveerbaar kunnen zijn terwijl hun nodes alleen privéadressen hebben. De resolver antwoordde waar de dienst is; hij maakte geen route, opende geen beveiligingsgroep en authenticeerde niemand. Of dat antwoord een probleem is, hangt af van feiten die u op volgorde kunt controleren.

Stap één: lees het schema, niet het IP

Het schemaveld is de eigen verklaring van de loadbalancer over zijn grens. aws elbv2 describe-load-balancers --names app-internal retourneert een Scheme met de waarde internal of internet-facing, plus een adrestype voor IPv4 of dubbele stack. Een naar internet gerichte loadbalancer kan nog steeds naar privédoelen doorsturen, dus het zien van privé-backendadressen bewijst niets over de frontend.

Noteer het schema voordat u iets anders bekijkt, want elk later oordeel hangt ervan af. Het vertelt ook welke controles bestaan, van beveiligingsgroepen en listenerregels tot de functieset van dat loadbalancertype. Een schema dat uit een oude consoleschermafbeelding is gekopieerd, is erger dan geen notitie. Lees het opnieuw uit de API en plak de waarde in het ticket.

Stap twee: kijk waar de naam naartoe resolveert

Vraag van buiten de VPC met dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com en noteer of de antwoorden in 10.0.0.0/8, 172.16.0.0/12 of 192.168.0.0/16 liggen. Een privéantwoord van een publieke resolver is het verwachte gedrag voor een interne loadbalancernaam; het is geen bewijs dat het adres vanaf internet routeerbaar is.

Los dezelfde naam op van binnen de VPC en vergelijk. Als de twee antwoorden verschillen, ziet u split-horizon-naamgeving, en dat verschil is een ontwerpdetail, geen lek.

Stap drie: noem de paden die hem kunnen bereiken

Een privéadres is bereikbaar vanaf elke plek waar een route en een beveiligingsregel bestaan. Noem ze bewust op: site-to-site-VPN, client-VPN, VPC-peering, transit gateway-koppelingen, Direct Connect en elke proxy of bastion binnen de VPC. Een van hen is het bedoelde pad, en de rest zijn de paden die een aanvaller zou zoeken.

Controleer daarna de controles op elk pad: beveiligingsgroepen op de loadbalancer, netwerk-ACL's op de subnetten en de routering die het pad überhaupt laat bestaan. De meeste gemelde gevallen van een blootgestelde interne dienst worden hier opgelost, hetzij omdat er een onbedoelde peering was, hetzij omdat het pad bedoeld was en de applicatie geen authenticatie had.

Stap vier: test de listener en de applicatie apart

Probeer te verbinden vanaf een netwerk dat de dienst niet zou moeten bereiken en bevestig dat het niet lukt. Probeer daarna vanaf een netwerk dat het wel zou moeten, en bevestig dat u een listener bereikt. Die twee resultaten scheiden netwerkbereikbaarheid van applicatiegedrag, en ze zijn het enige bewijs dat telt voor de blootstellingsvraag.

Een bereikbare listener is niet hetzelfde als een toegankelijke applicatie. Controleer het TLS-certificaat en het protocolbeleid, daarna de authenticatie en autorisatie van de applicatie zelf. Een intern hulpmiddel dat elke aanroeper op het bedrijfs-VPN accepteert, staat bloot aan elke gecompromitteerde laptop op dat VPN, wat een ander risico is dan een naar internet gerichte, maar nog steeds een risico.

Onthoud dat controles per type verschillen. Firewalls op de applicatielaag hangen aan de ene loadbalancerfamilie en niet aan de andere, dus bevestig wat feitelijk beschikbaar is voor het schema en type voor u in plaats van gelijkheid aan te nemen.

Stap vijf: beslis of de naam zelf ertoe doet

Publieke resolveerbaarheid kan een dienstnaam, een regio en een adresbereik onthullen. Behandel dat als een vraag over informatie-openbaarmaking met een beleidsantwoord, niet als een automatisch incident: houd gevoelige bedrijfstermen buiten resourcenamen, en noteer de openbaarmaking in uw risicoregister als de naamconventie meer verraadt dan u wilt.

Als de organisatie een private naamervaring wil, kan een private gehoste zone een alias leveren die alleen binnen de gekoppelde VPC's resolveert. Dat verandert de naam die gebruikers zien; het maakt de door de provider gegenereerde naam niet geheim en het verwijdert geen netwerkpad.

Probeer adressen niet vast te pinnen om het antwoord te verbergen. Loadbalanceradressen veranderen, vastpinnen breekt TLS-validatiegewoonten, en de controle die u echt nodig hebt, is wie de verbinding kan opzetten en wat de applicatie van hen eist. Controleer de vier feiten, schrijf ze op, en de vraag is niet langer dubbelzinnig.