Panloob na ALB na may pampublikong DNS name: talaga bang nakalantad?

Magpatakbo ng pampublikong DNS lookup laban sa panloob na load balancer at maaaring makakuha ka ng pribadong address pabalik, na mukhang maling configuration hanggang suriin mo kung para saan ang record. Idinodokumento ng AWS na ang mga pangalan ng panloob na load balancer ay maaaring pampublikong maresolba habang ang kanilang mga node ay may mga pribadong address lamang. Sinagot ng resolver kung saan ang serbisyo; hindi ito gumawa ng ruta, hindi nagbukas ng security group at hindi nag-authenticate ng kahit sino. Kung ang sagot na iyon ay problema ay depende sa mga faktang masusuri mo sa pagkakasunod-sunod.

Unang hakbang: basahin ang scheme, hindi ang IP

Ang field ng scheme ay ang sariling pahayag ng load balancer tungkol sa hangganan nito. Nagbabalik ang aws elbv2 describe-load-balancers --names app-internal ng Scheme na may halagang internal o internet-facing, kasama ang uri ng address para sa IPv4 o dual stack. Maaari pa ring mag-forward ang load balancer na nakaharap sa internet sa mga pribadong target, kaya ang pagtingin sa mga pribadong backend address ay walang pinapatunayan tungkol sa harap.

Isulat ang scheme bago tumingin sa anupaman, dahil nakasalalay rito ang bawat susunod na paghatol. Sinasabi rin nito kung aling mga kontrol ang umiiral, mula sa mga security group at patakaran ng listener hanggang sa set ng feature ng uri ng load balancer na iyon. Ang scheme na kinopya mula sa lumang screenshot ng console ay mas masama kaysa walang tala. Basahin itong muli mula sa API at i-paste ang halaga sa ticket.

Ikalawang hakbang: tingnan kung saan nagre-resolve ang pangalan

Magtanong mula sa labas ng VPC gamit ang dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com at tandaan kung ang mga sagot ay nasa 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16. Ang pribadong sagot mula sa pampublikong resolver ay ang inaasahang pag-uugali para sa pangalan ng panloob na load balancer; hindi ito patunay na ang address ay naruruta mula sa internet.

I-resolba ang parehong pangalan mula sa loob ng VPC at ihambing. Kung magkaiba ang dalawang sagot, nakikita mo ang split-horizon na pagpapangalan, at ang pagkakaibang iyon ay detalye ng disenyo, hindi pagtagas.

Ikatlong hakbang: ilahad ang mga landas na makakaabot dito

Ang pribadong address ay naaabot mula saanman may ruta at patakaran ng seguridad. Ilahad ang mga ito nang sinasadya: site-to-site VPN, client VPN, VPC peering, mga attachment ng transit gateway, Direct Connect at anumang proxy o bastion sa loob ng VPC. Isa sa kanila ang nilalayong landas, at ang natitira ay ang hahanapin ng isang attacker.

Pagkatapos suriin ang mga kontrol sa bawat landas: mga security group sa load balancer, network ACL sa mga subnet at ang routing na gumagawa sa landas. Karamihan sa mga naiulat na kaso ng nakalantad na panloob na serbisyo ay nalulutas dito, alinman may hindi sinasadyang peering o ang landas ay sinadya at walang authentication ang application.

Ikaapat na hakbang: subukan ang listener at application nang hiwalay

Subukang kumonekta mula sa network na hindi dapat maabot ang serbisyo at tiyakin na hindi ka makakaya. Pagkatapos subukan mula sa dapat, at tiyakin na naaabot mo ang isang listener. Ang dalawang resultang iyon ay naghihiwalay ng maabot ng network mula sa pag-uugali ng application, at sila ang tanging ebidensyang mahalaga sa tanong ng pagkalantad.

Ang naaabot na listener ay hindi kapareho ng naa-access na application. Suriin ang TLS certificate at patakaran ng protocol, pagkatapos ang authentication at authorization ng application mismo. Ang panloob na tool na tumatanggap ng sinumang tumatawag sa corporate VPN ay nakalantad sa bawat compromised na laptop sa VPN na iyon, na ibang panganib kaysa sa nakaharap sa internet ngunit panganib pa rin.

Tandaan na nagkakaiba ang mga kontrol ayon sa uri. Ang mga firewall sa application layer ay nakakabit sa isang pamilya ng load balancer at hindi sa isa pa, kaya tiyakin kung ano ang talagang available para sa scheme at uri sa harap mo sa halip na ipagpalagay ang pagkakapantay.

Ikalimang hakbang: magpasya kung mahalaga ang pangalan mismo

Ang pampublikong resolvability ay maaaring magbunyag ng pangalan ng serbisyo, rehiyon at hanay ng address. Ituring ito bilang tanong ng pagbubunyag ng impormasyon na may sagot sa patakaran, hindi awtomatikong insidente: ilayo ang sensitibong termino ng negosyo sa mga pangalan ng resource, at itala ang pagbubunyag sa iyong risk record kung ang convention ng pagpapangalan ay nagbubunyag ng higit sa gusto mo.

Kung gusto ng organisasyon ang pribadong karanasan sa pagpapangalan, ang pribadong hosted zone ay maaaring maghatid ng alias na nareresolba lamang sa mga kaugnay na VPC. Binabago nito ang pangalang nakikita ng mga user; hindi nito ginagawang lihim ang pangalang nabuo ng provider at hindi nag-aalis ng anumang landas ng network.

Huwag subukang i-pin ang mga address upang itago ang sagot. Nagbabago ang mga address ng load balancer, sinisira ng pag-pin ang mga ugali ng TLS validation, at ang kontrol na talagang kailangan mo ay kung sino ang makakagawa ng koneksyon at ano ang hinihingi ng application sa kanila. Suriin ang apat na katotohanan, isulat, at hindi na malabo ang tanong.