Perché bloccare le porte VPN non ferma i tunnel non autorizzati

Una regola del firewall nega il traffico che intercetta. Non nega ogni uso di una connessione che consente, ed è proprio in questo varco che falliscono la maggior parte delle politiche contro i tunnel non autorizzati. Bloccare le porte del client che era popolare cinque anni fa lascia intatto tutto ciò che passa sulla 443 e non dice nulla su un dispositivo che può riscrivere le proprie rotte. Costruite il controllo attorno all’autorità e alle destinazioni, poi leggete i flussi che consentite davvero.

Perché un elenco di porte non è una politica

Le porte sono un concetto del livello di trasporto e diverse tecnologie di tunnel non ne usano nessuna. Altre condividono di proposito una porta con il traffico web ordinario, perché quella porta è quella che ha il passaggio garantito. Una regola basata su una porta storica enumera quindi una manciata di implementazioni invece della classe di comportamento. Invecchia anche male: nel momento in cui un fornitore cambia i valori predefiniti, l’elenco descrive il passato.

Peggio ancora, un blocco riuscito su una porta può essere letto come prova che l’intero problema è risolto, il che ritarda i controlli che sarebbero stati importanti.

I numeri di protocollo e le porte sono spazi dei nomi diversi

A GRE è assegnato il numero di protocollo IP 47. Non è la porta TCP 47 né la porta UDP 47, e un filtro scritto per una porta non lo tocca. ESP e AH occupano i numeri di protocollo 50 e 51 con la stessa proprietà. Il traffico incapsulato può anche nascondersi dentro una connessione consentita, per questo una categoria o una firma può aiutare, ma non certifica mai lo scopo da sola. Fiducia e copertura appartengono a un prodotto e a una versione specifici, non al concetto.

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

Il primo comando mostra ciò che avete scritto davvero; il secondo mostra la tabella dei protocolli che lo stack conosce; il terzo mostra quante sessioni stanno usando la porta web in questo momento. Nessuno di essi dice a cosa servono quelle sessioni. L’intercettazione TLS è una decisione separata, con i propri costi di fiducia, privacy e compatibilità con i client. Non è un prerequisito per negare una destinazione nominata e non è nemmeno una garanzia di riconoscimento dei tunnel.

Controllate l’autorità di cui dispone il dispositivo

Un dispositivo che può cambiare la propria tabella di routing e il proprio filtraggio ha capacità che un’applicazione ordinaria non ha. La gestione delle ammissioni e della configurazione è ciò che rimuove quella capacità, e agisce indipendentemente dalla porta che il tunnel userebbe.

Ciò significa che i collegamenti approvati ricevono il loro ruolo dichiarato invece di un permesso illimitato di inoltrare per altri dispositivi, e significa che i diritti di installazione e di amministrazione della rete fanno parte della politica invece di essere un ripensamento.

Osservate i flussi che restano. Correlate identità del dispositivo, ruolo assegnato e metadati del flusso, e trattate la classificazione come prova con dei limiti invece che come verdetto.

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

Una sessione cifrata di lunga durata o un grande conteggio di byte non sono prova di abuso: backup, strumenti di supporto e collegamenti tra sedi sembrano uguali. Mantenete la raccolta limitata all’indagine e conservate ciò che trovate sotto il processo che ne è proprietario.

Rendete esplicite le eccezioni

Ogni ambiente ha destinazioni che devono restare raggiungibili per aggiornamenti, autenticazione e ripristino. Annotatele con uno scopo e un responsabile, e riesaminatele invece di scoprirle un’interruzione alla volta.

Quando l’azienda permette davvero un ampio servizio esterno, valutate l’autorità che quel servizio fornisce invece di presumere che l’etichetta della destinazione renda accettabile ogni uso.

Un’eccezione non riesaminata è un buco con un numero di ticket. Un’eccezione con un nome, un motivo e una data di revisione è una decisione.

Accettate con un piano scritto, non con uno slogan

L’accettazione ha due metà: il lavoro approvato riesce ancora e i casi vietati specifici falliscono in un test autorizzato. Entrambe vanno scritte prima della modifica e ripetute dopo.

Includete i cambiamenti di endpoint e di politica in quella revisione, perché una rotta aggiunta su un portatile può annullare un filtro che funzionava perfettamente al bordo.

Il risultato è un confine di uscita di proprietà con un elenco noto di rischio residuo. Affermare che qualche porta chiusa ha posto fine all’uso non autorizzato di VPN non è questo.