Il vostro file .ovpn può eseguire codice, non solo instradare traffico

La maggior parte delle persone legge un file .ovpn come legge la pagina delle impostazioni di un router: indirizzi, rotte, un elenco di cifrari. La parte che esegue codice sta vicino in fondo, accanto a direttive che sembrano lavori idraulici, e viene eseguita con qualunque privilegio il client abbia già. È la falla che sfrutta un profilo trascurato o malevolo, ed è anche la falla che trasforma un utile helper DNS in un problema di supporto tre settimane dopo. La direttiva evento, il livello di sicurezza e la proprietà del file decidono cosa può accadere; il contenuto dello script decide cosa accade davvero. Leggete tutti e quattro prima di connettervi.

Un profilo che esegue un helper è un programma, non un file di impostazioni

Direttive come route e dhcp-option descrivono lo stato che il client deve stabilire, e il client le tratta come dati. Uno script up è diverso: il client lo avvia come processo e gli passa un ambiente pieno di dettagli di connessione, quindi tutto ciò che ha scritto il suo autore gira con i diritti del vostro account. Su un portatile dove l’utente è amministratore, è una porta larga per un file arrivato come allegato o incollato da un thread di forum. La distinzione non è stilistica, è la differenza tra configurazione e codice.

Il mito da mandare in pensione è che un profilo possa solo reindirizzare il traffico. Un helper che esegue ip route add e uno che esegue curl verso un host remoto sono lo stesso meccanismo, e il profilo sembra identico dall’esterno. Nulla nell’aspetto del file vi dice quale avete, per questo la revisione deve arrivare allo script stesso.

Cosa decide davvero l’esecuzione, e come sono le righe che la abilitano

Tre cose governano un helper: la direttiva evento che lo nomina, il livello script-security che lo consente e l’implementazione della piattaforma client stessa. Un profilo può chiedere un hook e non vedere comunque accadere nulla, perché un client mobile o una build desktop ridotta può non implementare affatto quell’evento. Allo stesso modo, un profilo che chiede più permessi di quanti ne servano alla sua funzione vi dice qualcosa sulla sua origine. Un livello di permesso è una capacità, non un’approvazione. Le righe che lo abilitano sono così, con un percorso che sostituisce il vostro.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Il livello 0 rifiuta i programmi esterni e il livello 1, quello predefinito, consente solo gli eseguibili integrati del client, quindi un hook richiede 2 o superiore; il livello 3 esiste soprattutto per tramandare vecchie password ed è meglio evitarlo. Un profilo fornito con un hook richiede sia la direttiva sia quel livello, per questo una riga vicino al fondo del file merita lo stesso esame del blocco del certificato. Il manuale di OpenVPN elenca i livelli di permesso, e la sua formulazione merita di essere letta accanto a ciò che il profilo chiede davvero.

Proprietà, percorso e cosa viene dato in pasto all’helper

Un profilo di cui vi fidate ma che punta a uno script che un altro account può riscrivere non è un accordo affidabile, perché la revisione di ieri non descrive più ciò che gira oggi. Controllate il proprietario e il modo dell’helper, e verificate che il percorso configurato risolva al file che avete ispezionato e non a un nome che qualcos’altro può oscurare. Argomenti e ambiente meritano lo stesso sguardo: il client passa dettagli di connessione all’hook, e un helper che registra tutto il suo ambiente forse sta scrivendo credenziali in un ticket di supporto. Preferite un’integrazione documentata dell’operatore o della piattaforma a uno script DNS copiato da un articolo non correlato, perché due gestori di resolver che litigano sullo stesso file producono un guasto che sembra una VPN rotta.

Quando segnalate un hook che fallisce, oscurate l’ambiente prima di incollarlo ovunque. Il dump che vi aiuta a fare debug può anche portare il token che vi autentica.

I guasti di pulizia compaiono dopo che il tunnel è sparito

Un helper up aggiunge rotte e impostazioni del resolver, e l’helper down dovrebbe toglierle di nuovo. Quando l’hook down manca, fallisce in silenzio o non viene mai eseguito perché il client è stato ucciso, i residui sopravvivono alla sessione. Il traffico prende allora una strada che nessuno aveva pianificato e i nomi si risolvono attraverso un resolver che sarebbe dovuto essere rimosso, mentre il tunnel stesso sembra sano. Quei sintomi arrivano dopo la disconnessione, per questo si dà la colpa alla rete invece che al profilo.

Provate lo smontaggio come passo a sé: alzate il tunnel, annotate le rotte e il resolver, abbassatelo, poi confermate che entrambi sono spariti. Un profilo che si connette pulito può comunque lasciare stato dietro, e un codice di uscita zero dell’helper non prova che il resolver sia finito dove pensate.

Esaminare l’helper e tenersi un’uscita

Leggete lo script da capo a fondo cercando tre cose: comandi che richiedono privilegi, percorsi codificati che forse non esistono sul vostro sistema e qualsiasi chiamata di rete che fa. Poi guardate come fallisce, perché un helper che ingoia gli errori trasforma un errore di configurazione in un mistero. Se non riuscite a dire in una frase cosa fa lo script e chi può cambiarlo, non siete pronti ad attivarlo. Un profilo che chiede più privilegi di quelli richiesti da quella frase è il segnale di fermarsi.

Conservate l’ultimo profilo funzionante e l’helper a cui rimandava in archiviazione protetta, con entrambe le versioni annotate, così un ripristino è una copia e non una ricostruzione nel momento peggiore. Se l’helper esiste solo per una distribuzione o una versione del client che non ne ha più bisogno, mandatelo in pensione nella configurazione che possiede l’impostazione invece di alzare i privilegi finché gli errori non smettono. È questa l’uscita: meno parti mobili, non più permessi.