Filtro DNS per WiFi ospiti: Blocco di Malware e Contenuti Inappropriati
Questa guida fornisce ai responsabili IT, ai network architect e ai direttori operativi delle strutture un riferimento tecnico definitivo per l'implementazione del filtro DNS sulle reti WiFi ospiti. Copre l'architettura del blocco delle minacce a livello DNS, un confronto tra i principali servizi DNS cloud, una guida all'implementazione dettagliata e casi di studio reali in contesti alberghieri e retail. Il filtro DNS rappresenta la prima linea di difesa più conveniente contro malware, phishing e contenuti inappropriati sulle reti aperte al pubblico, e questa guida prepara i team a implementarlo con sicurezza e in conformità con i requisiti PCI-DSS, GDPR e HIPAA.
Video overview
Ascolta questa guida
Visualizza trascrizione del podcast
Parte della nostra serie principale: Guida alla Sicurezza del WiFi Aziendale →
Sintesi Esecutiva
Il filtraggio DNS per i WiFi per ospiti non è più un miglioramento opzionale della sicurezza - è un controllo di base per qualsiasi struttura che gestisca una rete aperta al pubblico. Quando un hotel, uno stadio, una catena di negozi o un centro congressi offre un servizio di WiFi per ospiti, si assume la responsabilità del traffico che attraversa la sua infrastruttura. Senza un filtraggio a livello DNS, tale rete rappresenta un canale aperto per callback di malware, sessioni di phishing e contenuti inappropriati, esponendo l'organizzazione a responsabilità normative, rischi di reputazione e potenziali compromissioni della rete.
Questa guida spiega come funziona il filtraggio DNS a livello tecnico, confronta i principali servizi DNS cloud disponibili per i gestori di strutture e fornisce una roadmap di implementazione strutturata. Affronta il requisito fondamentale di applicazione delle regole - l'intercettazione delle query DNS hardcoded - che la maggior parte delle implementazioni trascura, e copre la gestione dei falsi positivi, l'allineamento della conformità e la sfida emergente dei protocolli DNS crittografati. I clienti Purple possono integrare il filtraggio DNS direttamente sulla loro infrastruttura Guest WiFi, ottenendo sia la sicurezza sia la visibilità per correlare gli eventi di minaccia con i dati di WiFi Analytics.
Approfondimento Tecnico
Come Funziona il Filtraggio DNS
Il Domain Name System (DNS) è lo strato di risoluzione fondamentale di internet. Ogni volta che un dispositivo tenta di connettersi a una risorsa web, invia prima una query DNS per risolvere il nome di dominio in un indirizzo IP. Il filtraggio DNS intercetta questo processo di risoluzione e valuta il dominio richiesto confrontandolo con un database di threat intelligence prima di restituire una risposta. Se il dominio è classificato come dannoso - ospita malware, opera come sito di phishing o funge da endpoint di comando e controllo (C2) per una botnet - il resolver restituisce un indirizzo non instradabile o reindirizza il client a una pagina di blocco. La connessione TCP/IP verso l'host dannoso non viene mai stabilita.
Questa architettura offre un vantaggio di efficienza fondamentale rispetto ai firewall con packet inspection. Un firewall deve ispezionare i dati dopo che la connessione è stata avviata; il filtraggio DNS impedisce del tutto l'avvio della connessione. Per gli ambienti WiFi per ospiti in cui centinaia di dispositivi non attendibili possono essere attivi simultaneamente, questa intercettazione a monte riduce drasticamente il volume di traffico dannoso che raggiunge il perimetro della rete.
Cosa Può e Non Può Bloccare il Filtraggio DNS
Comprendere la portata del filtraggio DNS è essenziale per definire aspettative precise con le parti interessate.
| Categoria di Minaccia | Efficacia del Filtraggio DNS | Note |
|---|---|---|
| Domini di distribuzione malware | Alta | Blocca il download di payload dannosi |
| Siti di phishing | Alta | Blocca le pagine di raccolta credenziali |
| Comunicazioni C2 di botnet | Alta | Interrompe il malware già presente sul dispositivo |
| Server di staging per ransomware | Alta | Impedisce il recupero del payload e lo scambio di chiavi |
| Contenuti per adulti / inappropriati | Alta | Filtraggio basato su categorie |
| Pool di cryptomining | Alta | Blocca le connessioni ai pool basate su dominio |
| Minacce basate su IP (senza dominio) | Nessuna | Richiede un firewall o un IPS |
| Payload crittografati in HTTPS | Nessuna | Richiede l'ispezione TLS |
| Traffico incanalato in VPN | Nessuna | Richiede il blocco delle VPN sul firewall |
| Movimento laterale (LAN) | Nessuna | Richiede la segmentazione della rete |
Il filtraggio DNS non è una soluzione di sicurezza completa. È uno dei livelli di un'architettura di difesa in profondità. Per una sicurezza completa del WiFi per ospiti, dovrebbe essere affiancato alla segmentazione VLAN, all'autenticazione tramite Captive Portal, ai controlli di timeout della sessione (consultare la guida Guest WiFi Session Timeouts: Balancing UX and Security) e, ove giustificato, all'ispezione TLS.
Filtraggio DNS Cloud: Architettura e Confronto dei Servizi
I servizi di filtraggio DNS cloud operano su reti globali anycast, il che significa che le query DNS vengono instradate al data centre più vicino, riducendo al minimo la latenza. I quattro servizi principali di interesse per i gestori di sedi fisiche sono Cloudflare Gateway, Cisco Umbrella, Quad9 e NextDNS.
Cloudflare Gateway (parte della piattaforma Cloudflare Zero Trust) offre una latenza di risoluzione inferiore a 20 ms a livello globale, filtraggio granulare per categorie, applicazione delle policy per singola sede e un accordo sul trattamento dei dati conforme al GDPR. Il suo piano gratuito supporta il blocco delle minacce di base; i piani a pagamento aggiungono filtri di categoria avanzati, logging e accesso alle API per l'automazione delle policy.
Cisco Umbrella è lo standard aziendale per le organizzazioni che dispongono di un'infrastruttura Cisco esistente. Fornisce il feed di threat intelligence più completo - basato su Cisco Talos, una delle più grandi organizzazioni commerciali di ricerca sulle minacce - e supporta l'applicazione delle policy per SSID, il che è fondamentale per le strutture che gestiscono più SSID (personale, ospiti, IoT). Umbrella si integra con il portafoglio di sicurezza più ampio di Cisco, inclusi gli access point Meraki, semplificando l'implementazione per le reti basate su Meraki.
Quad9 (gestito dalla Fondazione Quad9, un'organizzazione svizzera senza scopo di lucro) si concentra esclusivamente sul filtraggio di sicurezza anziché sulla categorizzazione dei contenuti. Blocca i domini dannosi utilizzando la threat intelligence di oltre 20 partner, non registra informazioni di identificazione personale ed è gratuito. È un'ottima scelta per le organizzazioni con rigidi requisiti di sovranità dei dati o budget limitati, sebbene manchi delle funzionalità di filtraggio delle categorie e di reportistica delle alternative commerciali.
NextDNS offre un servizio DNS cloud altamente configurabile con un'ampia libreria di filtraggio per categorie, profili per singolo dispositivo e logging dettagliato delle query. Il suo modello di prezzo - basato sul volume mensile di query - lo rende conveniente per implementazioni di piccole e medie dimensioni. Supporta nativamente DNS-over-HTTPS e DNS-over-TLS.
Filtraggio DNS Self-Hosted: Quando Ha Senso
Le soluzioni self-hosted - più comunemente Pi-hole con blocklist commerciali, o un'implementazione BIND con Response Policy Zones (RPZ) - offrono una completa sovranità dei dati e il controllo delle policy. Sono adatte per organizzazioni con severi requisiti normativi sui dati delle query DNS, o per quelle con team infrastrutturali esistenti in grado di gestire il carico operativo. Il compromesso è significativo: le soluzioni self-hosted richiedono un'implementazione ad alta affidabilità (configurazioni active-passive o active-active - vedi RADIUS server high availability: Active-Active vs Active-Passive per una discussione parallela sui pattern HA), aggiornamenti manuali dei feed delle minacce e monitoraggio interno. Per la maggior parte dei gestori di sedi, il costo operativo supera i benefici.
DNS Crittografato: Considerazioni su DoH e DoT
DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT) crittografano le query DNS, proteggendo la privacy dell'utente su reti non attendibili. Tuttavia, creano anche un vettore di bypass per il filtraggio DNS. Un dispositivo configurato per utilizzare un resolver DoH pubblico (come https://cloudflare-dns.com/dns-query) crittograferà le sue query DNS all'interno del traffico HTTPS sulla porta 443, rendendo inefficace l'intercettazione tradizionale sulla porta 53.
La strategia di mitigazione prevede due componenti. In primo luogo, configurare il firewall o il controller wireless per bloccare le connessioni in uscita verso gli endpoint dei resolver DoH pubblici noti. Cloudflare, Google e altri provider pubblicano i propri intervalli IP degli endpoint DoH. In secondo luogo, assicurarsi che il servizio di filtraggio DNS scelto supporti nativamente DoH e DoT, in modo che i dispositivi configurati per utilizzare il DNS crittografato possano essere indirizzati al vostro resolver sicuro anziché a uno pubblico. Cisco Umbrella e Cloudflare Gateway supportano entrambi questa configurazione.
-
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.
Guida all'Implementazione
Passaggio 1: Selezionare il Servizio di Filtraggio DNS
I criteri di selezione devono essere guidati da tre fattori: scala, granularità delle policy e requisiti di conformità. Il seguente framework si applica alla maggior parte delle implementazioni nei locali.
| Scala di Distribuzione | Servizio Consigliato | Motivazione |
|---|---|---|
| < 100 utenti simultanei | Cloudflare Gateway (gratuito) o Quad9 | Costo zero, blocco delle minacce adeguato |
| 100–500 utenti simultanei | NextDNS (a pagamento) o Cloudflare Gateway | Filtraggio per categorie, dashboard di reportistica |
| 500+ utenti simultanei, sito singolo | Cisco Umbrella Essentials | Policy per SSID, SLA di livello enterprise |
| Enterprise multi-sito | Cisco Umbrella Advantage o Cloudflare Gateway Enterprise | Gestione centralizzata delle policy, automazione tramite API |
| Sanità / ambienti regolamentati | Cisco Umbrella o RPZ in self-hosting | Sovranità dei dati, registrazione dei log di audit HIPAA |
Passaggio 2: Configurare il DHCP sull'SSID Ospiti
Navigare nell'interfaccia di gestione del controller wireless o dell'access point e configurare lo scope DHCP per l'SSID ospiti in modo da assegnare gli indirizzi IP del resolver del servizio di filtraggio DNS. Non utilizzare i server DNS predefiniti dell'ISP a monte. Per Cloudflare Gateway, utilizzare gli IP del resolver forniti nella dashboard Zero Trust. Per Cisco Umbrella, utilizzare gli IP del resolver Umbrella (208.67.222.222 e 208.67.220.220 per le installazioni legacy; gli IP dell'appliance virtuale per le installazioni moderne).
Per le reti gestite da Purple, questa configurazione viene applicata a livello di controller, garantendo un'applicazione coerente delle policy su tutti gli access point sull'SSID ospiti.
Passaggio 3: Imporre l'Intercettazione DNS al Bordo della Rete
Questo è il passaggio più frequentemente trascurato. Configurare il firewall o il controller wireless per intercettare tutto il traffico in uscita sulla porta UDP 53 e sulla porta TCP 53 e reindirizzarlo al resolver di filtraggio DNS. Ciò impedisce ai dispositivi con impostazioni DNS codificate nel software (hardcoded) di aggirare il filtro. Su Cisco Meraki, questo viene implementato tramite una regola di traffic shaping. Su Fortinet FortiGate, utilizzare una policy di proxy DNS. Su pfSense o OPNsense, configurare una regola di reindirizzamento NAT. Inoltre, blocca le connessioni in uscita verso endpoint noti di resolver DoH pubblici sulla porta 443 per impedire il bypass del DNS crittografato. Mantieni un elenco regolarmente aggiornato di intervalli IP di resolver DoH.
Passaggio 4: Definisci la tua policy di filtraggio
Inizia con la baseline di sicurezza - categorie che dovrebbero essere bloccate universalmente indipendentemente dal tipo di sede:
- Distribuzione di malware
- Phishing e furto di credenziali
- Botnet command-and-control
- Staging di ransomware
- Cryptomining
Quindi applica le categorie di contenuto specifiche per la sede in base alla tua policy di utilizzo accettabile:
| Tipo di Sede | Categorie Aggiuntive Raccomandate da Bloccare |
|---|---|
| Vendita al dettaglio per famiglie / centro commerciale | Contenuti per adulti, gioco d'azzardo, contenuti estremisti |
| Hotel (rete ospiti) | Materiale pedopornografico (obbligatorio), contenuti estremisti |
| Stadio / luogo di eventi | Contenuti per adulti, contenuti estremisti, streaming illegale |
| Centro congressi | Condivisione di file peer-to-peer, proxy di anonimizzazione |
| Struttura sanitaria | Contenuti per adulti, gioco d'azzardo, social media (opzionale) |
| Settore pubblico / biblioteca | Contenuti per adulti, contenuti estremisti, gioco d'azzardo |
Passaggio 5: Test e convalida
Prima di andare online, convalida la configurazione utilizzando un dispositivo di test sull'SSID ospiti. Tenta di accedere a un dominio di test malware noto (la maggior parte dei servizi di filtraggio DNS fornisce domini di test a questo scopo). Conferma che venga visualizzata la pagina di blocco. Tenta di utilizzare un server DNS codificato (ad es. nslookup google.com 8.8.8.8) e conferma che la query venga intercettata e reindirizzata. Testa il bypass DoH configurando un browser per utilizzare un resolver DoH pubblico e conferma che la connessione sia bloccata.
Passaggio 6: Monitoraggio, ottimizzazione e reportistica
Esamina la dashboard di filtraggio DNS quotidianamente per le prime quattro settimane. Le metriche chiave da monitorare includono le query totali, le query bloccate per categoria, i domini più bloccati e le segnalazioni di falsi positivi da parte degli utenti. Stabilisci un processo di revisione della whitelist - qualsiasi dominio aggiunto alla whitelist deve essere documentato con una giustificazione aziendale e rivisto trimestralmente. Pianifica report mensili per il CISO o il direttore IT che mostrino i volumi delle minacce e le suddivisioni per categoria.
-
Best Practice
Segmenta le policy DNS per ospiti e aziendali. Non applicare mai la stessa policy di filtraggio DNS a SSID per ospiti e personale. Le reti ospiti richiedono un filtraggio dei contenuti più rigoroso; le reti del personale potrebbero richiedere l'accesso a categorie che sarebbero inappropriate per gli utenti pubblici. Cisco Umbrella e Cloudflare Gateway supportano entrambi policy per sede o per rete.
Allinea la tua policy di utilizzo accettabile con la configurazione del filtraggio DNS. La policy di filtraggio visualizzata nei termini di servizio del tuo Captive Portal deve riflettere accuratamente ciò che viene bloccato. Il disallineamento crea rischi legali. Collabora con il tuo team legale per garantire che l'AUP faccia esplicito riferimento al filtraggio dei contenuti a livello DNS. Il Captive Portal di Guest WiFi di Purple supporta un testo AUP personalizzabile a questo scopo.
Implementa resolver DNS ridondanti. Configura due indirizzi IP di risoluzione nel tuo ambito DHCP - uno primario e uno secondario. I servizi Cloud DNS forniscono endpoint di risoluzione multipli per garantire la ridondanza. Un singolo punto di errore nella risoluzione DNS renderà completamente inutilizzabile l'intera rete WiFi ospiti.
Registra le query DNS in conformità con la tua policy di conservazione dei dati. I log delle query DNS sono preziosi per le indagini di sicurezza, ma possono costituire dati personali ai sensi del GDPR se possono essere collegati a un individuo. Assicurati che l'accordo sul trattamento dei dati del tuo servizio di filtraggio DNS sia compatibile con i tuoi obblighi GDPR e configura i periodi di conservazione dei log di conseguenza.
Rivedi la tua architettura SD-WAN per garantire la coerenza della policy DNS. Per le distribuzioni multi-sito, la policy di filtraggio DNS deve essere applicata in modo coerente in tutti i siti. Le piattaforme SD-WAN possono centralizzare la gestione delle policy DNS - vedi The Core SD WAN Benefits for Modern Businesses per una discussione più ampia sul ruolo di SD-WAN nella gestione delle reti aziendali.
Considera l'interazione con la retail analytics. Negli ambienti Retail, i log del filtraggio DNS possono integrare i dati di WiFi Analytics per identificare pattern di comportamento insoliti dei dispositivi. Un dispositivo che genera un volume insolitamente alto di query DNS bloccate potrebbe indicare un dispositivo compromesso che richiede un'indagine.
Risoluzione dei problemi e mitigazione dei rischi
Modalità di guasto comuni
Bypass del DNS tramite resolver hardcoded. Sintomo: i log del filtraggio DNS mostrano volumi di query bassi rispetto al numero di dispositivi connessi. Causa principale: i dispositivi utilizzano server DNS hardcoded che aggirano i resolver assegnati dal DHCP. Risoluzione: implementa l'intercettazione e il reindirizzamento della porta 53 sul firewall.
Falsi positivi che bloccano servizi legittimi. Sintomo: reclami degli utenti relativi all'inaccessibilità di siti web specifici. Causa principale: il servizio di filtraggio DNS ha classificato erroneamente un dominio legittimo. Risoluzione: verifica la classificazione del dominio nello strumento di ricerca del servizio, invia una richiesta di riclassificazione e aggiungi il dominio alla whitelist in attesa di correzione.
Bypass di DoH. Sintomo: alcuni dispositivi sembrano aggirare il filtraggio nonostante l'intercettazione della porta 53. Causa principale: il dispositivo utilizza DNS-over-HTTPS verso un resolver pubblico. Risoluzione: blocca sul firewall le connessioni in uscita verso gli intervalli IP dei resolver DoH noti.
Errori di convalida DNSSEC. Sintomo: alcuni domini restituiscono risposte SERVFAIL. Causa principale: il servizio di filtraggio DNS sta eseguendo la convalida DNSSEC e i record DNSSEC del dominio sono configurati in modo errato. Risoluzione: verifica la configurazione DNSSEC del dominio utilizzando un analizzatore DNSSEC online; se il dominio è legittimo, aggiungilo alla whitelist.L'elevata latenza DNS causa il caricamento lento delle pagine. Sintomo: gli utenti segnalano una navigazione lenta nonostante una larghezza di banda adeguata. Causa principale: il risolutore di filtraggio DNS è geograficamente distante o sta subendo un sovraccarico. Risoluzione: verificare che il routing anycast funzioni correttamente; valutare il passaggio a un risolutore con un data center più vicino alla propria sede.
Framework di attenuazione dei rischi
Il seguente registro dei rischi riassume i rischi principali associati all'implementazione del filtraggio DNS e le relative attenuazioni.
| Rischio | Probabilità | Impatto | Attenuazione |
|---|---|---|---|
| Aggiramento del DNS tramite risolutori hardcoded | Alta | Alto | Intercettazione e reindirizzamento della porta 53 |
| Falsi positivi che bloccano servizi critici per il business | Media | Alto | Processo di whitelist, test pre-implementazione |
| Guasto di un singolo risolutore che causa un'interruzione di rete | Media | Alto | Configurazione di risolutori ridondanti |
| Aggiramento DoH che elude il filtro | Media | Medio | Blocco degli endpoint DoH noti sul firewall |
| Non conformità al GDPR a causa di una registrazione DNS eccessiva | Bassa | Alto | Criteri di conservazione dei dati, revisione del DPA |
| Obsolescenza del feed di threat intelligence (self-hosted) | Bassa | Alto | Aggiornamenti automatici dei feed, preferenza per i servizi cloud |
ROI e impatto sul business
Quantificare il valore del filtraggio DNS
Il ritorno sull'investimento per il filtraggio DNS su reti WiFi per gli ospiti è guidato da tre fattori: prevenzione dei costi dei sinistri, riduzione dei costi di conformità ed efficienza operativa.
La prevenzione dei costi dei sinistri è il fattore più significativo. Un singolo incidente informatico causato da malware originato da una rete ospiti - con conseguente avviso di abuso dell'ISP, indagine normativa o danno reputazionale - può costare decine di migliaia di sterline in riparazioni, spese legali e perdita di opportunità commerciali. I servizi di filtraggio DNS cloud costano da zero a poche centinaia di sterline al mese per la maggior parte delle installazioni nelle sedi. Il rapporto costi-benefici è estremamente vantaggioso.
La riduzione dei costi di conformità è sempre più rilevante con il progressivo inasprimento dei quadri normativi. Le normative PCI-DSS v4.0, GDPR e l'Online Safety Act del Regno Unito impongono obblighi in materia di monitoraggio della rete e controllo dei contenuti. Il filtraggio DNS fornisce prove documentate di controlli di sicurezza proattivi, riducendo la portata e i costi degli audit di conformità.
L'efficienza operativa è un vantaggio meno evidente ma reale. Il filtraggio DNS riduce il volume di traffico dannoso che raggiunge il firewall e l'infrastruttura di monitoraggio della sicurezza, riducendo l'affaticamento da avvisi e l'onere operativo derivante dall'analisi dei falsi allarmi.
Risultati previsti
Sulla base delle implementazioni nei settori dell'Hospitality, del Retail, dell'Healthcare e dei Transport, le organizzazioni che implementano il filtraggio DNS sulle reti WiFi ospiti possono aspettarsi i seguenti risultati entro 90 giorni:
| Metrica | Risultato tipico |
|---|---|
| Richieste di domini dannosi bloccate al giorno (per 100 dispositivi) | 50 - 200 |
| Riduzione delle segnalazioni di abuso da parte dell'ISP | 80 - 100% |
| Riduzione degli incidenti di sicurezza sulla rete ospiti | 60 - 80% |
| Tempo per rilevare un dispositivo compromesso (tramite anomalia DNS) | < 24 ore |
| Riduzione dei risultati dei controlli di conformità | 20–40% |
Per le strutture che già utilizzano la piattaforma Guest WiFi di Purple, l'integrazione del filtraggio DNS non richiede hardware aggiuntivo e richiede un tempo minimo di configurazione - in genere da due a quattro ore per una distribuzione in un singolo sito, fino a uno o due giorni per un rollout aziendale multi-sito con personalizzazione dei criteri per ciascun sito.
Definizioni chiave
Filtraggio DNS
Un controllo di sicurezza che intercetta le query DNS e blocca la risoluzione dei domini classificati come dannosi o che violano le policy, impedendo al dispositivo client di stabilire una connessione con l'host di destinazione.
I team IT si confrontano con questo aspetto quando valutano i controlli di sicurezza del WiFi per gli ospiti. Rappresenta il primo livello di difesa più conveniente contro malware, phishing e contenuti inappropriati sulle reti pubbliche.
Rete Anycast
Una metodologia di instradamento in cui più server condividono lo stesso indirizzo IP e le query dei client vengono instradate automaticamente al server più vicino in base alla topologia della rete. Utilizzata dai provider DNS cloud per ridurre al minimo la latenza delle query a livello globale.
Rilevante quando si valutano i servizi di filtraggio DNS cloud. L'Anycast garantisce che le query DNS provenienti da una sede a Manchester vengano risolte da un data center del Regno Unito, anziché da uno statunitense, mantenendo la latenza al di sotto dei 20 ms.
Response Policy Zone (RPZ)
Un'estensione DNS che consente a un risolutore di ignorare le risposte DNS standard in base a una zona di criteri definita localmente. Utilizzata nelle implementazioni di filtraggio DNS self-hosted per bloccare o reindirizzare le query per domini specifici.
Si riscontra in distribuzioni di filtraggio DNS self-hosted che utilizzano BIND o Unbound. RPZ fornisce un controllo granulare sulle risposte DNS senza richiedere un servizio cloud commerciale.
DNS-over-HTTPS (DoH)
Un protocollo che crittografa le query DNS all'interno del traffico HTTPS sulla porta 443, proteggendo la privacy delle query ma creando anche un potenziale vettore di bypass per i sistemi di filtraggio DNS che si affidano all'intercettazione sulla porta 53.
Sempre più rilevante in quanto i browser e i sistemi operativi adottano DoH per impostazione predefinita. I team IT devono tenere conto del bypass di DoH quando distribuiscono il filtraggio DNS sulle reti guest.
DNS-over-TLS (DoT)
Un protocollo che crittografa le query DNS utilizzando TLS sulla porta 853, offrendo vantaggi in termini di privacy simili a DoH ma utilizzando una porta dedicata più facile da rilevare e gestire all'edge della rete.
Meno comunemente usato rispetto a DoH nei dispositivi consumer, ma rilevante negli ambienti aziendali. Il traffico DoT sulla porta 853 può essere bloccato o reindirizzato sul firewall in modo più semplice rispetto a DoH.
Threat Intelligence Feed
Un database continuamente aggiornato di domini, indirizzi IP e URL dannosi noti, gestito da ricercatori di sicurezza e utilizzato dai servizi di filtraggio DNS per classificare e bloccare le minacce in tempo reale.
La qualità e la freschezza del threat intelligence feed rappresentano il principale elemento di differenziazione tra i servizi di filtraggio DNS. I provider cloud come Cisco Talos elaborano miliardi di query ogni giorno per mantenere l'accuratezza del feed.
Botnet Command-and-Control (C2)
Un server o un dominio utilizzato dagli operatori di malware per impartire istruzioni ai dispositivi compromessi (bot) e ricevere dati esfiltrati. Il filtraggio DNS blocca la risoluzione dei domini C2, interrompendo il malware già installato su un dispositivo ospite.
Fondamentale per la sicurezza del WiFi guest perché un dispositivo ospite potrebbe essere già infetto prima di connettersi alla rete. Il filtraggio DNS impedisce al malware di comunicare con i suoi operatori, limitando i danni.
DNSSEC (DNS Security Extensions)
Una suite di specifiche IETF che aggiunge firme crittografiche alle risposte DNS, consentendo ai risolutori di verificare che le risposte non siano state manomesse durante il transito. Distinta dal filtraggio DNS ma complementare.
I team IT potrebbero riscontrare errori di convalida DNSSEC durante l'implementazione del filtraggio DNS se il servizio di filtraggio esegue la convalida DNSSEC e i record di un dominio sono configurati in modo errato. Comprendere la distinzione tra DNSSEC e filtraggio DNS previene la confusione diagnostica.
Acceptable Use Policy (AUP)
Un documento di politica formale che definisce gli usi consentiti e vietati di una rete o di una risorsa informatica. Per il WiFi guest, l'AUP viene solitamente presentata sul Captive Portal e deve riflettere accuratamente le categorie di filtraggio DNS attive.
I team legali richiedono che l'AUP faccia esplicito riferimento al filtraggio dei contenuti a livello DNS per stabilire una posizione difendibile ai sensi del GDPR e del UK Online Safety Act. Il disallineamento tra l'AUP e l'effettiva politica di filtraggio crea esposizione legale.
Per-SSID Policy
Una funzionalità di configurazione del filtraggio DNS che consente di applicare politiche di filtraggio diverse a diversi nomi di rete wireless (SSID) - ad esempio, una politica di contenuti rigorosa sull'SSID guest e una politica di sola sicurezza sull'SSID del personale.
Essenziale per le sedi che gestiscono più SSID. Senza il supporto della politica per-SSID, le stesse regole di filtraggio si applicano a tutte le reti, il che limita eccessivamente l'accesso del personale o protegge in modo insufficiente l'accesso degli ospiti.
Esempi pratici
Un gruppo alberghiero con 12 strutture e 350 camere nel Regno Unito sta ricevendo segnalazioni di abuso da parte del proprio ISP relative a traffico malware originato da dispositivi degli ospiti. La loro rete WiFi ospiti è gestita tramite Purple. Hanno la necessità di implementare il filtro DNS in tutte le strutture entro 30 giorni, con la minima interruzione per gli ospiti e senza hardware aggiuntivo in loco.
L'approccio consigliato consiste nell'implementare Cloudflare Gateway (Zero Trust) come servizio di filtro DNS cloud, configurato a livello di controller wireless per l'SSID ospiti in tutte e 12 le strutture.
Settimana 1 - Configurazione del Servizio: Creare un account Cloudflare Zero Trust e configurare una policy di filtro DNS con i profili di sicurezza di base (malware, phishing, botnet C2, ransomware) abilitati. Aggiungere le categorie di utilizzo accettabile dell'hotel: contenuti per adulti e materiale estremista. Configurare la policy per mostrare una pagina di blocco personalizzata con il logo dell'hotel e un numero di contatto per gli ospiti che ritengono che un sito sia stato bloccato erroneamente.
Settimana 2 - Configurazione della Rete: Per ciascuna struttura, accedere all'interfaccia di gestione del controller wireless e aggiornare l'ambito DHCP per l'SSID ospiti per assegnare gli IP dei resolver di Cloudflare Gateway. Configurare il firewall di ciascuna struttura per intercettare il traffico in uscita sulla porta 53 e reindirizzarlo al resolver di Cloudflare. Registrare l'IP di uscita di ciascuna struttura nella dashboard di Cloudflare Zero Trust per associare le query alla policy della sede corretta.
Settimana 3 - Test e Validazione: Presso due strutture pilota, connettere un dispositivo di test all'SSID ospiti e verificare che: (a) il dominio di test dannoso sia bloccato, (b) la query DNS codificata nel dispositivo venga intercettata, (c) i servizi legittimi dell'hotel (motore di prenotazione, servizi di streaming) siano accessibili. Monitorare la dashboard di Cloudflare per rilevare eventuali falsi positivi e inserirli in whitelist se necessario.
Settimana 4 - Rollout Completo e Monitoraggio: Estendere la configurazione alle restanti 10 strutture. Configurare l'invio di report settimanali via email dalla dashboard di Cloudflare al direttore IT del gruppo. Stabilire un processo di revisione della whitelist con un referente designato presso ciascuna struttura.
Risultato atteso: Le notifiche di abuso dell'ISP cessano entro 30 giorni. La dashboard mostra una media di 340 richieste dannose bloccate al giorno in tutto il patrimonio immobiliare. Una struttura mostra un volume insolitamente alto di richieste bloccate, riconducibile a un dispositivo IoT compromesso in una sala conferenze, che viene isolato e ripristinato.
Una catena retail con 200 negozi in tutta Europa riscontra due problemi sulla propria rete WiFi per ospiti in negozio: gli ospiti accedono a contenuti per adulti e a servizi di streaming video, causando rischi di reputazione e congestione della rete. Il direttore IT ha bisogno di una soluzione che applichi il filtraggio dei contenuti in modo coerente in tutti i negozi, si integri con l'infrastruttura Cisco Meraki esistente e fornisca prove documentate di conformità al GDPR e al UK Online Safety Act.
Implementare Cisco Umbrella Advantage, integrato con l'infrastruttura Meraki esistente tramite l'integrazione Meraki-Umbrella.
Fase 1 - Progettazione delle Policy: Definire due policy di filtraggio DNS: (a) Policy SSID Ospiti - baseline di sicurezza più blocco di contenuti per adulti, streaming video, condivisione di file peer-to-peer e proxy di anonimizzazione; (b) Policy SSID Personale - solo baseline di sicurezza. Collaborare con il team legale per aggiornare l'AUP del Captive Portal in modo da fare esplicito riferimento al filtraggio dei contenuti a livello DNS.
Fase 2 - Integrazione Meraki: Nel cruscotto Cisco Umbrella, abilitare l'integrazione Meraki e collegare l'organizzazione Umbrella al cruscotto Meraki. Assegnare la policy SSID Ospiti a tutti gli SSID della rete ospiti nei 200 negozi. L'integrazione Meraki configura automaticamente il reindirizzamento DNS verso i resolver Umbrella - nessuna configurazione manuale di DHCP richiesta per singolo negozio.
Fase 3 - Applicazione delle Regole: Configurare Meraki per bloccare il traffico della porta 53 in uscita verso resolver non Umbrella utilizzando una regola di traffic shaping. Abilitare l'intelligent proxy di Umbrella per ispezionare e bloccare il traffico DoH verso resolver pubblici noti.
Fase 4 - Documentazione di Conformità: Esportare mensilmente la configurazione delle policy e i registri di controllo di Umbrella. Archiviare questi dati nell'ISMS (Information Security Management System) dell'organizzazione come prova dei controlli di filtraggio dei contenuti. Assicurarsi che l'accordo sul trattamento dei dati di Umbrella sia firmato e depositato presso il DPO.
Risultato atteso: L'utilizzo della rete ospiti diminuisce del 35% grazie al blocco dello streaming video. Zero incidenti relativi a contenuti per adulti segnalati nei 12 mesi successivi all'implementazione. L'audit di conformità conferma che i controlli di filtraggio documentati soddisfano gli obblighi dell'Online Safety Act.
Domande di esercitazione
Q1. Un operatore di un centro congressi gestisce tre SSID: 'Guest-Public' (aperto a tutti i partecipanti), 'Exhibitor-WiFi' (per gli espositori della fiera che elaborano pagamenti con carta) e 'Staff-Internal' (per i dipendenti della sede). Desiderano implementare il filtraggio DNS. Come dovrebbero strutturare le loro policy di filtraggio e quali considerazioni di conformità si applicano all'SSID degli espositori?
Suggerimento: Considera i diversi profili di rischio e i requisiti normativi per ciascun SSID. PCI-DSS si applica a qualsiasi rete in cui i dati delle carte possono essere presenti o adiacenti.
Visualizza risposta modello
Sono necessarie tre policy distinte. Guest-Public: baseline di sicurezza completa (malware, phishing, C2, ransomware) più categorie di contenuti appropriate per un ambiente professionale (contenuti per adulti, materiale estremista, proxy anonimizzanti). Exhibitor-WiFi: solo baseline di sicurezza - non applicare filtri sui contenuti che potrebbero bloccare strumenti di lavoro legittimi. Aspetto cruciale: poiché questo SSID è utilizzato da espositori che elaborano pagamenti con carta, si applica la conformità PCI-DSS v4.0. L'SSID deve essere su una VLAN separata senza percorsi verso l'ambiente dei dati dei titolari di carta, e i log del filtraggio DNS devono essere conservati per almeno 12 mesi come parte della traccia di audit. Prendi in considerazione l'implementazione di Cisco Umbrella con la sua funzione di reporting di conformità PCI-DSS. Staff-Internal: solo baseline di sicurezza, con un processo di eccezione documentato per il personale che necessita di accedere a categorie che altrimenti potrebbero essere bloccate. La principale considerazione di conformità per l'SSID degli espositori è che il requisito PCI-DSS 6.4 impone la protezione delle applicazioni web rivolte al pubblico, e il requisito 10.2 impone la conservazione dei log di audit - i log del filtraggio DNS soddisfano in parte questo requisito.
Q2. L'IT manager di un hotel distribuisce Cloudflare Gateway sull'SSID degli ospiti. Dopo due settimane, la dashboard mostra che i volumi di query DNS sono inferiori del 40% rispetto a quanto previsto in base al numero di dispositivi connessi. Qual è la causa più probabile e in che modo l'IT manager dovrebbe indagare e risolvere il problema?
Suggerimento: Pensa a cosa potrebbe spingere le query DNS a bypassare completamente il resolver cloud. Considera sia i vettori di bypass a livello di dispositivo che a livello di rete.
Visualizza risposta modello
La causa più probabile è che una percentuale significativa di dispositivi degli ospiti stia utilizzando resolver DNS hardcoded (come 8.8.8.8 o 1.1.1.1) anziché il resolver Cloudflare Gateway assegnato tramite DHCP. Ciò indica che la regola di intercettazione della porta 53 sul firewall non è stata configurata o non funziona correttamente. Passaggi di indagine: (1) Sul firewall, verificare se esiste una regola di reindirizzamento NAT per il traffico in uscita sulla porta UDP/TCP 53 dalla VLAN guest. (2) Da un dispositivo di test sull'SSID guest, eseguire 'nslookup google.com 8.8.8.8' - se restituisce un risultato anziché essere intercettato, la regola del firewall manca o è configurata in modo errato. (3) Controllare i log del firewall per il traffico in uscita sulla porta 53 verso indirizzi IP non appartenenti a Cloudflare. Risoluzione: configurare il firewall per intercettare tutto il traffico in uscita sulla porta 53 dalla VLAN guest e reindirizzarlo agli IP del resolver Cloudflare Gateway. Dopo aver implementato questo accorgimento, i volumi di query dovrebbero normalizzarsi. Inoltre, verificare se alcuni dispositivi utilizzano DoH - se i volumi di query rimangono bassi dopo l'intercettazione della porta 53, il bypass DoH potrebbe essere un fattore secondario.
Q3. Il direttore IT di una catena di negozi al dettaglio sta valutando il filtraggio DNS per 200 punti vendita. Il team di sicurezza desidera Cisco Umbrella per la sua threat intelligence Talos; il team finanziario spinge per una soluzione gratuita al fine di ridurre al minimo i costi. I negozi utilizzano access point Cisco Meraki. In che modo il direttore IT dovrebbe impostare l'argomentazione sul ROI e qual è la soluzione consigliata?
Suggerimento: Considera il costo totale di proprietà, non solo il costo delle licenze. Fattorizza i costi operativi di una soluzione gratuita su scala e il valore dell'integrazione nativa dell'infrastruttura.
Visualizza risposta modello
Il direttore IT dovrebbe strutturare l'argomentazione sul ROI attorno a tre categorie di costo: (1) Prevenzione dei costi di incidente - un singolo incidente di malware in un punto vendita, che si traduca in una notifica di abuso dell'ISP, un'indagine normativa o la compromissione del sistema POS, può costare tra £20.000 e £100.000 in rimedio e spese legali. Su 200 punti vendita, anche un tasso di incidenti annuo dell'1% senza filtraggio DNS rappresenta un costo atteso significativo. (2) Costo operativo - una soluzione gratuita come Pi-hole richiederebbe l'implementazione e la manutenzione in 200 punti vendita, senza gestione centralizzata. Con 1 ora di tempo IT per punto vendita a trimestre, si tratta di 800 ore all'anno, che probabilmente superano il costo delle licenze di Cisco Umbrella. (3) Valore di integrazione - l'integrazione nativa di Cisco Umbrella con Meraki elimina la configurazione DHCP per singolo punto vendita, riduce i tempi di implementazione da settimane a giorni e fornisce una gestione centralizzata delle policy. La soluzione consigliata è Cisco Umbrella Essentials o Advantage, integrata con Meraki. La preoccupazione del team finanziario riguardo ai costi è valida, ma il confronto deve basarsi sul costo totale di proprietà (TCO) e non solo sul costo delle licenze. L'integrazione Meraki-Umbrella è il fattore decisivo: rende l'implementazione su 200 punti vendita operativamente fattibile in un modo che nessuna soluzione gratuita può eguagliare a questa scala.
Continua a leggere questa serie
Come segmentare in sicurezza le reti WiFi del personale e degli ospiti: Best Practice per LAN aziendali
Questa guida fornisce ai responsabili IT e agli architetti di rete un progetto tecnico, indipendente dai vendor, per proteggere le LAN aziendali segmentando correttamente il traffico WiFi del personale e degli ospiti. Copre l'autenticazione 802.1X, il cloud RADIUS, l'isolamento VLAN e la gestione del ciclo di vita delle credenziali necessaria per eliminare le password condivise e proteggere le risorse aziendali.
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.
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.
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.