Intern ALB med offentleg DNS-namn: er han verkeleg eksponert?

Køyr eit offentleg DNS-oppslag mot ein intern lastbalanserar, og du kan få ei privat adresse tilbake, noko som ser ut som ein feilkonfigurasjon til du sjekkar kva oppføringa er for. AWS dokumenterer at interne lastbalanserarnamn kan vere offentleg oppløyselege medan nodane deira berre har private adresser. Resolveren svara kvar tenesta er; han oppretta ikkje ei rute, opna ikkje ei sikkerheitsgruppe og autentiserte ingen. Om svaret er eit problem avheng av fakta du kan sjekke i rekkjefølgje.

Trinn éin: les skjemaet, ikkje IP-en

Skjemafeltet er lastbalanseraren si eiga utsegn om grensa si. aws elbv2 describe-load-balancers --names app-internal returnerer Scheme med verdien internal eller internet-facing, pluss ein adressetype for IPv4 eller dobbel stakk. Ein internettvend lastbalanserar kan framleis videresende til private mål, så synet av private backend-adresser beviser ingenting om frontenden.

Skriv ned skjemaet før du ser på noko anna, fordi kvar seinare vurdering avheng av det. Det fortel òg kva kontrollar som finst, frå sikkerheitsgrupper og listener-reglar til funksjonssettet for den typen lastbalanserar. Eit skjema kopiert frå eit gammalt konsollskjermbilete er verre enn ingen notat. Les det på nytt frå API-et og lim inn verdien i saka.

Trinn to: sjå kva namnet blir løyst opp til

Spør frå utsida av VPC-en med dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com og noter om svara ligg i 10.0.0.0/8, 172.16.0.0/12 eller 192.168.0.0/16. Eit privat svar frå ein offentleg resolver er forventa åtferd for eit internt lastbalanserarnamn; det er ikkje bevis for at adressa kan rutast frå internett.

Løys opp same namn frå innsida av VPC-en og samanlikn. Om dei to svara er ulike, ser du split-horizon-namngjeving, og skilnaden er ein designdetalj, ikkje ein lekkasje.

Trinn tre: list opp stiane som kan nå han

Ei privat adresse er nåbar frå kvar som helst der ei rute og ei sikkerheitsregel finst. List dei opp med vilje: site-til-site-VPN, klient-VPN, VPC-peering, transit gateway-tilkoplingar, Direct Connect og kvar proxy eller bastion inne i VPC-en. Ein av dei er den tiltenkte stien, og resten er dei ein åtakar ville leite etter.

Sjekk deretter kontrollane på kvar sti: sikkerheitsgrupper på lastbalanseraren, nettverks-ACL-ar på subneta og rutinga som gjer at stien i det heile finst. Dei fleste rapporterte tilfelle av eksponert intern teneste blir løyste her, anten fordi det fanst ein utilsikta peering, eller fordi stien var tilsikta og applikasjonen ikkje hadde autentisering.

Trinn fire: test listeneren og applikasjonen kvar for seg

Prøv å kople til frå eit nettverk som ikkje skal nå tenesta, og stadfest at du ikkje kan. Prøv deretter frå eit som skal, og stadfest at du når ein listener. Desse to resultata skil nettverksnåbarheit frå applikasjonsåtferd, og dei er det einaste beviset som tel for eksponeringsspørsmålet.

Ein nåbar listener er ikkje det same som ein tilgjengeleg applikasjon. Sjekk TLS-sertifikatet og protokollpolicyen, deretter applikasjonen si eiga autentisering og autorisasjon. Eit internt verktøy som godtek kven som helst som ringjer inn på bedrifts-VPN-et, er eksponert for kvar kompromittert berbar PC på det VPN-et, noko som er ein annan risiko enn ein internettvend, men framleis ein risiko.

Hugs at kontrollar varierer etter type. Brannmurar i applikasjonslaget heng på éin lastbalanserarfamilie og ikkje den andre, så stadfest kva som faktisk er tilgjengeleg for skjemaet og typen framfor deg i staden for å anta likskap.

Trinn fem: avgjer om namnet i seg sjølv har noko å seie

Offentleg oppløyselegheit kan avdekkje eit tenestenamn, ein region og eit adresseområde. Handsame det som eit spørsmål om informasjonsavdekking med eit policysvar, ikkje som ei automatisk hending: hald sensitive forretningstermar utanfor ressursnamn, og noter avdekkinga i risikoregisteret ditt om namngjevingskonvensjonen avdekkjer meir enn du ønskjer.

Om organisasjonen ønskjer ei privat namngjevingsoppleving, kan ei privat hosta sone levere eit alias som berre blir løyst innanfor dei tilknytte VPC-ane. Det endrar namnet brukarane ser; det gjer ikkje det leverandørgenererte namnet hemmeleg, og det fjernar ingen nettverkssti.

Ikkje prøv å feste adresser for å skjule svaret. Lastbalanseraradresser endrar seg, festing øydelegg TLS-valideringsvanar, og kontrollen du faktisk treng, er kven som kan opprette sambandet og kva applikasjonen krev av dei. Sjekk dei fire fakta, skriv dei ned, og spørsmålet er ikkje lenger tvitydig.