Miglior filtraggio DNS: una guida completa per le aziende
Questa guida di riferimento tecnica spiega come il filtraggio DNS aziendale protegga le reti pubbliche bloccando i domini dannosi a livello di risoluzione - prima ancora che venga stabilita una connessione. Offre ai direttori IT, agli architetti di rete e ai team operativi delle strutture l'architettura di implementazione, la configurazione del firewall e il contesto di conformità necessari per proteggere il WiFi per gli ospiti nei settori dell'ospitalità, del retail e del settore pubblico. Purple Shield blocca malware, botnet e contenuti inappropriati a livello DNS in oltre 80.000 sedi attive.
Video overview
Ascolta questa guida
Visualizza trascrizione del podcast
Parte della nostra serie principale: Guida alla sicurezza del WiFi aziendale →
Enterprise DNS Filtering Sizing & Security Policy Advisor
Model real-world DNS query throughput, QPS spikes, malicious domain blocking rates, and CIPA compliance posture for guest and enterprise WiFi fleets with Purple Shield.
DNS Query Sizing & Edge Threat Mitigation Breakdown
Monthly WAN Bandwidth Savings
By sinkholing malware, malicious advertisements, and unauthorized streaming domains at the UDP resolution phase, the network prevents full TCP handshakes and payload downloads.
IT Administration Hours Saved
Managed threat intelligence feeds, no manual blocklist maintenance, and audit exports take repetitive resolver and firewall work off the service desk. The figure tracks the volume actually blocked, and is capped at 120 hours a month.
| Metric / Parameter | Current Model | Industry Benchmark | Status |
|---|---|---|---|
| Active Endpoint Concurrency | 3,825 devices | Peak concurrency 75%–90% | Sized |
| Resolver Response Latency | 12 ms | Target < 20 ms | Optimal |
| Total Monthly Queries Processed | 252,450,000 queries | High-density venue scale | Protected |
| DoH / DoT Bypass Containment | Active (Port 853 + ACL) | RFC 8484 / RFC 7858 block | Enforced |
Executive summary
Per i leader IT che gestiscono reti pubbliche su larga scala, proteggere l'ambiente di navigazione è un imperativo operativo, non un optional. Il guest WiFi nel settore alberghiero, 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 alla periferia 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. Ciò lo rende l'unico metodo pratico di controllo dei contenuti per ambienti ad alta densità che servono migliaia di dispositivi non gestiti simultanei.
Questa guida illustra l'architettura tecnica necessaria per implementare 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'evasione 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 con policy applicate ai dispositivi sulla VLAN guest.
Quando un dispositivo interroga questo resolver sicuro, il motore di filtraggio valuta il dominio confrontandolo simultaneamente con più fonti di dati: feed di intelligence sulle minacce in tempo reale, elenchi di blocchi di categorie (contenuti per adulti, gioco d'azzardo, pirateria) e registri dei domini di comando e controllo delle botnet. La decisione avviene in 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 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 una grande area retail - 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, il trasferimento dei dati avviene 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 dell'attivazione della connessione, è indipendente dal protocollo. Blocca le connessioni sia che l'applicazione utilizzi HTTP, HTTPS, FTP o una porta personalizzata. Questo è 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 nell'arco di 24 ore e abbandonano il dominio prima che raggiunga qualsiasi blacklist standard.
Purple Shield utilizza il rilevamento delle minacce guidato dall'intelligenza artificiale per analizzare in tempo reale i pattern di registrazione dei domini, la reputazione degli IP e le firme crittografiche. 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, questa finestra di rilevamento è 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.
Fase 1: Segmentazione VLAN
Segmenta la tua rete in modo che il traffico degli ospiti sia isolato dai sistemi operativi. Posiziona i dispositivi 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. In questo modo si garantisce che la policy di filtraggio DNS si applichi esclusivamente al traffico ospite non attendibile e non interrompa i sistemi operativi.
Questa segmentazione soddisfa anche il requisito PCI-DSS 1.3, che impone l'isolamento degli ambienti di dati dei titolari di carta dalle reti non attendibili. Il WiFi ospite non deve mai condividere una VLAN con l'infrastruttura di pagamento.
Fase 2: Configurazione dell'ambito DHCP
Configura l'ambito DHCP per la VLAN guest per assegnare gli indirizzi IP del tuo servizio di cloud DNS filtering come server DNS primario e secondario. Questo assicura che ogni dispositivo che si connette alla rete guest riceva automaticamente il resolver corretto.
Passaggio 3: Applicazione della porta 53 sul firewall
L'assegnazione DHCP da sola non è sufficiente. Un utente può escludere 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 direttamente 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 consigliato a uno obbligatorio.
Passaggio 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 sulla porta 53. Per mantenere la copertura, configura il tuo 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 norma NIST SP 800-81r3 (pubblicata a marzo 2026) affronta specificamente il DoH come considerazione di sicurezza del DNS aziendale.
Passaggio 5: Configurazione del walled garden del Captive Portal
Se utilizzi un Captive Portal per l'autenticazione degli ospiti, devi configurare un Walled Garden prima di applicare qualsiasi policy di blocco. Il Walled Garden è un elenco di domini a cui i dispositivi possono accedere prima di essere autenticati. Deve includere tutti i domini necessari al funzionamento del Captive Portal: il dominio del tuo portale, eventuali identity provider (Microsoft Entra ID, Okta, Google Workspace) e qualsiasi endpoint OAuth per il social login.
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 utenti frustrati. Configura prima il Walled Garden, quindi applica la tua policy di filtraggio dei contenuti solo alle sessioni autenticate.
Per saperne di più sull'architettura SSID e su come devono essere strutturate le reti Guest WiFi, Staff WiFi e IoT, consulta Tre SSID per dominarli tutti: guest, Passpoint e IoT WiFi.
Hai domande sulla tua configurazione specifica?
Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.
Best practice: progettazione delle policy e gestione continua
Blocco basato sulle categorie
Organizza la tua policy di filtraggio DNS intorno a categorie di contenuti piuttosto che a singole blocklist di domini. Le categorie in genere includono: malware e phishing, botnet command-and-control, contenuti per adulti, gioco d'azzardo, streaming illegale e condivisione di file peer-to-peer. Le policy basate sulle categorie sono più facili da gestire e acquisiscono automaticamente i nuovi domini man mano che l'intelligence sulle minacce si aggiorna.
Frequenza di aggiornamento dell'intelligence sulle minacce
Seleziona un fornitore di filtraggio DNS che aggiorni le informazioni sulle minacce in tempo reale o quasi reale. Le liste di blocco 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 intelligenza artificiale che offre un vantaggio di 10 giorni rispetto ai fornitori reattivi.
Implementazione indipendente dall'hardware
Purple Shield funziona 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, pertanto 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 le tendenze: un picco nei tentativi di phishing bloccati da uno specifico access point può indicare un attacco mirato. L'esame 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 tra eventi di sicurezza e prestazioni di rete.
Risoluzione dei problemi e mitigazione dei rischi
Aggiramento del filtro tramite DNS personalizzato
Sintomo: gli utenti segnalano di riuscire ad 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 tramite 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 accesso social non rispondono.
Causa: il filtro DNS blocca i domini dei provider di identità prima dell'autenticazione. Microsoft Entra ID, Google Workspace o il dominio stesso del tuo portale si trovano in un elenco di categorie bloccate.
Soluzione: controlla la configurazione del tuo Walled Garden. Aggiungi tutti i domini di autenticazione richiesti alla allowlist di pre-autenticazione. Testa l'intero flusso di accesso in un ambiente di staging prima di applicare modifiche alle policy.
Aggiramento del 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 il 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 l'implementazione del filtro DNS.
Causa: La policy di filtraggio DNS è stata applicata alla VLAN errata, oppure il DHCP sta assegnando il resolver DNS cloud ai dispositivi operativi.
Soluzione: Verificare il tagging delle VLAN su tutte le porte dello switch e sugli access point. Confermare che le VLAN dei dispositivi operativi siano configurate per utilizzare solo resolver DNS interni.
ROI e impatto aziendale
Il filtraggio DNS offre vantaggi misurabili su tre fronti.
Recupero della larghezza di banda: Bloccare lo streaming illegale, la condivisione peer-to-peer e il traffico automatizzato delle botnet consente di recuperare una quantità significativa di banda. In un ambiente alberghiero, questo può ridurre l'utilizzo della VLAN dei clienti del 20 - 40%, migliorando le prestazioni per gli utenti autorizzati senza richiedere aggiornamenti del circuito.
Riduzione dei costi di conformità: Dimostrare controlli attivi a livello 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 brand e della responsabilità: L'applicazione di policy di navigazione adatte alle famiglie negli ambienti retail e hospitality impedisce la visualizzazione pubblica di contenuti inappropriati. Nelle strutture destinate ai minori - centri commerciali, hotel per famiglie, stadi - questo rappresenta sia un requisito del brand sia una considerazione legale in molte giurisdizioni.
Per indicazioni specifiche sull'implementazione nei diversi settori, 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 sulle reti pubbliche. Non richiede l'installazione di alcun agente sull'endpoint.
Sinkholing
La 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 del rilevamento avvenuto.
Walled Garden
Un ambiente di rete limitato pre-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 le risorse 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 filtraggio DNS.
Segmentazione VLAN
La suddivisione di una singola rete fisica in più reti logiche isolate utilizzando la codifica 802.1Q.
Fondamentale per isolare il traffico degli ospiti dai sistemi operativi. Il requisito PCI DSS 1.3 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 il pieno accesso 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 basato sul contenuto ma introducendo un sovraccarico di elaborazione significativo.
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.
Feed di threat intelligence
Un database continuamente aggiornato di indirizzi IP, domini e pattern URL dannosi noti, utilizzato per guidare le decisioni di filtraggio DNS in tempo reale.
La qualità e la frequenza di aggiornamento del feed di threat intelligence 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 blocklist standard.
Le moderne campagne di attacco utilizzano domini usa e getta attivi per meno di 24 ore. Il rilevamento delle minacce basato sull'intelligenza artificiale identifica questi domini analizzando i pattern di registrazione invece di attendere le segnalazioni.
Esempi pratici
Una catena alberghiera da 400 camere sta implementando il WiFi per gli ospiti in 12 strutture. Utilizzano Microsoft Entra ID per l'autenticazione tramite Captive Portal e il loro sistema di gestione alberghiera (PMS) risiede sulla stessa infrastruttura fisica di switch. 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 dovrebbe 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 un circolo vizioso in cui gli ospiti non riescono a caricare la pagina di accesso. Fasi di risoluzione: 1. Nella dashboard del filtraggio DNS, creare una policy di pre-autenticazione che consenta esplicitamente tutti i domini di Microsoft Entra ID, inclusi login.microsoftonline.com, login.live.com e tutti i domini specifici del tenant. 2. Verificare che anche il dominio del Captive Portal e tutte le risorse CDN caricate siano inclusi nella whitelist. 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'intera procedura di accesso in ciascuna struttura interessata prima di chiudere l'incidente.
Una grande catena di negozi al dettaglio gestisce 200 punti vendita, ciascuno dotato di una rete WiFi per gli ospiti. Il loro team di sicurezza IT implementa un filtro DNS in cloud e aggiorna l'ambito DHCP su tutte le VLAN degli ospiti. Due settimane dopo, un penetration test rivela che il 18% dei dispositivi degli ospiti riesce a risolvere domini dannosi noti. I log del filtro DNS non mostrano query bloccate provenienti da questi dispositivi. Qual è il difetto architetturale e qual è la soluzione?
Il difetto risiede nel fatto che la porta 53 non è bloccata sul firewall. Il 18% dei dispositivi aggira i server DNS assegnati tramite DHCP utilizzando resolver codificati a livello hardware (8.8.8.8, 1.1.1.1) o utilizzando il protocollo 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 firewall sul gateway della VLAN degli ospiti che elimini tutto il traffico UDP e TCP in uscita sulla porta 53 diretto a qualsiasi IP diverso da quelli approvati del motore di filtraggio. 2. Identificare e bloccare sul firewall gli intervalli IP dei principali provider DoH (Cloudflare, Google, NextDNS) per impedire l'aggiramento crittografato. 3. Eseguire nuovamente il penetration test per confermare la copertura. 4. Monitorare i log di blocco del firewall per il traffico sulla porta 53 per verificare che la regola sia attiva.
Domande di esercitazione
Q1. Una catena di negozi lancia un filtro DNS cloud in 150 punti vendita. Aggiornano 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 riescono ancora ad accedere alle categorie di contenuti bloccati. 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 dal DHCP utilizzando risolutori 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 scarti tutto il traffico UDP e TCP in uscita sulla porta 53 dalla VLAN ospiti verso qualsiasi IP diverso da quelli approvati del motore di filtraggio. Inoltre, bloccare gli intervalli IP noti dei provider DoH per impedire l'aggiramento del DNS crittografato.
Q2. Un centro congressi sta distribuendo il filtraggio DNS per la prima volta. Utilizzano Google Workspace per l'autenticazione dei partecipanti sul loro 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 le eventuali risorse CDN devono essere inseriti in whitelist. Applicare 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 picco. Quale approccio è più appropriato e perché?
Suggerimento: Considerare il sovraccarico di elaborazione di ciascun metodo su una scala di 60.000 utenti simultanei.
Visualizza risposta modello
Il filtraggio DNS è la scelta appropriata. Opera 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 distribuzione del filtraggio DNS soddisfi i requisiti PCI DSS. I loro terminali di pagamento sono sulla VLAN 10 e il 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 attendibili e non attendibili.
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 sulla 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 di blocco attive per 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.
Domande frequenti
How does enterprise DNS filtering protect guest and corporate WiFi networks?
Enterprise DNS filtering secures networks at the resolution layer before an HTTP or TCP connection is established. When a user or background application requests an IP address for a domain, the recursive resolver evaluates the query against real-time threat intelligence. Malicious domains associated with malware, ransomware command-and-control (C2), or phishing are instantly sinkholed, protecting unmanaged guest devices and corporate assets with negligible latency.
How does DNS filtering prevent DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) security bypasses?
Modern mobile devices and browsers often default to encrypted DoH or DoT, which bypasses local network DNS forwarders. Enterprise venues counter this by blocking outbound TCP port 853 (DoT) and enforcing Layer 7 firewall rules or Access Control Lists (ACLs) that drop traffic to known public DoH resolver IPs (such as Cloudflare 1.1.1.1 and Google 8.8.8.8), forcing client devices to use the venue protective DNS resolver.
What is the difference between recursive DNS resolution and Anycast protective DNS filtering?
Standard recursive DNS queries travel through multi-tier root and authoritative nameservers without security evaluation, exposing networks to poisoned cache entries and malicious destinations. Anycast protective DNS routes queries to globally distributed Anycast data center nodes that cross-reference domains against real-time threat feeds, returning cached results in under 15ms while neutralizing cyber threats and policy violations at the edge.
How does DNS filtering enforce CIPA (Children's Internet Protection Act) compliance across venues?
Under CIPA and educational safe-browsing mandates, venues providing public access must block visual depictions of obscenity, child sexual abuse material (CSAM), and harmful content. Protective DNS enforces these requirements network-wide without installing device certificates or endpoint software, categorizing billions of domains and enforcing Google and YouTube SafeSearch restrictions across all connected devices.
Can DNS filtering reduce venue internet bandwidth consumption and firewall compute load?
Yes. By blocking malicious payload downloads, high-bandwidth streaming domains, and intrusive ad-tracking networks at the initial DNS lookup phase, the network prevents large TCP payload transfers before they start. Venues deploying protective DNS typically observe a 6% to 12% reduction in overall WAN traffic and substantially reduced deep-packet inspection (DPI) processing load on edge firewalls.
How does Purple Shield integrate with existing enterprise routers, access points, and captive portals?
Purple Shield operates independently of access point hardware, integrating directly via DHCP nameserver assignment or DNS forwarders on Cisco Meraki, HPE Aruba, Fortinet, Ruckus, and Ubiquiti systems. For guest WiFi, it pairs with Purple Captive Portals to enforce strict pre-authentication walled gardens, allowing authentication traffic while shielding the venue from unauthorized outbound browsing.
Continua a leggere questa serie
Conformità CIPA: checklist di conformità per i gestori di sedi
Sarai in grado di decidere se la conformità CIPA vincola il tuo WiFi, quindi segmentare le reti, instradare il DNS tramite Purple Shield e chiudere i percorsi di bypass. Saprai anche quali prove conservare per la certificazione del Form 486 o del Form 479. La checklist assegna ogni requisito a un responsabile, in modo che la certificazione del prossimo anno di finanziamento non presenti lacune.
Errori di connessione in modalità di transizione WPA3: una checklist di implementazione per Cisco Meraki, HPE Aruba e Ruckus
Usa questa checklist per diagnosticare il motivo per cui i dispositivi non riescono a connettersi a un SSID in modalità di transizione WPA3 SAE e risolvere il problema su Cisco Meraki, HPE Aruba o Ruckus. Imparerai a far corrispondere i codici di stato 802.11 alle relative cause, a isolare i problemi di PMF, 802.11r e 6GHz, e a decidere quando passare a un SSID solo WPA3.
La guida Enterprise a SCEP: implementare il Simple Certificate Enrollment Protocol per la sicurezza automatizzata del WiFi aziendale
Questa guida di riferimento tecnico fornisce un modello architetturale definitivo e una strategia di implementazione passo dopo passo per la distribuzione dei certificati WiFi aziendali tramite SCEP. Copre le differenze critiche tra SCEP e PKCS, l'esatta sequenza di implementazione necessaria per il successo e le strategie di mitigazione del rischio reali per i leader IT.
Hai domande sulla tua configurazione specifica?
Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.