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 dokumentuje 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 autentifikovao. Da li je taj odgovor problem zavisi od činjenica koje možete provjeriti po redu.

Prvi korak: čitajte šemu, ne IP

Polje šeme je vlastita izjava balansera o njegovoj granici. aws elbv2 describe-load-balancers --names app-internal vraća Scheme sa vrijednošću internal ili internet-facing, plus tip adrese za IPv4 ili dvostruki stek. Balanser okrenut internetu ipak može prosljeđivati na privatne ciljeve, pa viđanje privatnih backend adresa ništa ne dokazuje o front endu.

Zapišite šemu prije nego što pogledate bilo šta drugo, jer svaka kasnija procjena zavisi od nje. Ona takođe govori koje kontrole postoje, od sigurnosnih grupa i pravila listenera do skupa funkcija tog tipa balansera. Šema kopirana sa stare snimke konzole gora je od nikakve bilješke. Ponovo je pročitajte iz API-ja i zalijepite vrijednost u tiket.

Drugi korak: pogledajte u šta se ime razrješava

Upitajte izvan VPC-a pomoću dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com i zabilježite da li su 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 uporedite. 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 je dostupna svuda 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šte 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 trebalo da dosegne uslugu i potvrdite da ne možete. Zatim pokušajte s one koja bi trebalo 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 prihvata svakog pozivatelja na korporativnom VPN-u izložen je svakom kompromitovanom laptopu na tom VPN-u, što je drugačiji rizik od internet-izloženog, ali i dalje rizik.

Zapamtite da se kontrole razlikuju po tipu. Zaštitni zidovi aplikacijskog sloja priključuju se na jednu familiju balansera, a ne na drugu, pa potvrdite šta je zaista dostupno za šemu i tip pred vama umjesto da pretpostavljate jednakost.

Peti korak: odlučite da li samo ime ima značaja

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 hostovana 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 generiše provajder 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 zaista treba jeste ko može uspostaviti vezu i šta aplikacija od njih zahtijeva. Provjerite četiri činjenice, zapišite ih i pitanje prestaje biti dvosmisleno.

Povezani članci