ALB intern cu nume DNS public: este chiar expus?

Rulați o interogare DNS publică către un load balancer intern și puteți primi înapoi o adresă privată, ceea ce pare o configurare greșită până când verificați pentru ce este înregistrarea. AWS documentează că numele load balancerelor interne pot fi rezolvabile public, în timp ce nodurile lor au doar adrese private. Resolverul a răspuns unde este serviciul; nu a creat o rută, nu a deschis un grup de securitate și nu a autentificat pe nimeni. Dacă acel răspuns este o problemă depinde de fapte pe care le puteți verifica în ordine.

Pasul unu: citiți schema, nu IP-ul

Câmpul de schemă este propria declarație a load balancerului despre granița sa. aws elbv2 describe-load-balancers --names app-internal returnează un Scheme cu valoarea internal sau internet-facing, plus un tip de adresă pentru IPv4 sau stivă dublă. Un load balancer orientat spre internet poate totuși redirecționa către ținte private, așa că vederea adreselor private de backend nu dovedește nimic despre partea frontală.

Notați schema înainte de a privi orice altceva, pentru că fiecare judecată ulterioară depinde de ea. Ea spune și ce controale există, de la grupuri de securitate și reguli de listener până la setul de funcții al acelui tip de load balancer. O schemă copiată dintr-o captură veche a consolei este mai rea decât nicio notă. Recitiți-o din API și lipiți valoarea în tichet.

Pasul doi: vedeți în ce se rezolvă numele

Interogați din afara VPC cu dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com și notați dacă răspunsurile sunt în 10.0.0.0/8, 172.16.0.0/12 sau 192.168.0.0/16. Un răspuns privat de la un resolver public este comportamentul așteptat pentru un nume de load balancer intern; nu este dovada că adresa este rutabilă din internet.

Rezolvați același nume din interiorul VPC și comparați. Dacă cele două răspunsuri diferă, vedeți denumire split-horizon, iar diferența este un detaliu de proiectare, nu o scurgere.

Pasul trei: enumerați căile care pot ajunge la el

O adresă privată este accesibilă oriunde există o rută și o regulă de securitate. Enumerați-le deliberat: VPN site-to-site, VPN de client, VPC peering, conexiuni transit gateway, Direct Connect și orice proxy sau bastion din VPC. Una dintre ele este calea dorită, iar restul sunt cele pe care le-ar căuta un atacator.

Apoi verificați controalele pe fiecare cale: grupuri de securitate pe load balancer, ACL de rețea pe subrețele și rutarea care face calea să existe. Majoritatea cazurilor raportate de serviciu intern expus se rezolvă aici, fie pentru că exista un peering neintenționat, fie pentru că calea era intenționată și aplicația nu avea autentificare.

Pasul patru: testați listenerul și aplicația separat

Încercați să vă conectați dintr-o rețea care nu ar trebui să ajungă la serviciu și confirmați că nu puteți. Apoi încercați dintr-una care ar trebui, și confirmați că ajungeți la un listener. Aceste două rezultate separă accesibilitatea rețelei de comportamentul aplicației și sunt singura dovadă care contează pentru întrebarea expunerii.

Un listener accesibil nu este același lucru cu o aplicație accesibilă. Verificați certificatul TLS și politica de protocol, apoi autentificarea și autorizarea aplicației în sine. Un instrument intern care acceptă orice apelant în VPN-ul corporativ este expus fiecărui laptop compromis din acel VPN, ceea ce este un risc diferit de unul orientat spre internet, dar tot un risc.

Amintiți-vă că controalele diferă în funcție de tip. Firewall-urile de nivel aplicație se atașează unei familii de load balancere și nu celeilalte, așa că confirmați ce este disponibil efectiv pentru schema și tipul din fața dumneavoastră în loc să presupuneți egalitate.

Pasul cinci: decideți dacă numele în sine contează

Rezolvabilitatea publică poate dezvălui un nume de serviciu, o regiune și un interval de adrese. Tratați asta ca o întrebare de divulgare de informații cu răspuns de politică, nu ca un incident automat: țineți termenii de afaceri sensibili în afara numelor de resurse și notați divulgarea în registrul de risc dacă convenția de denumire dezvăluie mai mult decât doriți.

Dacă organizația dorește o experiență privată de denumire, o zonă găzduită privată poate servi un alias care se rezolvă doar în VPC-urile asociate. Aceasta schimbă numele pe care îl văd utilizatorii; nu face secret numele generat de furnizor și nu elimină nicio cale de rețea.

Nu încercați să fixați adrese pentru a ascunde răspunsul. Adresele load balancerului se schimbă, fixarea strică obiceiurile de validare TLS, iar controlul de care aveți cu adevărat nevoie este cine poate stabili conexiunea și ce cere aplicația de la el. Verificați cele patru fapte, notați-le, iar întrebarea nu mai este ambiguă.