Il DNS associa un nome di dominio leggibile a un indirizzo IP utilizzabile dagli apparecchi di rete. Le porte TCP, invece, determinano quali servizi accettano o rifiutano una connessione in entrata. Questi due meccanismi, spesso configurati una volta e poi dimenticati, costituiscono però dei vettori d’attacco privilegiati quando sono gestiti male.
Risoluzione DNS e superficie d’attacco: cosa cambia con la crittografia
Per impostazione predefinita, le richieste DNS circolano in chiaro sulla porta UDP 53. Un attaccante posizionato sulla rete può intercettare queste richieste, modificarle o reindirizzare il traffico verso un server malevolo. Il filtraggio DNS classico si basa proprio su questa visibilità: l’amministratore ispeziona le richieste per bloccare i domini pericolosi.
L’arrivo di DNS over HTTPS (DoH) sconvolge questo equilibrio. DoH incapsula le richieste DNS nel traffico HTTPS standard, sulla porta TCP 443. Il contenuto delle richieste diventa invisibile agli strumenti di supervisione della rete. Un dispositivo configurato per utilizzare un risolutore DoH esterno può così eludere l’intero filtraggio DNS aziendale senza attivare alcun allerta.
La soluzione non consiste nel bloccare DoH a priori. L’approccio raccomandato è di definire un risolutore DNS autorizzato internamente, compatibile con DoH o DoT (DNS over TLS, porta 853), e poi forzare il suo utilizzo sui dispositivi tramite politiche di gruppo o un MDM.
Le richieste verso risolutori esterni non approvati vengono quindi bloccate a livello del firewall. Questa configurazione preserva la riservatezza degli scambi DNS mantenendo al contempo la capacità di filtraggio, come dettaglia la guida sulla sicurezza di Open Syd nel suo capitolo dedicato al rafforzamento delle politiche di rete.
Porte TCP aperte: ridurre la superficie esposta della rete
Ogni porta TCP aperta su un server rappresenta un punto d’ingresso potenziale. Un servizio che ascolta su una porta non utilizzata o non monitorata offre un’opportunità diretta a un attaccante per tentare una connessione, sfruttare una vulnerabilità o stabilire un canale di comando.
Identificare le porte realmente necessarie
Il primo passo è un inventario. Troppi ambienti mantengono porte aperte ereditate da configurazioni obsolete: servizi di test, interfacce di amministrazione temporanee, protocolli obsoleti. Una scansione regolare delle porte esposte, dall’esterno della rete, rivela spesso servizi di cui nessuno sospettava l’esistenza.
Le porte da monitorare prioritariamente:
- La porta 53 (DNS) deve essere limitata ai soli server DNS interni autorizzati, e il traffico DNS in uscita verso risolutori esterni non approvati bloccato dal firewall
- La porta 443 (HTTPS) merita un’ispezione particolare poiché DoH vi transita, rendendo possibile l’exfiltrazione di dati o l’elusione delle politiche di sicurezza
- Le porte di amministrazione remota (22 per SSH, 3389 per RDP) non devono mai essere esposte direttamente su internet senza un gateway intermedio o VPN
- Le porte associate a servizi legacy (Telnet sulla porta 23, FTP sulla porta 21) dovrebbero essere disabilitate a favore dei loro equivalenti crittografati
Applicare il principio del minimo privilegio ai flussi di rete
Ogni regola del firewall dovrebbe specificare una fonte, una destinazione e una porta precisa. Le regole “any to any” su una porta data equivalgono a lasciare una porta aperta a chiunque conosca l’indirizzo. La segmentazione della rete completa questo approccio: posizionare i server DNS in un segmento dedicato limita la propagazione laterale in caso di compromissione.
DNSSEC e protezione dell’account DNS: due strati complementari
DNSSEC firma crittograficamente le risposte DNS per garantire che l’informazione ricevuta dal cliente corrisponda a quella pubblicata dal server legittimo. Senza questa validazione, un attaccante può iniettare risposte false (avvelenamento della cache) e reindirizzare il traffico verso server malevoli senza che l’utente se ne accorga.
Implementare DNSSEC rimane un argomento operativo tanto quanto crittografico. Errori di configurazione, in particolare nella rotazione delle chiavi di firma, possono provocare interruzioni del servizio. L’attivazione richiede quindi test preliminari e una procedura di rollback documentata.
Un aspetto spesso trascurato riguarda la protezione dell’account che gestisce i registri DNS. Prendere il controllo di questo account consente di modificare direttamente le risposte DNS, reindirizzare il traffico o generare certificati TLS fraudolenti. L’agenzia americana CISA raccomanda di proteggere questi accessi tramite autenticazione multifattoriale, di auditare regolarmente i registri pubblicati e di monitorare i log di Certificate Transparency per rilevare eventuali emissioni di certificato non autorizzate.
Direttiva NIS2 e gestione dei rischi DNS in Europa
La direttiva europea NIS2 amplia il perimetro delle entità soggette a obblighi di cybersicurezza. I fornitori di servizi DNS figurano esplicitamente tra le entità interessate. Il regolamento di esecuzione europeo 2024/2690 specifica i requisiti tecnici attesi, in particolare in materia di gestione dei rischi informatici.
Per le organizzazioni che gestiscono la propria infrastruttura DNS, questa evoluzione normativa implica la formalizzazione di diverse pratiche:
- Documentare la politica di gestione delle zone DNS, inclusi i trasferimenti di zona e i meccanismi di replicazione
- Implementare un registro delle modifiche ai registri e degli accessi ai server DNS
- Integrare i componenti DNS nel perimetro degli audit di sicurezza periodici
Questi requisiti non sono nuovi dal punto di vista tecnico. NIS2 li rende vincolanti dal punto di vista giuridico, con sanzioni in caso di non conformità.
Il controllo congiunto del DNS e delle porte TCP forma una base di sicurezza di rete che né i firewall applicativi né gli antivirus possono sostituire. Un risolutore DNS correttamente configurato e porte rigorosamente filtrate riducono la superficie d’attacco anche prima che uno strumento di rilevamento entri in gioco.
