Belső ALB nyilvános DNS-névvel: valóban szabadon elérhető?

Futtasson nyilvános DNS-lekérdezést egy belső terheléselosztó ellen, és lehet, hogy privát címet kap vissza, ami hibás konfigurációnak tűnik addig, amíg meg nem vizsgálja, mire való a rekord. Az AWS dokumentálja, hogy a belső terheléselosztók nevei nyilvánosan feloldhatók lehetnek, miközben csomópontjaik csak privát címeket tartanak. A feloldó megválaszolta, hol van a szolgáltatás; nem hozott létre útvonalat, nem nyitott biztonsági csoportot és nem hitelesített senkit. Hogy ez a válasz probléma-e, olyan tényektől függ, amelyeket sorrendben ellenőrizhet.

Első lépés: a sémát olvassa, ne az IP-t

A séma mezője a terheléselosztó saját nyilatkozata a határáról. A aws elbv2 describe-load-balancers --names app-internal egy Scheme értéket ad vissza internal vagy internet-facing tartalommal, valamint címtípust IPv4 vagy kettős verem esetén. Az internet felé néző terheléselosztó továbbra is továbbíthat privát célokra, ezért a privát backend címek látványa semmit sem bizonyít az elülső oldalról.

Jegyezze fel a sémát, mielőtt bármi másra nézne, mert minden későbbi ítélet ettől függ. Azt is megmondja, milyen vezérlők léteznek, a biztonsági csoportoktól és listener-szabályoktól az adott terheléselosztó-típus funkciókészletéig. Egy régi konzol-képernyőképről másolt séma rosszabb, mint bármilyen jegyzet hiánya. Olvassa ki újra az API-ból, és illessze be az értéket a jegybe.

Második lépés: nézze meg, mivé oldódik fel a név

Kérdezzen a VPC-n kívülről a dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com segítségével, és figyelje meg, hogy a válaszok a 10.0.0.0/8, 172.16.0.0/12 vagy 192.168.0.0/16 tartományba esnek-e. A nyilvános feloldótól kapott privát válasz a belső terheléselosztó-név várható viselkedése; nem bizonyítja, hogy a cím az internetről irányítható.

Oldja fel ugyanazt a nevet a VPC-n belülről, és hasonlítsa össze. Ha a két válasz eltér, split-horizon névadást lát, és ez a különbség tervezési részlet, nem szivárgás.

Harmadik lépés: sorolja fel az útvonalakat, amelyek elérhetik

A privát cím onnan érhető el, ahol útvonal és biztonsági szabály létezik. Sorolja fel őket szándékosan: site-to-site VPN, kliens VPN, VPC-peering, transit gateway csatlakozások, Direct Connect, valamint bármely proxy vagy bastion a VPC-n belül. Ezek egyike a szándékolt útvonal, a többi pedig az, amit egy támadó keresne.

Ezután ellenőrizze az egyes útvonalak vezérlőit: biztonsági csoportok a terheléselosztón, hálózati ACL-ek az alhálózatokon és az útvonalvezérlés, amely egyáltalán létrehozza az útvonalat. A bejelentett szabadon elérhető belső szolgáltatás esetek többsége itt oldódik meg, vagy nem szándékolt peering létezett, vagy az útvonal szándékolt volt, és az alkalmazásnak nem volt hitelesítése.

Negyedik lépés: tesztelje a listenert és az alkalmazást külön

Próbáljon csatlakozni olyan hálózatról, amelynek nem kellene elérnie a szolgáltatást, és erősítse meg, hogy nem tud. Utána próbálja olyanról, amelynek kellene, és erősítse meg, hogy elér egy listenert. Ez a két eredmény elválasztja a hálózati elérhetőséget az alkalmazás viselkedésétől, és ez az egyetlen bizonyíték, amely a kitettség kérdésében számít.

Egy elérhető listener nem ugyanaz, mint egy hozzáférhető alkalmazás. Ellenőrizze a TLS-tanúsítványt és a protokollszabályzatot, majd az alkalmazás saját hitelesítését és engedélyezését. Egy belső eszköz, amely a vállalati VPN-en bármely hívót elfogadja, ki van téve a VPN minden kompromittált laptopjának, ami más kockázat, mint egy internet felé néző eszközé, de még mindig kockázat.

Ne feledje, hogy a vezérlők típusonként eltérnek. Az alkalmazási réteg tűzfalai az egyik terheléselosztó-családhoz kapcsolódnak, nem a másikhoz, ezért erősítse meg, mi érhető el valójában az előtte lévő séma és típus számára, ahelyett hogy egyenlőséget feltételezne.

Ötödik lépés: döntse el, számít-e maga a név

A nyilvános feloldhatóság felfedhet egy szolgáltatásnevet, egy régiót és egy címtartományt. Kezelje ezt szabályzati válasszal bíró információfelfedési kérdésként, nem automatikus incidensként: tartsa a bizalmas üzleti kifejezéseket az erőforrásneveken kívül, és jegyezze fel a felfedést a kockázati nyilvántartásában, ha a névadási konvenció többet árul el a kívántnál.

Ha a szervezet privát névadási élményt szeretne, egy privát hosztolt zóna olyan aliast szolgálhat ki, amely csak a kapcsolt VPC-ken belül oldódik fel. Ez megváltoztatja a felhasználók által látott nevet; nem teszi titkossá a szolgáltató által generált nevet, és nem távolít el semmilyen hálózati útvonalat.

Ne próbálja rögzíteni a címeket, hogy elrejtse a választ. A terheléselosztó címei változnak, a rögzítés elrontja a TLS-ellenőrzési szokásokat, és a vezérlő, amelyre valóban szüksége van, az, hogy ki tud kapcsolatot létesíteni, és mit követel tőle az alkalmazás. Ellenőrizze a négy tényt, írja le őket, és a kérdés megszűnik kétértelműnek lenni.