Una VPN non affidabile sono tre confini separati, non uno

«Non mi fido di questa VPN» è di solito tre affermazioni vestite in una sola frase. I peer remoti di quella rete potrebbero raggiungere servizi sul vostro host, l’operatore che gestisce il tunnel potrebbe osservare il traffico che lo attraversa, e il software client che avete installato potrebbe cambiare la politica di rete della vostra macchina. La convinzione da correggere è che una regola del firewall, una macchina virtuale o una scelta accurata del sistema operativo rispondano a tutte e tre. Ogni misura risponde esattamente a una di esse.

Il mito: un solo controllo copre tutto il rischio

L’ipotesi comune è che entrare in una rete non affidabile sia una sola decisione con una sola mitigazione. Le persone scelgono il controllo di cui si fidano già, lo applicano e considerano il rischio chiuso: il firewall è attivo, lo spazio di lavoro è usa e getta, il client proviene da un fornitore rispettabile.

Questi controlli non si sovrappongono come l’ipotesi suggerisce. Un firewall dell’host limita ciò che un peer remoto può raggiungere e non fa nulla contro un operatore che termina il vostro TLS. Una macchina virtuale separa uno spazio di lavoro dai file del vostro host e non fa nulla contro un componente client a cui è permesso riconfigurare lo stack di rete sotto entrambi. Nominare il confine che ogni controllo crea realmente è tutto l’esercizio.

Separarli vi dice anche quale rischio avete scelto di accettare. La maggior parte delle decisioni reali mitiga un confine e ne tollera un altro, il che va bene purché il registro delle modifiche dica quale è quale.

A cosa può arrivare realmente il peer remoto

Iniziate dai servizi in ascolto. L’interfaccia del tunnel trattata come ampiamente affidabile perché i suoi pacchetti sono arrivati cifrati è l’errore abituale, e trasforma ogni ascoltatore locale in un bersaglio candidato per chiunque altro si trovi su quella rete. La cifratura protegge il filo tra due estremi; non dice nulla sull’intenzione del peer all’altro capo.

ss -tulpn
sudo nft list ruleset
ip -br addr

Legate i servizi all’indirizzo di cui hanno bisogno invece che a ogni interfaccia, e consentite solo le operazioni richieste dall’attività approvata. Mantenete espliciti l’inoltro, il bridging e il proxy delle applicazioni, perché due connessioni di rete non creano un percorso di transito da sole, ma una regola di proxy può certamente farlo.

Uno spazio di lavoro usa e getta approvato riduce ciò a cui la rete remota può arrivare, ma solo quando la sua configurazione di condivisione corrisponde all’affermazione. Cartelle condivise, integrazione degli appunti, agenti delle credenziali e canali di gestione attraversano tutti il confine che lo spazio di lavoro avrebbe dovuto creare. L’etichetta di uno spazio di lavoro non prova nulla su quali di essi siano aperti.

L’architettura a fiducia zero del NIST enuncia il principio dietro tutto questo: la posizione di rete da sola non concede fiducia implicita. L’autenticazione delle risorse ha ancora un compito dopo l’ammissione del tunnel, e così la domanda su chi altro condivida quella rete.

Cosa può vedere l’operatore nel percorso

Una VPN sposta il vostro traffico in un altro punto del percorso; non aggiunge cifratura applicativa. Se il fornitore termina il vostro TLS, il fornitore può leggere ciò che il vostro browser avrebbe altrimenti protetto, e nessuna regola del firewall locale lo cambia.

Mantenete la normale validazione dei certificati per la destinazione reale e comprendete il percorso del resolver e dei metadati, perché una query DNS può rivelare più del carico utile che la precede. I soli metadati, cioè quali indirizzi avete contattato e quando, spesso rispondono alla domanda dell’operatore senza alcun bisogno di leggere contenuti. Per questo «il traffico è cifrato» e «il traffico è privato» sono affermazioni diverse.

Se questa visibilità è inaccettabile per l’attività, la risposta è un’altra architettura approvata invece di più filtraggio locale. Il filtraggio locale non può rimuovere un osservatore da un percorso su cui si trova ancora.

Cosa può cambiare il client locale

Questo è il confine che le persone trascurano, ed è quello che rende irrilevanti gli altri due. Su Linux, CAP_NET_ADMIN copre la configurazione delle interfacce, l’amministrazione del firewall e le modifiche delle rotte nel suo contesto di rete. Un software che detiene quella capacità può riscrivere la politica che avete appena scritto.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

Un namespace di rete è un confine reale per lo stato di rete e uno scarso per tutto il resto: non isola il filesystem né l’archivio delle credenziali. Trattatelo come uno strato e non come un contenitore per l’intero problema.

Ottenete il client e la sua configurazione da una fonte mantenuta, esaminate l’autorità che richiede e tenete i componenti privilegiati sotto controllo dell’amministratore. Una macchina virtuale può far parte di un confine di valutazione qualificato senza diventare il permesso di eseguire un installatore inspiegato accanto a credenziali preziose. L’installatore viene eseguito con qualunque autorità gli diate, e quell’autorità è il confine.

Scrivete quale confine avete accettato

Terminate con una frase che nomina quattro cose: il codice locale affidabile, l’accesso remoto consentito, i dati applicativi protetti e la relazione con l’operatore che rimane. Quella frase vale più di un’affermazione generale secondo cui una VM, un sistema operativo o un antivirus hanno reso sicura una rete ostile.

Poi confermate che l’operazione ristretta funziona e che il rifiuto richiesto regge ancora, anche dopo che il tunnel cade. Un confine che esiste solo finché il tunnel è attivo non è il confine che avete documentato.

Nessun test dimostra che ogni vulnerabilità sia assente, e una revisione che affermi il contrario esagera. L’esito onesto nomina il rischio residuo e la persona che lo ha accettato.