Cos'è wireguard e come si configura, lo sappiamo ma mi serviva qualcosa che mi permettesse di fare provisioning e deprovisioning dei certificati in maniera più semplice di quanto già si faccia con i tool disponibili nella userland, wg e wg-quick.

E questo è il motivo principale per cui è nato questo script. Prende come riferimento una configurazione road warrior, il primo scenario di una topologia point-to-site, quella più comune.

Alcune considerazioni

1. Lo script definisce una workdir dove deposita tutte le configurazioni e i certificati. Le precondizioni sono legate alla presenza dei tool userland wg-tools (ovviamente) e di ufw. Vengono comunque verificate nello script.

2. Altra semplificazione è data dal fatto di allocare una /24 come rete wireguard. 254 host per una rete domestica sono più che sufficienti.

3. L'allocazione degli ip viene fatta con un progressivo memorizzato nel file 'ip_renew'. Gli ip dei certificati revocati vengono mantenuti in un file, 'ip_release'. Quando si crea un nuovo certificato, si controlla prima che ci sia un ip da recuperare in ip_release. Se la lista è vuota si ricorre al progressivo.

4. La creazione della configurazione lato server passa da due file di configurazione: una configurazione globale ottenuta tracciando l'evoluzione iniziale in termini di aggiunta o rimozione dei client peer e destinata al rilascio in esecuzione. L'altra contenente la sola configurazione del server e usata unicamente per la rigenerazione della configurazione globale a partire dai peer esistenti.

5. L'operazione di init è propedeutica per addclient, removeclient, rebuild, deploy, share.

Le operazioni a disposizione sono:

• init: inizializza la configurazione di un server wireguard
• addclient: crea il certificato lato client e aggiunge il relativo peer sulla configurazione del server
• removeclient: cancella il certificato lato client e rimuove il relativo peer sulla configurazione del server
• rebuild: rigenera la configurazione del server usando i certificati client esistenti
• deploy: finalizza la configurazione riavviando il servizio con le nuove impostazioni
• share: crea i qr-code per i certificati client da utilizzare nelle configurazioni

Per tutto il resto, i commenti nel codice sono abbastanza esplicativi.

Lo script

#!/bin/bash

# Questo è il file di configurazione globale, i dati sono fittizi.
# Può essere mantenuto nello script o nella home dell'utente 
# (es. $HOME/.config/wg_man.conf) e importato 
# con 'source' all'inizio.
WG_INTERFACE=wg0
PHYSICAL_INTERFACE=eth0
NETWORK="192.168.15.0"
SUBNET_MASK="24"
SERVER_IP_ADDRESS="192.168.15.1"
DNS="1.1.1.1"
LISTEN_PORT="51820"
ENDPOINT=wireguard.nodns.net:51820"
WORKDIR="$HOME/wireguard"



check_dependency() {
    if test -e /usr/sbin/ufw; then
        if test -e /usr/bin/wg; then
            return 0
        else
            return 2
        fi
    else
        return 1
    fi
}



is_init() {
    test -e ${WORKDIR}/conf.d/server_wg.conf && return 0 || return 1
}



# Genera la chiave privata
gen_priv_key() {
    wg genkey | tee ${WORKDIR}/keys/$1_privkey
}



# Genera la pre-shared key
gen_client_psk() {
    # Evita il warning sui permessi del file che devono essere 600
    umask 077
    wg genpsk | tee ${WORKDIR}/psk/$1_psk
}



# Rilascio di un nuovo indirizzo ip. Questa funziona viene invocata da
# addclient().
#
# I primi 3 ottetti li ottengo dalla variabile globale NETWORK.
# L'ultimo ottetto, relativo all'host, lo ricavo dalla lista degli ip
# riutilizzabili ("ip_release").
#
# Se non è vuota, prelevo il primo e lo rimuovo dalla lista. Se è vuota,
# prelevo l'ultimo ottetto da "ip_renew" e lo incremento per il successivo
# assegnamento.
ip_renew() {
    # Selezioni i primi 3 ottetti del network
    SUB_IP=$(echo ${NETWORK}|awk -F "." '{print $1"."$2"."$3}')

    if [[ ! -e ${WORKDIR}/conf.d/ip_release || ! -s ${WORKDIR}/conf.d/ip_release ]]; then
        # Genero il nuovo ip (Incremento di 1 l'ultimo ottetto)
        IP=$(cat ${WORKDIR}/conf.d/ip_renew)
        echo $((++IP)) > ${WORKDIR}/conf.d/ip_renew

        # Restituisco i 3 ottetti + il quarto
        #echo -n ${SUB_IP};cat ${WORKDIR}/conf.d/ip_renew
    else
        IP=$(head -n 1 ${WORKDIR}/conf.d/ip_release)
        sed -i "1d" ${WORKDIR}/conf.d/ip_release
    fi
    echo -n ${SUB_IP}"."${IP}
}



# Riallocazione di un indirizzo ip. Questa funzione viene invocata da
# removeclient().
# Aggiungo l'ultimo ottetto alla lista degli ip riallocabili.
# @par 1: ultimo ottetto.
ip_release() {
    echo $1|cut -d"." -f 4 >> ${WORKDIR}/conf.d/ip_release
}



# Aggiunge il nuovo peer al file di configurazione del server
# @par 1: CLIENT_PUBLIC_KEY
# @par 2: CLIENT_PSK
# @par 3: CLIENT_IP_ADDRESS
# @par 4: CLIENT_NAME
add_peer_to_server() {
    cat >> ${WORKDIR}/conf.d/server_wg.conf << EOF
# $4
[Peer]
PublicKey = $1
PresharedKey = $2
AllowedIPs = $3/32
PersistentKeepalive = 25

EOF
}



# Inizializza la configurazione del server wireguard.
#
# Questa operazione può essere fatta una sola volta a meno che non si
# cancelli tutta la workdir.
#
# Verranno creati due file  di configurazione: server_wg.conf e 
# server_wg_raw.conf
#
# Il primo conterrà la configurazione completa del server e dei peer,
# verrà aggiornato ad ogni modifica dei client (aggiunta o rimozione) e
# verrà usato per il deploy della configurazione.
#
# Il secondo conterrà la configurazione del solo server e verrà usato
# solo per rigenerare il primo file di configurazione.
init() {
    # Controllo che wireguard sia almeno abilitato
    echo -n "Inserire la password di Amministratore: "; read -s PASSWORD
    sudo -k
    if echo $PASSWORD|sudo -S echo "got a root" > /dev/null; then
        if ! sudo systemctl is-enabled --quiet wg-quick@${WG_INTERFACE}; then
            echo -en "\nAttivazione servizio wireguard... "
            #sudo systemctl enable --quiet wg-quick@${WG_INTERFACE}
            echo "fatto."
        fi
        sudo -k 
        
        #Verifico che queste cartelle esistano. Se lo sono, non faccio nulla, se no le creo.
        echo -n "Creazione workdir... "
        [[ ! -e ${WORKDIR}/conf.d || ! -e ${WORKDIR}/psk  || ! -e ${WORKDIR}/keys ]] \
            && { mkdir -p ${WORKDIR}/{conf.d,keys,psk}; } \
            || { echo "inizializzazione già effettuata."; exit; }
        echo "fatto."
        
        # Genero la chiave privata per il server
        echo -n "Creazione chiave private del server..."
        SERVER_PRIV_KEY=$(gen_priv_key "server_wg")
        echo "fatto."

        # Genero il file di configurazione
        echo -n "Inizializzazione del server... "
        cat > ${WORKDIR}/conf.d/server_wg.conf << EOF
[Interface]
Address = ${SERVER_IP_ADDRESS}/${SUBNET_MASK}
# SaveConfig = true

PreUp = ufw route allow in on ${WG_INTERFACE} out on ${PHYSICAL_INTERFACE} log from ${NETWORK}/${SUBNET_MASK} to 0.0.0.0/0
PostDown = ufw route delete allow in on ${WG_INTERFACE} out on ${PHYSICAL_INTERFACE} log from ${NETWORK}/${SUBNET_MASK} to 0.0.0.0/0

# IP masquerading
PreUp = iptables -t nat -A POSTROUTING -o ${PHYSICAL_INTERFACE} -s ${NETWORK}/${SUBNET_MASK} -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o ${PHYSICAL_INTERFACE} -s ${NETWORK}/${SUBNET_MASK} -j MASQUERADE

# IP filtering
PreUp = ufw allow in on ${PHYSICAL_INTERFACE} log to 0.0.0.0/0 app Wireguard
PostDown = ufw delete allow in on ${PHYSICAL_INTERFACE} log to 0.0.0.0/0 app Wireguard

ListenPort = ${LISTEN_PORT}
PrivateKey = ${SERVER_PRIV_KEY}

EOF
        echo "fatto."
        cp ${WORKDIR}/conf.d/server_wg.conf ${WORKDIR}/conf.d/server_wg_raw.conf
        # Inizializza l'erogatore di ip
        echo 1 > ${WORKDIR}/conf.d/ip_renew
    else
        echo "Sono necessarie le credenziali di amministrazione per eseguire questo comando."
        exit 1
    fi
}



# Genera un certificato per il client composto da:
# * chiave privata del client
# * chiave pre-condivisa
# * client ip
# * chiave pubblica del server
# * nome simbolico del client
#
# Dopo la creazione e il salvataggio in <WORKDIR>/conf.d, verrà aggiunto
# il relativo peer nella configurazione del server (server_wg.conf).
# @par_1 @par_2 @par_3...: lista di nomi relativi ai certificati da creare.
add_client() {
    if is_init; then
        # Se non c'è alcun input, esco.
        if [[ $# -lt 1 ]]; then
            echo -e "Devi inserire almeno un nome."
            exit 1
        else
            # Per ogni nome presente in input, creo una configurazione 
            # client e l'aggiungo alla configurazione del server.
            for CLIENT_NAME in "$@"; do
                echo -n "Creazione certificato per il client \"${CLIENT_NAME}\"... "
                
                # Controllo se la configurazione esista già discriminando
                # in base al nome del file.
                if [[ -e ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf ]]; then
                    echo "già esistente."
                else
                    # Creo la configurazione del client
                    CLIENT_PRIV_KEY=$(gen_priv_key ${CLIENT_NAME})
                    CLIENT_PUBLIC_KEY=$(echo ${CLIENT_PRIV_KEY} | wg pubkey)
                    CLIENT_PSK=$(gen_client_psk ${CLIENT_NAME})
                    CLIENT_IP_ADDRESS=$(ip_renew)
                    SERVER_PUBLIC_KEY=$(grep PrivateKey ${WORKDIR}/conf.d/server_wg.conf | cut -d " " -f 3 | tr -d " " | wg pubkey)
                    CLIENT_NAME_UPPER=$(echo ${CLIENT_NAME} | tr '[:lower:]' '[:upper:]')
                    cat > ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf << EOF
    # ${CLIENT_NAME_UPPER}
    [Interface]
    Address = ${CLIENT_IP_ADDRESS}/${SUBNET_MASK}
    DNS = ${DNS}
    PrivateKey = ${CLIENT_PRIV_KEY}

    [Peer]
    PublicKey = ${SERVER_PUBLIC_KEY}
    PresharedKey = ${CLIENT_PSK}
    AllowedIPs = 0.0.0.0/0
    Endpoint = ${ENDPOINT}
    PersistentKeepalive = 25
EOF
                    echo "fatto."
                    echo -n "Aggiunta peer \"${CLIENT_NAME}\" al file di configurazione del server... "
                    
                    # Aggiungo il peer alla configurazione del server.
                    add_peer_to_server ${CLIENT_PUBLIC_KEY} ${CLIENT_PSK} ${CLIENT_IP_ADDRESS} ${CLIENT_NAME_UPPER}
                    echo -e "fatto.\n"                
                fi
            done
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



# Rimuove file di configurazioni, chiavi e pre-shared key realtive a file
# dati in input.
# Rimuove inoltre il peer dal file di configurazione server_wg.conf.
# @par_1 @par_2 @par_3...: lista di nomi relativi ai certificati da rimuovere.
remove_client() {
    if is_init; then
        if [[ $# -lt 1 ]]; then
            echo -e "Devi inserire almeno un nome."
            exit 1
        else
            for CLIENT_NAME in "$@"; do
                echo -n "Rimozione client \"${CLIENT_NAME}\"... "
                if [[ ! -e ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf ]]; then
                    echo "non esistente."
                else
                    # Estraggo l'ultimo ottetto dell'ip del client.
                    IP=$(grep "Address" ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf|cut -d " " -f 3|tr -d " "|cut -d "/" -f 1)
                    
                    # Lo inserisco nella lista degli ip riallocabili.
                    ip_release ${IP}
                    
                    # Cancello file di configurazione, chiave e psk del client.
                    rm ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf ${WORKDIR}/keys/${CLIENT_NAME}_privkey ${WORKDIR}/psk/${CLIENT_NAME}_psk
                    echo "terminata con successo."
                    echo -n "Rimozione peer \"${CLIENT_NAME}\" dal file di configurazione del server... "
                    
                    # Rimuovo il peer dalla configurazione del server.
                    CLIENT_NAME_UPPER=$(echo ${CLIENT_NAME} | tr '[:lower:]' '[:upper:]')
                    sed -i "/# ${CLIENT_NAME_UPPER}/,+6d" ${WORKDIR}/conf.d/server_wg.conf
                    echo -e "terminata con successo.\n"   
                fi
            done
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



rebuild() {
    if is_init; then
        # Rigenero il file di configurazione del server da server_wg_raw.conf.
        echo -n "Ripristino del file di configurazione del server... "
        cat ${WORKDIR}/conf.d/server_wg_raw.conf > ${WORKDIR}/conf.d/server_wg.conf
        echo "fatto."
        
        # Per ogni file di configurazione client, aggiungo il relativo peer
        # nel file di configurazione server_wg.conf.
        for FILE_CONF in ${WORKDIR}/conf.d/client_*.conf; do
            CLIENT_PUBLIC_KEY=$(grep "PrivateKey" ${FILE_CONF}|cut -d " " -f 3|tr -d " " | wg pubkey)
            CLIENT_PSK=$(grep "PresharedKey" ${FILE_CONF}|cut -d " " -f 3|tr -d " ")
            CLIENT_IP_ADDRESS=$(grep "Address" ${FILE_CONF}|cut -d " " -f 3|tr -d " "|cut -d "/" -f 1)
            CLIENT_NAME_UPPER=$(grep "#" ${FILE_CONF} | cut -d " " -f 2)
            echo -n "Aggiunta peer \"$(echo ${CLIENT_NAME_UPPER} | tr '[:upper:]' '[:lower:]')\"... "
            add_peer_to_server ${CLIENT_PUBLIC_KEY} ${CLIENT_PSK} ${CLIENT_IP_ADDRESS} ${CLIENT_NAME_UPPER}
            echo -e "fatto."
        done
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



# Avvia il server wireguard con la nuova configurazione
deploy() {
    if is_init; then
        echo -n "Inserire la password di Amministratore: "; read -s PASSWORD
        sudo -k
        if echo $PASSWORD|sudo -S echo "got a root" > /dev/null; then
   
            # Stoppo il servizio wireguard
            echo -ne "\nStop wireguard... "
            sudo systemctl stop wg-quick@${WG_INTERFACE}
            echo "fatto."
            
            # Aggiorno la configurazione
            echo -n "Copia della nuova configurazione... "
            sudo cp ${WORKDIR}/conf.d/server_wg.conf /etc/wireguard/${WG_INTERFACE}
            echo "fatto."
            
            # Riavvio il servizio wireguard
            echo -n "Riavvio wireguard... "
            sudo systemctl start wg-quick@${WG_INTERFACE}
            echo "fatto."
            
            # Revoco i privilegi di amministrazione
            sudo -k
        else
            echo "Sono necessarie le credenziali di amministrazione per eseguire questo comando."
            exit 1
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



# Crea il qr-code della configurazione del client nella cartella corrente.
share() {
    if is_init; then
        if [[ $# -lt 1 ]]; then
            echo -e "Devi inserire almeno un nome."
            exit 1
        else
            for CLIENT_NAME in "$@"; do
                echo -n "Creazione qr-code per il client \"${CLIENT_NAME}\"... "
                qrencode -r ${WORKDIR}/conf.d/client_${CLIENT_NAME}.conf -o qrcode_client_${CLIENT_NAME}.jpg
                echo "fatto."
            done
        fi
    else
        echo "È necessario inizializzare il server con 'wg_init.sh init'."
        echo "L'operazione richiesta non sarà completata"
    fi
}



help() {

[[ $1 != "" && $1 != "help" ]] && echo -e "Comando inesistente."

    cat<<EOF
Usa come: ./wg_man.sh [command] ARG
dove:
    [command]
        init                     : Inizializza la configurazione del server.
        addclient <lista nomi>   : Aggiunge i client indicati in <lista nomi>.
        removeclient <lista nomi>: Rimuove i client indicati in <lista nomi>.
        rebuild                  : Ricostruisce il file di configurazione
                                   del server partendo dalle configurazioni
                                   di tutti i client registrati.
        deploy                   : Riavvia il server wireguard con l'ultima
                                   configurazione disponibile.
        share <lista nomi>       : Genera i qr-code relativi ai client indicati in <lista nomi>.
        help                     : Stampa questa pagina di help.

ESEMPI:
    INiZIALIZZA IL SERVER WIREGUARD
    wg_man.sh init

    AGGIUNGE I CLIENT 'macbook_pro', 'mobile'
    wg_man.sh addclient macbook_pro mobile

    RIMUOVE I CLIENT 'iphone_luca', 'workstation'
    wg_man.sh removeclient iphone_luca workstation

    RICOSTRUISCE LA CONFIGURAZIONE DEL SERVER WIREGUARD
    wg_man.sh rebuild
    
    ATTIVA LA NUOVA CONFIGURAZIONE
    wg_man.sh deploy

    GENERA I QRCODE PER 'pc_ufficio', 'laptop'
    wg_man.sh share pc_ufficio laptop
EOF
}



main() {
    case $1 in
        init         ) init ;;
        addclient    ) shift; add_client "$@" ;;
        removeclient ) shift; remove_client "$@" ;;
        rebuild      ) rebuild ;;
        deploy       ) deploy ;;
        share        ) shift; share "$@" ;;
        *            ) help ;;
    esac
}



check_dependency
case $? in
    "0" ) main $* ;;
    "1" ) echo -e "UFW non presente. Installare UFW."; exit 1 ;;
    "2" ) echo -e "wireguard-tools non presenti. È necessario installarli."; exit 1 ;;
esac

#bash #wireguard #psk #chiavi #certificati #crittografia

Introduzione

Da documentazione, Stunnel agisce come un proxy per aggiungere crittografia TLS a server e/o a client già esistenti.

Risulta quindi molto comodo quando si vuole aggiungere, attraverso un tunnel TLS, quella crittografia che manca alle nostre applicazioni per rendere le comunicazioni più sicure. Come in ssh, è possibile “tunnellizzare” solo connessioni TCP.

Di stunnel esaminerò in particolare la fase di autenticazione attraverso certificato o PSK.

Gli scenari possibili, in base alle combinazioni, sono tre:

• client tls – server in chiaro
• client in chiaro – server tls
• client e server in chiaro

Nel primo caso, occorre configurare stunnel in server mode, definendo un receiver ssl, a cui il client potrà connettersi. Scenario 1: stunnel server

Nel secondo caso, occorre configurare stunnel in client mode, definendo un sender ssl che il client userà per connettersi al server Scenario 2: stunnel client

Nel terzo caso, occorre configurare uno stunnel client e uno server Scenario 3: stunnel client e server

Come ulteriore evoluzione per quel che riguarda le tratte in chiaro (e non solo) di client-stunnel client, stunnel client-stunnel server, stunnel server-server, sarebbe buona norma limitarne l’accesso con un firewall. Stunnel e firewall

Se invece stunnel fosse locale (installato direttamente sul client e/o sul server), la richiesta del client o il listener del servizio, avverrebbero sull’interfaccia di loopback. Altrimenti, in assenza di firewall, sarebbe consigliabile accertare che la rete di collegamento fra i proxy stunnel e i rispettivi client/server, sia almeno di tipo “trusted”.

Stunnel consente un certo tuning sulla parte tls, potendo discriminare fra le cipher suites da abilitare, specificare comandi o configurazioni specifiche per openssl. Quando si deve incapsulare una connessione in chiaro in un tunnel ssl bisogna tenere presente gli scenari menzionati prima.

Convenzioni

• Per non perdere generalità, negli esempi che seguiranno, immaginiamo che stunnel non sia locale (anche se spesso lo è).
  • se stunnel in client mode è locale ⇒ accept avverrà sull’interfaccia di loopback, da dove avviene effettivamente la richiesta
  • se stunnel in server mode è locale ⇒ connect avverrà sull’interfaccia di loopback, dove viene erogato effettivamente il servizio
• Non faremo assunzioni sulla creazione dei certificati. Possono anche essere self-signed.

Configurazione stunnel

Verranno mostrate le configurazioni relative agli scenari mostrati nel modo più semplice possibile.

• accept: host e porta che ricevono la richiesta
• connect: host e porta a cui girare l’accept
• cert: normalmente conterrebbe il certificato pubblico che stunnel espone per autenticarsi (la parte privata viene specificata con key). Può però anche essere costituito da tutta i certificati della chain fino alla root CA, in formato pem o p12, iniziando dalla chiave privata, proseguendo con la chiave pubblica, fino a tutte le CA della chain.
• key: chiave privata del certificato
• client: stabilisce se stunnel funzioni in server mode oppure no

Primo scenario

Nel primo caso, una configurazione minimale lato server, ha bisogno:

1. host e porta dello stunnel server che riceve il traffico cifrato
2. host e porta del server su cui girare il traffico in chiaro
3. certificato pubblico e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem<br>
key = /server_key.pem

Secondo scenario

Nel secondo caso, una configurazione minimale lato client, ha bisogno:

1. host e porta dello stunnel client da cui partirà la richiesta
2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_server:port_server

Terzo Scenario

Il terzo caso, è una fusione dei primi due. Sono gli stunnel a gestire il grosso della comunicazione. E nei casi in cui lo stunnel viene installato sulle macchine di servizio, client e server reali usano solo l’interfaccia di loopback.

Una configurazione minimale per il client ha bisogno di:

1. host e porta dello stunnel client da cui partirà la richiesta
2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server

Una configurazione minimale per il server ha bisogno:

1. host e porta dello stunnel server che riceve il traffico cifrato
2. host e porta del server su cui girare il traffico in chiaro certificato pubblicato e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem
key = /server_key.pem

Piccola nota: se client e/o server dovessero supportare chiavi PSK, si potrebbe usare PSK in luogo dei certificati. Ci ritornerò più avanti.

Autenticazione dei client

Le impostazioni viste finora, mostrano come incapsulare un traffico in chiaro all’interno di un tunnel tls e si basano sulla sola autenticazione lato server.

Per migliorare la configurazione possiamo ricorrere alla mutua autenticazione facendo in modo che anche i client si autentichino.

Una mutua autenticazione, con tutte le verifiche del caso, aumenta il grado di sicurezza comunicazione TLS ed è un efficace deterrente contro eventuali attacchi MITM. L’autenticazione sul client si può ottenere sempre con i certificati oppure, più semplicemente, con chiavi PSK.

Autenticazione dei client con certificato

Ad una configurazione minimale per una mutua autenticazione, lato server, si richiede che i client esibiscano il certificato e i client (che sia stunnel in client mode, un browser o qualunque altra cosa) dovranno essere in grado di esibire i certificati nel momento in cui il server li richiederà.

Su stunnel server, alle configurazioni viste in precedenza, si aggiunge requireCert impostato a yes, che richiede ai client l’esibizione di un certificato. Se, durante l’handshake TLS, il client non esibisce un certificato, l’handshake fallisce e la connessione viene rifiutata.

Stunnel Server:

[myService]
…
requireCert = yes
…

È sufficiente questo se i client possono manipolare i propri certificati. Altrimenti, se c’è uno stunnel client che intermedia le richieste dei client effettivi, si deve aggiungere alla sua configurazione la chiave e il certificato del client

Stunnel Client:

[myService]
…
cert = /server_crt.pem
key = /server_key.pem
…

Autenticazione dei client con PSK

Per l’autenticazione PSK bisogna disporre della lista di utenti abilitati con relative chiavi esadecimali di almeno 16 bytes (ossia almeno 32 caratteri esadecimali visto che con un byte si rappresentano due esadecimali).

La creazione di una chiave esadecimale può essere fatta velocemente con openssl. Supponiamo di creare due utenze per Frodo e Gandalf con chiavi da 20 e 42 bytes.

echo -e "frodo:"$(openssl rand -hex 20) > frodo_psk.txt
echo -e "gandalf:"$(openssl rand -hex 42) > gandalf_psk.txt

Tutte le identità dovranno confluire nel file che, nella configurazione stunnel, sarà indicato da PSKsecrets. Ad es:

cat frodo_psk.txt gandalf_psk.txt > psksecrets.txt
…
frodo:84196825fab3389624dcc83eb61189e5b21099fe<br>gandalf:5daf128419855993a2d95ba0a337c51b3f373df88e594441f2979eba6461f25676f1f825b0c76df392f2
…

E, come detto, nella configurazione dello stunnel server dovrò indicare il file delle identità:

Stunnel Server

[myServer]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
PSKsecrets = <path_identity_file>/psksecrets.txt

Se il client supporta PSK, dovrà fornire identità e password. Ad es. facendo un test con openssl:

openssl s_client -port <porta> -psk_identity frodo -psk 84196825fab3389624dcc83eb61189e5b21099fe -tls1_2 -connect <host>

Altrimenti si configura stunnel client indicando sia l’identità, sia il file individuate da PSKsecrets.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKidentity = frodo
PSKsecrets = <path_identity_file>/psksecrets.txt

In alternativa, per non far viaggiare il file delle identità fra tutti i client, possiamo sfruttare a nostro vantaggio il default delle identità.

In assenza della direttiva PSKidentity, viene assunta come identità di default la prima riga del file indicato da PSKSecrets. Basta quindi creare un file con la sola identità che mi occorre, ad es. frodo_psk.txt

frodo:84196825fab3389624dcc83eb61189e5b21099fe

e indicare quello in PSKSecrets. La configurazione che segue è equivalente alla precedente.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKsecrets = <path_identity_file>/frodo_psk.txt

Ulteriori considerazioni di sicurezza

Autenticazione con certificato

La richiesta di autenticazione dei client mediante certificato è una buona misura preventiva ma può essere resa migliore.

Nelle configurazioni viste finora, stunnel server autorizza l’accesso al servizio solo se il client si presenta con un certificato ma non c’è nulla che vincoli il certificato al servizio. In altre parole, un client in possesso di un qualunque certificato, può accedere alla risorsa.

È possibile rafforzare il trusting fra le parti facendo in modo che stunnel autorizzi solo alcuni certificati invece che qualunque. Questo tipo di controllo può essere fatto sia su stunnel sia in client mode che in server mode.

• verifyChain = yes | no
• checkEmail = email del certificato
• checkHost = CN del certificato
• checkIP = IP del peer che presenta il certificato
• verifyPeer = yes | no
• CApath = < path CA >
• CAfile = < file pem contenente la fullchain del certificato presentato a stunnel >

verifyChain Impone che si possa verificare la fullchain del certificato presentato. Se uno degli issuer non viene trovato, la connessione fallisce. La fullchain viene indicata attraverso CAfile o CApath.

CAfile È il file contenente le CA con cui stunnel valida i certificati che gli vengono presentati. Se stunnel è in server mode, sarà la fullchain relativa ai client. Altrimenti sarà la fullchain relativa al server.

CApath È il path in cui si trovano le CA con cui stunnel valida i certificati che gli vengono presentati. Se lo stunnel è in server mode, sarà la fullchain realtiva ai client. Altrimenti sarà la fullchain relativa al server.

verifyPeer Se con CAfile e CApath si verifica la fullchain dei certificati presentati a stunnel, con verifyPeer = yes si verifica che questi certificati siano presenti anche nel suo keystore (CAfile o CApath). Permette di “legare” a stunnel i certificati che dovrà validare.

checkEmail, checkHost, checkIP Come per verifyPeer, sono direttive che permettono di stringere il legame fra il certificato che viene presentato e stunnel. Verifica che l’email, il CN o l’IP del certificato che viene presentato corrispondano a quelli presenti nella configurazione. In una configurazione lato server posso avere molteplici occorrenze di questi due campi relative ad altrettanti certificati. Il caso in cui ad es. si debbano autenticare n client.

Se i certificati sono self-signed, verifyChain perde di significato (coinciderebbe con verifyPeer). La possibilità di generare i certificati attraverso una CA, anche interna, renderebbe il processo più strutturato anche se più complesso (si dovrà trovare un modo per distribuire la CA, se interna). Si tratta di trovare il giusto compromesso fra ampiezza del servizio (quanti utenti coinvolge?) e complessità richiesta.

Se si tratta di realizzare un canale sicuro fra due apparati per una comunicazione server-2-server, vanno bene anche i certificati self-signed o un’autenticazione PSK. Altrimenti, soprattutto nel caso in cui l’autenticazione dei client è una fase critica, conviene valutare l’uso di una CA e una validazione il più possibile restrittiva sui client e sul server.

Autenticazione PSK

A differenza dell’autenticazione con certificato, l’autenticazione con PSK non prevede enhancement di sicurezza ulteriori a meno di specificare opportuni algoritmi di cifratura (cfr. paragrafo successivo).

Cifratura

Come sempre succede, negli scenari di cifratura asimmetrica orientatia alla connessione, l’autenticazione, per quanto possa essere accurata, costituisce solo uno degli aspetti di cui tenere conto nella fase di messa in sicurezza del servizio.

Avere un’autenticazione con certificato generato con tutti i crismi da una CA, è certamente una gran cosa ma mette in sicurezza solo l’aspetto dell’autenticazione, per l’appunto.

l transito dei dati è affidato alle suite di cifratura supportati da openssl e, volendo lavorare di fino, bisognerebbe stringere anche su quelli.

Altrimenti, paradossalmente, si avrà un’autenticazione robustissima ma con algoritmi colabrodo di cifratura dei dati che, ad attaccanti ben motivati, lascerebbero delle porte spalancate per sferrare attacchi MITM per intercettare direttamente i dati, piuttosto che provare il furto di identità.

Ad ogni modo, il default, per ragioni di compatibilità legacy, dei parametri di cifratura (da settare eventualmente su client e sul server) è il seguente:

ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK
ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

dove ciphers raggruppa le suite di cifratura relativi a TLS1.2 in giù e ciphersuites riguarda invece TLS1.3.

Configurazione servizio

Ulteriori restrizioni possono essere aggiunte a livelllo di sistema:

1. regolando i bit di setuid e setgid se stunnel gira come root
2. delimitando l’esecuzione del processo in una gabbia chroot
3. disabilitando le regonetiation (se supportato dalla versione di openssl in uso) che mitiga in parte attacchi dos di tipo CPU-exhaustion
4. ecc..

Caso reale: tunnelizzare Transmission.

Transmission è un client bittorrent che può essere controllato da remoto via rpc attraverso un’interfaccia web o altri client.

Transmission, nelle sue varie declinazioni, non incapsula il traffico rpc in una connessione tls.

Se si vuole che il dato in transito sia cifrato e che la connessione sia autenticata, si può ricorrere:

1. ad un tunnel ssh;
2. all’intermediazione di un webserver come apache o nginx ;
3. ad uno stunnel server

Sugli ultimi due punti si può configurare una mutua autenticazione con certificato (complessa e articolata e, per tanti client, ha un impatto significativo). Scegliamo il 3° caso.

Esposizione dell’interfaccia web

Scenario: abbiamo una macchina (il nostro serverino di fiducia o un nas) con transmission a bordo, presumibilmente dietro un firewall che natta il suo indirizzo privato (192.168.70.15).

Esposizione transmission attraverso stunnel server

Obiettivo: Vogliamo poter raggiungere transmission e vogliamo che i client autentichino la loro connessione prima di accedere al servizio. In base allo scenario, sappiamo che dovremmo configurare un port forwarding dall’AP fino allo stunnel server. Il server transmission rimarrà confinato nella nostra rete locale.

Utilizzo di un client esterno

Supponiamo di utilizzare diversi client: il browser, transmission-remote-gtk o transmission-remote-gui (transgui), tremotesf (mobile).

La prima cosa da fare è configurare un port forwarding sul nostro AP

Rule₁: 9091 ⇒ 192.168.70.10:9091

Dopodichè, configureremo stunnel in server mode davanti a transmission

[transmission]
accept = 192.168.70.10:9091
connect = 192.168.70.15:9091
cert = <path stunnel conf>/ssl/server/certs/stunnel_crt.pem
key = <path stunnel conf>/ssl/server/private/stunnel_key.pem
requireCert = yes
verifyChain = yes
verifyPeer = yes
CApath = <path stunnel conf>/ssl/client/certs

Alcune note sulla configurazione:

• devo disporre di un certificato per stunnel
• devo disporre dei certificati per i client che si connetteranno, le cui fullchain dovranno essere localizzate nel path indicato da CApath

A questo punto basta che i web-client puntino all’host pubblico (151.25.77.205) sulla porta 9091 e il gioco è fatto.

Per gli altri client come transmission-remote-gtk, transgui o tremotesf, per i quali al massimo posso chiedere di usare TLS (ma non sono riuscito ad usare un’autenticazione lato client), conviene installare stunnel in client mode :

[transmission-client]
accept = localhost:9091
connect = 151.25.77.205:9091
client = yes
cert = <path stunnel conf>/ssl/client/laptop_crt.pem
key = <path stunnel conf>/ssl/client/laptop_key.pem
verifyChain = yes
verifyPeer = yes
CAPath = <path stunnel conf>/ssl/server/certs

Il client (ad es. sul laptop) si connetterà su localhost:9091 e dovrà disporre anche del certificato del server e della sua fullchain affinchè i check su verifyChain e verifyPeer non falliscano.

#ca #DigitalCertificate #AsymmetricEncryption #SymmetricEncryption #cryptography #fullchain #psk #ssh #ssl #stunnel #tls #x509 #openssl