Show HN: WireGuard için Wag çok faktörlü kimlik doğrulama ve kayıt sistemi

 (github.com/NHAS)
1 puan yazan GN⁺ 2024-05-13 | 1 yorum | WhatsApp'ta paylaş
  • Wag, WireGuard'a çok faktörlü kimlik doğrulama, rota kısıtlamaları ve cihaz kaydı ekleyen bir proje olup MFA gerektiren rotalar ile her zaman erişilebilen genel rotaları ayırabiliyor
  • Yeni istemci kaydı API'si, yüksek erişilebilirlik, gerçek zamanlı kullanıcı güncellemeleri ve bildirimler ile Security Key, SSO, PAM, TOTP gibi çeşitli MFA entegrasyonları sunuyor
  • Sunucuyu çalıştırmak için IP yönlendirmesinin etkinleştirilmesi gerekiyor; elle çalıştırmada iptables ve libpam kurulumu ile iptables ve WireGuard cihazlarını yönetmek için root olarak çalıştırma gerekli
  • Yönetim web UI ve CLI ile yapılabiliyor; CLI, kayıt token'ları, cihaz kilitleme, MFA sıfırlama ve web yönetici hesaplarını start, registration, devices, users, webadmin alt komutlarıyla ele alıyor
  • Kısıtlamalar arasında istemci başına yalnızca bir AllowedIP desteği bulunuyor; esas olarak Linux'a yönelik ve Windows bazı ek işlemlerle çalışabiliyor

Wag'in WireGuard'a eklediği özellikler

  • Wag, WireGuard'a MFA, rota kısıtlamaları ve cihaz kaydı ekler
  • Rotalar, MFA doğrulaması gerektiren yollar ile her zaman erişilebilen genel rotalar olarak ayrılıp tanımlanabilir
  • Yeni istemci kaydı için kolay bir API sunar
  • Yüksek erişilebilirlik, gerçek zamanlı kullanıcı güncellemeleri ve bildirimleri destekler
  • MFA entegrasyonları şu yöntemleri içerir
    • Security Key
    • SSO
    • PAM
    • TOTP
  • Dokümantasyon Documentation adresinde sunulmaktadır

Kurulum ve çalıştırma koşulları

  • Sunucuda forwarding etkin olmalıdır
    • IPv4 için net.ipv4.ip_forward=1 ayarı kullanılır
    • IPv6 için net.ipv6.conf.all.forwarding=1 gibi ilgili sysctl ayarları kullanılır
  • Docker Compose çalıştırma örneği wagvpn/wag:latest imajını kullanır
    • Yönetim sayfası port örneği 4433/tcp
    • Genel kayıt sayfası port örneği 8081/tcp
    • WireGuard port örneği 53230/udp
    • /dev/net/tun cihazı konteynere bağlanır
  • Elle kurulum için iptables ve libpam gerekir
  • Wag, iptables ve WireGuard cihazlarını yönetmek için root olarak çalıştırılmalıdır
  • İkili sürümler için glibc 2.31+ gerekir
  • Kaynaktan derleme için go1.23.1 ve npm gerekir

Yönetim yöntemleri

  • Yönetim UI etkinleştirilip Wag yapılandırıldıktan sonra ilk yönetici oluşturulur ve parola STDOUT'a yazdırılır
  • Ardından web UI'ye giriş yaparak kullanıcılar yönetilebilir
  • Root kullanıcı CLI ile Wag sunucusunu yönetebilir
  • CLI biçimi wag subcommand [-options] şeklindedir
  • Desteklenen alt komutlar şunlardır
    • start: Wag sunucusunu başlatır, daemon moduna geçmez
    • registration: kayıt token'ı oluşturma, silme ve listelemeyi işler
    • devices: WireGuard cihazlarını listeleme, silme, kilitleme, kilit açma ve etkin MFA oturumlarını görüntülemeyi işler
    • users: kullanıcı MFA yönetimi, kullanıcı silme, hesap kilitleme ve MFA sıfırlamayı işler
    • webadmin: web UI yönetici kullanıcısı ekleme, silme, listeleme, hesap kilitleme ve kilit açmayı işler
    • version, firewall da desteklenen komutlar arasındadır

Kayıt token'ı ve MFA akışı

  • Yeni cihaz kaydı için önce wag registration -add -username tester gibi bir komutla kayıt token'ı oluşturulur
  • Oluşturulan token genel kayıt endpoint'ine gönderildiğinde WireGuard yapılandırma yanıtı alınabilir
  • Döndürülen yapılandırma Interface, PrivateKey, Address, Peer, Endpoint, PublicKey, AllowedIPs, PersistentKeepAlive gibi öğeleri içerir
  • Kullanıcı sunucunun VPN adresine bağlanarak 2FA kodunu girer
  • Oturumun sona ermeden önce ne kadar süreceği yapılandırma dosyasında belirtilir

Web yönetim konsolu

  • Yönetim konsoluna giriş yapabilmek için Webserver.Management.Enabled değeri true olarak ayarlanmalıdır
  • Konsolda sudo ./wag webadmin -add -username <your_username> -password <your-password-here> komutuyla web yöneticisi hesabı eklenir
  • Ardından yönetim dinleme adresine gidilip kimlik bilgileri girilir
  • Web arayüzünün kendisi yönetici kullanıcı ekleyemez
  • Yönetim portalının dışarıya açılmaması önerilir; ListenAddress değerinin 127.0.0.1 veya localhost olarak ayarlanması ve SSH forwarding ile erişime açılması tavsiye edilir

Başlıca yapılandırma öğeleri

  • NumberProxies, istemcinin önündeki güvenilir reverse proxy sayısını belirtir ve Wag'in X-Forward-For bilgisini dikkate alarak istemci IP'sini ayrıştırmasını sağlar
  • Socket, Wag kontrol soketidir; değiştirilirse aynı makinede birden fazla Wag instance'ı çalıştırılabilir
  • NAT, masquerading'i açıp kapatır; etkinleştirildiğinde tüm trafik VPN sunucusundan çıkıyormuş gibi görünür
  • NATExcludeRanges, NAT=true olduğunda NAT dışında bırakılacak CIDR aralıklarını belirtir
  • ExposePorts, VPN sunucusunun portlarını istemcilere açar ve iptables kuralları ekler
  • CheckUpdates varsayılan olarak kapalıdır; etkinleştirildiğinde yönetim UI yeni Wag sürümleri için bildirim gösterir ve api.github.com adresine erişir
  • Acls, grupları ve politikaları tanımlar ancak yalnızca ilk çalıştırmada uygulanır; çalışma zamanında web UI üzerinden düzenlenir
  • Webserver, genel kayıt endpoint'i, tünel MFA portalı ve yönetim portalı ayarlarını içerir
  • Wireguard, cihaz adı, dinleme portu, özel anahtar, VPN'in yöneteceği alt ağ, MTU ve DNS sunucularını ayarlar
  • Clustering, küme adı, etcd küme durumu, log seviyesi, witness node, veritabanı konumu ve küme sertifikalarıyla ilgili ayarları içerir

ACL politika davranışı

  • Policies, VPN'in yakalayacağı rotaları ve Wag üzerinden geçecek port/protokolleri tanımlar
  • Kural uygulaması subnet prefix length kullanır ve en spesifik eşleşme rota erişim seviyesini belirler
  • Örneğin /16 MFA olarak tanımlanıp bunun içindeki belirli bir /32 Allow olarak tanımlanırsa, daha spesifik olan /32 öncelik kazanır ve MFA olmadan erişilebilir
  • Bu davranış v6.0.0 sürümünde değişmiştir; önceden MFA rotaları her zaman öncelikliydi
  • Tek bir rota için birden fazla politika tanımlanırsa politikalar birleştirilir ve MFA kuralı öncelikli olur
  • Henüz yayınlanmamış sürümlerden itibaren Deny kurallarıyla rota erişimi engellenebilir
  • En spesifik kural yeni bir kural “bucket”ı oluşturduğundan, /32 bucket'ında yalnızca deny varsa aynı /32 üzerindeki diğer portlara erişim de mümkün olmayabilir

Port ve protokol kuralları

  • Servis erişimi port ve protokol kurallarıyla tanımlanabilir
  • Desteklenen kural türleri 3 tanedir
    • Any: ayrı bir kural yoksa veya any anahtar sözcüğü kullanılırsa tüm servis ve port kombinasyonlarına izin verir
    • Single Service: 192.168.1.1 22/tcp 53/udp gibi, bir host üzerindeki belirli TCP/UDP portlarına izin verir
    • Ranges: 192.168.1.1 22-1024/tcp 23-53/any gibi, port aralıkları tanımlanabilir
  • Port aralıklarında önce düşük port yazılmalıdır
  • ICMP'nin portu olmadığından 1.1.1.1 icmp gibi portsuz belirtilebilir

Sınırlamalar ve geliştirme

  • Wag istemci başına yalnızca bir AllowedIP destekler
  • Bu sınırlama, istemciden sunucuya uzanan yapılar için uygundur
  • Esas olarak Linux odaklıdır; Windows bazı ek işlemlerle çalışabilir
  • Geliştirme modunda, tünele gelen isteklerin IP'sini istemci IP'si olarak ayarlamak için bir ortam değişkeni kullanılabilir
  • Test örneği olarak internal/router içinde sudo go test -v . çalıştırılır
  • Dış katkılar için, özellik ekleme veya hata düzeltme durumunda mümkünse test yazılması ve ardından Pull Request açılması istenir

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-13
Hacker News yorumları

  • Görünüşte iyi duruyor ama birkaç şey aklıma takıldı
    curl [http://public.server.address:8080/register_device?key=e83253...](<http://public.server.address/register_device/…;) örneği ve “servis tamamen şablonlanmış bir yanıt döndürür” açıklamasına bakınca, kayıt sürecinde istemcinin özel anahtar oluşturup açık anahtarı sunucuya göndermesinden ziyade sunucunun özel anahtarı oluşturup istemciye gönderdiği anlaşılıyor
    Üstelik örnek HTTP olduğu için, insanların HTTP’nin de uygun bir seçenek olduğunu düşünmemesi adına en azından bu kısmın değiştirilmesi iyi olur
    Oturum süresi dolduğunda istemcinin bunu fark etmesinin bir yolu var mı, onu da merak ediyorum. Yoksa SSH oturumu gibi bir şey öylece takılı mı kalıyor?
    Bazen Wi-Fi’daki captive portal algılaması gibi çalışan bir WireGuard istemcisi aradım; idealde yapılandırma dosyasına persistentkeepalive benzeri tek bir satır ekleyip bir URL’yi çekmesi ve düzenli olarak kontrol etmesi güzel olurdu. OK gelirse normal, yanıt yoksa ağ sorunu, Location başlığı gelirse tarayıcıyı o konuma açıp oturumu yeniden doğrulatmak vb.
    Henüz böyle bir istemci bulamadım

    • Kayıt URL’si isteğe bağlı olarak pubkey parametresini de alabiliyor; yani sunucunun özel anahtar üretmesine bağlı kalmak gerekmiyor. Dokümantasyon eksik olduğu için kafa karıştırması normal
      Son soruya yanıt olarak, kullandığım eBPF XDP yalnızca PASS, DROP, REDIRECT yapabiliyor. Bu yüzden en kolay sonuç olan PASS/DROP ile ele alınıyor ve bağlantı öylece takılı kalıyor
      Ancak captive portal algılama sayfasını wag MFA listesine eklerseniz algılamayı kendiniz yapılandırabilirsiniz; sonrasını tarayıcı halleder
      wag’de araya girme veya proxy gibi davranan bir işlev uygulamayı düşünmüyorum. Bunu yapmak kimlik doğrulama süresinin dolması ya da çıkış işlemini biraz kolaylaştırırdı ama hedefim bu değil
    • Böyle bir özellik gerçekten harika olurdu; umarım bu projenin geliştiricisi bunu değerlendirir
    • Benzer bir sunucu yapmıştım. Cihaz başına istemci sertifikası gerekiyordu; onunla giriş sayfasına mTLS ile bağlanıyor, ardından kullanıcıyı OIDC ile doğrulayıp tüneli etkinleştiriyordu. Zor kısım istemciydi
      Mac için bir Go istemcisi yazdım ve Brew’in komut satırı wg aracını kullanarak anahtar üretimini de hallettim; ama kaba saba çalışıyordu ve sudo gerekiyordu
      Ağ izinlerini kullanan düzgün bir yerel uygulama iyi olurdu, fakat bu benim kapasitemin dışında

  • Oturum yönetimi meselesini hâlihazırda ele alıp almadığınızı ya da ele almayı planlayıp planlamadığınızı merak ediyorum
    Özünde WireGuard anahtarı sonsuz ömürlü bir oturum anahtarı gibi
    WireGuard taşıma katmanını uygulayan yazılım doğru düzgün bir VPN sunucu çözümüyse bence oturum yönetimini de uygulamalı. Yani sunucuyla ikinci bir kanal üzerinden oturum anahtarını düzenli olarak döndürmeli, oturumu sonlandırmalı, IP adresini değiştirmeli, yeni rotalar kurmalı ve gerekirse kimlik doğrulamayı tekrarlamalı

    • Bu amaç için Firezone kullanırdım. Kullanıcıların platforma düzenli olarak giriş yapmasını zorunlu kılan bir seçeneği var; OIDC ile harici kimlik sağlayıcıya bağlandığında oturum yönetimi için oldukça sağlam ve basit bir çözüm oluyor
    • wag bağlamında “sonsuz ömürlü oturum anahtarı” ile tam olarak ne kastedildiğini bilmiyorum
      WireGuard anahtarı wag sunucusuyla iletişim kurmayı sağlar; ancak asıl oturum, kullanıcının doğrulanıp doğrulanmadığını tutan eBPF map ile korunur
      Bu yüzden biri özel anahtar materyalini çalsa bile MFA ile sınırlandırılmış rotalara erişemez
    • GlobalProtect benzeri bir VPN istemcisini WireGuard ile yapsaydım, istemci başına kalıcı bir kimlik doğrulama anahtarı koyar, bununla VPN denetleyicisine kadar ilk tüneli kurar, ardından bunun içinde kimlik doğrulaması yapıp ayrı bir oturum anahtarı aldırırdım. İlk tünel, kimlik doğrulama bitip gerçek oturum anahtarı alınır alınmaz kapatılırdı
    • Düzenli oturum anahtarı rotasyonu, oturum sonlandırma, IP adresi değiştirme, yeni rota yapılandırma ve yeniden kimlik doğrulama için ikinci bir kanal diyorsanız bu aslında IPsec’in IKE protokolü değil mi? Doğrudan IPsec kullanılsa olmaz mı?

  • TOTP kodu brute force denemelerini engelleyip engellemediğinizi merak ediyorum. Örneğin hız sınırlama veya deneme sayısı sınırı gibi
    Koda hızlıca baktım ama buna dair bir şey bulamadım
    Aklımdaki senaryo, birinin tarayıcıda TOTP giriş arayüzünü açıp geliştirici araçlarını çalıştırdıktan sonra olası tüm TOTP kodlarını sırayla denemesi

    • TOTP kodu brute force’a karşı koruma var. Her kimlik doğrulamada kullanıcının deneyebileceği deneme sayısı sınırı bulunuyor; bunu aşarsa hesap kilitleniyor ve kilidi bir yöneticinin açması gerekiyor
      Özellikle kullanıcının, cihazın neden kimlik doğrulamayı zorla denemeye çalıştığını düşünmesini sağlama amacı da var. Böyle bir durum uç noktanın ele geçirildiğine işaret edebilir
    • Muhtemelen burası: https://github.com/NHAS/wag/blob/cdbdbec3393fa86bf6c823117c8...
    • Bu uygulamanın ayrıntılarını bilmiyorum ama genelde TOTP aşamasına gelebilecek giriş bilgilerine, yani kullanıcı adı ve parolaya zaten sahipseniz o kullanıcı zaten ele geçirilmiştir

  • Headscale veya Tailscale’e çok benziyor gibi geliyor. WireGuard ağlarını yönetmek için alternatifler görmek güzel
    Özelliklerin ne kadar örtüştüğünü, nelerin eklendiğini, nelerin farklı olduğunu ve ileride de nelerin uygulanmayacağını anlayabileceğimiz bir karşılaştırma var mı merak ediyorum

    • WireGuard kullanması açısından kesinlikle benzer
      Dokümantasyona doğrudan bir karşılaştırma koymadım; şu anda gitmek istediğim yön bu değil. Bu proje benim ihtiyaçlarıma uyuyor ve oldukça eğlenceli
      Wag, her şeyin birbirine ulaşabildiği ve kuralların overlay’i tanımladığı Tailscale tarzı mesh yapıdan ziyade, net sınırlar isteyen hub-and-spoke mimarisi için daha uygun
      Hem wag hem Tailscale SSO entegrasyonu ve kullanıcıyı korumak için fiilen 2FA ekliyor
      İkisinde de kayıt yöntemi ve yönetim için web UI var; ancak web geliştirmeyi sevmeyen tek kişilik bir geliştirici olduğum için Tailscale muhtemelen çok daha cilalıdır
      Kesinlikle uygulamayacağım şey, oturum kapatıldıktan sonra kullanıcıyı yönlendirmek için araya girme veya TLS proxy tarafı. Bunun başlıca nedeni, bunu şu anda eBPF ile yapmak benim için biraz fazla zor ve çalıştırmak için muhtemelen yazmam gereken DNAT/SNAT bileşenlerini kullanmak istememem

  • Yalnızca IPv4 olması ilginç; WireGuard’ı seçen bir sitenin daha modern bir yapılandırmaya sahip olup kendi hizmet tipi ULA’larını bolca kullanması da mümkün gibi

    • Yakında IPv6 desteği eklemeyi planlıyorum; ayrıca kullanıcıların gerçek yerel ağlarıyla çakışma riskini azaltmak için insanların IPv4 adreslerini özel IPv6 alanına eşlemeyi de düşünüyorum
      ULA’dan söz ederken özellikle aklınızda olan bir nokta var mıydı merak ediyorum
    • Burada düşündüğünüz ULA avantajının ne olduğunu merak ediyorum