Come verificare cosa copre un interruttore di sicurezza su un host compromesso

Eseguite il test di interruzione, leggete il risultato di ogni livello e vedete dove si ferma un interruttore di sicurezza: blocca percorsi, non il software che legge i dati prima della cifratura.

Attivate l'interruttore di sicurezza, portate offline il server del tunnel e osservate cosa fa ancora la macchina. Il test vale la pena perché separa ciò che il firewall applica da ciò che supponevate, e i risultati sono più stretti di quanto suggeriscano la maggior parte delle pagine di prodotto. Un interruttore di sicurezza governa i percorsi di rete; non governa il software già in esecuzione sul dispositivo. Eseguo questa sequenza su ogni macchina il cui client dichiara di essere fail-closed, e richiede una decina di minuti.

Partite dal client, non dal server

Il punto di applicazione è l'host su cui siete seduti: il firewall del sistema operativo, un servizio ausiliario o il driver del client VPN stesso. Questo conta perché tutto ciò che l'interruttore può fare è limitato da ciò che quel livello vede. Se il client implementa il blocco con una regola di instradamento più un marchio, qualunque cosa con privilegi sufficienti può aggiungere una propria regola; se usa una tabella di firewall del kernel, gli stessi privilegi possono modificare la tabella. La forza della cifratura non entra mai in questa questione.

Quindi la prima cosa da stabilire è chi possiede la politica su questo dispositivo e cosa le è consentito ignorare. Su una macchina di lavoro gestita la risposta è di solito l'agente endpoint dell'organizzazione, e una VPN personale non rimuove quelle capacità, comunque sia configurato il tunnel.

Primo passo: confermate il blocco sui percorsi che ritenete coperti

Abbattete il tunnel all'estremità remota, non sul client, così il client crede ancora di dover essere connesso. Poi provate ciò che proverebbe davvero una persona:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Volete un client che fallisca in fretta e in modo pulito, non uno che resta appeso fino al timeout del browser. Restare appesi di solito significa che i pacchetti vengono scartati in silenzio da una regola senza rifiuto, il che è accettabile, ma può anche significare che il client ha lasciato una rotta predefinita obsoleta puntata a un'interfaccia morta. Leggete la tabella di instradamento con il tunnel abbassato: una rotta predefinita che punta ancora al dispositivo del tunnel e una regola di firewall che blocca solo le nuove connessioni in uscita sono due stati diversi, e solo uno dei due è fail-closed.

Ripetete gli stessi comandi con l'opzione consentì-LAN del client attiva e disattiva. Quell'interruttore è dove vivono la maggior parte delle sorprese, perché riapre un percorso che il resto della politica era scritto per chiudere.

Secondo passo: controllate DNS e IPv6 come percorsi separati

La risoluzione dei nomi è la lacuna che sopravvive alla maggior parte delle implementazioni, perché la query può uscire per qualcosa di diverso dal resolver di sistema. Chiedete con uno strumento che ignora la vostra configurazione del resolver, e controllate il lato v6 mentre ci siete:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Risposte vuote a entrambe le query di nome con il tunnel abbassato sono il risultato che volete. Se la seconda query risponde, un indirizzo di resolver codificato è raggiungibile e il tunnel non è l'unica via d'uscita dalla macchina. Se solo la richiesta v6 riesce, la politica copre IPv4 e ignora IPv6, che è la stessa fuga in un'altra famiglia di indirizzi.

I browser rendono tutto questo più difficile da leggere dall'esterno, perché un browser configurato per DNS su HTTPS risolve la query tramite una richiesta HTTPS: la query è bloccata solo nella misura in cui lo è la porta 443 verso quell'endpoint. Su un host in cui la politica consente la sottorete locale, quella richiesta può ancora raggiungere un resolver sulla LAN.

Terzo passo: separate l'esposizione di rete da quella dell'endpoint

Ora la parte che nessuna regola di firewall raggiunge. Un interruttore di sicurezza blocca i percorsi fuori dalla macchina; non impedisce al software sulla macchina di leggere i dati prima che siano cifrati, e non impedisce a quel software di usare legittimamente il tunnel. Un keylogger, un'estensione malevola, uno schermo lasciato sbloccato, un client di sincronizzazione con ampi permessi: tutti spostano informazioni su una connessione che l'interruttore concede volentieri.

Lo stesso vale per il software di monitoraggio che un datore di lavoro ha installato di proposito. Bloccare le rotte non lo rimuove, e comprare un nuovo server VPN non è la riparazione, perché l'esposizione sta a monte del tunnel.

Un gestore degli appunti che carica su un account cloud lo mostra con nettezza. Il traffico è cifrato, la destinazione è consentita, e l'interruttore di sicurezza segnala uno stato sano per tutto il tempo.

Quarto passo: scrivete l'affermazione che il vostro test sostiene

Dopo il test di interruzione potete affermare fatti precisi: quali applicazioni hanno fallito, quali percorsi si sono fermati, come si sono comportati DNS e IPv6 e se il blocco ha tenuto quando il tunnel è caduto. Non potete affermare che il sistema operativo sia pulito, né che un servizio all'estremità remota manterrà privato il vostro accesso.

Tenete separati i due problemi e date a ciascuno il proprio controllo:

  • Interruttore di sicurezza: il requisito di guasto definito, verificato con un test di interruzione che ripetete dopo ogni aggiornamento del client.
  • Fiducia del dispositivo: aggiornamenti supportati, protezione degli endpoint da una fonte affidabile, revisione dei permessi e delle richieste di autenticazione inspiegati.
  • Incidente: seguite il processo della piattaforma o dell'organizzazione quando si sospetta una compromissione; un server nuovo non è una fase di pulizia.
  • Divulgazione: quando chiedete aiuto, non incollate chiavi private o archivi diagnostici completi, perché i log e le schermate portano gli stessi segreti della connessione.

Eseguite di nuovo la sequenza dopo il prossimo aggiornamento, perché un interruttore di sicurezza è configurazione che si muove con le versioni. Il test è l'unica prova che il comportamento su cui contate è ancora quello che ottenete.

Articoli correlati