Perché il NAT domestico non protegge la tua interfaccia VPN

I portatili dietro un router domestico senza inoltro delle porte accettano comunque connessioni SSH che arrivano tramite la VPN. Non è una contraddizione, perché due dispositivi diversi giudicano due pacchetti diversi. Il router inoltra il trasporto cifrato e l'host decide cosa fare con il pacchetto decifrato che raggiunge la sua interfaccia tunnel. Tenere separate queste due decisioni è tutto l'esercizio.

Il router inoltra il tunnel, l'host giudica il pacchetto

Traccia il percorso dalla sorgente remota al servizio prima di guardare una sola regola. Il tratto esterno è il trasporto VPN, gestito dal router e dal gateway. Il tratto interno inizia quando l'endpoint rimuove lo strato tunnel e l'host riceve un pacchetto indirizzato al suo indirizzo VPN.

Unisci i due tratti e il router si prende il merito di una decisione che prende l'host. Una pagina di inoltro delle porte o un registro del router descrivono solo conversazioni esterne, e nessuno dei due dice quale traffico decifrato accetterà l'host. L'host applica la propria politica di ingresso al pacchetto interno, come a qualsiasi pacchetto che arrivi su un'interfaccia. È in quella politica che la questione dell'esposizione viene davvero risolta.

Un ascoltatore wildcard non è un servizio pubblico

Su Linux, il binding a INADDR_ANY significa ogni indirizzo locale, quindi un servizio può rispondere su un'interfaccia tunnel che non ha mai nominato. Il riferimento dei socket IP descrive quel binding, e vale la pena leggerlo prima di trarre conclusioni da un elenco di ascoltatori. Una voce wildcard è un fatto sul socket, non un'affermazione sulla raggiungibilità.

Le due righe sotto sono lo stesso servizio in due binding diversi, e la differenza è tutta la risposta alla domanda se l'interfaccia conti. Leggi su quale indirizzo si trova il socket prima di ogni altra cosa.

ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))

Nomina la disposizione che potrebbe raggiungere la porta

Tre disposizioni mettono un pacchetto su quell'interfaccia, e hanno proprietari diversi. Nominare quella giusta decide chi deve cambiare una politica.

Un risultato del browser che mostra un indirizzo di uscita pubblico non dice nulla di nessuna delle tre, perché descrive come esce il traffico in uscita e non cosa è permesso al traffico in entrata. Lavora all'indietro dall'ascoltatore e dall'indirizzo sorgente nel registro del servizio. Se la sorgente è un altro peer del tunnel, la politica del gateway è il documento interessante. Se è un indirizzo tradotto, trova la traduzione prima di cambiare una regola.

Limita il servizio al percorso previsto

Se SSH serve solo da un percorso di gestione, scrivi quel percorso come intervallo di sorgenti più un'interfaccia. Poi limita le regole di ingresso dell'host per interfaccia, destinazione e sorgente invece che per nome di rete, poiché un nome che sembra privato può rappresentare qualsiasi indirizzo. Tieni una rotta per la persona che risolverà il prossimo problema.

nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input

Una regola che nomina l'interfaccia del tunnel e l'intervallo di gestione dichiara l'intenzione in un solo posto. Confrontala con una regola scritta per la rete Wi-Fi, che non dice nulla del traffico tunnel decifrato. Quando i due strati non sono d'accordo, la politica dell'host è quella che il pacchetto incontra.

Lascia accessi e patch esattamente dove sono; raggiungere una porta non è mai stato lo stesso che avere il permesso di usarla. Registra la famiglia di indirizzi e l'ora per ogni sorgente sconosciuta, e indaga prima di dare la colpa a una funzione o a una vulnerabilità. Una regola che ammette ogni peer del tunnel è un progetto diverso da una che ammette una sottorete di gestione, e nessuna riga di registro dirà quale era voluta.

Accetta la correzione con un successo e un rifiuto

Dimostra entrambe le metà: una connessione approvata riesce e un percorso escluso viene rifiutato. Il rifiuto è la metà che la gente salta, ed è quella che mostra che la regola lavora invece di stare accanto a un valore predefinito permissivo. Prova dal lato escluso invece di ragionarci sopra.

Ripeti la coppia dopo una riconnessione, perché un tunnel che torna con un altro nome di interfaccia può aggirare in silenzio una regola limitata a quello vecchio. Il confine che conta è quello che l'host applica ai pacchetti che riceve davvero.