Sisäinen ALB ja julkinen DNS-nimi: onko se todella altistettu?

Aja julkinen DNS-kysely sisäistä kuormantasaajaa vastaan, ja saatat saada takaisin yksityisen osoitteen, mikä näyttää väärältä määritykseltä, kunnes tarkistat, mitä varten tietue on. AWS dokumentoi, että sisäisten kuormantasaajien nimet voivat olla julkisesti ratkaistavissa, vaikka niiden solmut pitävät vain yksityisiä osoitteita. Resolveri vastasi, missä palvelu on; se ei luonut reittiä, avannut tietoturvaryhmää eikä todentanut ketään. Onko vastaus ongelma, riippuu faktoista, jotka voit tarkistaa järjestyksessä.

Vaihe yksi: lue skeema, älä IP

Skeemakenttä on kuormantasaajan oma lausunto rajastaan. aws elbv2 describe-load-balancers --names app-internal palauttaa Scheme-arvon internal tai internet-facing sekä osoitetyypin IPv4:lle tai kaksoispinolle. Internettiin suuntautuva kuormantasaaja voi silti välittää yksityisille kohteille, joten yksityisten backend-osoitteiden näkeminen ei todista mitään etuosasta.

Kirjoita skeema muistiin ennen kuin katsot mitään muuta, koska jokainen myöhempi arvio riippuu siitä. Se kertoo myös, mitkä kontrollit ovat olemassa, tietoturvaryhmistä ja listener-säännöistä kyseisen kuormantasaajatyypin ominaisuuksiin. Vanhasta konsolin kuvakaappauksesta kopioitu skeema on huonompi kuin ei mitään muistiinpanoa. Lue se uudelleen API:sta ja liitä arvo tikettiin.

Vaihe kaksi: katso, mihin nimi ratkeaa

Kysy VPC:n ulkopuolelta komennolla dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com ja merkitse, ovatko vastaukset osoiteavaruudessa 10.0.0.0/8, 172.16.0.0/12 vai 192.168.0.0/16. Yksityinen vastaus julkiselta resolverilta on odotettu käytös sisäisen kuormantasaajan nimelle; se ei ole todiste siitä, että osoite olisi reititettävissä internetistä.

Ratkaise sama nimi VPC:n sisältä ja vertaa. Jos vastaukset eroavat, kyseessä on split-horizon-nimeäminen, ja ero on suunnitteluyksityiskohta, ei vuoto.

Vaihe kolme: luettele polut, jotka voivat päästä siihen

Yksityinen osoite on saavutettavissa kaikkialta, missä on reitti ja tietoturvasääntö. Luettele ne tarkoituksella: site-to-site-VPN, asiakas-VPN, VPC-peering, transit gateway -liitännät, Direct Connect sekä mikä tahansa proxy tai bastion VPC:n sisällä. Yksi niistä on aiottu polku, ja loput ovat niitä, joita hyökkääjä etsisi.

Tarkista sitten kunkin polun kontrollit: tietoturvaryhmät kuormantasaajalla, verkon ACL:t aliverkoilla ja reititys, joka ylipäätään luo polun. Useimmat raportoidut altistuneen sisäisen palvelun tapaukset ratkeavat tässä, joko siksi, että oli tahaton peering, tai siksi, että polku oli tarkoitettu ja sovelluksella ei ollut todennusta.

Vaihe neljä: testaa listener ja sovellus erikseen

Yritä yhdistää verkosta, jonka ei pitäisi tavoittaa palvelua, ja varmista, ettet pysty. Yritä sitten verkosta, jonka pitäisi, ja varmista, että tavoitat listenerin. Nämä kaksi tulosta erottavat verkon saavutettavuuden sovelluksen käyttäytymisestä, ja ne ovat ainoa todiste, jolla on merkitystä altistumiskysymyksessä.

Saavutettavissa oleva listener ei ole sama kuin käytettävissä oleva sovellus. Tarkista TLS-varmente ja protokollakäytäntö, sitten sovelluksen oma todennus ja valtuutus. Sisäinen työkalu, joka hyväksyy jokaisen soittajan yrityksen VPN:ssä, on altistettu jokaiselle siinä VPN:ssä kompromissoidulle kannettavalle, mikä on eri riski kuin internettiin suuntautuva, mutta silti riski.

Muista, että kontrollit vaihtelevat tyypin mukaan. Sovelluskerroksen palomuurit liittyvät yhteen kuormantasaajaperheeseen eivätkä toiseen, joten varmista, mitä edessäsi olevan skeeman ja tyypin kohdalla on todella saatavilla, sen sijaan että olettaisit samanlaisuutta.

Vaihe viisi: päätä, onko nimellä itsellään merkitystä

Julkinen ratkaistavuus voi paljastaa palvelun nimen, alueen ja osoitealueen. Käsittele sitä käytäntövastauksella varustettuna tietojen paljastamiskysymyksenä, älä automaattisena tapahtumana: pidä arkaluontoiset liiketoimintatermit poissa resurssien nimistä ja kirjaa paljastuminen riskirekisteriisi, jos nimeämiskäytäntö paljastaa enemmän kuin haluat.

Jos organisaatio haluaa yksityisen nimeämiskokemuksen, yksityinen ylläpidetty vyöhyke voi tarjota aliaksen, joka ratkeaa vain liitetyissä VPC:issä. Se muuttaa nimeä, jonka käyttäjät näkevät; se ei tee palveluntarjoajan luomaa nimeä salaiseksi eikä poista mitään verkkopolkua.

Älä yritä kiinnittää osoitteita vastauksen piilottamiseksi. Kuormantasaajan osoitteet muuttuvat, kiinnittäminen rikkoo TLS-validoinnin tottumuksia, ja kontrolli, jota todella tarvitset, on kuka voi muodostaa yhteyden ja mitä sovellus vaatii heiltä. Tarkista neljä faktaa, kirjoita ne ylös, ja kysymys lakkaa olemasta monitulkintainen.