Show HN: Wag Multi-Faktor-Authentifizierungs- und Registrierungssystem für WireGuard

 (github.com/NHAS)
1 Punkte von GN⁺ 2024-05-13 | 1 Kommentare | Auf WhatsApp teilen

Hauptfunktionen von Wag

  • Fügt WireGuard MFA, Pfadbeschränkungen und Geräte-Registrierung hinzu
    • Es können Pfade definiert werden, die eine MFA-Authentifizierung erfordern, oder Pfade, die immer öffentlich zugänglich sind
    • Bietet eine einfache API zur Registrierung neuer Clients
    • Unterstützt Hochverfügbarkeit
    • Bietet verschiedene MFA-Optionen wie WebAuthn und OIDC
  • Entwickelt mit Unterstützung von Aura Information Security

Voraussetzungen

  • iptables und libpam müssen installiert sein
  • Wag muss als root ausgeführt werden, um iptables und wireguard-Geräte zu verwalten
  • Forwarding muss in sysctl aktiviert sein 
    sysctl -w net.ipv4.ip_forward=1
  • Solange der Kernel WireGuard unterstützt, benötigt Wag weder wg-quick noch Ähnliches

Installation

Binär-Release (erfordert glibc 2.31+)

curl -L $(curl -s https://api.github.com/repos/NHAS/wag/releases/latest | jq -M -r '.assets[0].browser_download_url') -o wag
sudo ./wag gen-config
sudo ./wag start -config <generated_config_name>

Installation aus dem Quellcode (go1.19, npm, gulp, clang, llvm-strip, libbpf erforderlich)

git clone git@github.com:NHAS/wag.git
cd wag
make
cp example_config.json config.json
sudo ./wag start
  • Wenn es hinter einem Reverse Proxy läuft, muss X-Forwarded-For gesetzt werden

Verwaltung

Der root-Benutzer kann den Wag-Server mit folgendem Befehl verwalten:

wag subcommand [-options]
  • Unterstützte Unterbefehle: start, cleanup, reload, version, firewall, registration, devices, users, webadmin, gen-config
  • Für jeden Befehl wird eine Nutzungsbeschreibung bereitgestellt

Benutzerleitfaden

Wag installieren

  1. wag und config.json nach /opt/wag kopieren
  2. Mit wg genkey einen privaten WireGuard-Schlüssel erzeugen und ihn in der Beispielkonfiguration unter PrivateKey eintragen
  3. wag.service nach /etc/systemd/system/ kopieren (oder verlinken) und den Dienst starten/aktivieren

Neues Registrierungs-Token erstellen

# ./wag registration -add -username tester

token,username
e83253fd9962c68f73aa5088604f3f425d58a963bfb5c0889cca54d63a34b2e3,tester

Token per curl abrufen:

curl http://public.server.address/register_device/…

Der Dienst gibt eine vollständige Antwort zurück. Diese kann als Konfigurationsdatei gespeichert werden.

MFA durchführen

Benutzer verbinden sich mit der VPN-Adresse (z. B. 192.168.1.1:8080) und geben den 2FA-Code ein. Die Sitzungsdauer kann in der Konfigurationsdatei festgelegt werden.

Beim Verwaltungskonsolen anmelden

ManagementUI.Enabled auf true setzen und den folgenden Befehl ausführen:

sudo ./wag webadmin -add -username <your_username> -password <your-password-here>

Mit der Management-Listening-Adresse verbinden und die Anmeldedaten eingeben. Über das Web-Interface können keine Management-Benutzer hinzugefügt werden.

GN⁺-Meinung

  • Beeindruckend ist die Unterstützung von Hochverfügbarkeit durch Clustering. Das dürfte für Disaster Recovery oder unterbrechungsfreie Dienste nützlich sein.

  • Positiv ist auch die Unterstützung verschiedener Authentifizierungsmethoden. Über TOTP, WebAuthn und OIDC lässt es sich vermutlich leicht in die Authentifizierungsinfrastruktur von Unternehmen integrieren.

  • ACL-Regeln lassen sich flexibel definieren, sodass eine feingranulare Zugriffskontrolle möglich erscheint. Zugängliche IPs, Ports und Protokolle können pro Benutzer bzw. Gruppe eingeschränkt werden.

  • Schade ist die fehlende Unterstützung für IPv6. Da der Umstieg auf IPv6 inzwischen aktiv vorangetrieben wird, wäre eine schnelle Unterstützung wünschenswert.

  • Wer nach einer auf Linux spezialisierten VPN-Lösung sucht, dürfte hier eine gute Option finden. Sie läuft auf aktuellen Systemen mit Kernel 5.9 oder neuer.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-13
Hacker-News-Kommentar

Zusammenfassung:

  • Es ist nicht wünschenswert, dass der Server den privaten Schlüssel erzeugt und an den Client sendet. Sinnvoller ist es, wenn der Client den privaten Schlüssel erzeugt und den öffentlichen Schlüssel an den Server übermittelt.
  • Im Beispiel wird das HTTP-Protokoll verwendet; das ist aus Sicherheitsgründen ungeeignet, daher wird vorgeschlagen, es durch HTTPS zu ersetzen.
  • Es wird eine Möglichkeit benötigt, mit der der Client einen Session-Timeout erkennen kann. Man könnte zum Beispiel erwägen, den Status durch regelmäßiges Prüfen einer URL festzustellen, ähnlich wie bei der Captive-Portal-Erkennung von WLAN.
  • Die Schlüssel von WireGuard fungieren als dauerhafte Session-Schlüssel. Damit dies zu einer vollständigen VPN-Server-Lösung wird, müssen zusätzliche Funktionen implementiert werden, etwa ein regelmäßiger Wechsel der Session-Schlüssel, das Beenden von Sessions, das Ändern von IP-Adressen, das Setzen von Routen und bei Bedarf die Erneuerung der Authentifizierung.
  • Es gibt viele Ähnlichkeiten mit Head oder Tailscale; es wäre gut, wenn es Material gäbe, das Funktionsüberschneidungen, Unterschiede und Implementierungspläne vergleicht.
  • Es sollten Schutzmaßnahmen gegen Brute-Force-Angriffe auf TOTP-Codes vorgesehen werden. Denkbar wären zum Beispiel Rate-Limits für Anfragen oder eine Begrenzung der Anzahl von Versuchen.
  • Bei einer Site, die sich für WireGuard entschieden hat, ist zu erwarten, dass aktuelle Konfigurationen verwendet werden; daher dürfte IPv6-ULA (Unique Local Address) dort einen hohen Nutzwert haben.