Pengerasan VPN Windows: perbaiki autentikasi sebelum tunnel

Server VPN Windows Anda meminta nama pengguna dan kata sandi, dan satu kotak dialog itu menyembunyikan tiga tugas yang tidak saling terkait. Satu membuktikan siapa orangnya, satu mencegah seseorang yang mengamati kabel memakai ulang bukti itu, dan satu menentukan alamat mana yang boleh dijangkau sesudahnya. Sebagian besar penerapan kecil mengeraskan tunnel lebih dulu dan membiarkan dua tugas pertama pada nilai bawaannya, dan itu urutan yang salah.

Bekerjalah dalam urutan yang dipakai penyerang. Pertama, apa yang dapat ditangkap dari kabel. Lalu, apa yang dapat diputar ulang nanti dengan rekaman itu. Terakhir, apa yang dapat dicapai penyerang yang sudah terautentikasi setelah masuk.

Tiga tugas, satu kotak dialog

Identitas adalah bagian yang dipikirkan orang, dan itu hanya sepertiga masalah. Bukti identitas harus bertahan terhadap pengamat yang merekam pertukaran dan mencoba lagi nanti. Otorisasi adalah keputusan terpisah yang diambil server setelah identitas dipastikan, dan Windows menyimpannya di layanan yang berbeda dari layanan yang memvalidasi kredensial.

Ketika ketiganya hidup dalam satu ember mental, hasil biasanya adalah server yang mengautentikasi dengan kuat lalu mengizinkan pengguna menjangkau segala hal. Memperbaikinya nanti lebih sulit daripada memutuskan kebijakan sekarang, karena saat itu profil firewall, kumpulan alamat, dan rute semuanya sudah mengodekan asumsi lama.

Pisahkan ketiganya dalam catatan Anda sebelum menyentuh pengaturan apa pun, lalu perbaiki dari mata rantai terlemah ke atas.

Mengapa MS-CHAPv2 tidak lolos uji pemutaran ulang

Jika server masih menerima PPTP dengan MS-CHAPv2, tunnel tidak melindungi kata sandi dalam arti yang berarti. Tantangan dan responsnya dapat ditangkap dan diserang secara luring, dan pada 2012 sebuah layanan pemecah publik menunjukkan pemulihan dari jabat tangan semacam itu dalam sekitar satu hari untuk kata sandi biasa. Kata sandi yang lebih panjang dan rumit menaikkan biaya; itu tidak menghilangkan bahan yang dibutuhkan penyerang dari jaringan.

Properti yang Anda inginkan adalah kredensial yang tidak dapat diputar ulang. EAP-TLS dengan sertifikat klien memberi setiap perangkat identitasnya sendiri dan memungkinkan Anda mencabut tepat satu perangkat.

Menerapkan sertifikat adalah pekerjaan nyata: CA privat, jalur pencabutan yang diperiksa klien, dan rencana pembaruan yang bertahan terhadap pergantian staf. Perlakukan pekerjaan itu sebagai proyek, bukan sebagai penghalang antara Anda dan tunnel yang berfungsi. Anggarkan untuknya seperti Anda menganggarkan penggantian firewall. Kata sandi bersama hanya lebih murah sampai pencabutan pertama.

Kunci yang dibagikan sebelumnya mengautentikasi pasangan, bukan orangnya

L2TP/IPsec dengan kunci yang dibagikan sebelumnya membuktikan bahwa dua gateway mengetahui rahasia yang sama. Itu tidak mengatakan apa pun tentang siapa orang yang terhubung, dan tidak dapat membedakan satu karyawan dari yang lain pada lapisan itu. Gunakan nilai acak yang panjang, jauh melewati sepuluh karakter yang disarankan sebagian panduan, karena siapa pun yang menangkap jabat tangan dapat menyerang kunci itu secara luring.

Setiap klien pada profil itu berbagi rahasia, jadi mengeluarkan satu orang berarti membagikannya ulang kepada semua yang tersisa. Pertahankan langkah autentikasi pengguna terpisah di atas rahasia tingkat mesin, dan beralihlah ke sertifikat seiring bertambahnya populasi klien. Kunci yang dibagikan sebelumnya digabung dengan MS-CHAPv2 adalah dua lapisan lemah, dan yang kedua membatalkan yang pertama.

Otorisasi berada di Network Policy Server

NPS di Windows memutuskan siapa yang boleh terhubung, dan melakukannya setelah autentikasi sudah berhasil. Pemisahan itu adalah kontrol pengerasan paling berguna dalam produk ini, dan banyak penerapan membiarkannya tak tersentuh.

Gunakan kondisi kebijakan yang mencerminkan batasan nyata: keanggotaan grup, jendela waktu ketika dukungan berisi staf, dan status perangkat dari pemeriksaan kesehatan. Tambahkan faktor kedua di tempat data membenarkan gesekan itu, dan ingat bahwa kebijakan dievaluasi per percobaan koneksi, yang menjadikannya kontrol hidup dan bukan dokumen.

Akuntansi RADIUS juga memberi Anda satu catatan tentang siapa yang terhubung dan kapan. Log itu adalah perbedaan antara tinjauan insiden dan dugaan, dan log itu ada entah ada yang membacanya atau tidak.

Batasi apa yang dapat dijangkau oleh login yang berhasil

Adaptor VPN seharusnya mendarat di profil firewall yang mengizinkan layanan yang dibutuhkan perannya, bukan seluruh subnet. Persoalan perutean terpisah dari penyaringan. Tunnel penuh melindungi perangkat klien dan mendorong setiap bita melalui uplink Anda, sedangkan tunnel terpisah menjaga lalu lintas lokal tetap lokal dan memaparkan perangkat ke jaringan mana pun tempat ia berada.

Tidak ada dari kedua pilihan itu yang merupakan bawaan keamanan. Keduanya perlu dituliskan di samping profil firewall yang mereka asumsikan.

Verifikasi jalur kegagalan

Uji apa yang seharusnya rusak: kata sandi salah, sertifikat kedaluwarsa, perangkat dicabut, pengguna di luar grup. Masing-masing harus gagal pada titik yang berbeda, dan log harus menyebut yang mana. Jalankan rangkaian itu pada akun uji lebih dulu, lalu ulangi untuk pengguna sungguhan. Penolakan yang masuk ke log peristiwa tanpa alasan layak diperbaiki jauh sebelum Anda membutuhkan catatan itu.

Lalu pastikan port mana yang dipublikasikan dan mengapa. PPTP membutuhkan TCP 1723 dan GRE sebagai protokol IP, bukan port, IKEv2 membutuhkan UDP 500 dan 4500, dan L2TP membutuhkan UDP 1701 plus IPsec. Mengekspos antarmuka manajemen agar klien dapat terhubung bukan perbaikan, melainkan insiden kedua yang menunggu ditemukan.

Terakhir, putuskan apa yang dicatat server dan untuk berapa lama. Titik akhir tanpa riwayat autentikasi tidak dapat menjawab pertanyaan pertama setelah insiden, yaitu apakah percobaan itu pernah diotorisasi.