Intern ALB med offentlig DNS-navn: er den virkelig eksponert?

Kjør et offentlig DNS-oppslag mot en intern lastbalanserer, og du kan få en privat adresse tilbake, noe som ser ut som en feilkonfigurasjon til du sjekker hva oppføringen er for. AWS dokumenterer at interne lastbalanserernavn kan være offentlig oppløsbare mens nodene deres bare har private adresser. Resolveren svarte hvor tjenesten er; den opprettet ikke en rute, åpnet ikke en sikkerhetsgruppe og autentiserte ingen. Om svaret er et problem avhenger av fakta du kan sjekke i rekkefølge.

Trinn én: les skjemaet, ikke IP-en

Skjemafeltet er lastbalansererens egen uttalelse om grensen sin. aws elbv2 describe-load-balancers --names app-internal returnerer Scheme med verdien internal eller internet-facing, pluss en adressetype for IPv4 eller dobbel stakk. En internettvendt lastbalanserer kan fortsatt videresende til private mål, så synet av private backend-adresser beviser ingenting om frontenden.

Skriv ned skjemaet før du ser på noe annet, fordi hver senere vurdering avhenger av det. Det forteller også hvilke kontroller som finnes, fra sikkerhetsgrupper og listener-regler til funksjonssettet for den typen lastbalanserer. Et skjema kopiert fra et gammelt konsollskjermbilde er verre enn ingen notat. Les det på nytt fra API-et og lim inn verdien i saken.

Trinn to: se hva navnet løses opp til

Spør fra utsiden av VPC-en med dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com og noter om svarene ligger i 10.0.0.0/8, 172.16.0.0/12 eller 192.168.0.0/16. Et privat svar fra en offentlig resolver er forventet atferd for et internt lastbalanserernavn; det er ikke bevis for at adressen kan rutes fra internett.

Slå opp samme navn fra innsiden av VPC-en og sammenlign. Hvis de to svarene er ulike, ser du split-horizon-navngiving, og forskjellen er en designdetalj, ikke en lekkasje.

Trinn tre: list opp stiene som kan nå den

En privat adresse er nåbar fra hvor som helst en rute og en sikkerhetsregel finnes. List dem opp bevisst: site-til-site-VPN, klient-VPN, VPC-peering, transit gateway-tilkoblinger, Direct Connect og enhver proxy eller bastion inne i VPC-en. En av dem er den tiltenkte stien, og resten er dem en angriper ville lete etter.

Sjekk deretter kontrollene på hver sti: sikkerhetsgrupper på lastbalanseren, nettverks-ACL-er på subnettene og rutingen som gjør at stien i det hele tatt finnes. De fleste rapporterte tilfeller av eksponert intern tjeneste løses her, enten fordi det fantes en utilsiktet peering, eller fordi stien var tilsiktet og applikasjonen ikke hadde autentisering.

Trinn fire: test listeneren og applikasjonen hver for seg

Prøv å koble til fra et nettverk som ikke skal nå tjenesten, og bekreft at du ikke kan. Prøv deretter fra et som skal, og bekreft at du når en listener. Disse to resultatene skiller nettverksnåbarhet fra applikasjonsatferd, og de er det eneste beviset som betyr noe for eksponeringsspørsmålet.

En nåbar listener er ikke det samme som en tilgjengelig applikasjon. Sjekk TLS-sertifikatet og protokollpolicyen, deretter applikasjonens egen autentisering og autorisasjon. Et internt verktøy som godtar enhver som ringer inn på bedrifts-VPN-et, er eksponert for enhver kompromittert bærbar PC på det VPN-et, noe som er en annen risiko enn en internettvendt, men fortsatt en risiko.

Husk at kontroller varierer etter type. Brannmurer i applikasjonslaget henger på én lastbalansererfamilie og ikke den andre, så bekreft hva som faktisk er tilgjengelig for skjemaet og typen foran deg i stedet for å anta likhet.

Trinn fem: avgjør om navnet i seg selv betyr noe

Offentlig oppløsbarhet kan avsløre et tjenestenavn, en region og et adresseområde. Behandle det som et spørsmål om informasjonsavsløring med et policysvar, ikke som en automatisk hendelse: hold følsomme forretningstermer utenfor ressursnavn, og noter avsløringen i risikoregisteret ditt hvis navngivningskonvensjonen avslører mer enn du ønsker.

Hvis organisasjonen ønsker en privat navngivingsopplevelse, kan en privat hostet sone levere et alias som bare løses innenfor de tilknyttede VPC-ene. Det endrer navnet brukerne ser; det gjør ikke det leverandørgenererte navnet hemmelig, og det fjerner ingen nettverkssti.

Ikke prøv å feste adresser for å skjule svaret. Lastbalansereradresser endres, festing ødelegger TLS-valideringsvaner, og kontrollen du faktisk trenger, er hvem som kan opprette forbindelsen og hva applikasjonen krever av dem. Sjekk de fire faktaene, skriv dem ned, og spørsmålet er ikke lenger tvetydig.