Nomi VPN privati che non funzionano? La protezione dal rebinding DNS è l'indiziata

Sulla LAN dell'ufficio il nome interno risponde all'istante. Appena la VPN è attiva smette di funzionare, l'applicazione segnala un timeout e il tunnel continua a trasportare traffico senza lamentarsi. Ciò che è cambiato è il resolver, e quel resolver ha un'opinione sugli indirizzi privati.

La protezione dal rebinding esiste per fermare un trucco specifico. Un nome privato pubblicato di proposito appare abbastanza simile perché la difesa scatti.

Leggi la risposta prima della regola

Interroga il nome sul resolver che la VPN distribuisce davvero, non su quello che il tuo portatile usa a casa. Confronta la risposta con il record atteso e annota se la replica è vuota, rifiutata o piena di indirizzi pubblici che nessuno aveva previsto.

I sintomi si sovrappongono, quindi è la forma della risposta a decidere la diagnosi. Un NXDOMAIN è un record mancante, un REFUSED è una regola di accesso, un indirizzo pubblico per un nome interno è un errore di policy o di split DNS, e un indirizzo privato corretto che il client non riesce a usare è un problema del tutto diverso. Una connessione rifiutata o una richiesta bloccata non dimostra nulla da sola, ed è per questo che il primo comando in ticket simili dovrebbe essere un'interrogazione e non un riavvio. Annota la risposta prima di cambiare qualsiasi cosa.

Che cosa ferma davvero la difesa

Il rebinding DNS funziona cambiando ciò a cui un nome risolve dopo che il client si è già fidato. Una pagina si carica da un nome controllato dall'attaccante, la risposta passa a un indirizzo privato e il browser viene ingannato per parlare con qualcosa sulla rete locale a cui non avrebbe mai accettato una connessione diretta. La difesa consiste nel rifiutare le risposte che puntano allo spazio privato quando al resolver non è mai stato chiesto di servire un namespace privato. Quell'asimmetria è l'intero attacco.

dnsmasq documenta esattamente questo comportamento, insieme alle eccezioni per dominio. Nel suo manuale descrive rebind-domain-ok come il modo per indicare i domini che possono legittimamente restituire tali indirizzi. Leggilo come un segnale che la correzione prevista è un'autorizzazione circoscritta, non un interruttore globale.

Limita l'eccezione al namespace

Prima correggi il namespace, poi l'eccezione. Verifica che il nome che fallisce appartenga a un dominio controllato dall'organizzazione e che il record sia mantenuto di proposito. Un indirizzo inatteso che assomiglia soltanto a un intervallo LAN familiare merita sospetto, non un'eccezione, quindi controlla il proprietario della zona prima di scrivere qualsiasi autorizzazione.

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

Poi aggiungi l'autorizzazione più stretta che copre i nomi previsti: un dominio, o un sottodominio delegato, nella configurazione del resolver interrogata dai client VPN. Disattivare la protezione per ogni nome su quel resolver elimina la difesa per tutti insieme, compresi i nomi che non ne hanno mai avuto bisogno.

Lo split DNS rientra nella stessa decisione. Se il namespace privato deve essere risolto solo sul resolver interno, pubblicalo lì e smetti di farlo trapelare verso i resolver pubblici, così l'eccezione copre un percorso invece di ogni percorso.

Ricontrolla la risorsa e la difesa

Interroga di nuovo, poi connettiti al servizio e controlla ciò che vede il client. Una risposta privata corretta con una sessione funzionante significa che l'eccezione ha avuto effetto. Una risposta corretta con una sessione bloccata significa che il prossimo indiziato è la rotta o l'identità del servizio.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

Prova anche un nome pubblico attraverso lo stesso resolver. La protezione dovrebbe continuare a comportarsi bene per i nomi fuori dall'eccezione, e se quel controllo fallisce la modifica è stata più ampia del previsto. Mantieni intatta la validazione dei certificati per tutta la durata, perché un nome che risolve correttamente deve comunque corrispondere al certificato presentato dal servizio.

Registra nel ticket la risposta rifiutata, il dominio, il resolver e chi possiede la policy. È quel registro che trasforma un guasto interno misterioso in una modifica di configurazione che qualcuno può riesaminare.