Show HN: Sistema de autenticación multifactor y registro Wag para WireGuard

 (github.com/NHAS)
1 puntos por GN⁺ 2024-05-13 | 1 comentarios | Compartir por WhatsApp

Funciones principales de WagWag

  • Agrega MFA, restricciones de rutas y registro de dispositivos a WireGuard
    • Permite definir rutas que requieren autenticación MFA o rutas que siempre son accesibles públicamente
    • Proporciona una API simple para registrar nuevos clientes
    • Soporta alta disponibilidad
    • Ofrece varias opciones de MFA como Webauthn y OIDC
  • Desarrollado con apoyo de Aura Information Security

Requisitos

  • Deben estar instalados iptables y libpam
  • Wag debe ejecutarse como root para administrar iptables y los dispositivos wireguard
  • El reenvío debe estar habilitado en sysctl 
    sysctl -w net.ipv4.ip_forward=1
  • Wag no necesita wg-quick ni similares siempre que el kernel soporte WireGuard

Método de instalación

Release binario (requiere 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>

Instalación desde el código fuente (requiere go1.19, npm, gulp, clang, llvm-strip, libbpf)

git clone git@github.com:NHAS/wag.git
cd wag
make
cp example_config.json config.json
sudo ./wag start
  • Si se ejecuta detrás de un reverse proxy, se debe configurar X-Forwarded-For

Administración

El usuario root puede administrar el servidor wag con un comando como este:

wag subcommand [-options]
  • Subcomandos soportados: start, cleanup, reload, version, firewall, registration, devices, users, webadmin, gen-config
  • Incluye explicación de uso para cada comando

Guía de usuario

Instalar Wag

  1. Copiar wag y config.json a /opt/wag
  2. Generar una clave privada de WireGuard con wg genkey y configurarla en PrivateKey dentro de la configuración de ejemplo
  3. Copiar (o enlazar) wag.service a /etc/systemd/system/ y luego iniciar/habilitar el servicio

Crear un nuevo token de registro

# ./wag registration -add -username tester

token,username
e83253fd9962c68f73aa5088604f3f425d58a963bfb5c0889cca54d63a34b2e3,tester

Obtener el token con curl:

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

El servicio devuelve una respuesta completa que puede guardarse como archivo de configuración.

Realizar MFA

El usuario se conecta a la dirección VPN (por ejemplo, 192.168.1.1:8080) e ingresa el código 2FA. La duración de la sesión puede definirse en el archivo de configuración.

Iniciar sesión en la consola de administración

Configura ManagementUI.Enabled como true y ejecuta el siguiente comando:

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

Conéctate a la dirección de escucha de administración e ingresa las credenciales. No es posible agregar usuarios administradores desde la interfaz web.

Opinión de GN⁺

  • Es impresionante que soporte alta disponibilidad mediante funciones de clustering. Parece útil para recuperación ante desastres o servicios sin interrupciones.

  • También es positivo que soporte varios métodos de autenticación. Con TOTP, WebAuth y OIDC, parece fácil integrarlo con los sistemas de autenticación de una empresa.

  • Como permite definir reglas ACL de forma flexible, parece posible tener un control de acceso detallado. Se pueden restringir por usuario/grupo las IP, puertos y protocolos accesibles.

  • Es una lástima que no soporte IPv6. Hoy en día la migración a IPv6 avanza bastante, así que parece necesario que lo agreguen pronto.

  • Si buscas una solución VPN especializada para Linux, parece una buena opción. Funciona en sistemas recientes con kernel 5.9 o superior.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-05-13
Comentario de Hacker News

Resumen:

  • No es recomendable que el servidor genere la clave privada y la envíe al cliente. Lo apropiado es que el cliente genere la clave privada y envíe la clave pública al servidor.
  • En el ejemplo se está usando el protocolo HTTP, pero no es adecuado desde el punto de vista de la seguridad, por lo que se sugiere reemplazarlo por HTTPS.
  • Hace falta una forma de que el cliente pueda detectar cuando expire la sesión. Por ejemplo, se podría considerar un método para verificar periódicamente el estado revisando una URL, similar a la detección de portal cautivo en Wi-Fi.
  • Las claves de WireGuard funcionan como claves de sesión permanentes, por lo que, para convertirse en una solución completa de servidor VPN, haría falta implementar funciones adicionales como rotación periódica de claves de sesión, finalización de sesión, cambio de dirección IP, configuración de rutas y, cuando sea necesario, renovación de la autenticación.
  • Tiene bastantes similitudes con Head o Tailscale; sería bueno contar con material que compare la superposición de funciones, las diferencias y los planes de implementación.
  • Deberían existir medidas para prevenir ataques de fuerza bruta contra los códigos TOTP. Por ejemplo, se podrían considerar límites de velocidad en las solicitudes y límites en la cantidad de intentos.
  • Si un sitio eligió WireGuard, es esperable que use configuraciones modernas, por lo que es probable que el uso de ULA (Unique Local Address) de IPv6 sea alto.