Intern ALB med offentligt DNS-namn: är den verkligen exponerad?

Kör en offentlig DNS-fråga mot en intern lastbalanserare och du kan få en privat adress tillbaka, vilket ser ut som en felkonfiguration tills du kontrollerar vad posten är till för. AWS dokumenterar att namn på interna lastbalanserare kan vara offentligt upplösbara medan deras noder bara har privata adresser. Resolvern svarade var tjänsten finns; den skapade ingen rutt, öppnade ingen säkerhetsgrupp och autentiserade ingen. Om svaret är ett problem beror på fakta du kan kontrollera i ordning.

Steg ett: läs schemat, inte IP-adressen

Schemafältet är lastbalanserarens eget uttalande om sin gräns. aws elbv2 describe-load-balancers --names app-internal returnerar Scheme med värdet internal eller internet-facing, plus en adresstyp för IPv4 eller dubbel stack. En internetvänd lastbalanserare kan fortfarande vidarebefordra till privata mål, så synen av privata backend-adresser bevisar ingenting om frontend.

Skriv ner schemat innan du tittar på något annat, eftersom varje senare bedömning beror på det. Det berättar också vilka kontroller som finns, från säkerhetsgrupper och lyssnarregler till funktionsuppsättningen för den typen av lastbalanserare. Ett schema kopierat från en gammal konsolskärmbild är sämre än ingen anteckning. Läs det igen från API:et och klistra in värdet i ärendet.

Steg två: se vad namnet löses upp till

Fråga från utanför VPC:n med dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com och notera om svaren ligger i 10.0.0.0/8, 172.16.0.0/12 eller 192.168.0.0/16. Ett privat svar från en offentlig resolver är förväntat beteende för ett internt lastbalanserarnamn; det är inte bevis för att adressen är routbar från internet.

Lös upp samma namn inifrån VPC:n och jämför. Om de två svaren skiljer sig ser du split-horizon-namngivning, och skillnaden är en designdetalj, inte en läcka.

Steg tre: lista vägarna som kan nå den

En privat adress är nåbar varhelst en rutt och en säkerhetsregel finns. Lista dem medvetet: site-to-site-VPN, klient-VPN, VPC-peering, transit gateway-anslutningar, Direct Connect och vilken proxy eller bastion som helst inne i VPC:n. En av dem är den avsedda vägen, och resten är de som en angripare skulle leta efter.

Kontrollera sedan kontrollerna på varje väg: säkerhetsgrupper på lastbalanseraren, nätverks-ACL:er på subnäten och routningen som gör att vägen överhuvudtaget finns. De flesta rapporterade fall av exponerad intern tjänst löses här, antingen för att det fanns en oavsiktlig peering eller för att vägen var avsedd och applikationen saknade autentisering.

Steg fyra: testa lyssnaren och applikationen var för sig

Försök ansluta från ett nätverk som inte borde nå tjänsten och bekräfta att du inte kan. Försök sedan från ett som borde, och bekräfta att du når en lyssnare. Dessa två resultat skiljer nätverksnåbarhet från applikationsbeteende, och de är det enda beviset som spelar roll för exponeringsfrågan.

En nåbar lyssnare är inte samma sak som en tillgänglig applikation. Kontrollera TLS-certifikatet och protokollpolicyn, sedan applikationens egen autentisering och auktorisering. Ett internt verktyg som accepterar varje anropare på företagets VPN är exponerat för varje komprometterad bärbar dator på det VPN:et, vilket är en annan risk än en internetvänd, men fortfarande en risk.

Kom ihåg att kontroller varierar beroende på typ. Brandväggar på applikationslagret hänger på en lastbalanserarfamilj och inte den andra, så bekräfta vad som faktiskt är tillgängligt för schemat och typen framför dig i stället för att anta likhet.

Steg fem: avgör om själva namnet spelar roll

Offentlig upplösbarhet kan avslöja ett tjänstenamn, en region och ett adressintervall. Behandla det som en fråga om informationsavslöjande med ett policysvar, inte som en automatisk incident: håll känsliga affärstermer utanför resursnamn, och notera avslöjandet i ditt riskregister om namngivningskonventionen avslöjar mer än du vill.

Om organisationen vill ha en privat namngivningsupplevelse kan en privat hostad zon leverera ett alias som bara löses upp inom de associerade VPC:erna. Det ändrar namnet användare ser; det gör inte det leverantörsgenererade namnet hemligt och tar inte bort någon nätverksväg.

Försök inte fästa adresser för att dölja svaret. Lastbalanserarens adresser ändras, fästande bryter TLS-valideringsvanor, och kontrollen du faktiskt behöver är vem som kan upprätta anslutningen och vad applikationen kräver av dem. Kontrollera de fyra fakta, skriv ner dem, och frågan är inte längre tvetydig.