WireGuard: ¿qué hay de malo con esta asignación automática de IP?

5

WireGuard es una VPN de kernel-espacio extremadamente simple y rápida basada en la criptografía moderna. Quiero usarlo en producción y necesito la asignación automática de IP para nuevos pares. El proyecto proporciona dos scripts cortos para el servidor y el cliente que hacen esto. Sin embargo, indica :

  

No utilice estos scripts en producción. Son simplemente un   demostración de lo fácil que es la herramienta wg(8) en la línea de comando, pero   de ninguna manera deberías intentar usar estos. Son   horriblemente inseguros y derrotan el propósito de WireGuard.                        ¡Mantente alejado!

Los scripts son:
Server :

#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
#
# Copyright (C) 2015-2018 Jason A. Donenfeld <[email protected]>. All Rights Reserved.

if [[ -z $NCAT_REMOTE_ADDR ]]; then
    ip link del dev wg0 2>/dev/null
    set -e
    ip link add dev wg0 type wireguard
    ip address add 192.168.4.1/24 dev wg0
    wg set wg0 private-key <(wg genkey) listen-port 12912
    ip link set up dev wg0
    exec ncat -e "$(readlink -f "$0")" -k -l -p 42912 -v
fi
read -r public_key
[[ $(wg show wg0 peers | wc -l) -ge 253 ]] && wg set wg0 peer $(wg show wg0 latest-handshakes | sort -k 2 -b -n | head -n 1 | cut -f 1) remove
next_ip=$(all="$(wg show wg0 allowed-ips)"; for ((i=2; i<=254; i++)); do ip="192.168.4.$i"; [[ $all != *$ip/32* ]] && echo $ip && break; done)
wg set wg0 peer "$public_key" allowed-ips $next_ip/32 2>/dev/null && echo "OK:$(wg show wg0 private-key | wg pubkey):$(wg show wg0 listen-port):$next_ip" || echo ERROR

Cliente :

#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
#
# Copyright (C) 2015-2018 Jason A. Donenfeld <[email protected]>. All Rights Reserved.

set -e
[[ $UID == 0 ]] || { echo "You must be root to run this."; exit 1; }
umask 077
trap 'rm -f /tmp/wg_private_key' EXIT INT TERM
exec 3<>/dev/tcp/demo.wireguard.com/42912
wg genkey | tee /tmp/wg_private_key | wg pubkey >&3
IFS=: read -r status server_pubkey server_port internal_ip <&3
[[ $status == OK ]]
ip link del dev wg0 2>/dev/null || true
ip link add dev wg0 type wireguard
wg set wg0 private-key /tmp/wg_private_key peer "$server_pubkey" allowed-ips 0.0.0.0/0 endpoint "demo.wireguard.com:$server_port" persistent-keepalive 25
ip address add "$internal_ip"/24 dev wg0
ip link set up dev wg0
if [ "$1" == "default-route" ]; then
    host="$(wg show wg0 endpoints | sed -n 's/.*\t\(.*\):.*//p')"
    ip route add $(ip route get $host | sed '/ via [0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/{s/^\(.* via [0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\).*//}' | head -n 1) 2>/dev/null || true
    ip route add 0/1 dev wg0
    ip route add 128/1 dev wg0
fi

Preguntas:

  1. ¿Qué está mal con esos scripts? ¿Cuál es el peor de los casos?
  2. ¿Hay alguna manera de solucionar esos problemas?
  3. ¿Podría alguien escribir un breve comentario sobre lo que hace cada línea de esos scripts?

Actualización: el autor de WireGuard ha declarado que "el problema es que utiliza TCP no autenticado". Entonces, ¿cuál es el peor de los casos y cómo se puede arreglar? ¿Se puede proporcionar este socket TCP dentro de un túnel SSH?

    
pregunta user1876484 17.04.2018 - 10:31
fuente

2 respuestas

3

El problema se reduce a su tercer punto. Usted no sabe lo que hace sin leerlo en detalle y contiene bastante código impuro.

Probablemente "simplemente funciona", pero si algo falla no se implementa un manejo de errores. Además, la pantalla elimina algunas utilidades de shell sin saber si su formato de salida es fijo. Tal vez usted actualice su distribución, obtenga una nueva versión de una de las herramientas y, de repente, el script falla.

  

¿Cuál es el peor de los casos

Algunos de los análisis de resultados fallan y el siguiente comando obtiene un resultado confuso y elimina /home . No como un resultado real del análisis de la secuencia de comandos, sino algo que podría suceder con las secuencias de comandos de shell sin el manejo adecuado de errores y sucedió en el pasado (es decir, rm -r $uninitialized/* ).

El error más probable es que lo deje con una red rota y, como tiene que pedir una explicación del script (lo cual está bien. Necesitaría estudiarlo bastante tiempo antes de comprender completamente los riesgos), esto probablemente lo obligue a reiniciar para que el sistema vuelva a estar en un estado consistente.

Esto no es per se inseguro , pero es descuidado y puede ser inseguro. Para un script que se ejecuta como root y configura cosas importantes, debe haber un manejo cuidadoso de errores para cada cosa que pueda fallar.

El dispositivo general es que todo corre el riesgo de ser inseguro hasta que se demuestre que es seguro. Puede intentar verificar el script si es seguro, pero no vale la pena ya que hay varios anti-patrones (es decir, la salida de análisis que no está garantizada (aún) para ser estable, procesando IPs con expresiones regulares, no hay limpieza cuando una línea falla), por lo que es recomendable volver a escribirlo de una manera más segura.

Las personas pueden, por ejemplo, confiar en la VPN para evitar el envío de datos confidenciales de la empresa sin cifrar a través de Internet. Cuando la secuencia de comandos de VPN (en silencio) no tuvo éxito en la configuración de la VPN, los datos pueden enviarse de forma insegura.

  

¿Hay alguna manera de solucionar esos problemas?

Reescribiéndolo con un manejo cuidadoso de errores después de cada comando. Probablemente en un lenguaje más adecuado que bash y leer los datos utilizando una API en lugar de raspar la pantalla con otros programas.

    
respondido por el allo 17.04.2018 - 16:00
fuente
1

El peor de los casos es que te estás conectando directamente con tu atacante y lees comentarios no autorizados de él.

Este script conecta su shell directamente a un host externo que solo se aprende de DNS, probablemente en la mitad del mundo, lo que podría no ser la fiesta que espera, ya que un MITM selectivo funcionaría bastante bien.

    
respondido por el Matthias š 14.06.2018 - 23:15
fuente

Lea otras preguntas en las etiquetas