Seguridad de WireGuard: guía para endurecer tu VPN

WireGuard fija su criptografía en un solo conjunto: handshake basado en Noise con Curve25519, ChaCha20-Poly1305, BLAKE2s, SipHash24 y HKDF. En Linux corre en el espacio del kernel. Lo que no resuelve por sí solo es el host comprometido, el patrón de tráfico visible ni la fuga de una llave privada. El endurecimiento real está en el sistema operativo, en la llave precompartida opcional y en reglas de firewall con estado y conscientes de la interfaz.

Qué protege WireGuard por diseño

WireGuard no negocia suites de cifrado, las trae fijas. Eso elimina toda una categoría de errores de configuración. En Linux la ruta de datos vive en el kernel, lo que la vuelve eficiente y predecible.

Lo que cubre de forma predeterminada

• Autenticación fuerte de pares: cada peer se identifica con una llave pública. Los paquetes de llaves desconocidas se descartan de inmediato, sin usuarios ni cadenas de certificados.
• Protección completa de los datos: todo el tráfico va cifrado y autenticado con criptografía AEAD moderna. Un paquete alterado o corrupto nunca llega a tus aplicaciones.
• Forward secrecy: las llaves de sesión rotan de forma automática en handshakes breves. Si una se ve comprometida más adelante, las comunicaciones anteriores siguen protegidas.
• Movilidad de red: los endpoints pueden cambiar de dirección IP, por ejemplo en redes móviles o en un failover, sin reconfigurar los peers. La identidad criptográfica no se mueve.
• Superficie de ataque mínima: la implementación se cita habitualmente en unas 4.000 líneas de código, lo que reduce los casos borde que suelen aprovechar los atacantes. [VERIFY]

Lo que WireGuard no puede resolver solo

• El patrón de tráfico queda visible: quien monitorea la red puede identificar conexiones de WireGuard por el patrón de sus paquetes UDP y por análisis de tiempos. La ofuscación, según la documentación oficial, corresponde a una capa superior.
• Exposición de identidad en el handshake: los paquetes de datos tienen forward secrecy, pero un handshake puede revelar quién inició la conexión si más adelante se comprometen las llaves junto con los registros de tráfico.
• Seguridad del host: si el servidor o el cliente cae, el túnel cae con él. El endurecimiento del sistema operativo y la gestión disciplinada de llaves siguen siendo tu tarea.
• Criptografía post-cuántica: la criptografía actual no es resistente a ataques cuánticos de forma predeterminada. La llave precompartida agrega una capa de secreto post-cuántico, aunque por sí sola no convierte el handshake en post-cuántico.

Las limitaciones y sus mitigaciones están documentadas en la página oficial de limitaciones conocidas de WireGuard.

WireGuard autentica peers y protege paquetes, y se mantiene lo bastante simple para auditarlo a fondo. Lo que te toca a ti es combinarlo con un host endurecido, una gestión de llaves ordenada y políticas de firewall precisas. Esa combinación conserva la ventaja de rendimiento y cierra los huecos que los atacantes reales aprovechan.

El paso decisivo: asegurar el host del VPS

Empieza por el sistema operativo. Hasta el protocolo VPN más sólido falla si la máquina que lo aloja está comprometida.

Sistema actualizado y mínimo

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y
sudo apt install unattended-upgrades -y

El último paquete activa las actualizaciones de seguridad automáticas.

Endurecer SSH

SSH es tu superficie de ataque principal. Ciérrala antes de instalar WireGuard:

# Respalda la configuración inicial de SSH
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

# Edita la configuración
sudo nano /etc/ssh/sshd_config

Dentro del archivo, desactiva el acceso de root y la autenticación por contraseña, deja solo llaves y cambia el puerto:

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

# Limita quién puede entrar por SSH
AllowUsers tuusuario

En versiones de OpenSSH anteriores a la 8.7 la directiva se llamaba ChallengeResponseAuthentication. El nombre antiguo todavía funciona como alias, pero en instalaciones actuales conviene usar KbdInteractiveAuthentication.

Revisa la sintaxis y reinicia el servicio:

sudo sshd -t
sudo systemctl restart sshd

Mantén siempre una segunda sesión SSH abierta mientras cambias esto. Si algo sale mal, es tu única vía de regreso.

Seguridad de las llaves de WireGuard

Genera las llaves con permisos correctos desde el principio:

umask 077
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
sudo chmod 600 /etc/wireguard/privatekey

Nunca guardes una llave privada en un repositorio ni la envíes por un canal sin cifrar.

Firewall básico con iptables

Este camino funciona en cualquier distribución. Primero las reglas que permiten, al final la política de denegar por defecto. Ten una segunda sesión SSH abierta también aquí:

# Loopback y conexiones ya establecidas
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# SSH y WireGuard
sudo iptables -A INPUT -p tcp --dport 2222 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A INPUT -p udp --dport 51820 -m conntrack --ctstate NEW -j ACCEPT

# Políticas predeterminadas
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Usar el puerto 2222 en lugar del 22 no es una medida de seguridad en sí misma, pero reduce el ruido de los escaneos automáticos en los registros.

Si tienes IPv6 activo, repite las mismas reglas con ip6tables. Para que sobrevivan a un reinicio en Debian y Ubuntu:

sudo apt install -y iptables-persistent && sudo netfilter-persistent save

La vía sencilla en Ubuntu con UFW

UFW está pensado para Ubuntu. En otras distribuciones tendrías que instalarlo y habilitarlo, o quedarte con iptables:

sudo apt update && sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 51820/udp
sudo ufw enable

Autenticación solo con llaves

En instalaciones modernas de OpenSSH puedes dejar el archivo principal intacto y escribir un fragmento propio:

sudo tee /etc/ssh/sshd_config.d/99-keys-only.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
EOF

# Recarga sin cortar las sesiones activas (el nombre del servicio varía por distribución)
sudo systemctl reload ssh || sudo systemctl reload sshd

# Prueba rápida desde otra terminal (ajusta usuario, host y puerto)
ssh -p 2222 [email protected] -- true

Una capa extra: la llave precompartida

La llave precompartida, o PSK, es un secreto simétrico opcional que se mezcla con el handshake normal de llaves públicas. Aunque alguien obtuviera después una llave privada o hubiera grabado el tráfico, la barrera criptográfica sube de forma considerable.

Tiene sentido en enlaces site-to-site y en entornos con requisitos de cumplimiento. La documentación oficial la menciona como capa de secreto post-cuántico.

Configuración

Genera una PSK distinta para cada par servidor-cliente:

umask 077
wg genpsk | sudo tee /etc/wireguard/psk-client1 >/dev/null
sudo chmod 600 /etc/wireguard/psk-client1

Después agrega la línea en la sección [Peer] de ambos lados:

PresharedKey = <contenido de /etc/wireguard/psk-client1>

Buenas prácticas

• Una PSK única por conexión. Nunca reutilices la misma en varios peers.
• Rótalas de forma periódica, en ventanas de mantenimiento planificadas.
• Guárdalas con el mismo cuidado que la llave privada, fuera de repositorios y de canales sin cifrar.

Verificación

Ejecuta wg show. Debajo de cada peer debe aparecer preshared key: (hidden), lo que confirma que la PSK está activa.

Cómo evitar fugas de la llave privada

La llave privada es el elemento más sensible del montaje. Trátala como la contraseña de root: no se transmite, no se pega en un chat ni en un ticket y solo root puede leerla. En la práctica, las fugas causan muchos más incidentes que la criptografía.

Generar en local y restringir permisos

Crea las llaves en el host que las va a usar y guárdalas en /etc/wireguard/. Usa sudoedit para editar la configuración, así los secretos no terminan en el historial del shell:

# Crea el directorio con permisos correctos
sudo install -d -m 700 -o root -g root /etc/wireguard

# Genera las llaves sin imprimirlas en la terminal
umask 077
wg genkey | sudo tee /etc/wireguard/privatekey >/dev/null
sudo wg pubkey < /etc/wireguard/privatekey | sudo tee /etc/wireguard/publickey >/dev/null

# Fija propietario y permisos
sudo chown root:root /etc/wireguard /etc/wireguard/*key
sudo chmod 700 /etc/wireguard
sudo chmod 600 /etc/wireguard/*key

Eliminar canales secundarios

• Nada de llaves privadas en argumentos de línea de comandos, capturas o tickets. Aparecen en ps, en registros, en el scrollback y en el portapapeles.
• Desactiva los archivos de intercambio y respaldo del editor cuando toques material de llaves, para no dejar un *.swp o un *~ olvidado.
• Nunca subas una llave privada a Git, ni siquiera a un repositorio privado. Si usas gestión de configuración, deja los secretos en un gestor de secretos y plantilla solo las llaves públicas.
• En los respaldos, excluye /etc/wireguard/*key de las copias en texto claro o cifra el respaldo completo. Al restaurar, conserva propietarios y permisos: buena parte de las fugas ocurre en restauraciones descuidadas.

Rotación y monitoreo ligero

Para rotar con el mínimo de interrupción:

1. En el peer que rota, genera un par nuevo y actualiza el PrivateKey local con sudoedit.
2. En el peer remoto, actualiza el PublicKey correspondiente.
3. Reinicia ambas interfaces y confirma que hay un handshake nuevo.
4. Borra las llaves privadas antiguas y los archivos temporales, y rota las instantáneas que hayan capturado las llaves viejas.

Los comandos del tercer paso:

sudo systemctl restart wg-quick@wg0
wg show

En la salida de wg show te interesan el último handshake y los contadores. Como capa adicional puedes agregar una PSK por peer y reglas de integridad de archivos que vigilen /etc/wireguard/*key ante lecturas o escrituras inesperadas.

Endurecimiento avanzado del firewall

Un buen firewall para WireGuard permite solo el tráfico que tú decides y tolera clientes que cambian de red. Mantén las reglas con estado, atadas a la interfaz y en el plano correcto: primero el grupo de seguridad del proveedor, después el firewall del sistema. Elige UFW, nftables o iptables y quédate con uno.

El principio base es denegar por defecto en INPUT, con un permiso explícito para tu puerto UDP de WireGuard, que por defecto es el 51820, y para el tráfico ESTABLISHED,RELATED. Ata las reglas a interfaces cuando puedas, con iif wg0 u oif wg0, para que la política siga siendo legible. Si el servidor actúa como gateway y enruta una subred a través del túnel, necesitas abrir FORWARD y agregar NAT con MASQUERADE en la interfaz WAN. En un túnel solo entre hosts, deja FORWARD cerrado.

nftables

nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input udp dport 51820 ct state new accept

iptables como gateway

iptables -A FORWARD -i wg0 -o <WAN_IFACE> -j ACCEPT
iptables -A FORWARD -i <WAN_IFACE> -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o <WAN_IFACE> -j MASQUERADE

MSS y PMTU

Cuando enrutas subredes, ajusta el MSS de TCP para que los paquetes no excedan el MTU de la ruta y se pierdan a mitad de camino:

iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

En túneles de host a host que no reenvían subredes esto suele ser innecesario.

Límites de tasa sin sabotearte

Puedes agregar límites suaves de tasa o de ráfaga en UDP para amortiguar el ruido de los escaneos, pero mantenlos conservadores. Un límite muy estricto recorta el pico de throughput o rompe handshakes en enlaces cargados. Mide después de cada cambio.

Reenvío y NAT pueden unir redes y dar la sensación de una VPN, pero no cifran ni autentican nada. El firewall se encarga de la política y del enrutamiento, WireGuard de la identidad y del cifrado. Juntos forman un enlace site-to-site real.

Diagnóstico rápido

• Sin handshake: el puerto UDP 51820 está bloqueado en el grupo de seguridad del proveedor o en el firewall del sistema. Confirma que el servicio escucha con ss -uapn | grep 51820.
• Handshake correcto pero sin tráfico: falta FORWARD o MASQUERADE en un gateway. Agrega las reglas de arriba y vuelve a probar.
• Funciona en un solo sentido: faltan reglas para el camino de regreso. Corre iperf3 -R por el túnel y arregla la dirección contraria.
• Se atora o pide fragmentar: activa el clamping de MSS cuando enrutes y revisa el MTU elegido.

FAQ: seguridad de WireGuard

Por dónde empezar

Si el servidor ya está en producción, arranca por SSH y por la política de denegar por defecto, porque ahí está el riesgo inmediato. Después pasa a los permisos de /etc/wireguard/ y a la rotación de llaves, donde fallan la mayoría de los montajes reales. La PSK y los límites de tasa vienen al final.