Show HN: Sistem autentikasi multi-faktor dan pendaftaran Wag untuk WireGuard

 (github.com/NHAS)
1 poin oleh GN⁺ 2024-05-13 | 1 komentar | Bagikan ke WhatsApp
  • Wag adalah proyek yang menambahkan autentikasi multi-faktor, pembatasan rute, dan pendaftaran perangkat ke WireGuard, serta dapat membedakan antara rute yang memerlukan MFA dan rute publik yang selalu dapat diakses
  • Menyediakan API pendaftaran klien baru, ketersediaan tinggi, pembaruan dan notifikasi pengguna secara real-time, serta berbagai integrasi MFA seperti Security Key, SSO, PAM, dan TOTP
  • Pengoperasian server memerlukan IP forwarding diaktifkan, dan saat dijalankan secara manual membutuhkan instalasi iptables dan libpam, serta menjalankan sebagai root untuk mengelola iptables dan perangkat WireGuard
  • Pengelolaan dapat dilakukan melalui UI web dan CLI, dan CLI menangani token pendaftaran, penguncian perangkat, reset MFA, dan akun admin web melalui subperintah start, registration, devices, users, webadmin
  • Keterbatasannya adalah hanya mendukung satu AllowedIP per klien, terutama ditujukan untuk Linux, dan Windows dapat berfungsi setelah melalui beberapa langkah tambahan

Fitur WireGuard yang ditambahkan Wag

  • Wag menambahkan MFA, pembatasan rute, dan pendaftaran perangkat ke WireGuard
  • Rute dapat didefinisikan dengan membagi jalur yang memerlukan autentikasi MFA dan rute publik yang selalu dapat diakses
  • Menyediakan API yang mudah untuk pendaftaran klien baru
  • Mendukung ketersediaan tinggi, pembaruan pengguna secara real-time, dan notifikasi
  • Integrasi MFA mencakup metode berikut
    • Security Key
    • SSO
    • PAM
    • TOTP
  • Dokumentasi tersedia di Documentation

Instalasi dan syarat menjalankan

  • Forwarding harus diaktifkan di server
    • Untuk IPv4 gunakan pengaturan net.ipv4.ip_forward=1
    • Untuk IPv6 gunakan pengaturan sysctl terkait seperti net.ipv6.conf.all.forwarding=1
  • Contoh menjalankan dengan Docker Compose menggunakan image wagvpn/wag:latest
    • Contoh port halaman admin: 4433/tcp
    • Contoh port halaman pendaftaran publik: 8081/tcp
    • Contoh port WireGuard: 53230/udp
    • Hubungkan perangkat /dev/net/tun ke kontainer
  • Instalasi manual memerlukan iptables dan libpam
  • Wag harus dijalankan sebagai root untuk mengelola iptables dan perangkat WireGuard
  • Rilis biner memerlukan glibc 2.31+
  • Build dari source memerlukan go1.23.1 dan npm

Cara pengelolaan

  • Setelah mengaktifkan UI admin dan mengonfigurasi Wag, administrator pertama dibuat dan kata sandinya dicetak ke STDOUT
  • Setelah itu Anda dapat masuk ke UI web untuk mengelola pengguna
  • Pengguna root dapat mengelola server Wag melalui CLI
  • Format CLI adalah wag subcommand [-options]
  • Subperintah yang didukung adalah sebagai berikut
    • start: memulai server Wag tanpa dijalankan sebagai daemon
    • registration: menangani pembuatan, penghapusan, dan daftar token pendaftaran
    • devices: menangani daftar perangkat WireGuard, penghapusan, penguncian, pembukaan kunci, dan melihat sesi MFA yang aktif
    • users: menangani pengelolaan MFA pengguna, penghapusan pengguna, penguncian akun, dan reset MFA
    • webadmin: menangani penambahan, penghapusan, daftar, penguncian, dan pembukaan kunci pengguna admin UI web
    • version, firewall juga termasuk perintah yang didukung

Token pendaftaran dan alur MFA

  • Untuk mendaftarkan perangkat baru, pertama buat token pendaftaran dengan perintah seperti wag registration -add -username tester
  • Jika token yang dibuat dikirim ke endpoint pendaftaran publik, Anda dapat menerima respons konfigurasi WireGuard
  • Konfigurasi yang dikembalikan mencakup item seperti Interface, PrivateKey, Address, Peer, Endpoint, PublicKey, AllowedIPs, PersistentKeepAlive
  • Pengguna terhubung ke alamat VPN server dan memasukkan kode 2FA
  • Lama sesi bertahan hingga kedaluwarsa ditentukan dalam berkas konfigurasi

Konsol administrasi web

  • Untuk masuk ke konsol admin, Webserver.Management.Enabled harus disetel ke true
  • Dari konsol, tambahkan akun admin web dengan sudo ./wag webadmin -add -username <your_username> -password <your-password-here>
  • Setelah itu akses alamat listening admin dan masukkan kredensial
  • Antarmuka web itu sendiri tidak dapat menambahkan pengguna admin
  • Disarankan untuk tidak mengekspos portal admin ke luar, dan dianjurkan menyetel ListenAddress ke 127.0.0.1 atau localhost lalu mengeksposnya melalui SSH forwarding

Item konfigurasi utama

  • NumberProxies menentukan jumlah reverse proxy tepercaya di depan klien, sehingga Wag akan memperhitungkan X-Forward-For saat mem-parsing IP klien
  • Socket adalah soket kontrol Wag, dan jika diubah Anda dapat menjalankan beberapa instance Wag pada mesin yang sama
  • NAT mengaktifkan atau menonaktifkan masquerading, dan bila aktif semua lalu lintas akan terlihat seolah berasal dari server VPN
  • NATExcludeRanges menentukan rentang CIDR yang dikecualikan dari NAT saat NAT=true
  • ExposePorts mengekspos port server VPN ke klien dan menambahkan aturan iptables
  • CheckUpdates nonaktif secara default, dan bila diaktifkan UI admin akan menampilkan notifikasi versi Wag baru serta mengakses api.github.com
  • Acls mendefinisikan grup dan kebijakan, tetapi hanya diterapkan saat pertama kali dijalankan, dan selama runtime diedit melalui UI web
  • Webserver mencakup pengaturan endpoint pendaftaran publik, portal MFA tunnel, dan portal admin
  • Wireguard mengatur nama perangkat, port listening, private key, subnet yang ditangani VPN, MTU, dan server DNS
  • Clustering mencakup nama klaster, status klaster etcd, level log, node witness, lokasi basis data, dan pengaturan terkait sertifikat klaster

Cara kerja kebijakan ACL

  • Policies mendefinisikan rute yang akan ditangkap VPN serta port dan protokol yang diizinkan melewati Wag
  • Penerapan aturan menggunakan panjang prefix subnet, dan kecocokan yang paling spesifik menentukan tingkat akses rute
  • Misalnya jika /16 didefinisikan sebagai MFA dan /32 tertentu di dalamnya didefinisikan sebagai Allow, maka /32 yang lebih spesifik akan diprioritaskan sehingga dapat diakses tanpa MFA
  • Perilaku ini berubah di v6.0.0; sebelumnya rute MFA selalu diprioritaskan
  • Jika beberapa kebijakan didefinisikan untuk satu rute, kebijakan tersebut akan digabungkan, dan aturan MFA diprioritaskan
  • Mulai versi yang belum dirilis, akses rute dapat diblokir dengan aturan Deny
  • Aturan yang paling spesifik membuat “bucket” aturan baru, jadi jika bucket /32 hanya berisi deny, akses ke port lain pada /32 yang sama juga mungkin tidak diizinkan

Aturan port dan protokol

  • Akses layanan dapat didefinisikan dengan aturan port dan protokol
  • Ada 3 jenis aturan yang didukung
    • Any: jika tidak ada aturan terpisah atau memakai kata kunci any, semua kombinasi layanan dan port diizinkan
    • Single Service: mengizinkan port TCP atau UDP tertentu pada host, seperti 192.168.1.1 22/tcp 53/udp
    • Ranges: menentukan rentang port, seperti 192.168.1.1 22-1024/tcp 23-53/any
  • Untuk rentang port, port yang lebih rendah harus ditulis lebih dulu
  • Karena ICMP tidak memiliki port, dapat ditentukan tanpa port seperti 1.1.1.1 icmp

Keterbatasan dan pengembangan

  • Wag hanya mendukung satu AllowedIP per klien
  • Keterbatasan ini cocok untuk struktur dari klien ke server
  • Utamanya khusus Linux, dan Windows dapat berfungsi setelah melalui beberapa langkah tambahan
  • Dalam mode pengembangan, variabel lingkungan dapat digunakan untuk menetapkan IP permintaan yang masuk melalui tunnel sebagai IP klien
  • Contoh pengujian dijalankan dengan sudo go test -v . di internal/router
  • Kontribusi eksternal dianjurkan untuk menulis pengujian jika memungkinkan saat menambahkan fitur atau memperbaiki bug, lalu membuka Pull Request

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-13
Komentar Hacker News

  • Kelihatannya bagus, tapi ada beberapa hal yang mengganjal
    Dari contoh curl [http://public.server.address:8080/register_device?key=e83253...](<http://public.server.address/register_device/…;) dan penjelasan bahwa “layanan mengembalikan respons yang sepenuhnya ditemplatkan”, tampaknya dalam proses pendaftaran server membuat kunci privat lalu mengirimkannya ke klien, alih-alih klien membuat kunci privat dan mengirim kunci publik ke server
    Selain itu, karena contohnya memakai HTTP, setidaknya bagian itu sebaiknya diubah agar orang tidak mengira HTTP juga merupakan pilihan yang aman
    Saya juga penasaran apakah ada cara bagi klien untuk menyadari saat sesi kedaluwarsa. Atau apakah sesi seperti SSH akan langsung macet begitu saja?
    Saya kadang mencari klien WireGuard yang bekerja seperti deteksi captive portal pada Wi-Fi; idealnya cukup menambahkan satu baris seperti persistentkeepalive ke file konfigurasi agar klien mengambil URL dan memeriksanya secara berkala. Jika mendapat OK, berarti normal; jika tidak ada respons, berarti masalah jaringan; jika ada header Location, browser dibuka ke lokasi itu untuk autentikasi ulang sesi dan semacamnya
    Sampai sekarang saya belum menemukan klien seperti itu

    • URL pendaftaran secara opsional juga bisa menerima parameter pubkey, jadi tidak harus bergantung pada pendekatan server membuat kunci privat. Dokumentasinya memang agak kurang sehingga mudah membingungkan
      Untuk menjawab pertanyaan terakhir, eBPF XDP yang saya gunakan hanya bisa PASS, DROP, dan REDIRECT. Jadi saya menangani ini dengan hasil termudah yaitu PASS/DROP, dan koneksi pun hanya akan macet begitu saja
      Namun, jika Anda menambahkan halaman deteksi captive portal ke daftar MFA wag, deteksi itu bisa dikonfigurasi sendiri, dan setelahnya browser yang akan menangani sisanya
      Saya tidak berniat membuat wag berfungsi seperti intersepsi atau proxy. Itu memang bisa mempermudah penanganan kedaluwarsa autentikasi atau logout, tetapi bukan arah proyek ini
    • Fitur seperti itu akan sangat keren, dan saya harap penulis proyek ini mempertimbangkannya
    • Saya pernah membuat server serupa. Strukturnya membutuhkan sertifikat klien per perangkat, lalu dengan itu mengakses halaman login melalui mTLS, mengautentikasi pengguna via OIDC, dan mengaktifkan tunnel, tetapi bagian sulitnya adalah klien
      Saya menulis klien Go untuk Mac dan juga memakai wg dari command line Brew untuk menangani pembuatan kunci, tetapi hasilnya terasa kasar dan memerlukan sudo
      Akan lebih baik jika ada aplikasi native yang proper dengan izin jaringan, tetapi itu di luar kemampuan saya

  • Saya penasaran apakah masalah manajemen sesi ini sudah ditangani atau ada rencana untuk menanganinya
    Pada dasarnya, kunci WireGuard itu seperti kunci sesi yang berlaku selamanya
    Jika perangkat lunak yang mengimplementasikan lapisan transport WireGuard ingin menjadi solusi server VPN yang proper, menurut saya ia juga harus mengimplementasikan manajemen sesi. Artinya, melalui kanal kedua dengan server, ia harus secara berkala mengganti kunci sesi, mengakhiri sesi, mengubah alamat IP, menetapkan rute baru, dan bila perlu mengulang autentikasi

    • Untuk kebutuhan seperti itu, saya akan memakai Firezone. Ada opsi untuk memaksa pengguna login berkala ke platform, dan jika digabungkan dengan OIDC ke penyedia identitas eksternal, itu menjadi solusi manajemen sesi yang sangat kokoh dan sederhana
    • Dalam konteks wag, saya kurang yakin apa tepatnya yang dimaksud dengan “kunci sesi yang berlaku selamanya”
      Kunci WireGuard memang memungkinkan komunikasi dengan server wag, tetapi sesi aktual dipertahankan sebagai peta eBPF yang menyimpan apakah pengguna sudah terautentikasi atau belum
      Jadi, bahkan jika seseorang mencuri material kunci privat, mereka tetap tidak bisa mengakses rute yang dibatasi MFA
    • Jika saya membuat klien VPN seperti GlobalProtect dengan WireGuard, saya mungkin akan memiliki kunci autentikasi permanen per klien, menggunakannya untuk membangun tunnel awal ke pengendali VPN, lalu melakukan autentikasi di dalamnya dan menerima kunci sesi terpisah. Tunnel pertama akan diputus segera setelah autentikasi selesai dan kunci sesi yang sebenarnya diterima
    • Jika yang dimaksud kanal kedua untuk rotasi kunci sesi berkala, pengakhiran sesi, perubahan alamat IP, konfigurasi rute baru, dan autentikasi ulang, bukankah itu pada dasarnya protokol IKE milik IPsec? Kenapa tidak pakai IPsec saja?

  • Saya penasaran apakah ada perlindungan terhadap brute force kode TOTP. Misalnya pembatasan laju atau batas jumlah percobaan
    Saya sempat menelusuri kode dengan cepat, tetapi tidak menemukan penanganan seperti itu
    Skenario yang saya bayangkan adalah seseorang membuka UI input TOTP di browser, lalu membuka developer tools dan mencoba semua kemungkinan kode TOTP secara berulang

    • Ada perlindungan terhadap brute force kode TOTP. Setiap autentikasi memiliki batas jumlah percobaan yang bisa dilakukan pengguna, dan jika terlampaui akun akan dikunci serta harus dibuka oleh admin
      Secara khusus, ini juga dimaksudkan agar pengguna berpikir kenapa perangkat mereka dipaksa mencoba autentikasi, karena situasi seperti itu bisa menandakan endpoint telah dikompromikan
    • Mungkin yang ini: https://github.com/NHAS/wag/blob/cdbdbec3393fa86bf6c823117c8...
    • Saya tidak tahu detail implementasinya, tetapi biasanya jika seseorang sudah memiliki kredensial login untuk sampai ke tahap TOTP, yakni nama pengguna dan kata sandi, maka pengguna itu pada dasarnya sudah dalam keadaan terkompromi

  • Kedengarannya sangat mirip dengan Headscale atau Tailscale. Senang melihat ada alternatif untuk mengelola jaringan WireGuard
    Saya penasaran apakah ada materi perbandingan untuk memahami sejauh mana fiturnya tumpang tindih, apa yang ditambahkan, apa yang berbeda, dan apa yang memang tidak akan diimplementasikan ke depan

    • Jelas mirip dalam hal sama-sama memakai WireGuard
      Saya memang tidak memasukkan perbandingan langsung di dokumentasi, tetapi itu bukan arah yang sedang saya tuju saat ini. Proyek ini sesuai kebutuhan saya dan cukup menyenangkan untuk dikerjakan
      Wag lebih cocok untuk arsitektur hub-and-spoke yang menginginkan batas yang tegas, daripada mesh ala Tailscale di mana semuanya saling terhubung dan aturan mendefinisikan overlay
      Baik wag maupun Tailscale sama-sama menambahkan integrasi SSO dan secara efektif 2FA untuk perlindungan pengguna
      Keduanya juga punya metode pendaftaran dan UI web untuk pengelolaan, tetapi saya adalah pengembang tunggal yang tidak suka pengembangan web, jadi Tailscale pasti jauh lebih matang
      Hal yang pasti tidak akan saya implementasikan adalah intersepsi atau proxy TLS untuk mengalihkan pengguna setelah logout sesi. Alasan utamanya, melakukan itu dengan eBPF saat ini agak terlalu berat bagi saya, dan agar bisa berjalan saya kemungkinan harus memakai komponen konfigurasi DNAT/SNAT yang tidak ingin saya tulis

  • Hanya IPv4, padahal kalau memilih WireGuard, situs seperti ini sepertinya cenderung punya konfigurasi yang lebih modern dan banyak memakai ULA sebagai layanan mandiri

    • Saya berencana menambahkan dukungan IPv6 dalam waktu dekat, dan juga sedang mempertimbangkan memetakan alamat IPv4 orang ke ruang IPv6 privat untuk mengurangi risiko bentrok dengan jaringan lokal nyata milik pengguna
      Saat menyebut ULA, apakah ada hal tertentu yang Anda pikirkan?
    • Saya penasaran apa keuntungan ULA yang Anda maksud di sini