Nama VPN privat gagal? Proteksi pengikatan ulang DNS jadi tersangka

Di LAN kantor, nama internal menjawab seketika. Begitu VPN menyala, nama itu berhenti berfungsi, aplikasi melaporkan timeout, dan tunnel sendiri tetap mengalirkan lalu lintas tanpa keluhan. Yang berubah adalah resolver, dan resolver itu punya pendapat sendiri tentang alamat privat.

Proteksi pengikatan ulang ada untuk menghentikan satu trik tertentu. Sebuah nama privat yang sengaja diterbitkan tampak cukup mirip sehingga pertahanan itu menyala.

Baca Jawabannya Sebelum Membaca Kebijakan

Kueri nama itu ke resolver yang benar-benar didorong oleh VPN, bukan resolver yang dipakai laptop Anda di rumah. Bandingkan jawabannya dengan catatan yang Anda harapkan, dan catat apakah balasannya kosong, ditolak, atau penuh alamat publik yang tidak direncanakan siapa pun.

Gejalanya tumpang tindih, jadi bentuk jawabanlah yang menentukan diagnosis. NXDOMAIN berarti catatan tidak ada, REFUSED berarti aturan akses, alamat publik untuk nama internal berarti kesalahan kebijakan atau split-DNS, dan alamat privat yang benar tetapi tidak bisa dipakai klien adalah masalah yang sama sekali berbeda. Koneksi yang ditolak atau permintaan yang macet tidak membuktikan apa pun dengan sendirinya, karena itulah perintah pertama dalam tiket semacam ini seharusnya pencarian nama, bukan memulai ulang. Tuliskan jawabannya sebelum mengubah apa pun.

Apa yang Sebenarnya Dihentikan oleh Pertahanan Itu

Pengikatan ulang DNS bekerja dengan mengubah ke alamat apa sebuah nama diselesaikan setelah klien sudah memercayainya. Sebuah halaman dimuat dari nama yang dikendalikan penyerang, jawabannya berbalik ke alamat privat, dan peramban diperdaya untuk berbicara dengan sesuatu di jaringan lokal yang tidak akan pernah ia terima koneksi langsungnya. Pertahanannya adalah menolak jawaban yang mengarah ke ruang privat ketika resolver tidak pernah diminta melayani ruang nama privat. Asimetri itulah seluruh serangannya.

dnsmasq mendokumentasikan persis perilaku itu, bersama pengecualian per domain. Di halaman manual dnsmasq, rebind-domain-ok dijelaskan sebagai cara menamai domain yang boleh mengembalikan alamat semacam itu secara sah. Bacalah itu sebagai tanda bahwa perbaikan yang dimaksud adalah izin terbatas, bukan sakelar global.

Batasi Pengecualian ke Ruang Nama

Perbaiki dulu ruang namanya, baru pengecualiannya. Pastikan nama yang gagal itu milik domain yang dikendalikan organisasi dan catatannya dipelihara dengan sengaja. Alamat tak terduga yang hanya mirip rentang LAN yang familier justru patut dicurigai, bukan diberi pengecualian, jadi periksa pemilik zona sebelum menulis izin apa pun.

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

Lalu tambahkan izin paling sempit yang mencakup nama yang dimaksud: satu domain, atau satu subdomain yang didelegasikan, di konfigurasi resolver yang dikueri klien VPN. Mematikan proteksi untuk semua nama di resolver itu menghapus pertahanan bagi semuanya sekaligus, termasuk nama yang tidak pernah membutuhkannya.

Split DNS termasuk dalam keputusan yang sama. Jika ruang nama privat seharusnya hanya dijawab di resolver internal, terbitkan di sana dan hentikan kebocorannya ke resolver publik, sehingga pengecualian mencakup satu jalur, bukan setiap jalur.

Uji Ulang Sumber Daya dan Pertahanannya

Kueri lagi, lalu sambungkan ke layanan dan periksa apa yang dilihat klien. Jawaban privat yang benar dengan sesi yang berjalan berarti pengecualiannya berhasil. Jawaban yang benar dengan sesi yang macet berarti rute atau identitas layanan adalah tersangka berikutnya.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

Uji juga nama publik melalui resolver yang sama. Proteksi seharusnya tetap berperilaku untuk nama di luar pengecualian, dan jika pemeriksaan itu gagal, perubahannya lebih luas dari yang dimaksud. Jaga validasi sertifikat tetap utuh sepanjang proses, karena nama yang resolve dengan benar tetap harus cocok dengan sertifikat yang disajikan layanan.

Catat jawaban yang ditolak, domain, resolver, dan siapa pemilik kebijakannya di tiket. Catatan itulah yang mengubah gangguan internal yang misterius menjadi perubahan konfigurasi yang bisa ditinjau seseorang.