Un server DNS che risponde a tutte le richieste senza distinzione, porte aperte per impostazione predefinita che nessuno ha rivisto dalla messa in servizio: troviamo questo schema nella maggior parte delle reti aziendali. La sicurezza della rete si gioca spesso su questi due assi trascurati, la gestione dei DNS e il controllo delle porte TCP, molto prima dell’acquisto di un firewall di nuova generazione.
Controllo dei risolutori DNS: il primo lucchetto da mettere sulla rete
Sul campo, il problema inizia quasi sempre nello stesso punto. I computer e gli oggetti connessi inviano le loro richieste DNS verso qualsiasi risolutore, compresi risolutori pubblici che l’amministratore non supervisiona. Finché non si limitano i risolutori autorizzati, si lascia un canale di uscita invisibile.
La prima azione consiste nel forzare tutto il traffico DNS verso un risolutore interno controllato. Si bloccano le richieste in uscita sulle porte UDP e TCP 53 verso qualsiasi destinazione diversa da questo risolutore. Questo permette di registrare ogni richiesta, rilevare i domini sospetti e interrompere le comunicazioni verso server di comando e controllo (C2).
La crittografia DNS complica questo approccio. DNS over HTTPS (DoH) utilizza la porta TCP 443, la stessa del traffico web classico, il che lo rende difficile da filtrare con regole di rete tradizionali. DNS over TLS (DoT) passa attraverso la porta TCP 853, più facilmente identificabile.
Per mantenere il controllo, si può imparare il funzionamento di Open Syd e scegliere una strategia adeguata: autorizzare DoT sulla porta 853 verso il risolutore interno mentre si blocca DoH sui computer per evitare che i browser aggirino la politica DNS dell’organizzazione.
Porte TCP aperte: audit prima di filtrare
Si vedono regolarmente server con decine di porte in ascolto, alcune delle quali corrispondono a servizi installati per impostazione predefinita e mai utilizzati. Ogni porta aperta è una superficie di attacco potenziale. Il riflesso consiste nel scansionare il proprio perimetro prima che un attaccante lo faccia.
Un audit delle porte TCP e UDP attive, effettuato dall’esterno della rete, rivela spesso servizi dimenticati: un’interfaccia di amministrazione su una porta non standard, un servizio di database esposto, un vecchio server di posta ancora raggiungibile. Chiudere una porta inutile riduce il rischio più efficacemente di una regola di rilevamento.
Prioritizzare la chiusura per livello di rischio
Tutte le porte aperte non presentano lo stesso pericolo. Ecco un approccio di classificazione pragmatico:
- Le porte legate all’amministrazione remota (SSH su 22, RDP su 3389, interfacce web su 8080 o 8443) devono essere limitate a intervalli IP interni o accessibili solo tramite VPN. Lasciarle esposte su Internet rimane la prima causa di compromissione per forza bruta.
- Le porte dei servizi di messaggistica (25, 465, 587, 993) meritano un filtraggio geografico rigoroso se l’attività è locale, e una verifica che i protocolli di crittografia TLS siano attivati per proteggere i dati in transito.
- Le porte utilizzate da protocolli non crittografati (Telnet su 23, FTP su 21, HTTP su 80) dovrebbero essere disabilitate a favore dei loro equivalenti sicuri. Se un servizio legacy impone il loro mantenimento, si isola questo servizio in un segmento di rete dedicato.
Registrazione DNS e correlazione con i flussi TCP
Bloccare e filtrare non basta se non si guarda mai cosa succede. La registrazione delle richieste DNS, incrociata con i log di connessione sulle porte TCP, costituisce uno strumento di rilevamento formidabile e sottoutilizzato.
Un computer che risolve un nome di dominio insolito, poi apre una connessione TCP in uscita verso un indirizzo IP sconosciuto su una porta alta, produce un segnale debole. Preso isolatamente, ogni evento sembra innocuo. È la correlazione tra la richiesta DNS e il flusso TCP che rivela l’exfiltrazione.
La guida NIST SP 800-81 Revision 3, pubblicata il 19 marzo 2026, insiste su questa nozione di visibilità operativa. Raggruppa DoH, DoT e DoQ sotto la categoria “encrypted DNS” e raccomanda di trattare il DNS non più come una semplice infrastruttura di fondo, ma come un punto di controllo di sicurezza a tutti gli effetti.
Ciò che la registrazione deve catturare
Per essere utilizzabile, un registro DNS deve registrare almeno il nome di dominio richiesto, l’indirizzo IP sorgente, il timestamp e la risposta restituita. Per quanto riguarda le porte TCP, si conservano le connessioni stabilite, rifiutate e i tentativi di connessione abortiti. I ritorni variano sulla durata di conservazione ideale, ma il regolamento di esecuzione europeo 2024/2690, applicabile dal 7 novembre 2024, impone ad alcuni fornitori di servizi DNS e di infrastruttura una registrazione continua con prova di efficacia dei controlli.
DNSSEC e crittografia: proteggere l’integrità delle risposte DNS
Un risolutore che risponde correttamente non garantisce che la risposta non sia stata alterata lungo il percorso. L’avvelenamento della cache DNS reindirizza gli utenti verso server fraudolenti senza che alcun avviso si attivi lato rete. DNSSEC aggiunge una firma crittografica ai record di zona per convalidarne l’autenticità.
DNSSEC convalida l’origine delle risposte, la crittografia DNS protegge la loro riservatezza in transito: i due meccanismi si completano, nessuno sostituisce l’altro.
In pratica, implementare DNSSEC sulle proprie zone interne impone di gestire il rinnovo delle chiavi crittografiche. Una chiave scaduta senza rotazione programmata provoca un’interruzione della risoluzione tanto brusca quanto un attacco. Si automatizza la rotazione o non si implementa.
Politica di sicurezza della rete: collegare DNS e porte in un approccio unificato
Trattare i DNS da un lato e le porte dall’altro crea angoli morti. Un servizio autorizzato dal firewall ma che risolve domini malevoli passerà sotto il radar. Al contrario, un blocco DNS senza controllo delle porte lascia la porta aperta alle connessioni dirette per indirizzo IP.
Il percorso coerente collega i tre strati:
- Il risolutore DNS interno filtra i domini e registra le richieste.
- Il firewall limita le porte TCP e UDP ai soli servizi dichiarati e mantenuti.
- Uno strumento di correlazione (SIEM o semplice script di analisi dei log) incrocia gli eventi DNS e le connessioni di rete per identificare comportamenti anomali.
Questa articolazione non richiede un budget consistente. Un risolutore filtrante, regole di firewall riviste trimestralmente e una pila di log consultata ogni settimana coprono la maggior parte delle vulnerabilità legate ai DNS e alle porte. Il collegamento più fragile non è lo strumento, è la regolarità della revisione.
