Belajar WireGuard - WireGuard Security Model

#Pendahuluan

Setiap protokol kriptografi adalah pilihan: algoritma apa yang dipakai, serangan apa yang ditangani, dan serangan apa yang secara sadar ditinggalkan. WireGuard mengambil pendekatan radikal — satu set primitif modern, tidak ada pilihan cipher, dan model ancaman yang didokumentasikan dengan jelas.

Episode 13 membedah model keamanan WireGuard: primitif kriptografi yang menjadi bahan bakunya, ancaman yang berhasil ditangani, dan keterbatasan yang harus kalian kompensasi dengan lapisan di luar protokol.

Model keamanan bukan sekadar daftar algoritma; model ini menentukan ke mana energi kalian harus diarahkan. Setelah episode ini, kalian seharusnya bisa menjawab pertanyaan sederhana: apakah WireGuard sudah cukup untuk skenario saya, atau apakah saya perlu menambah lapisan?

#Primitif Kriptografi

#Empat Bahan Baku

WireGuard hanya memakai empat primitif, semua merupakan standar modern yang terkurasi:

• Curve25519: kurva eliptik untuk key exchange berbasis Diffie-Hellman, cepat dan aman dari banyak side channel.
• ChaCha20-Poly1305: authenticated encryption yang menawarkan enkripsi sekaligus integritas dalam satu konstruksi AEAD.
• BLAKE2s: fungsi hash cepat untuk menurunkan kunci dan mencampur material handshake.
• SipHash24: hash ringan untuk struktur data internal tabel, bukan untuk kriptografi.

#Kenapa Hanya Empat

Dengan primitif yang sedikit, tidak ada kombinasi yang bisa salah dikonfigurasi. Tidak ada menu cipher suite seperti di TLS atau IPsec, sehingga permukaan untuk kesalahan implementasi dan kesalahan konfigurasi menyusut drastis. Inilah bagian dari filosofi "crypto-first" yang kita bahas di episode 1.

Dengan empat primitif, seluruh protokol bisa diaudit oleh sekelompok kecil pakar, dan hasilnya jauh lebih mudah dipercaya dibanding sistem dengan puluhan kombinasi. Ini selaras dengan cerita sejarah di episode 1: keamanan tumbuh dari kesederhanaan, bukan dari banyaknya opsi.

grep -i -E "aes|avx|sha" /proc/cpuinfo | head -1

Perintah grep -i -E "aes|avx|sha" /proc/cpuinfo memeriksa instruksi yang tersedia pada CPU kalian. Dukungan instruksi seperti AVX mempercepat ChaCha20-Poly1305 di banyak CPU modern, dan kinerjanya akan kita ukur di episode 15.

#Model Ancaman

#Passive Eavesdropper

Penyerang yang hanya menyadap paket tidak akan mendapatkan apa-apa selain teks tersandi dan metadata minimal. Tanpa kunci privat dan material handshake, tidak ada cara memecahkan sesi. Forward secrecy menjaga bahwa bahkan jika kunci jangka panjang bocor nanti, sesi masa lalu tetap tertutup.

Selain itu, karena kunci sesi terus di-rekey seperti di episode 5, dampak kebocoran kunci jangka panjang bisa dibatasi. Kombinasi forward secrecy dan rekeying inilah yang membuat penyadap pasif tidak punya bahan untuk menyerang sesi lama.

#Active MITM

Penyerang aktif yang menyamar sebagai salah satu pihak diblokir oleh cryptokey routing: setiap paket harus ditandatangani secara implisit dengan kunci yang sesuai dengan kunci publik peer. Penyamar tidak punya kunci privat yang sah, sehingga handshake dan semua paketnya ditolak.

Yang perlu diingat: WireGuard melindungi integritas koneksi, bukan identitas manusia. Jika penyerang bisa menguasai perangkat yang memegang kunci privat, semua perlindungan kriptografi tidak ada artinya. Keamanan perangkat tetap menjadi tanggung jawab kalian.

#Serangan DoS

Ban handshake dengan paket palsu diredam mekanisme cookie yang kita bahas di episode 5. Handshake juga mahal bagi penyerang, dan server dapat membatasi kecepatannya tanpa menyimpan state besar.

Mekanisme cookie adalah bagian dari pertahanan berlapis: handshake yang mahal dihitung ulang hanya setelah cookie diterima, sehingga membanjiri server dengan handshake palsu menjadi tidak menguntungkan.

#Keterbatasan yang Harus Kalian Lengkapi

#Tidak Ada Autentikasi Pengguna

WireGuard hanya mengenal kunci, bukan orang. Tidak ada konsep username, password, atau sertifikat pengguna. Jika dua orang berbagi satu perangkat dan kunci, mereka tidak bisa dibedakan. Untuk kebutuhan identitas pengguna, kalian perlu lapisan manajemen seperti Firezone yang membungkus WireGuard dengan autentikasi.

#Tidak Ada ACL Berbasis Pengguna

Karena identitasnya kunci, kebijakan akses WireGuard juga berbasis kunci. Kalian tidak bisa menetapkan "pengguna ini boleh akses subnet itu" secara langsung — yang bisa dilakukan adalah mengatur AllowedIPs per peer, dan siapa yang memegang kunci peer itu diatur di luar protokol.

#Metadata Lalu Lintas Terlihat

WireGuard menyembunyikan isi paket, tetapi pola lalu lintas — kapan, seberapa sering, dan seberapa besar paket — tetap bisa diamati oleh penyadap pasif. Untuk menyembunyikan pola ini, kalian perlu lapisan tambahan seperti obfuscation atau membawa WireGuard di dalam tunnel lain.

Menilai ancaman metadata perlu konteks: bagi penyadap pasif, mengetahui bahwa dua pihak sedang berkomunikasi bisa lebih berharga daripada isi komunikasinya. Jika profil ancaman kalian memasukkan penyadapan tingkat lanjut, pertimbangkan menambahkan lapisan yang menyamarkan pola, atau menjadwalkan komunikasi dengan pola yang tidak mudah ditebak.

#Manajemen Key adalah Tanggung Jawab Kalian

Protokol tidak menyediakan cara menyimpan kunci dengan aman, memperbaruinya, atau mencabutnya. Semua itu berada di tangan kalian: backup terenkripsi, rotasi berkala, dan audit peer seperti yang kita bahas di episode 12. Perluas juga untuk mencabut kunci peer yang tidak lagi dipakai, agar tabel peer tidak mengendap tanpa pemilik.

Pola terbaiknya adalah menjadikan manajemen kunci bagian dari rutinitas, bukan peristiwa darurat. Rotasi terjadwal, audit peer berkala, dan pemulihan teruji adalah kebiasaan yang mencegah krisis, bukan sekadar menanggapinya.

Dengan begitu, keterbatasan protokol bukan kelemahan yang menakutkan, melainkan ruang yang jelas bagi kalian untuk bekerja.

#Menilai Kebutuhan Lapisan Tambahan

#Sesuaikan dengan Konteks

Model keamanan WireGuard sudah memadai untuk mayoritas skenario VPN. Lapisan tambahan baru diperlukan ketika:

• Identitas pengguna yang individual harus diautentikasi.
• Akses harus dibatasi per peran dan per subnet.
• Pola lalu lintas harus disembunyikan dari penyadap.
• Kunci harus dikelola terpusat untuk ratusan perangkat.

Untuk keputusan ini, kembali ke threat model kalian sendiri: siapa lawannya, apa asetnya, dan apa yang sudah ditangani WireGuard secara default.

Praktik yang baik adalah menuliskan threat model dalam satu dokumen singkat, lalu mengujinya setiap kali ada perubahan jaringan. Dokumen ini membantu tim menjawab pertanyaan sulit dengan konsisten, bukan berdasarkan kebiasaan atau tren.

Jangan lupa bahwa dokumentasi keamanan hanya berguna bila dibaca ulang. Jadwalkan peninjauan berkala, misalnya setiap kuartal, dan perbarui bersama perubahan infrastruktur apa pun.

#Penutup

Episode 13 menuntaskan pemahaman model keamanan: empat primitif modern yang terkurasi, proteksi terhadap penyadap pasif dan MITM aktif, mekanisme cookie untuk DoS, serta keterbatasan seperti tidak adanya autentikasi pengguna dan ACL yang harus kalian lengkapi.

Inti yang harus dibawa pulang:

• WireGuard memakai Curve25519, ChaCha20-Poly1305, BLAKE2s, dan SipHash24.
• Passive eavesdropper hanya melihat teks tersandi dan pola lalu lintas.
• Active MITM diblokir oleh cryptokey routing.
• DoS diredam mekanisme cookie dan rate limiting handshake.
• Tidak ada autentikasi pengguna maupun ACL berbasis pengguna.
• Manajemen kunci dan backup adalah tanggung jawab kalian.

Di episode 14 selanjutnya kita membahas firewall dan access control — mengintegrasikan WireGuard dengan nftables dan iptables, menyusun aturan lewat PostUp dan PostDown, serta menerapkan access control berbasis kunci untuk membatasi akses antar subnet.