ALB dalaman dengan nama DNS awam: adakah ia benar-benar terdedah?
Penyelesai awam boleh memulangkan alamat peribadi untuk penyeimbang beban AWS dalaman. Semak skema, laluan dan pendengar sebelum mengisytiharkannya terdedah.
Jalankan carian DNS awam terhadap penyeimbang beban dalaman dan anda mungkin mendapat alamat peribadi kembali, yang kelihatan seperti salah konfigurasi sehingga anda menyemak untuk apa rekod itu. AWS mendokumentasikan bahawa nama penyeimbang beban dalaman boleh diselesaikan secara awam walaupun nodnya hanya menyimpan alamat peribadi. Penyelesai menjawab di mana perkhidmatan itu; ia tidak mencipta laluan, tidak membuka kumpulan keselamatan dan tidak mengesahkan sesiapa. Sama ada jawapan itu masalah bergantung pada fakta yang boleh anda semak mengikut urutan.
Langkah satu: baca skema, bukan IP
Medan skema ialah kenyataan penyeimbang beban itu sendiri tentang sempadannya. aws elbv2 describe-load-balancers --names app-internal mengembalikan Scheme dengan nilai internal atau internet-facing, serta jenis alamat untuk IPv4 atau tindanan berganda. Penyeimbang beban yang menghadap internet masih boleh memajukan ke sasaran peribadi, jadi melihat alamat backend peribadi tidak membuktikan apa-apa tentang bahagian hadapan.
Catat skema sebelum melihat apa-apa lagi, kerana setiap penilaian kemudian bergantung padanya. Ia juga memberitahu kawalan mana yang wujud, daripada kumpulan keselamatan dan peraturan pendengar hingga set ciri jenis penyeimbang beban itu. Skema yang disalin daripada tangkapan skrin konsol lama lebih buruk daripada tiada nota. Baca semula daripada API dan tampal nilai ke dalam tiket.
Langkah dua: lihat ke apa nama itu diselesaikan
Tanya dari luar VPC dengan dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com dan catat sama ada jawapannya dalam 10.0.0.0/8, 172.16.0.0/12 atau 192.168.0.0/16. Jawapan peribadi daripada penyelesai awam ialah tingkah laku yang dijangka untuk nama penyeimbang beban dalaman; ia bukan bukti bahawa alamat itu boleh dilalukan dari internet.
Selesaikan nama yang sama dari dalam VPC dan bandingkan. Jika dua jawapan berbeza, anda melihat penamaan split-horizon, dan perbezaan itu ialah butiran reka bentuk, bukan kebocoran.
Langkah tiga: senaraikan laluan yang boleh mencapainya
Alamat peribadi boleh dicapai dari mana-mana sahaja laluan dan peraturan keselamatan wujud. Senaraikannya dengan sengaja: VPN tapak-ke-tapak, VPN klien, peering VPC, lampiran transit gateway, Direct Connect dan mana-mana proksi atau bastion dalam VPC. Salah satunya ialah laluan yang dimaksudkan, dan selebihnya ialah yang akan dicari penyerang.
Kemudian semak kawalan pada setiap laluan: kumpulan keselamatan pada penyeimbang beban, ACL rangkaian pada subnet dan penghalaan yang menjadikan laluan itu wujud. Kebanyakan kes perkhidmatan dalaman terdedah yang dilaporkan diselesaikan di sini, sama ada peering tidak dimaksudkan wujud atau laluan itu dimaksudkan dan aplikasi tiada pengesahan.
Langkah empat: uji pendengar dan aplikasi secara berasingan
Cuba sambung dari rangkaian yang tidak sepatutnya mencapai perkhidmatan dan pastikan anda tidak boleh. Kemudian cuba dari yang sepatutnya, dan pastikan anda mencapai pendengar. Kedua-dua keputusan itu memisahkan ketersampaian rangkaian daripada tingkah laku aplikasi, dan itulah satu-satunya bukti yang penting untuk soalan pendedahan.
Pendengar yang boleh dicapai bukan sama dengan aplikasi yang boleh diakses. Semak sijil TLS dan dasar protokol, kemudian pengesahan dan kebenaran aplikasi itu sendiri. Alat dalaman yang menerima mana-mana pemanggil pada VPN korporat terdedah kepada setiap komputer riba yang terjejas pada VPN itu, yang merupakan risiko berbeza daripada yang menghadap internet tetapi masih risiko.
Ingat bahawa kawalan berbeza mengikut jenis. Tembok api lapisan aplikasi terikat pada satu keluarga penyeimbang beban dan bukan yang lain, jadi sahkan apa yang benar-benar tersedia untuk skema dan jenis di hadapan anda dan bukannya menganggap kesetaraan.
Langkah lima: tentukan sama ada namanya sendiri penting
Kebolehan selesai secara awam boleh mendedahkan nama perkhidmatan, wilayah dan julat alamat. Anggapnya sebagai soalan pendedahan maklumat dengan jawapan dasar, bukan insiden automatik: jauhkan istilah perniagaan sensitif daripada nama sumber, dan catat pendedahan dalam rekod risiko anda jika konvensyen penamaan mendedahkan lebih daripada yang anda mahu.
Jika organisasi mahukan pengalaman penamaan peribadi, zon dihoskan peribadi boleh menyediakan alias yang hanya diselesaikan dalam VPC yang berkaitan. Itu mengubah nama yang dilihat pengguna; ia tidak menjadikan nama yang dijana pembekal sebagai rahsia dan tidak membuang mana-mana laluan rangkaian.
Jangan cuba memakukan alamat untuk menyembunyikan jawapan. Alamat penyeimbang beban berubah, pemakukan merosakkan tabiat pengesahan TLS, dan kawalan yang benar-benar anda perlukan ialah siapa yang boleh membina sambungan dan apa yang aplikasi tuntut daripada mereka. Semak empat fakta, catat, dan soalan itu tidak lagi samar.