Interne ALB met 'n openbare DNS-naam: is dit werklik blootgestel?

Voer 'n openbare DNS-navraag teen 'n interne lasbalanseerder uit en jy kan dalk 'n private adres terugkry, wat soos 'n verkeerde opstelling lyk totdat jy nagaan waarvoor die rekord is. AWS dokumenteer dat interne lasbalanseerder-name openbaar oplosbaar kan wees terwyl hul nodusse slegs private adresse hou. Die resolver het geantwoord waar die diens is; dit het nie 'n roete geskep, 'n sekuriteitsgroep oopgemaak of iemand geauthentiseer nie. Of daardie antwoord 'n probleem is, hang af van feite wat jy in volgorde kan nagaan.

Stap een: lees die skema, nie die IP nie

Die skema-veld is die lasbalanseerder se eie verklaring oor sy grens. aws elbv2 describe-load-balancers --names app-internal gee 'n Scheme van óf internal óf internet-facing terug, plus 'n adrestipe vir IPv4 of dubbele stapel. 'n Internetgerigte lasbalanseerder kan steeds na private teikens deurstuur, dus die sien van private backend-adresse bewys niks oor die voorkant nie.

Skryf die skema neer voordat jy na enigiets anders kyk, want elke latere oordeel hang daarvan af. Dit sê ook watter beheermaatreëls bestaan, van sekuriteitsgroepe en luisteraar-reëls tot die kenmerke van daardie lasbalanseerder-tipe. 'n Skema wat uit 'n ou konsole-skermkiekie gekopieer is, is erger as geen nota nie. Lees dit weer uit die API en plak die waarde in die kaartjie.

Stap twee: kyk waarheen die naam oplos

Vra van buite die VPC met dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com en let op of die antwoorde in 10.0.0.0/8, 172.16.0.0/12 of 192.168.0.0/16 is. 'n Private antwoord van 'n openbare resolver is die verwagte gedrag vir 'n interne lasbalanseerder-naam; dit is nie bewyse dat die adres van die internet af bereikbaar is nie.

Los dieselfde naam van binne die VPC op en vergelyk. As die twee antwoorde verskil, kyk jy na split-horizon-naamgewing, en daardie verskil is 'n ontwerpbesonderheid, nie 'n lek nie.

Stap drie: lys die paaie wat dit kan bereik

'n Private adres is bereikbaar van oral waar 'n roete en 'n sekuriteitsreël bestaan. Lys dit doelbewus: site-to-site VPN, kliënt-VPN, VPC-peering, transit gateway-aanhegings, Direct Connect en enige proxy of bastion binne die VPC. Een van hulle is die bedoelde roete, en die res is die wat 'n aanvaller sou soek.

Kontroleer dan die beheermaatreëls op elke roete: sekuriteitsgroepe op die lasbalanseerder, netwerk-ACL's op die subnette en die roetering wat die roete hoegenaamd laat bestaan. Die meeste gevalle van 'n blootgestelde interne diens word hier opgelos, hetsy omdat 'n onbedoelde peering bestaan het of omdat die roete bedoel was en die toepassing geen verifikasie gehad het nie.

Stap vier: toets die luisteraar en die toepassing afsonderlik

Probeer verbind vanaf 'n netwerk wat nie die diens behoort te bereik nie en bevestig dat jy nie kan nie. Probeer dan vanaf een wat dit wel behoort te kan, en bevestig dat jy 'n luisteraar bereik. Daardie twee resultate skei netwerkbereikbaarheid van toepassingsgedrag, en hulle is die enigste bewyse wat vir die blootstellingsvraag saak maak.

'n Bereikbare luisteraar is nie dieselfde as 'n toeganklike toepassing nie. Kontroleer die TLS-sertifikaat en protokolbeleid, dan die toepassing se eie verifikasie en magtiging. 'n Interne hulpmiddel wat enige oproeper op die korporatiewe VPN aanvaar, is blootgestel aan elke gekompromitteerde skootrekenaar op daardie VPN, wat 'n ander risiko as 'n internetgerigte een is, maar steeds 'n risiko.

Onthou dat beheermaatreëls per tipe verskil. Toepassingslaag-vuurmure koppel aan een lasbalanseerder-familie en nie die ander nie, so bevestig wat werklik vir die skema en tipe voor jou beskikbaar is in plaas daarvan om gelykheid te aanvaar.

Stap vyf: besluit of die naam self saak maak

Openbare oplosbaarheid kan 'n diensnaam, 'n streek en 'n adresreeks openbaar. Behandel dit as 'n vraag oor die openbaarmaking van inligting met 'n beleidsantwoord, nie as 'n outomatiese voorval nie: hou sensitiewe saketerme uit hulpbronname, en teken die openbaarmaking in jou risikorekord aan as die naamkonvensie meer verklap as wat jy wil.

As die organisasie 'n private naamervaring wil hê, kan 'n private gehoste sone 'n alias bedien wat net binne die geassosieerde VPC's oplos. Dit verander die naam wat gebruikers sien; dit maak nie die naam wat die verskaffer genereer geheim nie, en dit verwyder geen netwerkroete nie.

Moenie adresse probeer vaspen om die antwoord te versteek nie. Lasbalanseerder-adresse verander, vaspenning breek TLS-valideringsgewoontes, en die beheermaatreël wat jy werklik nodig het, is wie die verbinding kan vestig en wat die toepassing van hulle vereis. Gaan die vier feite na, skryf hulle neer, en die vraag is nie meer dubbelsinnig nie.