Interni ALB s javnim DNS imenom: je li doista izložen?
Javni resolver može vratiti privatne adrese za interni AWS balanser opterećenja. Provjerite shemu, putanje i listener prije nego što ga nazovete izloženim.
Pokrenite javno DNS pretraživanje internog balansera opterećenja i možete dobiti privatnu adresu, što izgleda kao pogrešna konfiguracija dok ne provjerite čemu zapis služi. AWS dokumentira da imena internih balansera mogu biti javno razrješiva dok njihovi čvorovi drže samo privatne adrese. Resolver je odgovorio gdje je usluga; nije stvorio rutu, otvorio sigurnosnu grupu niti ikoga autentificirao. Je li taj odgovor problem zavisi od činjenica koje možete provjeriti redom.
Prvi korak: čitajte shemu, ne IP
Polje sheme vlastita je izjava balansera o njegovoj granici. aws elbv2 describe-load-balancers --names app-internal vraća Scheme s vrijednošću internal ili internet-facing, plus tip adrese za IPv4 ili dvostruki stog. Balanser okrenut internetu ipak može prosljeđivati na privatne ciljeve, pa viđanje privatnih backend adresa ništa ne dokazuje o prednjoj strani.
Zapišite shemu prije nego što pogledate bilo što drugo, jer svaka kasnija prosudba ovisi o njoj. Ona također govori koje kontrole postoje, od sigurnosnih grupa i pravila listenera do skupa značajki tog tipa balansera. Shema kopirana sa stare snimke konzole gora je od nikakve bilješke. Ponovno je pročitajte iz API-ja i zalijepite vrijednost u tiket.
Drugi korak: pogledajte u što se ime razrješava
Upitajte izvan VPC-a pomoću dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com i zabilježite jesu li odgovori u 10.0.0.0/8, 172.16.0.0/12 ili 192.168.0.0/16. Privatan odgovor javnog resolvera očekivano je ponašanje za ime internog balansera; to nije dokaz da je adresa rutabilna s interneta.
Razriješite isto ime unutar VPC-a i usporedite. Ako se dva odgovora razlikuju, gledate split-horizon imenovanje, a ta razlika je detalj dizajna, ne curenje.
Treći korak: nabrojite putanje koje mogu doći do njega
Privatna adresa dostupna je svugdje gdje postoji ruta i sigurnosno pravilo. Nabrojite ih namjerno: VPN od lokacije do lokacije, klijentski VPN, VPC peering, priključci transit gatewaya, Direct Connect i svaki proxy ili bastion unutar VPC-a. Jedan od njih je namjeravana putanja, a ostali su oni koje bi napadač tražio.
Zatim provjerite kontrole na svakoj putanji: sigurnosne grupe na balanseru, mrežne ACL-ove na podmrežama i rutiranje koje uopće stvara putanju. Većina prijavljenih slučajeva izložene interne usluge rješava se ovdje, bilo da je postojao nenamjerni peering ili da je putanja bila namjeravana a aplikacija nije imala autentifikaciju.
Četvrti korak: testirajte listener i aplikaciju odvojeno
Pokušajte se povezati s mreže koja ne bi trebala dosegnuti uslugu i potvrdite da ne možete. Zatim pokušajte s one koja bi trebala i potvrdite da dosežete listener. Ta dva rezultata razdvajaju mrežnu dostupnost od ponašanja aplikacije i jedini su dokaz koji je bitan za pitanje izloženosti.
Dostupan listener nije isto što i pristupačna aplikacija. Provjerite TLS certifikat i politiku protokola, zatim vlastitu autentifikaciju i autorizaciju aplikacije. Interni alat koji prihvaća svakog pozivatelja na korporativnom VPN-u izložen je svakom kompromitiranom prijenosniku na tom VPN-u, što je drugačiji rizik od internet-izloženog, ali i dalje rizik.
Zapamtite da se kontrole razlikuju po tipu. Vatrozidi aplikacijskog sloja priključuju se na jednu obitelj balansera, a ne na drugu, pa potvrdite što je doista dostupno za shemu i tip pred vama umjesto da pretpostavljate jednakost.
Peti korak: odlučite je li samo ime važno
Javna razrješivost može otkriti ime usluge, regiju i raspon adresa. Tretirajte to kao pitanje otkrivanja informacija s odgovorom u politici, a ne kao automatski incident: držite osjetljive poslovne termine izvan imena resursa i zabilježite otkrivanje u registru rizika ako konvencija imenovanja otkriva više nego što želite.
Ako organizacija želi privatno imenovanje, privatna hostana zona može posluživati alias koji se razrješava samo unutar povezanih VPC-ova. To mijenja ime koje korisnici vide; ne čini ime koje generira pružatelj tajnim i ne uklanja nijednu mrežnu putanju.
Ne pokušavajte fiksirati adrese da sakrijete odgovor. Adrese balansera se mijenjaju, fiksiranje kvari navike TLS validacije, a kontrola koja vam doista treba jest tko može uspostaviti vezu i što aplikacija od njih zahtijeva. Provjerite četiri činjenice, zapišite ih i pitanje prestaje biti dvosmisleno.