Intern ALB med offentligt DNS-navn: er den reelt eksponeret?

Kør et offentligt DNS-opslag mod en intern loadbalancer, og du får måske en privat adresse tilbage, hvilket ligner en fejlkonfiguration, indtil du undersøger, hvad posten er til. AWS dokumenterer, at interne loadbalancer-navne kan være offentligt opløselige, mens deres noder kun har private adresser. Resolveren svarede på, hvor tjenesten er; den oprettede ikke en rute, åbnede ikke en sikkerhedsgruppe og autentificerede ingen. Om svaret er et problem afhænger af fakta, du kan kontrollere i rækkefølge.

Trin et: læs scheme, ikke IP-adressen

Scheme-feltet er loadbalancerens eget udsagn om sin grænse. aws elbv2 describe-load-balancers --names app-internal returnerer Scheme med værdien internal eller internet-facing plus en adressetype til IPv4 eller dual stack. En internetvendt loadbalancer kan stadig videresende til private mål, så synet af private backend-adresser beviser intet om frontenden.

Skriv scheme ned, før du ser på noget andet, fordi hver senere vurdering afhænger af det. Det fortæller også, hvilke kontroller der findes, fra sikkerhedsgrupper og listenerregler til funktionssættet for den type loadbalancer. Et scheme kopieret fra et gammelt konsolskærmbillede er værre end ingen note. Læs det igen fra API'et, og indsæt værdien i billetten.

Trin to: se, hvad navnet opløses til

Forespørg udefra 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 den forventede adfærd for et internt loadbalancer-navn; det er ikke bevis for, at adressen kan routes fra internettet.

Slå det samme navn op inde fra VPC'en, og sammenlign. Hvis de to svar er forskellige, ser du split-horizon-navngivning, og forskellen er en designdetalje, ikke en lækage.

Trin tre: list de stier, der kan nå den

En privat adresse er nåbar fra ethvert sted, hvor der findes en rute og en sikkerhedsregel. Opregn dem bevidst: site-to-site VPN, klient-VPN, VPC-peering, transit gateway-tilkoblinger, Direct Connect og enhver proxy eller bastion inde i VPC'en. En af dem er den tilsigtede sti, og resten er dem, en angriber ville lede efter.

Kontroller derefter kontrollerne på hver sti: sikkerhedsgrupper på loadbalanceren, netværks-ACL'er på undernettene og den routing, der overhovedet skaber stien. De fleste rapporterede sager om en eksponeret intern tjeneste løses her, enten fordi der fandtes en utilsigtet peering, eller fordi stien var tilsigtet, og applikationen ingen autentificering havde.

Trin fire: test listeneren og applikationen hver for sig

Prøv at forbinde fra et netværk, der ikke burde nå tjenesten, og bekræft, at du ikke kan. Prøv derefter fra et, der burde, og bekræft, at du når en listener. De to resultater adskiller netværksnåbarhed fra applikationsadfærd, og de er det eneste bevis, der betyder noget for eksponeringsspørgsmålet.

En nåbar listener er ikke det samme som en tilgængelig applikation. Kontroller TLS-certifikatet og protokolpolitikken, derefter applikationens egen autentificering og autorisation. Et internt værktøj, der accepterer enhver kaldende på virksomhedens VPN, er eksponeret for enhver kompromitteret laptop på det VPN, hvilket er en anden risiko end en internetvendt, men stadig en risiko.

Husk, at kontroller varierer efter type. Firewalls i applikationslaget knytter sig til én loadbalancer-familie og ikke den anden, så bekræft, hvad der reelt er tilgængeligt for det scheme og den type, du har foran dig, i stedet for at antage paritet.

Trin fem: afgør, om navnet i sig selv betyder noget

Offentlig opløselighed kan afsløre et tjenestenavn, en region og et adresseområde. Behandl det som et spørgsmål om informationsafsløring med et politikssvar, ikke som en automatisk hændelse: hold følsomme forretningstermer ude af ressourcenavne, og notér afsløringen i din risikolog, hvis navngivningskonventionen afslører mere, end du ønsker.

Hvis organisationen ønsker en privat navngivningsoplevelse, kan en privat hosted zone levere et alias, der kun opløses i de tilknyttede VPC'er. Det ændrer navnet, brugerne ser; det gør ikke det udbydergenererede navn hemmeligt, og det fjerner ingen netværkssti.

Forsøg ikke at fastlåse adresser for at skjule svaret. Loadbalancer-adresser ændrer sig, fastlåsning bryder TLS-valideringsvaner, og den kontrol, du reelt har brug for, er hvem der kan oprette forbindelsen, og hvad applikationen kræver af dem. Kontroller de fire fakta, skriv dem ned, og spørgsmålet holder op med at være tvetydigt.