La risoluzione DNS e la gestione delle porte TCP costituiscono due strati di sicurezza spesso trattati separatamente nelle politiche di rete delle aziende. Tuttavia, il frazionamento di questi due argomenti crea dei punti ciechi sfruttabili: un firewall può filtrare correttamente la porta 53 lasciando passare richieste DNS incapsulate nel traffico HTTPS sulla porta 443. Comprendere come questi meccanismi interagiscono consente di indurire la configurazione di rete senza moltiplicare gli strumenti.
DNS crittografato sulla porta 443: la vulnerabilità che il filtraggio classico non vede
Il filtraggio DNS tradizionale si basa sull’ispezione del traffico che transita per la porta UDP/53 o TCP/53. Questo approccio funzionava finché le richieste DNS circolavano in chiaro su un canale dedicato.
Il DNS-over-HTTPS (DoH), trasportato sulla porta TCP 443, cambia le carte in tavola. Le richieste DNS sono incapsulate nel traffico HTTPS standard, rendendole indistinguibili dal resto della navigazione web per un firewall configurato esclusivamente sulla base dei numeri di porta. Il DNS-over-TLS (DoT), che utilizza generalmente la porta TCP 853, presenta un problema simile ma rimane più facile da identificare e bloccare.
Secondo raccomandazioni diffuse dalla CISA e da Axio Networks, una politica di filtraggio DNS efficace deve ora imporre i resolver autorizzati su ogni terminale, inclusi i browser che attivano il DoH per impostazione predefinita. Non è più sufficiente monitorare la porta 53: le uscite verso le porte 443 e 853 devono essere controllate per rilevare le risoluzioni DNS non autorizzate.
Troverete informazioni tecniche su Open Syd che dettagliano i meccanismi di indurimento applicabili a queste configurazioni.
Porta TCP 53 e firewall: perché bloccare TCP provoca guasti DNS
Un errore comune nella configurazione dei firewall consiste nell’autorizzare solo il traffico UDP sulla porta 53, bloccando TCP/53. La logica sembra ragionevole: la grande maggioranza delle richieste DNS comuni utilizza UDP.
In pratica, TCP/53 rimane necessario per le risposte DNS di grandi dimensioni. I record DNSSEC, che aggiungono firme crittografiche alle risposte, superano regolarmente il limite di dimensione dei pacchetti UDP. I trasferimenti di zona tra server DNS autoritativi utilizzano anch’essi esclusivamente TCP. Bloccare questo protocollo sulla porta 53 provoca guasti intermittenti difficili da diagnosticare, poiché si manifestano solo per alcuni tipi di richieste o per alcuni domini.
La documentazione Cisco sui prerequisiti DNS per Cisco Secure Access distingue tre ruoli di rete, ognuno dei quali richiede regole di firewall diverse sulla porta 53:
- Il client, che invia richieste al resolver ricorsivo interno, può limitarsi a UDP/53 nella maggior parte dei casi
- Il resolver ricorsivo deve poter emettere e ricevere in TCP/53 e UDP/53 verso i server autoritativi, pena il non risolvere i record firmati DNSSEC
- Il server autoritativo richiede TCP/53 aperto per i trasferimenti di zona e le risposte di grandi dimensioni
Applicare una regola uniforme a questi tre ruoli equivale a indebolire la risoluzione dei nomi o ad aprire canali non necessari.
Politica di sicurezza di rete: superare il filtraggio per numero di porta
La porta 443 non è più un indicatore affidabile di un uso web classico. Il DoH vi transita, ma anche tunnel VPN, flussi applicativi proprietari e alcune soluzioni di sicurezza DNS stesse. Una strategia basata solo sui numeri di porta lascia passare traffico non identificato.
Un approccio più robusto combina diversi parametri di controllo:
- L’identificazione dei resolver DNS autorizzati tramite il loro indirizzo IP, bloccando qualsiasi altro resolver sulle porte 53, 443 e 853
- L’ispezione dei certificati TLS per distinguere il DoH legittimo dal traffico web standard sulla porta 443
- Il monitoraggio applicativo che identifica il protocollo reale indipendentemente dalla porta utilizzata, consentendo di rilevare un tunnel DNS incapsulato in HTTPS
- Il controllo dei parametri di configurazione dei browser per impedire l’attivazione automatica del DoH verso resolver esterni
Questa logica di difesa in profondità richiede di trattare il DNS non come un servizio isolato, ma come un componente trasversale del sistema informativo. Le regole di routing, la gestione delle applicazioni installate sui terminali e la configurazione dei sistemi operativi partecipano tutte alla postura DNS dell’azienda.
Monitoraggio DNS e rilevamento dei flussi anomali sulla rete
Il rafforzamento delle regole del firewall copre solo una parte del problema. Un resolver DNS interno compromesso, o un software malevolo che utilizza il DNS come canale di esfiltrazione dei dati, può generare traffico conforme alle regole di filtraggio pur essendo malevolo.
Il monitoraggio del volume e della frequenza delle richieste DNS costituisce un complemento necessario. Un terminale che emette diverse migliaia di richieste verso lo stesso dominio in pochi minuti presenta un comportamento atipico che merita un’indagine. Allo stesso modo, richieste verso nomi di dominio ad alta entropia (stringhe di caratteri casuali) segnalano spesso un tunnel DNS o una comunicazione con un server di comando e controllo.
I feedback sul campo divergono sul limite oltre il quale questi avvisi diventano sfruttabili senza generare troppi falsi positivi. La dimensione della rete, il numero di terminali e la diversità delle applicazioni aziendali influenzano direttamente il calibro. Un sistema di monitoraggio DNS mal calibrato genera rumore che finisce per essere ignorato dai team di sicurezza.
La correlazione tra i log DNS e i log del firewall (porte TCP aperte, connessioni in uscita insolite) consente di ridurre questo rumore. Un picco di richieste DNS verso un dominio sconosciuto, combinato con una connessione TCP in uscita su una porta non standard dallo stesso terminale, produce un avviso molto più affidabile di un indicatore isolato.
Il rafforzamento DNS e il controllo delle porte TCP non sono due progetti distinti. I dati disponibili mostrano che gli attacchi recenti sfruttano precisamente l’intersezione tra questi due strati, dove il DNS crittografato attraversa porte considerate sicure. Affrontare questi argomenti insieme, in una politica di sicurezza di rete unificata, rimane l’unico approccio che tiene conto della realtà del traffico attuale.
