WireGuard: cosa c'è di sbagliato in questo assegnazione automatica di IP

5

WireGuard è una VPN kernel-space estremamente semplice e veloce basata sulla crittografia moderna. Voglio usarlo in produzione e ho bisogno dell'assegnazione automatica dell'IP per i nuovi colleghi. Il progetto fornisce due brevi script per server e client che fanno proprio questo. Tuttavia, afferma :

Do not use these scripts in production. They are simply a demonstration of how easy the wg(8) tool is at the command line, but by no means should you actually attempt to use these. They are horribly insecure and defeat the purpose of WireGuard. STAY AWAY!

Gli script sono:
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

Client :

#!/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

Domande:

  1. Cosa c'è di sbagliato in quegli script? Qual è il caso peggiore?
  2. C'è un modo per risolvere questi problemi?
  3. Qualcuno potrebbe scrivere un breve commento su ciascuna riga di questi script?

Aggiornamento: l'autore di WireGuard ha dichiarato che "Il problema è che utilizza TCP non autenticato." Allora, qual è il caso peggiore e come può essere risolto? Si può fornire questo socket TCP all'interno di un tunnel SSH?

    
posta user1876484 17.04.2018 - 10:31
fonte

2 risposte

3

Il problema si riduce al terzo punto. non sai cosa fa senza leggerlo in dettaglio e contiene un bel po 'di codice non pulito.

Probabilmente "funziona", ma se qualcosa va storto non viene implementata alcuna gestione degli errori. Inoltre, lo schermo recupera alcune utilità di shell senza sapere se il loro formato di output è corretto. Forse aggiorni la tua distribuzione, ottieni una nuova versione di uno degli strumenti e improvvisamente lo script fallisce.

What is the worst case

Alcuni dei parsing dell'output falliscono e il comando successivo ottiene un output confuso e cancella /home . Non come un risultato effettivo dell'analisi dello script, ma qualcosa che potrebbe accadere con gli script della shell senza una corretta gestione degli errori e fatto in passato (cioè rm -r $uninitialized/* ).

L'errore più probabile che si verifichi è quello di lasciarti con una rete guasta e come devi chiedere spiegazioni sul copione (che va bene. Avrei bisogno di studiarlo parecchio tempo prima di comprenderne pienamente i rischi) questo sarebbe probabilmente ti costringono a riavviare per riportare il sistema in uno stato coerente.

Questo non è di per se insicuro , ma è sciatto e potrebbe non essere sicuro. Per uno script che funziona come root e imposta cose importanti, dovrebbe esserci un'attenta gestione degli errori per ogni cosa che potrebbe fallire.

L'idea generale è che tutto rischia di essere insicuro finché non si dimostra sicuro. Si può provare a verificare lo script se è sicuro, ma non ne vale la pena in quanto vi sono diversi anti-pattern (cioè l'output di analisi che non è garantito (ancora) per essere stabile, l'elaborazione degli IP con espressioni regolari, nessuna pulizia quando una linea fallisce) che rendono consigliabile riscriverlo in modo più sicuro.

Le persone possono ad esempio affidarsi alla VPN per impedire l'invio di dati aziendali riservati non crittografati su Internet. Quando lo script VPN (silenziosamente) non riesce a configurare la VPN, i dati potrebbero essere inviati in modo non sicuro.

Is there a way to fix those issues?

Riscrivendolo con un'attenta gestione degli errori dopo ogni comando. Probabilmente in un linguaggio più adatto di bash e la lettura dei dati utilizzando un'API invece di scansionare altri programmi.

    
risposta data 17.04.2018 - 16:00
fonte
1

Il caso peggiore è che ti stai connettendo direttamente al tuo aggressore e leggi il suo input non criticato.

Questo script collega la tua shell direttamente ad un host esterno, appresa solo dal DNS, probabilmente mezzo mondo, che potrebbe non essere la parte che ti aspetti, dal momento che un MITM selettivo funzionerebbe abbastanza bene.

    
risposta data 14.06.2018 - 23:15
fonte

Leggi altre domande sui tag