Mitigasi Blast-RADIUS dengan Proksi ISE: Cara Kekinian Biar Jaringan Tetap Aman
Intro: Lagi Ramai Blast-RADIUS? Yuk, Kita Beresin
Belakangan ini, dunia IT lagi heboh sama isu Blast-RADIUS. Intinya: ada celah di protokol RADIUS klasik (yang umurnya udah puluhan tahun) yang bisa dieksploitasi penyerang untuk “nyamar” jadi server dan mengirimkan Access-Accept palsu. Dampaknya? Perangkat yang seharusnya ketat bisa kebablasan ngasih akses ke orang yang salah. Serem kan?
Kabar baiknya, ada cara praktis buat ngurangin risiko ini tanpa harus nurunin layanan ke user: pakai Cisco ISE (Identity Services Engine) sebagai RADIUS proxy. Di artikel ini, kita bahas konsep, arsitektur, dan langkah implementasinya dengan bahasa yang santai tapi tetap teknis.
Blast-RADIUS Singkatnya: Apa dan Kenapa Bahaya?
– RADIUS klasik pakai MD5 buat proteksi tertentu. MD5 udah lama dianggap lemah.
– Dengan posisi man-in-the-middle (MitM), penyerang bisa “ngacak-acak” paket RADIUS dan bikin Access-Accept palsu.
– Kalau NAD (switch, WLC, VPN gateway) percaya begitu aja, akses jaringan bisa terbuka lebar.
Simplenya: jangan lagi anggap RADIUS-UDP polos itu aman kalau lewat network yang nggak dilindungi. Harus ada lapisan proteksi tambahan.
Kenapa Pakai ISE Sebagai Proksi?
Pakai ISE sebagai RADIUS proxy itu semacam bikin “gateway keamanan” di tengah:
– ISE bisa jadi titik kontrol tunggal buat policy, logging, dan inspeksi.
– ISE bisa memaksa penggunaan proteksi tambahan, seperti enkripsi kanal (mis. TLS/DTLS atau IPsec), validasi atribut, dan kebijakan drop paket yang mencurigakan.
– ISE bantu menjembatani perangkat lama yang belum support proteksi modern, sambil menjaga koneksi ke upstream RADIUS/IdP tetap aman.
Catatan penting: dukungan fitur (mis. RADIUS over TLS/DTLS) tergantung versi ISE dan perangkat jaringan kamu. Cek release notes vendor dan versi perangkatmu, ya.
Arsitektur Rekomendasi
Ada beberapa skenario yang umum dipakai:
1) NAD → ISE (aman) → RADIUS/IdP (aman)
– Idealnya pakai RADIUS over TLS/DTLS atau IPsec di kedua sisi.
– Ini ngasih end-to-end proteksi terhadap MitM.
2) NAD → ISE (polos tapi di segmen aman) → RADIUS/IdP (aman)
– Kalau NAD belum mendukung TLS/DTLS, taruh ISE sedekat mungkin dengan NAD di jaringan internal yang tersegmentasi/terproteksi.
– Dari ISE ke upstream RADIUS/IdP, wajib pakai TLS/DTLS atau IPsec.
3) NAD → ISE (aman) → RADIUS/IdP (legacy)
– Kalau upstream server belum support koneksi aman, minimal amankan sisi NAD ke ISE.
– Batasi jalur ISE ke upstream hanya di network internal yang trusted.
Langkah Implementasi dengan ISE sebagai Proksi
Berikut flow praktisnya:
1) Cek kapabilitas perangkat
– Lihat apakah NAD (switch, WLC, VPN) support RADIUS over TLS/DTLS atau bisa di-IPsec-kan.
– Cek versi Cisco ISE yang kamu pakai, dan lihat opsi keamanan RADIUS yang tersedia. Update kalau perlu.
2) Rancang topologi yang “short path”
– Usahakan jalur NAD ↔ ISE sesingkat dan seaman mungkin (VLAN/VRF manajemen khusus, ACL ketat).
– Kalau jalurnya lintas segmen yang kurang trusted, pertimbangkan IPsec.
3) Konfigurasi ISE sebagai RADIUS proxy
– Tambahkan NAD sebagai Network Device di ISE, lengkap dengan shared secret kuat.
– Buat policy proxy/sequence ke upstream RADIUS/IdP sesuai use case (802.1X, VPN, MAB, dsb.).
– Aktifkan enkripsi kanal ke arah upstream bila tersedia (TLS/DTLS atau IPsec).
4) Perketat validasi di ISE
– Tolak request yang mencurigakan (mis. atribut tak standar/duplikat yang aneh).
– Wajibkan penggunaan Message-Authenticator pada Access-Request jika perangkat mendukung. Ini nambah lapisan integritas paket.
– Terapkan rate-limit/logging untuk anomali.
5) Testing end-to-end
– Uji skenario sukses dan gagal (password salah, sertifikat tidak valid, user nonaktif).
– Pastikan NAD tidak “tertipu” dengan respon aneh; pastikan ISE bener-bener memverifikasi dan mem-proxy sesuai policy.
Checklist Kebijakan Keamanan di ISE
– Gunakan shared secret yang panjang dan unik per NAD.
– Aktifkan enkripsi kanal bila didukung: TLS/DTLS untuk RADIUS atau IPsec tunnel.
– Wajibkan Message-Authenticator untuk semua Access-Request bila environment memungkinkan.
– Monitor log ISE (Live Logs, pxGrid, syslog) untuk mendeteksi anomali: ukuran paket tak wajar, atribut ganda, atau lonjakan retry.
– Segregasi jaringan manajemen ISE dari jaringan user.
– Update ISE dan NAD ke versi patch terbaru yang meng-address isu Blast-RADIUS dan hardening RADIUS.
Best Practice di Sisi NAD
– Pakai firmware terbaru yang menambahkan mitigasi Blast-RADIUS.
– Jika bisa, aktifkan RADIUS over TLS/DTLS atau pakai IPsec ke ISE.
– Nonaktifkan fallback protokol lemah (PAP) jika tidak wajib.
– Pastikan randomizer/nonce di NAD benar-benar acak, supaya sulit diprediksi penyerang.
– Terapkan ACL yang ketat: hanya izinkan NAD bicara RADIUS ke IP ISE, bukan ke mana-mana.
Jangka Panjang: Menuju RADIUS yang Lebih Aman
– Targetkan migrasi ke RADIUS over TLS (RadSec) atau DTLS secara luas di environment kamu.
– Dorong penggunaan metode EAP berbasis sertifikat (EAP-TLS) untuk keamanan yang lebih kuat pada sisi identitas pengguna/perangkat.
– Standarisasi segmentasi jaringan, Zero Trust, dan pemantauan real-time (telemetri) biar anomali cepat ketahuan.
– Dokumentasikan dependency lama (legacy) dan buat roadmap upgrade-nya.
FAQ Singkat
– Apakah cukup hanya upgrade ISE? Tidak. Kamu tetap perlu amankan kanal NAD ↔ ISE dan ISE ↔ upstream.
– Kalau perangkatku belum support TLS/DTLS? Pakai IPsec atau pastikan jalurnya benar-benar ada di jaringan internal yang dilindungi, plus hardening ketat.
– EAP-TLS saja cukup? EAP-TLS memperkuat auth user/perangkat, tapi Blast-RADIUS menyerang lapisan transport RADIUS. Kanalnya tetap perlu diamankan.
Penutup
Blast-RADIUS ngingetin kita bahwa protokol tua butuh “baju zirah” modern. Menaruh ISE sebagai proksi RADIUS itu langkah realistis dan efektif buat banyak organisasi: gampang dipantau, fleksibel, dan bisa jadi titik pusat enkripsi plus policy. Mulai dari hal yang bisa kamu kontrol sekarang—update, segmentasi, enkripsi kanal—sambil nyusun roadmap menuju RADIUS over TLS/DTLS end-to-end. Dengan begitu, akses jaringan kamu tetap aman, nyaman, dan siap hadapi serangan kekinian.
