Interní ALB s veřejným DNS jménem: je opravdu vystavený?

Spusťte veřejný DNS dotaz na interní nástroj pro vyrovnávání zátěže a můžete dostat zpět privátní adresu, což vypadá jako chybná konfigurace, dokud neprověříte, k čemu záznam slouží. AWS dokumentuje, že jména interních nástrojů mohou být veřejně rozlišitelná, i když jejich uzly drží jen privátní adresy. Resolver odpověděl, kde služba je; nevytvořil trasu, neotevřel bezpečnostní skupinu ani nikoho neautentizoval. Zda je tato odpověď problém, závisí na faktech, která můžete prověřit popořadě.

Krok první: čtěte schéma, ne IP

Pole schématu je vlastní tvrzení nástroje o jeho hranici. aws elbv2 describe-load-balancers --names app-internal vrací Scheme s hodnotou internal nebo internet-facing, plus typ adresy pro IPv4 nebo duální zásobník. Nástroj obrácený do internetu může přesto předávat na privátní cíle, takže pohled na privátní adresy backendu nic nedokazuje o front endu.

Zapište schéma, než se podíváte na cokoli jiného, protože na něm závisí každé další posouzení. Říká také, jaké kontroly existují, od bezpečnostních skupin a pravidel listeneru po sadu funkcí daného typu nástroje. Schéma zkopírované ze starého snímku konzole je horší než žádná poznámka. Přečtěte je znovu z API a vložte hodnotu do tiketu.

Krok druhý: podívejte se, na co se jméno překládá

Dotazujte se zvenčí VPC pomocí dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com a poznamenejte, zda odpovědi leží v 10.0.0.0/8, 172.16.0.0/12 nebo 192.168.0.0/16. Privátní odpověď z veřejného resolveru je očekávané chování pro jméno interního nástroje; není to důkaz, že adresa je směrovatelná z internetu.

Vyřešte stejné jméno zevnitř VPC a porovnejte. Pokud se obě odpovědi liší, díváte se na split-horizon pojmenování a tento rozdíl je detail návrhu, ne únik.

Krok třetí: vypište cesty, které se k němu mohou dostat

Privátní adresa je dostupná odkudkoli, kde existuje trasa a bezpečnostní pravidlo. Vyjmenujte je záměrně: VPN mezi lokalitami, klientská VPN, VPC peering, připojení transit gateway, Direct Connect a jakýkoli proxy nebo bastion uvnitř VPC. Jedna z nich je zamýšlená cesta a ostatní jsou ty, které by hledal útočník.

Pak zkontrolujte kontroly na každé cestě: bezpečnostní skupiny na nástroji, síťové ACL na podsítích a směrování, které cestu vůbec vytváří. Většina hlášených případů vystavené interní služby se řeší tady, buď existoval nezamýšlený peering, nebo byla cesta zamýšlená a aplikace neměla autentizaci.

Krok čtvrtý: testujte listener a aplikaci odděleně

Zkuste se připojit ze sítě, která by ke službě neměla dosáhnout, a potvrďte, že nemůžete. Pak zkuste ze sítě, která by měla, a potvrďte, že se dostanete k listeneru. Tyto dva výsledky oddělují síťovou dosažitelnost od chování aplikace a jsou jediným důkazem, který u otázky vystavení záleží.

Dosažitelný listener není totéž co přístupná aplikace. Zkontrolujte TLS certifikát a politiku protokolu, potom vlastní autentizaci a autorizaci aplikace. Interní nástroj, který přijímá každého volajícího na firemní VPN, je vystaven každému kompromitovanému notebooku na této VPN, což je jiné riziko než internetové vystavení, ale pořád riziko.

Pamatujte, že kontroly se liší podle typu. Firewally aplikační vrstvy se připojují k jedné rodině nástrojů a ne k druhé, takže si potvrďte, co je pro schéma a typ před vámi skutečně dostupné, místo abyste předpokládali shodu.

Krok pátý: rozhodněte, zda na samotném jménu záleží

Veřejná rozlišitelnost může prozradit jméno služby, region a rozsah adres. Berte to jako otázku úniku informací s politickou odpovědí, ne jako automatický incident: držte citlivé obchodní termíny mimo jména prostředků a poznamenejte prozrazení do registru rizik, pokud konvence pojmenování odhaluje víc, než chcete.

Pokud organizace chce privátní pojmenování, privátní hostovaná zóna může sloužit alias, který se rozlišuje jen v přidružených VPC. To mění jméno, které uživatelé vidí; nečiní jméno generované poskytovatelem tajným a neodstraňuje žádnou síťovou cestu.

Nesnažte se adresy připnout, abyste odpověď skryli. Adresy nástroje se mění, připnutí kazí návyky validace TLS a kontrola, kterou skutečně potřebujete, je kdo může navázat spojení a co po něm aplikace vyžaduje. Prověřte čtyři fakta, zapište je a otázka přestane být nejednoznačná.