ExplainerDNS filtering limits
Filtro DNS fail open vs fail closed: cosa succede quando il filtro smette di funzionare
Potrà decidere come devono comportarsi le reti WiFi ospiti e il WiFi del personale quando il filtro DNS smette di rispondere e verificare se la rete passa davvero alla modalità fail closed. Scoprirà dove si nascondono i meccanismi di fallback in DHCP, forwarder e dispositivi, e come testare la ridondanza prima che sia...
La scelta tra fail open e fail closed nel filtraggio DNS riguarda la reazione di una rete quando il relativo resolver di filtraggio smette di rispondere. Il fail open reindirizza a un resolver non filtrato, consentendo di proseguire la navigazione senza protezione. Il fail closed non invia le query a nessun altro resolver, in linea con il controllo SC-24 dello standard NIST SP 800-53 (fail in a known state), garantendo che nulla venga risolto senza filtraggio.
Qual è la differenza tra fail open e fail closed nel filtraggio DNS?
Il filtraggio DNS interviene al primo passaggio di ogni connessione. Un telefono chiede a un resolver di convertire un nome di dominio in un indirizzo IP prima di aprire qualsiasi sessione (RFC 1035). Un resolver DNS protettivo verifica tale nome confrontandolo con l'intelligence sulle minacce e con la policy sui contenuti. Restituisce quindi l'indirizzo reale, l'indirizzo di una pagina di blocco o un rifiuto.
Questa collocazione è il motivo per cui il filtraggio DNS funziona. La verifica avviene prima che un singolo pacchetto raggiunga la destinazione. In questo modo è possibile bloccare un link di phishing o un richiamo di malware che un firewall vedrebbe solo come traffico consentito sulla porta 443. Il National Cyber Security Centre del Regno Unito gestisce un servizio DNS protettivo per il settore pubblico basato sullo stesso principio.
Tale collocazione rappresenta tuttavia anche il punto debole. Se ogni ricerca dipende dal resolver di filtraggio, occorre un piano per i casi in cui quest'ultimo non sia raggiungibile. Esistono solo due opzioni.
- Fail open. La rete o il dispositivo invia la query a un altro resolver che non applica alcuna policy. La navigazione prosegue, ma la protezione, la registrazione dei log e le regole sui contenuti si interrompono fino al ripristino del filtro.
- Fail closed. Non esiste alcun percorso non filtrato. Le nuove ricerche attendono la risposta di un resolver di filtraggio e nulla viene risolto senza una decisione basata sulla policy.
La scelta è un compromesso tra disponibilità e sicurezza. Il fail open favorisce l'utente che desidera caricare una pagina immediatamente. Il fail closed favorisce il team di sicurezza, il responsabile della conformità e i revisori, che devono dimostrare che la rete sia stata filtrata in ogni momento dell'anno.
Lo standard NIST SP 800-53 Rev. 5 inquadra lo stesso concetto in due controlli. SC-24 indica la modalità "fail in a known state" e SC-7(18) indica la modalità "fail secure" (NIST SP 800-53 Rev. 5).
Come funziona il comportamento del filtro in caso di guasto a livello di resolver?
Il comportamento del filtro in caso di guasto è determinato dalla configurazione e non dal filtro stesso. Può essere impostato in tre punti: nel server DHCP, in qualsiasi forwarder DNS locale e sul dispositivo.
I campi DNS del server DHCP
Il DHCP è il protocollo che assegna a ciascun dispositivo l'indirizzo IP e le impostazioni di rete al momento della connessione. La maggior parte delle reti per ospiti e del personale lo utilizza per fornire a ogni dispositivo due o più indirizzi di server DNS. Se tutti gli indirizzi puntano a resolver di filtraggio, la configurazione è di tipo fail closed. Se il secondo indirizzo punta a un ISP o a un resolver pubblico, la configurazione è di tipo fail open, indipendentemente dalle garanzie offerte dal fornitore del servizio di filtraggio.
Flow diagram showing a guest device query timing out at the filtering resolver, falling back to an unfiltered secondary resolver and connecting to a domain with no policy check.
Connections
- Guest device to Filtering resolver (1. Query on port 53)
- Filtering resolver to Guest device (2. Timeout, no reply)
- Guest device to Unfiltered fallback resolver (3. Retry to secondary)
- Unfiltered fallback resolver to Answer with no policy check (4. Resolves any domain)
- Answer with no policy check to Connection opens (5. Device connects)
Il forwarder locale
Molti firewall e gateway eseguono un forwarder DNS. I dispositivi interrogano il gateway e questo inoltra ai resolver a monte. In questo caso il fallback risiede nell'elenco a monte del forwarder. Un forwarder che elenca un resolver pubblico al di sotto del filtro presenta un comportamento fail-open, anche se il DHCP appare corretto.
Il comportamento del dispositivo
La selezione del resolver varia in base al sistema operativo. Alcuni dispositivi considerano il secondo server come uno standby rigido. Altri lo interrogano ogni volta che il primo è lento, oppure inviano query a entrambi. In una configurazione fail-open, le risposte non filtrate possono quindi trapelare anche quando il filtro funziona perfettamente.
Come si presenta una configurazione fail-closed
In una architettura fail-closed, ogni indirizzo DNS che un dispositivo o forwarder può utilizzare punta a un resolver di filtraggio con la stessa policy. Se uno smette di rispondere, il dispositivo riprova con quello successivo. La ricerca fallisce solo quando tutti i resolver di filtraggio sono irraggiungibili. Il dispositivo riceve quindi un timeout o SERVFAIL, la risposta di errore del server DNS standard, anziché una risposta non filtrata.
Diagramma di flusso che mostra un dispositivo che riprova un secondo resolver di filtraggio dopo il fallimento del primo, la policy che consente o blocca il dominio e un percorso tratteggiato in cui tutti i resolver falliscono e nessuna connessione viene aperta.
Connections
- Dispositivo to Resolver di filtraggio 1 (1. Query)
- Dispositivo to Resolver di filtraggio 2 (2. Riprova con il filtro successivo)
- Resolver di filtraggio 2 to Controllo policy (3. Applica policy di rete)
- Controllo policy to Risposta pulita (4a. Dominio consentito)
- Controllo policy to Risposta di blocco (4b. Minaccia o categoria bloccata)
- Dispositivo to Nessuna risposta (Se tutti i filtri falliscono)
Se applicato correttamente, il fail closed non è fragile. La resilienza deriva da resolver di filtraggio ridondanti, non da una via di fuga non filtrata.
Fail open, fail closed, fail secure: quali termini generano confusione?
Quattro termini affini compaiono frequentemente nella documentazione dei fornitori, nei report di audit e nei ticket di modifica. Descrivono concetti diversi e confonderli porta a una progettazione errata.
| Termine | Cosa descrive | Durante un disservizio del filtro | Rischio comportato |
|---|---|---|---|
| Fail open | Le query ripiegano su un resolver non filtrato quando il filtro è irraggiungibile | La navigazione prosegue, non filtrata | Le minacce e le categorie bloccate vengono risolte senza policy e spesso senza log |
| Fail closed | Sono configurati solo resolver con filtraggio, senza fallback non filtrato | Le nuove ricerche falliscono finché un resolver con filtraggio non risponde | La disponibilità dipende dalla ridondanza del filtro |
| Fail secure (NIST SC-7(18)) | Termine del framework di controllo: un dispositivo di confine non deve entrare in uno stato non sicuro in caso di guasto | Stesso risultato pratico del fail closed | Gli auditor potrebbero richiedere prove in merito |
| Serve-stale (RFC 8767) | Un resolver risponde dalla cache scaduta quando i server upstream sono irraggiungibili | I domini visitati di recente continuano a essere risolti | Le risposte riflettono l'ultima decisione, non un nuovo controllo della policy |
| Default deny | Policy per i domini non ancora categorizzati dal filtro | Non è una modalità di guasto; si applica mentre il filtro è funzionante | Eccesso di blocchi se impostato in modo troppo rigido |
| Bypass | Un dispositivo ignora il resolver di rete tramite DNS hardcoded, DoH o DoT | Invariato, perché rimane non filtrato in qualsiasi momento | Richiede controlli di uscita, non un'impostazione di guasto |
Fail closed non è default deny
Default deny è una scelta di policy relativa ai domini non categorizzati. Funziona quando il filtro è in perfetto stato. Fail closed riguarda ciò che accade quando il filtro è assente. È possibile eseguire il fail closed con una policy permissiva, o il fail open con una rigida.
Serve-stale si colloca tra i due
L'RFC 8767 consente a un resolver di rispondere dalla cache scaduta quando non può raggiungere i server upstream. Ciò mantiene operativi i nomi più popolari durante i brevi disservizi. Riproduce l'ultima decisione, quindi un dominio diventato malevolo nel frattempo non viene intercettato.
Il bypass non è un guasto
Un dispositivo che utilizza DNS over HTTPS (DoH, RFC 8484) o DNS over TLS (DoT, RFC 7858) verso un resolver pubblico non interagisce mai con il filtro. Le impostazioni di fail closed non hanno alcun effetto in questo caso. Il bypass si gestisce con regole di uscita (egress rules).
Dove si riscontra un disservizio del filtraggio DNS all'atto pratico?
Un disservizio del filtraggio DNS diventa rilevante solo quando il collegamento a internet è attivo ma il filtro è irraggiungibile. Se cade l'intero uplink, entrambe le modalità si comportano allo stesso modo. Nella pratica, il divario si crea a causa di ordinari eventi operativi:
- una modifica al firewall che blocca la porta 53 in uscita verso gli indirizzi del filtro;
- un forwarder locale che va in crash o smette di inoltrare le richieste upstream;
- una modifica al routing su una WAN aziendale che invia il DNS nella direzione errata;
- un fornitore esterno che modifica un ambito DHCP e aggiunge un risolutore pubblico "per resilienza";
- un incidente presso il fornitore del filtro stesso.
Ciascuna di queste azioni sembra innocua su una rete fail closed. Ciascuna di esse rimuove silenziosamente la protezione su una rete fail open.
Reti per ospiti nel settore Hospitality
Gli hotel e i gruppi di pub applicano policy sui contenuti per garantire che il WiFi per gli ospiti sia adatto alle famiglie e al sicuro da malware. Una rete per ospiti fail open disattiva tale policy senza avvisare nessuno. Per i grandi operatori dell'hospitality, una violazione delle policy sul WiFi pubblico comporta sia un rischio di reputazione del brand che un rischio di sicurezza.
Sanità
Shield blocca circa 241.000 minacce alla settimana presso lo St George's Healthcare NHS Trust. Secondo i nostri calcoli, si tratta di una media di circa 1.400 all'ora. Finestra di fail open di una sola ora consentirebbe a tali risoluzioni di avvenire senza controlli, su tutti i dispositivi di pazienti, visitatori e personale.
Hub di trasporto
Gli aeroporti ospitano migliaia di dispositivi dei passeggeri su reti pubbliche, molti dei quali non gestiti. In un terminal, una falla dovuta al fail open si traduce in una rete pubblica non filtrata durante i picchi di traffico.
Reti aziendali e del personale
Le reti del personale aumentano la posta in gioco sulla disponibilità. Le app aziendali devono continuare a funzionare, quindi il fail closed necessita di una reale ridondanza alla base. I nomi interni di solito vengono risolti su server DNS interni, che poi inoltrano le query esterne al filtro. Assicurati che questo livello di inoltro non abbia un upstream non filtrato.
Quali sono i limiti e i casi limite del DNS fail closed?
Il fail closed è la scelta predefinita corretta per la maggior parte delle reti WiFi per ospiti e personale. Presenta comunque dei limiti, ed è bene conoscerli prima di progettarvi attorno la rete.
Il fail closed con un solo risolutore equivale a un piano di disservizio
Se la rete indica un singolo indirizzo di filtraggio, il fail closed significa che ogni interruzione di quell'indirizzo interrompe il DNS. La ridondanza su più risolutori di filtraggio è ciò che rende il fail closed praticabile. Chiedi al tuo fornitore quanti indirizzi di risolutori puoi configurare e testane ciascuno.
La cache mantiene attivi alcuni nomi
Ogni risposta DNS include un TTL (time to live), ovvero il numero di secondi in cui un dispositivo o un risolutore può memorizzarla nella cache. Durante una breve interruzione, i nomi memorizzati nella cache continuano a funzionare mentre i nuovi nomi falliscono. I visitatori notano questo problema come "alcuni siti funzionano, altri no", il che può trarre in inganno il tuo supporto tecnico.
I Captive Portal richiedono il DNS prima dell'accesso
Un Captive Portal è la pagina di benvenuto che un ospite vede prima di connettersi a Internet. Il dispositivo deve risolvere il portale e gli eventuali domini nel walled garden prima dell'autenticazione. Se la rete pre-login utilizza un risolutore non filtrato, il portale diventa una falla di sicurezza. Se va in fail closed senza ridondanza, gli ospiti non possono accedere affatto.
Un errore appare diverso da un blocco
Un dominio bloccato dovrebbe restituire una pagina di blocco o un rifiuto esplicito. Una ricerca non riuscita restituisce un timeout o SERVFAIL. Gli errori DNS estesi definiti in RFC 8914 aggiungono codici che permettono di distinguerli, come Blocked (15) e Filtered (17) rispetto a No Reachable Authority (22). Istruisci il tuo helpdesk su entrambi i casi, in modo che possa distinguere un blocco di policy da un'interruzione di servizio.
Il DNS non può vedere oltre il nome
La modalità fail closed garantisce una decisione di policy su ogni ricerca, non una copertura totale. Le connessioni agli indirizzi IP grezzi saltano completamente il DNS. Le connessioni già aperte prima dell'interruzione proseguono. Inoltre, il DNS vede solo il dominio e mai il percorso, come spiegato nella guida su perché il filtraggio DNS non può vedere gli URL completi.
Per capire come questi limiti si inseriscono in uno stack più ampio, consulta il filtraggio DNS è sufficiente? e la panoramica sui limiti del filtraggio DNS.
In che modo il DNS fail closed si collega a Purple Shield?
Purple Shield è un sistema di protezione DNS e filtraggio dei contenuti per qualsiasi rete. Shield funziona in modalità fail closed, in modo che un'interruzione non lasci mai una rete priva di filtraggio. Ogni ricerca riceve una decisione di policy oppure nessuna risposta, mai una risposta non verificata.
È possibile eseguire Shield in modalità standalone su qualsiasi rete WiFi o insieme a Purple Access. Imposti una policy per rete e per VLAN (virtual LAN, una rete logicamente separata su hardware condiviso). Le reti ospiti, del personale e del back-office di una stessa struttura possono applicare regole diverse. Shield non richiede nuovo hardware e si posiziona come un overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet.
- ~241,000minacce bloccate a settimanaSt George's Healthcare NHS Trust
- 80,000+strutture attiveDati Purple
- 90paesiDati Purple
Anche DNSFilter e Cisco Umbrella filtrano a livello di risoluzione DNS, quindi la questione del posizionamento si applica a tutti e tre. La domanda da porre a ciascun fornitore riguarda la gestione del fallback. Chiedi come si comportano i loro agenti di roaming quando i resolver non sono raggiungibili e quanti indirizzi di filtraggio puoi configurare. Successivamente, verifica che le impostazioni DHCP e del forwarder non reintroducano un percorso non filtrato.
Shield è attivo su tutta la presenza di Purple di oltre 80.000 strutture in 90 paesi. Leggi come funziona Shield per i dettagli sull'implementazione. La guida alla sicurezza WiFi enterprise mostra dove si colloca il filtraggio DNS insieme all'identità e alla segmentazione.
Questo concetto si rivela cruciale durante la finestra di modifica, non sulla brochure. La regola del firewall, la modifica del DHCP o il secondario pubblico "resiliente" determinano se la rete rimane filtrata. Esegua un audit di queste tre impostazioni nel trimestre in corso. Successivamente, legga DNS over TLS e filtraggio: cosa cambia con la porta 853, poiché un resolver fail-closed protegge solo i dispositivi che lo utilizzano effettivamente.
Domande frequenti
Un DNS con modalità fail-closed significa che un'interruzione porta offline il WiFi?
No, non quando il filtro viene eseguito su resolver ridondanti. La modalità fail-closed blocca le nuove ricerche solo quando tutti i resolver di filtraggio risultano irraggiungibili contemporaneamente. I dispositivi riprovano prima con l'indirizzo di filtraggio successivo. Le risposte in cache mantengono risolvibili i siti visitati di recente durante brevi interruzioni. Progetti la ridondanza prima di andare in produzione, quindi la testi bloccando un resolver alla volta da una VLAN di prova.
Shield funzionerà con gli access point e i firewall già in mio possesso?
Sì. Shield applica i filtri a livello di risoluzione DNS, pertanto non richiede nuovo hardware e funziona in modo autonomo su qualsiasi rete WiFi. Purple funziona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. È sufficiente indirizzare il DNS di ciascuna rete o VLAN verso Shield, rimuovere qualsiasi fallback non filtrato e applicare una politica per rete. La pagina del prodotto illustra i passaggi necessari.
Come viene calcolato il prezzo di Shield?
Purple fornisce un preventivo per Shield in base alla Sua infrastruttura, anziché pubblicare un listino prezzi in questa guida. Shield è un add-on di sicurezza che può eseguire in modo autonomo su qualsiasi rete WiFi o insieme a Purple Access. Il preventivo riflette quindi le Sue reti e le Sue sedi, non l'acquisto di nuovo hardware. Richieda un preventivo indicando il numero di sedi, il numero di reti e VLAN, e se utilizza già Purple.
Come posso effettuare la migrazione da DNSFilter o Cisco Umbrella senza interruzioni nel filtraggio?
Esegua il passaggio una rete o una VLAN alla volta. Indirizzi il DNS DHCP di una VLAN di prova verso Shield, verifichi i blocchi e i log, quindi sposti le reti operative durante una finestra di modifica. Rimuova completamente i vecchi indirizzi dei resolver invece di lasciarli come DNS secondario. Verifichi anche gli agenti di roaming sui dispositivi del personale, poiché le loro impostazioni di fallback risiedono all'esterno dell'ambito DHCP.
Esiste una normativa che richiede il filtraggio DNS fail-closed?
Nessuna normativa cita esplicitamente il DNS fail-closed, ma i framework di controllo prevedono che i controlli di sicurezza ripieghino su uno stato noto e sicuro. Il controllo SC-24 dello standard NIST SP 800-53 Rev. 5 riguarda il ripiegamento su uno stato noto. Il controllo SC-7(18) riguarda la protezione del perimetro con ripiegamento sicuro. Il filtraggio fail-closed fornisce la prova che la politica è stata applicata costantemente, un elemento utile in sede di audit o su richiesta dei responsabili della tutela della sicurezza.
Come posso testare il comportamento attuale del mio filtro in caso di guasto?
Blocchi il DNS in uscita verso i resolver di filtraggio da una singola VLAN di prova e osservi il comportamento del dispositivo. Se i siti web continuano a caricarsi e il filtro non registra nulla nei log, la rete ripiega in modalità fail-open. Verifichi i campi DNS del DHCP, gli elenchi upstream dei forwarder e le impostazioni dei dispositivi hardcoded. Ripeta l'operazione bloccando un resolver di filtraggio alla volta per confermare il corretto funzionamento della ridondanza.
Il filtraggio DNS è sufficiente da solo o è necessario un secure web gateway?
Il filtraggio DNS copre la protezione dalle minacce e la policy sui contenuti per la maggior parte delle reti ospiti e di sede, ma non l'ispezione completa degli URL o la prevenzione della perdita di dati (DLP). Vede i nomi di dominio, non i percorsi o i contenuti dei file. Se si necessita di tali controlli, aggiungere un secure web gateway sui dispositivi gestiti. Consultare DNS filtering vs secure web gateway per comprendere la differenza tra i due approcci.
Key terms
- DNS protettivo
- Un resolver ricorsivo che confronta ciascun dominio interrogato con le informazioni sulle minacce e con le politiche sui contenuti prima di rispondere, restituendo l'indirizzo reale, l'indirizzo di una pagina di blocco o un rifiuto. Agisce sulla ricerca dei nomi definita in RFC 1035, prima dell'apertura di qualsiasi sessione. L'NCSC del Regno Unito gestisce un servizio di DNS protettivo per il settore pubblico basato su questo principio. Si tratta del controllo la cui modalità di guasto è disciplinata da questa decisione.
- Fail-open (Apertura in caso di guasto)
- Una configurazione in cui le query DNS effettuano il fallback su un resolver che non applica alcuna politica quando il resolver di filtraggio non è raggiungibile. La risoluzione prosegue, ma il blocco delle minacce, le regole sui contenuti e la registrazione delle attività si interrompono. Di solito si presenta come resolver pubblico o dell'ISP nel campo DNS secondario del DHCP o nella lista upstream di un forwarder. Spesso viene introdotto accidentalmente durante una modifica.
- Fail-closed (Chiusura in caso di guasto)
- Una configurazione in cui ogni indirizzo DNS utilizzabile da un dispositivo o forwarder punta a un resolver di filtraggio con la medesima politica. Una ricerca fallisce con un timeout o un SERVFAIL solo quando tutti i resolver di filtraggio risultano irraggiungibili. Questa è la scelta predefinita corretta per la maggior parte delle reti ospiti e del WiFi del personale, a condizione che vi siano resolver di filtraggio ridondanti a supporto.
- Fail-secure (Sicurezza in caso di guasto) (NIST SC-7(18))
- Estensione di protezione del perimetro NIST SP 800-53 Rev. 5 SC-7(18), che richiede a un dispositivo di perimetro di evitare di entrare in uno stato non sicuro in caso di guasto. Gli auditor potrebbero chiederLe di fornirne prova. Il filtraggio DNS fail closed offre lo stesso risultato pratico.
- Guasto in uno stato noto (NIST SC-24)
- Controllo NIST SP 800-53 Rev. 5 SC-24, che richiede ai sistemi di passare in uno stato definito e noto in caso di guasto, piuttosto che in uno imprevedibile. Nessuna normativa cita esplicitamente il DNS fail closed, ma questo controllo rappresenta la terminologia del framework a cui fare riferimento quando lo si giustifica ad auditor o responsabili della sicurezza.
- Gestione serve-stale (Invio di dati obsoleti in caso di errore)
- Comportamento definito da RFC 8767 che consente a un resolver di rispondere attingendo dalla cache scaduta quando non riesce a raggiungere i server upstream, mantenendo funzionanti i nomi risolti di recente. Attenua le brevi interruzioni, ma ripropone l'ultima decisione presa; pertanto, un dominio diventato malevolo nel frattempo non viene rilevato.
- SERVFAIL
- Il codice di risposta di errore del server nel formato del messaggio DNS definito in RFC 1035, restituito quando un resolver non può completare una ricerca. Su una rete fail closed è ciò che un dispositivo riceve quando ogni resolver di filtraggio è inattivo. Il tuo helpdesk deve saperlo distinguere da un blocco.
- Extended DNS Errors
- Codici RFC 8914 che aggiungono dettagli alle risposte DNS, inclusi Blocked (15), Filtered (17) e No Reachable Authority (22). Consentono al personale di supporto e agli strumenti di separare un blocco di policy da un'interruzione quando si analizzano le segnalazioni di siti che non si caricano.
- TTL (time to live)
- Il campo in ogni record di risorsa DNS, definito in RFC 1035, che indica il numero di secondi in cui un dispositivo o resolver può memorizzare in cache la risposta. Durante una breve interruzione i nomi in cache continuano a funzionare mentre i nuovi nomi falliscono. Gli utenti segnalano questo comportamento come se alcuni siti funzionassero e altri no.
- DNS forwarder
- Un servizio DNS su un firewall, gateway o server interno che riceve le query dai dispositivi e le inoltra a un elenco configurato di resolver upstream. Il fallback risiede nel suo elenco upstream. Un resolver pubblico presente lì fallisce in modalità fail open anche se il DHCP è corretto, compreso il livello dietro il DNS interno sulle reti del personale.
- DoH e DoT
- DNS over HTTPS, specificato in RFC 8484, e DNS over TLS, specificato in RFC 7858. Entrambi crittografano il DNS verso un resolver scelto e possono instradare il traffico all'esterno del resolver di rete. Rappresentano un aggiramento, non un guasto. Le impostazioni fail closed non hanno effetto su di essi, quindi li controlli con regole di egress.
- Captive Portal
- La pagina di benvenuto che un utente ospite visualizza prima di andare online. Il dispositivo deve risolvere i domini del portale e del walled garden prima di autenticarsi. Un resolver pre-login non filtrato rende il portale una vulnerabilità. Una rete con Captive Portal fail closed priva di ridondanza impedisce agli ospiti di effettuare l'accesso.
- Default deny
- Una policy di filtraggio per i domini che il filtro non ha ancora categorizzato. Si applica quando il filtro è perfettamente operativo e non è una modalità di guasto. Viene spesso confuso con la modalità fail closed. È possibile eseguire il fail closed con una policy permissiva o il fail open con una severa.
Worked examples
Un esterno aggiunge un resolver pubblico all'ambito DHCP di una rete ospiti come DNS secondario per garantire la resilienza. Il resolver di filtraggio rimane primario. La rete è ancora protetta?
No. Un resolver pubblico nel campo secondario trasforma la configurazione in fail open. Alcuni sistemi operativi interrogano il secondo server ogni volta che il primo è lento, quindi le ricerche non filtrate possono verificarsi quotidianamente, non solo durante le interruzioni. Per confermare ciò, blocchi il DNS in uscita verso i resolver di filtraggio da un singolo VLAN di prova. Se i siti continuano a caricarsi e il filtro non registra nulla, significa che la rete è in modalità fail open. Sostituisca l'indirizzo pubblico con un secondo resolver di filtraggio che applichi la stessa politica. Successivamente, verifichi che le liste upstream dei forwarder e le impostazioni cablate nei dispositivi non presentino lo stesso difetto. Infine, blocchi un resolver di filtraggio alla volta per dimostrare che la ridondanza funzioni correttamente.
Sta migrando le reti ospiti e il WiFi del personale da DNSFilter o Cisco Umbrella a Purple Shield. Come evita un'interruzione del filtraggio durante il passaggio?
Esegua il passaggio di una rete o di un VLAN alla volta. Inizi puntando il DNS DHCP di un VLAN di prova su Shield, quindi confermi che i blocchi e i log appaiano come previsto. Una volta superato il test, sposti le reti operative durante una finestra di manutenzione. Rimuova completamente i vecchi indirizzi dei resolver invece di lasciarli come DNS secondari. Un secondario residuo reinserisce un percorso non filtrato o incoerente. Controlli anche gli agenti roaming sui dispositivi del personale, poiché le loro impostazioni di fallback si trovano all'esterno dell'ambito DHCP. Questo approccio garantisce che ogni ricerca rimanga soggetta a una regola di politica durante l'intero passaggio. Mantiene inoltre intatto il comportamento fail closed di Shield una volta rimosso il vecchio fornitore.
Frequently asked questions
La modalità fail closed del DNS significa che un'interruzione porta offline la mia rete WiFi?
No, non quando il filtro viene eseguito su resolver ridondanti. La modalità fail closed blocca le nuove ricerche solo quando tutti i resolver di filtraggio sono irraggiungibili contemporaneamente. I dispositivi riprovano prima verso l'indirizzo di filtraggio successivo. Le risposte memorizzate in cache mantengono risolvibili i siti visitati di recente durante brevi interruzioni. Progetta la ridondanza prima della messa in funzione, quindi testala bloccando un resolver alla volta da una VLAN di prova.
Purple Shield funzionerà con gli access point e i firewall che già possiedo?
Sì. Purple Shield esegue il filtraggio al momento della risoluzione DNS, pertanto non richiede nuovo hardware e funziona in modo autonomo su qualsiasi rete WiFi. Purple si integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. È sufficiente puntare il DNS di ogni rete o VLAN su Purple Shield, rimuovere qualsiasi fallback non filtrato e applicare una policy per rete. La pagina del prodotto descrive tutti i passaggi.
Come viene determinato il prezzo di Shield?
Purple fornisce preventivi personalizzati per Shield in base alla Sua infrastruttura, anziché pubblicare un listino prezzi in questa guida. Shield è un componente aggiuntivo di sicurezza che può essere eseguito sia in modalità stand-alone su qualsiasi rete WiFi, sia affiancato ad Purple Access. Il preventivo riflette quindi le Sue reti e le Sue sedi, senza richiedere nuovo hardware. Richieda un preventivo indicando il numero di sedi, la rete, il numero di VLAN e specificando se utilizza già Purple.
Come posso passare da DNSFilter o Cisco Umbrella senza interruzioni nel filtraggio?
Effettui la migrazione una rete o un VLAN alla volta. Punti il DNS DHCP di un VLAN di prova verso Shield, verifichi i blocchi e i log, quindi sposti le reti operative durante una finestra di manutenzione. Rimuova completamente i vecchi indirizzi dei risolutori anziché lasciarli come DNS secondari. Controlli anche gli agenti di roaming sui dispositivi del personale, poiché le loro impostazioni di fallback risiedono all'esterno dell'ambito DHCP.
Esiste qualche regolamento che richieda il filtraggio DNS di tipo fail-closed?
Nessun regolamento menziona esplicitamente il filtraggio DNS fail-closed, ma i framework di controllo esigono che i controlli di sicurezza si arrestino in uno stato sicuro e noto. Il controllo SC-24 del NIST SP 800-53 Rev. 5 riguarda l'arresto in uno stato noto; il controllo SC-7(18) riguarda la protezione perimetrale con arresto sicuro (fail-secure). Il filtraggio fail-closed fornisce la prova che la policy è stata applicata costantemente, offrendo un riscontro utile in sede di audit o durante le verifiche di tutela della sicurezza.
Come posso testare il comportamento del mio attuale filtro in caso di guasto?
Blocchi il DNS in uscita verso i risolutori di filtraggio da un singolo VLAN di prova e osservi il comportamento del dispositivo. Se i siti web continuano a caricarsi e il filtro non registra nulla, significa che la rete è impostata su fail-open. Verifichi i campi DNS DHCP, gli elenchi dei forwarder a monte e le impostazioni dei dispositivi codificate in modo rigido. Ripeta la procedura bloccando un risolutore di filtraggio alla volta per confermare il corretto funzionamento della ridondanza.
Il filtraggio DNS è sufficiente da solo o è necessario un secure web gateway?
Il filtraggio DNS copre la protezione dalle minacce e le policy sui contenuti per la maggior parte delle reti ospiti e delle sedi, ma non include l'ispezione completa degli URL o la prevenzione della perdita di dati. Rileva i nomi di dominio, non i percorsi o il contenuto dei file. Se necessita di tali controlli, aggiunga un secure web gateway sui dispositivi gestiti. Consulti [Filtraggio DNS rispetto al secure web gateway](guide:dns-filtering-vs-secure-web-gateway) per comprendere dove si colloca il limite di demarcazione.