Il miglior filtro DNS: una guida completa per le aziende

Questa guida tecnica di riferimento spiega in che modo il filtraggio DNS aziendale protegge le reti pubbliche bloccando i domini dannosi a livello di risoluzione - prima ancora che venga stabilita una connessione. Fornisce ai direttori IT, agli architetti di rete e ai team operativi delle sedi l'architettura di implementazione, la configurazione del firewall e il contesto di conformità necessari per proteggere il WiFi per gli ospiti in ambienti alberghieri, retail e del settore pubblico. Purple Shield blocca malware, botnet e contenuti inappropriati a livello DNS in oltre 80.000 sedi attive.

📖 8 minuti di lettura📝 1,807 parole🔧 2 esempi pratici❓ 4 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Benvenuto al Technical Briefing di Purple. Oggi analizzeremo un componente fondamentale della sicurezza delle reti aziendali: il filtraggio DNS.

Se sei un IT director o un network architect che gestisce reti pubbliche nel settore dell'ospitalità, del retail o in grandi location, sai bene che offrire il WiFi è ormai un servizio di base. Proprio come l'elettricità o l'aria condizionata, è un servizio che i visitatori si aspettano funzioni nel momento stesso in cui entrano in un edificio. Ma dal punto di vista della sicurezza, questo servizio crea una superficie di attacco enorme e non gestita.

Quando offri un accesso aperto a una rete, inviti dispositivi non gestiti all'interno della tua infrastruttura. Non puoi installare una protezione endpoint sul dispositivo personale di un ospite. I perimetri di sicurezza tradizionali non sono sufficienti. Ecco perché il filtraggio DNS è diventato il livello più critico in uno stack di sicurezza moderno. Sposta la difesa al primissimo passo di una connessione digitale.

Iniziamo con l'approfondimento tecnico. Come funziona effettivamente il filtraggio DNS?

Il Domain Name System, o DNS, è la rubrica telefonica di internet. Quando un ospite si connette al tuo WiFi e digita l'indirizzo di un sito web nel browser, il suo dispositivo deve tradurre quel dominio leggibile dall'uomo in un indirizzo IP leggibile dalla macchina. In una configurazione standard, questa query va a un resolver predefinito, spesso fornito dall'ISP.

In un'architettura sicura che utilizza il filtraggio DNS, il server DHCP assegna un resolver DNS specifico e sicuro al dispositivo dell'ospite. Quando la query raggiunge questo motore di filtraggio, non si limita a risolvere l'indirizzo IP. Valuta il dominio confrontandolo con feed di threat intelligence in tempo reale e con le tue specifiche policy aziendali.

Se il dominio è sicuro, l'IP viene restituito e la connessione procede. Questo avviene in millisecondi. Tuttavia, se il dominio viene segnalato come dannoso, ad esempio come sito di phishing noto o server di comando e controllo di una botnet, o se viola la tua policy sui contenuti, il motore interviene. Restituisce un indirizzo IP non instradabile, una tecnica nota come sinkholing, oppure reindirizza l'utente a una pagina di blocco personalizzata.

Perché questo approccio è superiore ad alternative come la Deep Packet Inspection o il filtraggio proxy? È una questione di prestazioni e scalabilità.

La Deep Packet Inspection richiede che l'hardware di rete ispezioni il payload di ogni singolo pacchetto. In un ambiente ad alta densità come uno stadio con cinquantamila utenti simultanei, la DPI introduce una latenza enorme e richiede hardware incredibilmente costoso. Il filtraggio DNS, al contrario, opera all'inizio del ciclo di vita della connessione. Valuta un pacchetto UDP leggero. Una volta completata la risoluzione DNS, il trasferimento effettivo dei dati avviene direttamente tra il client e il server sicuro. Il motore di filtraggio non ha bisogno di elaborare il pesante payload dei dati. Ciò si traduce in un impatto sulla latenza quasi nullo, tipicamente inferiore a due millisecondi.
Inoltre, poiché il filtraggio DNS opera prima che venga stabilita la connessione, è completamente indipendente dal protocollo. Blocca la connessione sia che l'applicazione stia cercando di utilizzare HTTP, HTTPS, FTP o una porta personalizzata.

Prendiamo ora in esame un esempio reale. Consideriamo una catena di hotel di lusso con cinquecento camere. Registrano un elevato utilizzo della larghezza di banda a causa dello streaming illegale e hanno ricevuto lamentele per l'accesso a contenuti inappropriati nelle aree pubbliche. Il loro sistema di gestione della proprietà condivide la stessa infrastruttura fisica tramite VLAN.

L'approccio corretto consiste nello distribuire una soluzione di filtraggio DNS basata sul cloud e configurare l'ambito DHCP specificamente per la VLAN Guest WiFi in modo da assegnare gli IP DNS del cloud. È fondamentale implementare regole firewall sul gateway per bloccare il traffico in uscita sulle porte UDP e TCP cinquantatré dalla VLAN Guest verso qualsiasi IP esterno diverso dai server DNS approvati. Successivamente, si crea una policy che blocca le categorie di contenuti per adulti, pirateria e malware. La decisione architetturale chiave consiste nel garantire che la VLAN del sistema di gestione della proprietà continui a utilizzare i server DNS interni, isolando completamente la policy di filtraggio alla rete degli ospiti.

Parliamo ora degli errori di implementazione.

Il passo fondamentale è la configurazione della rete. È necessario configurare il gateway o il server DHCP per distribuire gli indirizzi IP del servizio di filtraggio DNS a tutti i client sulla VLAN guest.

Ma ecco la regola empirica fondamentale: blocca la porta cinquantatré, o sarà tutto inutile.

Se ti limiti ad assegnare i server DNS tramite DHCP, gli utenti esperti o le applicazioni dannose possono aggirare il filtro codificando manualmente le proprie impostazioni DNS, come l'otto-otto-otto-otto di Google o l'uno-uno-uno-uno di Cloudflare. Per prevenire questa elusione, è necessario implementare regole firewall sul gateway che blocchino tutto il traffico in uscita sulla porta cinquantatré, sia UDP che TCP, verso qualsiasi indirizzo IP diverso dai server di filtraggio designati.

Un altro grave errore riguarda i Captive Portal. Lo riscontriamo spesso nelle installazioni per il retail e l'hospitality. Una struttura implementa un filtraggio DNS rigoroso e, improvvisamente, gli ospiti non riescono più a connettersi. Perché? Perché il Captive Portal si affida a domini esterni per l'autenticazione, ad esempio i provider OAuth per il social login. Se il filtro DNS blocca questi domini prima che l'utente si sia autenticato, si crea un circolo vizioso. L'utente non può accedere a Internet per autenticarsi e non può autenticarsi per accedere a Internet.

La soluzione consiste nell'assicurarsi che il Walled Garden sia configurato correttamente. È necessario inserire esplicitamente nella allowlist i domini richiesti per l'esperienza del Captive Portal all'interno della policy di filtraggio DNS.

Un secondo scenario reale: un grande centro commerciale desidera offrire WiFi pubblico gratuito con un Captive Portal per l'acquisizione di dati demografici, rispettando al contempo rigide politiche aziendali a tutela delle famiglie. L'integrazione del filtraggio DNS con il Captive Portal richiede l'aggiunta dei domini di autenticazione, come Microsoft Entra ID o Google Workspace, alla allowlist di pre-autenticazione. La policy di filtraggio dei contenuti viene quindi applicata solo dopo che l'utente si è autenticato con successo. Questo approccio trasforma un potenziale conflitto tecnico in un'esperienza utente fluida.

Passiamo ora a una sessione di domande e risposte rapide basata su scenari comuni.

Domanda uno: Possiamo utilizzare l'ispezione HTTPS trasparente invece del filtraggio DNS per la nostra rete ospiti?

No. L'ispezione HTTPS trasparente richiede l'installazione di un certificato root personalizzato sul dispositivo endpoint per decrittografare il traffico. Non è possibile distribuire certificati su dispositivi ospiti non gestiti. Ciò comprometterebbe la loro esperienza di navigazione con gravi avvisi di sicurezza. Il filtraggio DNS è l'approccio corretto per gli ambienti bring-your-own-device.

Domanda due: In che modo il filtraggio DNS gestisce il DNS over HTTPS, o DoH?

Il DoH crittografa la query DNS, il che può bypassare la tradizionale intercettazione a livello di rete. La best practice consiste nell'identificare e bloccare gli indirizzi IP dei provider DoH noti sul firewall, costringendo il client a ripiegare sul DNS standard e filtrabile.

Domanda tre: Il filtraggio DNS aiuta con la conformità?

Assolutamente sì. Per framework come PCI-DSS, dimostrare la segmentazione della rete e controlli di accesso robusti è obbligatorio. Sebbene le reti ospiti debbano sempre essere segmentate dalle reti di pagamento, prevenire l'esecuzione di malware sulla rete ospiti riduce il profilo di rischio complessivo della sede. Ai fini del GDPR, dimostrare di aver adottato misure tecniche ragionevoli per prevenire l'uso improprio della rete è un indicatore positivo di conformità.

Per riassumere il briefing di oggi. Il filtraggio DNS non è solo una best practice di sicurezza. È una necessità operativa per le reti pubbliche aziendali. Fornisce un meccanismo scalabile e a bassa latenza per bloccare le minacce informatiche e applicare le policy di utilizzo accettabile.

I punti chiave sono i seguenti. Primo, il filtraggio DNS intercetta le query di dominio prima che venga stabilita una connessione, aggiungendo meno di due millisecondi di latenza. Secondo, bloccare sempre la porta cinquantatré in uscita sul firewall per impedire l'elusione tramite impostazioni DNS personalizzate. Terzo, configurare attentamente il Walled Garden per garantire che i domini di autenticazione del Captive Portal non siano bloccati. Quarto, utilizzare la segmentazione VLAN per applicare le policy di filtraggio esclusivamente al traffico ospiti, proteggendo i sistemi operativi. E quinto, il filtraggio DNS supporta la conformità con PCI-DSS e GDPR dimostrando robusti controlli di accesso alla rete.

I vostri prossimi passi: verificate la configurazione DNS attuale della rete ospiti, accertatevi che la porta cinquantatré in uscita sia limitata e controllate il Walled Garden del vostro Captive Portal rispetto alla policy di filtraggio DNS attiva.

Grazie per aver ascoltato questo Purple Technical Briefing. Per guide di implementazione e modelli di architettura più dettagliati, visita purple dot ai.

Punti chiave

✓Il filtraggio DNS intercetta le richieste di risoluzione dei domini prima che venga stabilita qualsiasi connessione, aggiungendo meno di 2 ms di latenza - rendendolo l'unico metodo pratico di controllo dei contenuti per le reti ospiti ad alta densità.
✓L'assegnazione DHCP da sola non costituisce un'applicazione forzata. Blocca la porta 53 in uscita (UDP e TCP) sul firewall per impedire agli utenti e ai malware di aggirare il filtro con impostazioni DNS personalizzate.
✓Configura il Walled Garden prima di applicare qualsiasi policy di blocco. I domini dei provider di identità (Microsoft Entra ID, Google Workspace, Okta) devono essere inseriti nella whitelist affinché l'autenticazione del Captive Portal funzioni.
✓Limita le policy di filtraggio DNS solo alla VLAN ospiti. Le VLAN operative che eseguono sistemi POS e PMS devono utilizzare resolver DNS interni per evitare interruzioni e problemi di conformità PCI DSS.
✓Blocca i range IP dei provider DoH noti sul firewall per impedire l'aggiramento del DNS crittografato sui browser e dispositivi moderni.
✓Il filtraggio DNS supporta il requisito PCI DSS 1.3 (segmentazione della rete) e l'articolo 32 del GDPR (misure di sicurezza tecniche), fornendo prove documentate per gli audit di conformità.
✓Purple Shield identifica e blocca le minacce zero-day fino a 10 giorni più velocemente rispetto ai provider di blacklist reattivi, utilizzando l'analisi dei domini basata sull'intelligenza artificiale anziché attendere la segnalazione dei siti dannosi.

Sintesi per il management

Per i leader IT che gestiscono reti pubbliche su larga scala, la sicurezza dell'ambiente di navigazione è un imperativo operativo, non un optional. Il Guest WiFi nel settore hospitality, retail e nei luoghi pubblici è un ambiente intrinsecamente non attendibile. Senza controlli robusti, diventa un vettore per la distribuzione di malware, attività di botnet e accesso a contenuti inappropriati che danneggiano la reputazione del marchio e creano rischi di conformità.

Il filtraggio DNS è il meccanismo più efficiente per applicare le policy sui contenuti e bloccare le minacce all'edge della rete. A differenza del Deep Packet Inspection (DPI), che richiede un utilizzo intensivo di risorse, il filtraggio DNS intercetta la richiesta di risoluzione del dominio prima dello scambio di qualsiasi payload. Valuta un pacchetto UDP leggero rispetto all'intelligence sulle minacce in tempo reale e restituisce un indirizzo IP valido o un sinkhole, aggiungendo meno di due millisecondi di latenza. Questo lo rende l'unico metodo pratico di controllo dei contenuti per ambienti ad alta densità che servono migliaia di dispositivi non gestiti simultaneamente.

Questa guida illustra l'architettura tecnica necessaria per distribuire il filtraggio DNS in sedi aziendali distribuite, tra cui la segmentazione VLAN, l'applicazione della porta 53, l'integrazione del Captive Portal e la prevenzione dell'elusione del DNS over HTTPS (DoH). Affronta inoltre la conformità con PCI-DSS e GDPR, e spiega come Purple Shield si integra negli stack hardware esistenti di Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet senza richiedere la sostituzione dell'hardware.

Approfondimento tecnico: come funziona il filtraggio DNS

Il Domain Name System (DNS) traduce i domini leggibili dall'uomo in indirizzi IP leggibili dalla macchina. Ogni connessione Internet inizia con una richiesta di risoluzione DNS. In una rete standard, i dispositivi interrogano un resolver predefinito assegnato dall'ISP. In un'architettura sicura, il server DHCP assegna un resolver DNS soggetto a policy ai dispositivi sulla VLAN guest.

Quando un dispositivo interroga questo resolver sicuro, il motore di filtraggio valuta il dominio confrontandolo simultaneamente con più origini dati: feed di intelligence sulle minacce in tempo reale, blacklist di categorie (contenuti per adulti, gioco d'azzardo, pirateria) e registri dei domini di comando e controllo delle botnet. La decisione avviene in pochi millisecondi.

Se il dominio è sicuro, il motore restituisce l'indirizzo IP corretto e la connessione procede normalmente. Se il dominio viene contrassegnato come dannoso o viola la policy di utilizzo accettabile, il motore restituisce un indirizzo IP non instradabile (sinkholing) o reindirizza l'utente a una pagina di blocco personalizzata. Il punto chiave: questo intervento avviene prima che avvenga qualsiasi scambio di payload di dati tra il dispositivo e il server di destinazione.

Vantaggi in termini di prestazioni e scalabilità

Il filtraggio DNS è strutturalmente superiore al DPI per gli ambienti pubblici ad alta densità. Il DPI richiede che l'hardware di rete ispezioni il payload di ogni singolo pacchetto. In una struttura con 50.000 utenti simultanei - come uno stadio, un centro congressi o un grande complesso commerciale - il DPI introduce una latenza significativa e richiede hardware costoso e dedicato in ogni punto di ispezione.

Il filtraggio DNS opera all'inizio del ciclo di vita della connessione. Valuta un singolo pacchetto UDP leggero. Una volta completata la risoluzione, i dati vengono trasferiti direttamente tra il client e il server di destinazione. Il motore di filtraggio non elabora mai il payload dei dati. L'impatto sulla latenza è costantemente inferiore a due millisecondi, indipendentemente dal numero di utenti simultanei.

Poiché il filtraggio DNS opera prima dello stabilimento della connessione, è indipendente dal protocollo. Blocca le connessioni sia che l'applicazione utilizzi HTTP, HTTPS, FTP o una porta personalizzata. Questo rappresenta un vantaggio significativo rispetto al filtraggio basato su URL, che ispeziona solo il traffico HTTP/HTTPS.

Il vantaggio di 10 giorni nella rilevazione delle minacce

La sicurezza DNS legacy si basa su blacklist reattive: un dominio viene identificato come dannoso, segnalato a un'autorità centrale, aggiunto a un database e infine distribuito al filtro - un processo che può richiedere giorni. Le campagne malware moderne sfruttano questo ritardo. Gli aggressori registrano nuovi domini, eseguono una campagna entro una finestra di 24 ore e abbandonano il dominio prima che raggiunga qualsiasi blocklist standard.

Purple Shield utilizza la rilevazione delle minacce basata sull'intelligenza artificiale per analizzare i pattern di registrazione dei domini, la reputazione degli IP e le firme crittografiche in tempo reale. Questo approccio identifica e blocca le minacce zero-day emergenti fino a 10 giorni prima rispetto ai tradizionali provider reattivi (dati interni Purple, 2026). In un ambiente in cui un singolo link dannoso su un dispositivo ospite può portare a un ransomware, tale finestra di rilevazione è operativamente significativa.

Guida all'implementazione: architettura e deployment

La corretta implementazione del filtraggio DNS richiede una configurazione di rete precisa su tre livelli: DHCP, firewall e Captive Portal.

Passaggio 1: Segmentazione della VLAN

Segmenta la tua rete in modo che il traffico degli ospiti sia isolato dai sistemi operativi. Posiziona i dispositivi degli ospiti su una VLAN dedicata (ad esempio, VLAN 20) e mantieni i terminali POS, i sistemi di gestione della proprietà e i dispositivi del personale su VLAN separate con resolver DNS interni. Questo assicura che la tua policy di filtraggio DNS si applichi esclusivamente al traffico non attendibile degli ospiti e non interrompa i sistemi operativi.

Questa segmentazione soddisfa anche il requisito PCI-DSS 1.3, che impone l'isolamento degli ambienti con dati dei titolari di carta da reti non attendibili. Il WiFi ospiti non deve mai condividere una VLAN con l'infrastruttura di pagamento.

Passaggio 2: Configurazione dello scope DHCP

Configura lo scope DHCP per la VLAN guest in modo da assegnare gli indirizzi IP del tuo servizio di filtraggio DNS cloud come server DNS primario e secondario. Questo assicura che ogni dispositivo che si connette alla rete guest riceva automaticamente il resolver corretto.

Passo 3: Applicazione della porta 53 sul firewall

L'assegnazione tramite DHCP da sola non è sufficiente. Un utente può ignorare le impostazioni DNS fornite dal DHCP configurando manualmente il proprio dispositivo per utilizzare un resolver pubblico come Google (8.8.8.8) o Cloudflare (1.1.1.1). I malware spesso codificano in modo rigido le impostazioni DNS per aggirare completamente i controlli di rete.

È necessario implementare una regola di firewall che elimini tutto il traffico in uscita sulla porta 53 (sia UDP che TCP) dalla VLAN guest verso qualsiasi indirizzo IP diverso dai server di filtraggio designati. Questo trasforma il filtro DNS da un controllo consultivo a uno obbligatorio.

Passo 4: Mitigazione del DNS over HTTPS (DoH)

I browser e le applicazioni moderni utilizzano sempre più spesso il DoH, che crittografa le query DNS all'interno del normale traffico HTTPS sulla porta 443. Questo aggira completamente l'intercettazione della porta 53. Per mantenere la copertura, configura il firewall per bloccare gli intervalli di indirizzi IP noti dei principali provider DoH. Questo costringe i dispositivi client a ripiegare sul DNS standard non crittografato, che il tuo motore di filtraggio può ispezionare. La pubblicazione NIST SP 800-81r3 (marzo 2026) affronta specificamente il DoH come considerazione sulla sicurezza del DNS aziendale.

Passo 5: Configurazione del walled garden del Captive Portal

Se utilizzi un Captive Portal per l'autenticazione dei guest, devi configurare un Walled Garden prima di applicare qualsiasi criterio di blocco. Il Walled Garden è un elenco di domini a cui i dispositivi possono accedere prima di essersi autenticati. Deve includere tutti i domini necessari per il funzionamento del Captive Portal: il dominio del portale stesso, eventuali provider di identità (Microsoft Entra ID, Okta, Google Workspace) e tutti gli endpoint OAuth per il login social.

Se questi domini vengono bloccati prima dell'autenticazione, gli utenti non possono completare il flusso di accesso. Il risultato è un'esperienza di onboarding interrotta e guest frustrati. Configura prima il Walled Garden, quindi applica il criterio di filtraggio dei contenuti solo alle sessioni autenticate.

Per saperne di più sull'architettura degli SSID e su come dovrebbero essere strutturate le reti Guest WiFi, Staff WiFi e IoT, consulta Tre SSID per dominarli tutti: guest, Passpoint e IoT WiFi .

Best practice: progettazione delle policy e gestione continua

Blocco basato sulle categorie

Organizza la tua policy di filtraggio DNS attorno alle categorie di contenuti piuttosto che a singole liste di blocco dei domini. Le categorie includono in genere: malware e phishing, comando e controllo di botnet, contenuti per adulti, gioco d'azzardo, streaming illegale e condivisione di file peer-to-peer. Le policy basate sulle categorie sono più facili da mantenere e acquisiscono automaticamente i nuovi domini man mano che l'intelligence sulle minacce si aggiorna.

Frequenza di aggiornamento della threat intelligence

Seleziona un fornitore di filtraggio DNS che aggiorni le informazioni sulle minacce in tempo reale o quasi in tempo reale. Le blocklist statiche aggiornate quotidianamente non sono sufficienti contro le moderne campagne di malware fast-flux. Purple Shield aggiorna continuamente le sue informazioni sulle minacce, riflettendo lo stesso rilevamento basato su AI che offre un vantaggio di 10 giorni rispetto ai fornitori reattivi.

Distribuzione indipendente dall'hardware

Purple Shield opera come un overlay cloud, il che significa che si integra con l'infrastruttura di access point esistente senza dover sostituire l'hardware. È compatibile con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La policy di filtraggio viene applicata a livello DNS, quindi l'hardware dell'access point deve solo inoltrare le query DNS al resolver corretto.

Analisi e reportistica

Il filtraggio DNS genera log di query dettagliati che offrono visibilità sul comportamento della rete. Utilizza questi log per identificare i trend: un picco di tentativi di phishing bloccati da uno specifico access point può indicare un attacco mirato. L'analisi regolare dei report sulle categorie bloccate supporta anche gli audit di conformità, dimostrando ai valutatori PCI-DSS e agli auditor GDPR che disponi di controlli attivi.

La piattaforma WiFi Analytics di Purple si integra con Shield per fornire una visibilità unificata sugli eventi di sicurezza e sulle prestazioni della rete.

Risoluzione dei problemi e mitigazione dei rischi

Aggiramento del filtro tramite DNS personalizzato

Sintomo: gli utenti segnalano di accedere a contenuti che dovrebbero essere bloccati. I log del firewall mostrano query DNS verso 8.8.8.8 o 1.1.1.1 dalla VLAN guest.

Causa: la porta 53 non è bloccata sul firewall. Gli utenti stanno ignorando le impostazioni DNS assegnate dal DHCP.

Soluzione: implementa una regola del firewall che scarti tutto il traffico in uscita sulla porta UDP/TCP 53 dalla VLAN guest verso qualsiasi IP diverso dal tuo motore di filtraggio.

Errore di autenticazione del Captive Portal

Sintomo: gli ospiti non riescono a completare il flusso di accesso. La pagina del Captive Portal non si carica o i pulsanti di login social non rispondono.

Causa: il filtro DNS sta bloccando i domini del provider di identità prima dell'autenticazione. Microsoft Entra ID, Google Workspace o il dominio del tuo portale sono inclusi in un elenco di categorie bloccate.

Soluzione: controlla la configurazione del tuo Walled Garden. Aggiungi tutti i domini di autenticazione richiesti alla whitelist di pre-autenticazione. Testa l'intero flusso di login in un ambiente di staging prima di distribuire le modifiche alle policy.

Aggiramento DoH

Sintomo: i log del filtro DNS mostrano un volume di query basso nonostante l'elevato utilizzo della rete. Alcuni dispositivi sembrano aggirare completamente il filtraggio.

Causa: i browser o le applicazioni utilizzano DoH, instradando query DNS crittografate sulla porta 443 verso resolver esterni.

Soluzione: blocca sul firewall gli intervalli IP noti dei principali fornitori di DoH. Verifica la copertura monitorando le connessioni HTTPS verso gli IP dei resolver DoH noti.

Interruzione della VLAN operativa

Sintomo: i terminali POS o i sistemi di gestione della proprietà perdono la connettività dopo la distribuzione del filtro DNS.

Causa: La policy di filtraggio DNS è stata applicata alla VLAN errata, oppure il DHCP sta assegnando il risolutore DNS cloud ai dispositivi operativi.

Soluzione: Verificare il tagging VLAN su tutte le porte degli switch e gli access point. Confermare che le VLAN dei dispositivi operativi siano configurate per utilizzare solo risolutori DNS interni.

ROI e impatto sul business

Il filtraggio DNS offre vantaggi misurabili su tre livelli.

Recupero della larghezza di banda: Il blocco dello streaming illegale, della condivisione peer-to-peer e del traffico botnet automatizzato consente di recuperare una quantità significativa di larghezza di banda. In un ambiente alberghiero, questo può ridurre l'utilizzo della VLAN degli ospiti del 20-40%, migliorando le prestazioni per gli utenti legittimi senza richiedere aggiornamenti dei circuiti.

Riduzione dei costi di conformità: Dimostrare controlli attivi a livello di DNS riduce l'ambito e i costi delle valutazioni PCI-DSS. Fornisce inoltre prove documentate per l'Articolo 32 del GDPR (misure tecniche per garantire la sicurezza dei dati) e supporta i requisiti di certificazione Cyber Essentials per la protezione dal malware.

Protezione del marchio e della responsabilità: L'applicazione di policy di navigazione adatte alle famiglie nei settori retail e hospitality previene la visualizzazione pubblica di contenuti inappropriati. Nelle strutture dedicate ai minori - centri commerciali, hotel per famiglie, stadi - questa è sia un'esigenza di brand che un obbligo di legge in molte giurisdizioni.

Per indicazioni di implementazione specifiche per il settore, consultare le nostre pagine dedicate a Hospitality , Retail , Healthcare e Transport .

Definizioni chiave

Filtraggio DNS

Una tecnica di sicurezza che intercetta le richieste di risoluzione dei domini e le valuta rispetto ai feed di threat intelligence e alle policy sui contenuti prima di consentire o bloccare una connessione.

Il metodo principale di controllo dei contenuti per i dispositivi degli ospiti non gestiti su reti pubbliche. Non richiede alcun agente endpoint.

Sinkholing

Restituzione di un indirizzo IP non instradabile (come 0.0.0.0) in risposta a una query DNS per un dominio dannoso, impedendo al dispositivo di stabilire una connessione.

Utilizzato per bloccare silenziosamente il traffico di comando e controllo delle botnet senza avvisare il malware che è stato rilevato.

Walled Garden

Un ambiente di rete limitato prima dell'autenticazione che consente l'accesso a un set specifico di domini approvati prima che l'utente completi il flusso di accesso al Captive Portal.

Deve includere tutti i domini dei provider di identità (Microsoft Entra ID, Google Workspace, Okta) e gli asset del Captive Portal per evitare errori di autenticazione.

DNS over HTTPS (DoH)

Un protocollo che crittografa le query DNS all'interno del normale traffico HTTPS sulla porta 443, nascondendo il dominio di destinazione all'ispezione a livello di rete.

Sempre più utilizzato per impostazione predefinita nei browser moderni. Richiede il blocco a livello di firewall degli intervalli IP dei provider DoH per mantenere la copertura del filtro DNS.

Segmentazione VLAN

Suddivisione di una singola rete fisica in più reti logiche isolate utilizzando il tagging 802.1Q.

Fondamentale per isolare il traffico degli ospiti dai sistemi operativi. Il requisito 1.3 dello standard PCI-DSS impone che gli ambienti dei dati dei titolari di carta siano separati dalle reti non attendibili, incluso il WiFi ospiti.

Captive Portal

Una pagina web con cui i dispositivi devono interagire prima di ottenere l'accesso completo alla rete, utilizzata per l'autenticazione, l'accettazione dei termini di servizio e l'acquisizione di dati di prima parte.

Richiede un'attenta configurazione del Walled Garden per funzionare correttamente insieme al filtraggio DNS.

Deep Packet Inspection (DPI)

Un metodo di filtraggio di rete che esamina l'intero payload dei pacchetti in un punto di ispezione, consentendo un filtraggio sensibile al contenuto ma introducendo un notevole sovraccarico di elaborazione.

Poco pratico per reti ospiti ad alta densità a causa della latenza e dei costi hardware. Il filtraggio DNS è l'alternativa preferita per gli ambienti con dispositivi non gestiti.

Threat intelligence feed

Un database continuamente aggiornato di indirizzi IP, domini e pattern URL noti come dannosi, utilizzato per alimentare le decisioni di filtraggio DNS in tempo reale.

La qualità e la frequenza di aggiornamento del threat intelligence feed determinano la rapidità con cui un filtro DNS risponde alle nuove minacce zero-day.

Dominio zero-day

Un dominio registrato di recente utilizzato in una campagna di malware o phishing prima che appaia su una qualsiasi blocklist standard.

Le moderne campagne di attacco utilizzano domini usa e getta attivi per meno di 24 ore. Il rilevamento delle minacce guidato dall'intelligenza artificiale identifica questi domini analizzando i pattern di registrazione anziché attendere le segnalazioni.

Esempi pratici

Una catena alberghiera da 400 camere sta implementando il WiFi per gli ospiti in 12 strutture. Utilizza Microsoft Entra ID per l'autenticazione tramite Captive Portal e il suo sistema di gestione immobiliare (PMS) funziona sulla stessa infrastruttura di switch fisici. Dopo aver abilitato il filtraggio DNS, gli ospiti di tre strutture segnalano di non riuscire a completare la procedura di accesso. Qual è la causa principale e come deve risolverla il team?

La causa principale è una configurazione incompleta del Walled Garden. Il filtro DNS blocca i domini di autenticazione di Microsoft Entra ID prima che gli ospiti si autentichino, creando una situazione di stallo in cui gli ospiti non possono caricare la pagina di login. Passaggi per la risoluzione: 1. Nella dashboard del filtraggio DNS, creare una policy di pre-autenticazione che inserisca esplicitamente nella allowlist tutti i domini di Microsoft Entra ID, inclusi login.microsoftonline.com, login.live.com e qualsiasi dominio specifico del tenant. 2. Verificare che anche il dominio del Captive Portal e tutte le risorse CDN che carica siano inclusi nella allowlist. 3. Confermare che la VLAN del PMS (VLAN 10) sia configurata per utilizzare resolver DNS interni e non il motore di filtraggio cloud. 4. Applicare la policy restrittiva di blocco dei contenuti solo alle sessioni post-autenticazione sulla VLAN degli ospiti (VLAN 20). 5. Testare l'intero flusso di accesso in ogni struttura interessata prima di chiudere l'incidente.

Commento dell'esaminatore: Questo è il singolo errore di implementazione del filtraggio DNS più comune nel settore alberghiero. La correzione è semplice ma richiede la consapevolezza che il filtraggio DNS si applica a tutte le query DNS inviate da un dispositivo, comprese quelle effettuate prima dell'autenticazione. Il Walled Garden deve essere configurato prima che qualsiasi policy di blocco sia attiva. Il problema dell'isolamento del PMS è un riscontro secondario ma critico - mescolare le policy DNS operative e degli ospiti sullo stesso resolver crea un rischio di conformità ai sensi del PCI DSS Requirement 1.3.

Una grande catena retail gestisce 200 negozi, ognuno dotato di una rete WiFi per gli ospiti. Il loro team di sicurezza IT distribuisce un filtro DNS cloud e aggiorna lo scope DHCP su tutte le VLAN degli ospiti. Due settimane dopo, un penetration test rivela che il 18% dei dispositivi degli ospiti risolve con successo domini dannosi noti. I log del filtro DNS non mostrano query bloccate da questi dispositivi. Qual è il difetto architetturale e quale la soluzione?

Il difetto è che la porta 53 non è bloccata sul firewall. Il 18% dei dispositivi aggira i server DNS assegnati tramite DHCP utilizzando resolver hardcoded (8.8.8.8, 1.1.1.1) o utilizzando DNS over HTTPS. Poiché le loro query DNS non raggiungono mai il motore di filtraggio, nei log non compare alcuna query bloccata. Soluzione: 1. Implementare una regola di firewall sul gateway della VLAN ospiti che scarti tutto il traffico UDP e TCP in uscita sulla porta 53 verso qualsiasi IP diverso da quelli approvati per il motore di filtraggio. 2. Identificare e bloccare sul firewall gli intervalli IP dei principali provider DoH (Cloudflare, Google, NextDNS) per impedire l'elusione crittografata. 3. Eseguire nuovamente il penetration test per confermare la copertura. 4. Monitorare i log di drop del firewall per il traffico sulla porta 53 per verificare che la regola sia attiva.

Commento dell'esaminatore: Il DHCP è un suggerimento, non un meccanismo di imposizione. La regola del firewall rappresenta il vero livello di applicazione. Questa distinzione è fondamentale e viene spesso trascurata nelle distribuzioni iniziali. L'aggiramento tramite DoH è un vettore secondario che richiede una mitigazione separata. Insieme, questi due controlli - il blocco della porta 53 e il blocco degli IP dei provider DoH - chiudono le principali vie di elusione.

Domande di esercitazione

Q1. Una catena retail distribuisce un filtro DNS cloud in 150 negozi. Aggiorna l'ambito DHCP su tutte le VLAN ospiti per assegnare gli IP del motore di filtraggio. Una settimana dopo, i direttori dei negozi segnalano che i clienti possono ancora accedere alle categorie di contenuti bloccate. La dashboard del filtro DNS mostra un volume di query molto basso da questi negozi. Qual è la causa più probabile e quale la soluzione?

Suggerimento: Considera come un dispositivo possa risolvere il DNS senza utilizzare il server assegnato dal DHCP.

Visualizza risposta modello

La causa più probabile è che la porta 53 in uscita non è bloccata sul firewall. I dispositivi stanno ignorando i server DNS assegnati tramite DHCP utilizzando resolver pubblici hardcoded. Il basso volume di query nella dashboard conferma che le query non raggiungono il motore di filtraggio. La soluzione consiste nell'implementare una regola firewall che elimini tutto il traffico UDP e TCP in uscita sulla porta 53 dalla VLAN ospiti verso qualsiasi IP diverso dagli IP approvati del motore di filtraggio. Inoltre, è necessario bloccare gli intervalli IP dei provider DoH noti per impedire l'aggiramento del DNS crittografato.

Q2. Un centro congressi sta implementando il filtraggio DNS per la prima volta. Utilizza Google Workspace per l'autenticazione dei partecipanti sul proprio Captive Portal. Durante i test, i partecipanti non riescono a completare il flusso di accesso: la pagina di accesso di Google non si carica. Quale passaggio di configurazione è stato saltato e come dovrebbe essere corretto?

Suggerimento: L'autenticazione avviene prima che il dispositivo abbia pieno accesso a Internet. Quali domini devono essere raggiungibili prima che l'autenticazione sia completata?

Visualizza risposta modello

Il Walled Garden non è stato configurato prima dell'applicazione della policy di filtraggio DNS. Il filtro DNS sta bloccando i domini di autenticazione di Google Workspace (accounts.google.com, oauth2.googleapis.com) prima che i partecipanti possano autenticarsi. La soluzione consiste nell'aggiungere tutti i domini di autenticazione e OAuth di Google Workspace richiesti alla whitelist di pre-autenticazione nella policy di filtraggio DNS. Anche il dominio del Captive Portal e gli eventuali asset CDN devono essere inseriti nella whitelist. Applica la policy restrittiva sui contenuti solo alle sessioni post-autenticazione.

Q3. Il team IT di uno stadio sta valutando il filtraggio DNS rispetto alla Deep Packet Inspection per la propria struttura da 60.000 posti. Il team di rete è preoccupato per la latenza durante gli eventi di punta. Quale approccio è più appropriato e perché?

Suggerimento: Considera il sovraccarico di elaborazione di ciascun metodo su una scala di 60.000 utenti simultanei.

Visualizza risposta modello

Il filtraggio DNS è la scelta appropriata. Funziona a livello di risoluzione, valutando un singolo pacchetto UDP leggero prima che venga stabilita qualsiasi connessione, aggiungendo meno di due millisecondi di latenza indipendentemente dal numero di utenti simultanei. La DPI richiede l'ispezione dell'intero payload di ogni pacchetto, il che con 60.000 utenti simultanei introdurrebbe una latenza significativa e richiederebbe hardware proibitivamente costoso in ogni punto di ispezione. Il filtraggio DNS è inoltre indipendente dal protocollo, bloccando le connessioni su qualsiasi porta, mentre la DPI è in genere limitata al traffico HTTP e HTTPS.

Q4. Un direttore IT di un gruppo alberghiero desidera confermare che la propria implementazione del filtraggio DNS soddisfi i requisiti PCI DSS. I loro terminali di pagamento sono sulla VLAN 10 e la WiFi per gli ospiti è sulla VLAN 20. Il filtro DNS è applicato solo alla VLAN 20. Quali prove aggiuntive dovrebbero documentare per il loro valutatore PCI DSS?

Suggerimento: Il requisito PCI DSS 1.3 copre i controlli di accesso alla rete tra reti affidabili e non affidabili.

Visualizza risposta modello

Il direttore IT dovrebbe documentare: 1. Regole del firewall che confermano che la VLAN 10 (ambiente dei dati dei titolari di carta) non è accessibile dalla VLAN 20 (rete ospiti), soddisfacendo il requisito PCI DSS 1.3. 2. Configurazione DHCP che mostra che i dispositivi della VLAN 10 utilizzano resolver DNS interni, non il motore di filtraggio cloud. 3. Regole del firewall che bloccano la porta 53 in uscita dalla VLAN 20 verso IP non approvati, dimostrando l'applicazione del filtraggio DNS. 4. Documentazione della policy del filtro DNS che mostra le categorie attive di blocco di malware e botnet sulla VLAN 20. 5. Log del filtro DNS che mostrano gli eventi di query bloccati, dimostrando che il controllo è attivo e monitorato.

Continua a leggere questa serie

Come segregare in sicurezza le reti WiFi del personale e degli ospiti

Questa guida tecnica autorevole fornisce ai leader IT strategie pratiche per segregare in sicurezza le reti WiFi del personale, degli ospiti e dei dispositivi IoT utilizzando VLAN e 802.1X. Descrive dettagliatamente come proteggere l'infrastruttura aziendale, mantenere la conformità PCI DSS e sfruttare i captive portal per raccogliere dati di prima parte.

Comprensione di Cisco SUDI: Identità ancorata all'hardware nel controllo degli accessi di rete sicuro

Questa guida spiega come Cisco SUDI fornisca un'identità crittograficamente sicura e ancorata all'hardware per l'infrastruttura di rete aziendale. Scopri come sostituire gli indirizzi MAC facilmente falsificabili con certificati 802.1AR immutabili per proteggere il controllo degli accessi alla rete della tua struttura.

Come configurare SCEP per la registrazione automatica dei certificati WiFi aziendali

Questa guida spiega come configurare SCEP (Simple Certificate Enrollment Protocol) per la registrazione automatica dei certificati WiFi aziendali, coprendo l'intera architettura, da PKI e NDES fino alla distribuzione dei profili MDM e alla convalida RADIUS. Si rivolge a responsabili IT, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi, centri congressi e organizzazioni del settore pubblico che hanno l'esigenza di superare le chiavi precondivise e implementare un'autenticazione 802.1X EAP-TLS scalabile e basata sull'identità. La piattaforma cloud overlay di Purple, indipendente dall'hardware, si integra direttamente con questa architettura, fornendo il livello WiFi per ospiti e BYOD che si affianca alla rete del personale autenticata tramite certificato.