ALB internal dengan nama DNS publik: apakah benar-benar terekspos?

Jalankan pencarian DNS publik terhadap load balancer internal dan Anda mungkin mendapat alamat privat kembali, yang tampak seperti kesalahan konfigurasi sampai Anda memeriksa untuk apa catatan itu. AWS mendokumentasikan bahwa nama load balancer internal dapat diresolusikan secara publik sementara node-nya hanya menyimpan alamat privat. Resolver menjawab di mana layanan berada; ia tidak membuat rute, membuka grup keamanan, atau mengautentikasi siapa pun. Apakah jawaban itu masalah bergantung pada fakta yang dapat Anda periksa secara berurutan.

Langkah satu: baca skema, bukan IP

Bidang skema adalah pernyataan load balancer itu sendiri tentang batasnya. aws elbv2 describe-load-balancers --names app-internal mengembalikan Scheme dengan nilai internal atau internet-facing, ditambah tipe alamat untuk IPv4 atau tumpukan ganda. Load balancer yang menghadap internet tetap dapat meneruskan ke target privat, jadi melihat alamat backend privat tidak membuktikan apa pun tentang front end.

Catat skema sebelum melihat hal lain, karena setiap penilaian berikutnya bergantung padanya. Itu juga memberi tahu kontrol apa yang ada, dari grup keamanan dan aturan listener hingga rangkaian fitur tipe load balancer tersebut. Skema yang disalin dari tangkapan layar konsol lama lebih buruk daripada tidak ada catatan. Baca ulang dari API dan tempelkan nilainya ke tiket.

Langkah dua: lihat ke apa nama itu diresolusikan

Kueri dari luar VPC dengan dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com dan catat apakah jawabannya berada di 10.0.0.0/8, 172.16.0.0/12, atau 192.168.0.0/16. Jawaban privat dari resolver publik adalah perilaku yang diharapkan untuk nama load balancer internal; itu bukan bukti bahwa alamat dapat dirutekan dari internet.

Resolusikan nama yang sama dari dalam VPC dan bandingkan. Jika kedua jawaban berbeda, Anda melihat penamaan split-horizon, dan perbedaan itu adalah detail desain, bukan kebocoran.

Langkah tiga: daftar jalur yang bisa mencapainya

Alamat privat dapat dijangkau dari mana pun ada rute dan aturan keamanan. Daftarkan dengan sengaja: VPN situs-ke-situs, VPN klien, peering VPC, lampiran transit gateway, Direct Connect, dan setiap proxy atau bastion di dalam VPC. Salah satunya adalah jalur yang dimaksudkan, dan sisanya adalah jalur yang akan dicari penyerang.

Lalu periksa kontrol pada setiap jalur: grup keamanan pada load balancer, ACL jaringan pada subnet, dan perutean yang membuat jalur itu ada. Sebagian besar kasus layanan internal terekspos yang dilaporkan terselesaikan di sini, entah karena ada peering yang tidak dimaksudkan atau karena jalur itu memang dimaksudkan dan aplikasi tidak memiliki autentikasi.

Langkah empat: uji listener dan aplikasi secara terpisah

Coba hubungkan dari jaringan yang seharusnya tidak menjangkau layanan dan pastikan Anda tidak bisa. Lalu coba dari jaringan yang seharusnya, dan pastikan Anda mencapai listener. Kedua hasil itu memisahkan keterjangkauan jaringan dari perilaku aplikasi, dan itulah satu-satunya bukti yang penting untuk pertanyaan paparan.

Listener yang dapat dijangkau bukan hal yang sama dengan aplikasi yang dapat diakses. Periksa sertifikat TLS dan kebijakan protokol, lalu autentikasi dan otorisasi aplikasi itu sendiri. Alat internal yang menerima pemanggil mana pun di VPN korporat terekspos ke setiap laptop yang disusupi di VPN itu, yang merupakan risiko berbeda dari yang menghadap internet tetapi tetap risiko.

Ingat bahwa kontrol berbeda menurut tipe. Firewall lapisan aplikasi terpasang pada satu keluarga load balancer dan bukan yang lain, jadi pastikan apa yang benar-benar tersedia untuk skema dan tipe di depan Anda alih-alih mengasumsikan kesetaraan.

Langkah lima: putuskan apakah namanya sendiri penting

Keteresolusian publik dapat mengungkap nama layanan, wilayah, dan rentang alamat. Perlakukan itu sebagai pertanyaan pengungkapan informasi dengan jawaban kebijakan, bukan insiden otomatis: jauhkan istilah bisnis sensitif dari nama sumber daya, dan catat pengungkapan itu dalam catatan risiko Anda jika konvensi penamaan mengungkapkan lebih banyak dari yang Anda inginkan.

Jika organisasi menginginkan pengalaman penamaan privat, zona hosted privat dapat menyajikan alias yang hanya diresolusikan di dalam VPC terkait. Itu mengubah nama yang dilihat pengguna; itu tidak membuat nama yang dihasilkan penyedia menjadi rahasia dan tidak menghapus jalur jaringan apa pun.

Jangan mencoba mematok alamat untuk menyembunyikan jawaban. Alamat load balancer berubah, pematokan merusak kebiasaan validasi TLS, dan kontrol yang benar-benar Anda butuhkan adalah siapa yang dapat membangun koneksi dan apa yang aplikasi tuntut dari mereka. Periksa keempat fakta, catat, dan pertanyaannya tidak lagi ambigu.