Show HN : Wag, système d’authentification multifacteur et d’inscription pour WireGuard

 (github.com/NHAS)
1 points par GN⁺ 2024-05-13 | 1 commentaires | Partager sur WhatsApp

Principales fonctionnalités de Wag

  • Ajoute à Wireguard la MFA, la restriction des routes et l’enregistrement des appareils
    • Possibilité de définir des routes nécessitant une authentification MFA ou des routes toujours accessibles publiquement
    • Fournit une API simple pour enregistrer de nouveaux clients
    • Prise en charge de la haute disponibilité
    • Propose diverses options MFA comme Webauthn, OIDC, etc.
  • Développé avec le soutien d’Aura Information Security

Prérequis

  • iptables et libpam doivent être installés
  • Wag doit être exécuté en root pour gérer iptables et les périphériques wireguard
  • Le forwarding doit être activé dans sysctl 
    sysctl -w net.ipv4.ip_forward=1
  • Tant que le noyau prend en charge wireguard, Wag n’a pas besoin de wg-quick ni d’autres outils du même type

Installation

Release binaire (glibc 2.31+ requis)

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 depuis les sources (go1.19, npm, gulp, clang, llvm-strip, libbpf requis)

git clone git@github.com:NHAS/wag.git
cd wag
make
cp example_config.json config.json
sudo ./wag start
  • Si l’application tourne derrière un reverse proxy, il faut configurer X-Forwarded-For

Administration

L’utilisateur root peut administrer le serveur wag avec une commande de la forme suivante :

wag subcommand [-options]
  • Sous-commandes prises en charge : start, cleanup, reload, version, firewall, registration, devices, users, webadmin, gen-config
  • Une aide d’utilisation est fournie pour chaque commande

Guide utilisateur

Installer Wag

  1. Copier wag et config.json dans /opt/wag
  2. Générer une clé privée WireGuard avec wg genkey, puis la renseigner dans PrivateKey de l’exemple de configuration
  3. Copier (ou lier) wag.service dans /etc/systemd/system/, puis démarrer/activer le service

Générer un nouveau jeton d’inscription

# ./wag registration -add -username tester

token,username
e83253fd9962c68f73aa5088604f3f425d58a963bfb5c0889cca54d63a34b2e3,tester

Récupérer le jeton avec curl :

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

Le service renvoie une réponse complète, qui peut être enregistrée comme fichier de configuration.

Effectuer la MFA

L’utilisateur se connecte à l’adresse VPN (par exemple 192.168.1.1:8080) et saisit son code 2FA. La durée de vie de la session peut être définie dans le fichier de configuration.

Se connecter à la console d’administration

Définir ManagementUI.Enabled sur true, puis exécuter la commande suivante :

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

Se connecter à l’adresse d’écoute d’administration et saisir les identifiants. Il n’est pas possible d’ajouter des utilisateurs d’administration via l’interface web.

Avis de GN⁺

  • La prise en charge de la haute disponibilité via les fonctions de clustering est impressionnante. Cela semble utile pour la reprise après sinistre ou les services sans interruption.

  • Le support de plusieurs méthodes d’authentification est aussi un point fort. TOTP, WebAuth, OIDC, etc. devraient permettre une intégration facile avec les systèmes d’authentification d’entreprise.

  • Les règles ACL peuvent être définies de manière souple, ce qui semble permettre un contrôle d’accès fin. Il est possible de limiter les IP, ports et protocoles accessibles par utilisateur ou par groupe.

  • L’absence de prise en charge d’IPv6 est regrettable. Avec l’accélération actuelle de la transition vers IPv6, un support rapide paraît nécessaire.

  • Si vous cherchez une solution VPN spécialisée pour Linux, cela semble être une bonne option. Elle fonctionne sur des systèmes récents avec un noyau 5.9 ou supérieur.

À lire aussi

1 commentaires

 
GN⁺ 2024-05-13
Commentaire Hacker News

Résumé :

  • Il n’est pas souhaitable que le serveur génère la clé privée et l’envoie au client. Il est préférable que le client génère la clé privée et transmette la clé publique au serveur.
  • L’exemple utilise le protocole HTTP, ce qui n’est pas approprié du point de vue de la sécurité ; il est recommandé de le remplacer par HTTPS.
  • Il faut un moyen pour que le client puisse détecter l’expiration de la session. On peut par exemple envisager une vérification périodique d’une URL pour confirmer l’état, comme le mécanisme de détection de portail captif du Wi‑Fi.
  • Les clés WireGuard jouent le rôle de clés de session permanentes ; pour devenir une solution de serveur VPN complète, il faut donc ajouter des fonctionnalités comme la rotation périodique des clés de session, la fin de session, le changement d’adresse IP, la configuration du routage et, si nécessaire, le renouvellement de l’authentification.
  • Il y a beaucoup de similitudes avec Head ou Tailscale ; il serait utile d’avoir une ressource comparant les recouvrements fonctionnels, les différences et les plans d’implémentation.
  • Il faut prévoir des mesures de protection contre les attaques par force brute sur les codes TOTP, par exemple une limitation du débit des requêtes ou du nombre de tentatives.
  • Sur un site ayant choisi WireGuard, on peut s’attendre à l’usage de configurations récentes, ce qui rendra probablement l’utilisation des ULA (Unique Local Address) en IPv6 particulièrement pertinente.