Regole del firewall per reti WiFi guest

# Podcast Script: Mastering Firewall Rules for Guest WiFi **Host:** A senior solutions architect from Purple. **(Musica d'introduzione - Vivace, professionale, sfuma dopo 5 secondi)** **Host:** Ciao e benvenuti al Purple Technical Briefing. Sono un senior solutions architect qui in Purple, e oggi affrontiamo un argomento assolutamente fondamentale per implementare un WiFi guest sicuro e ad alte prestazioni: le regole del firewall. Questo è per gli IT manager, gli architetti di rete e i direttori operativi che devono bilanciare un accesso guest fluido con una sicurezza di rete aziendale di ferro. Sbagliare questo aspetto è uno dei rischi più grandi in qualsiasi struttura, e può portare a violazioni della sicurezza e colli di bottiglia nelle prestazioni. In questo briefing, forniremo indicazioni dirette e pratiche per aiutarvi a configurare correttamente i vostri firewall, in particolare per un'implementazione Purple. **(Musica di transizione - breve, discreta)** **Host:** Entriamo subito nei dettagli tecnici. Il principio in assoluto più importante da rispettare è l'**isolamento**. La rete guest deve essere trattata come un ambiente completamente non attendibile. Ciò significa creare una Virtual LAN dedicata, o VLAN, per il traffico guest, completamente segmentata dalla LAN aziendale in cui risiedono i sistemi aziendali critici. Non deve essere assolutamente possibile alcun movimento laterale dalla VLAN Guest alla VLAN aziendale. Il firewall è il guardiano che impone questa separazione. Quindi, quale traffico dovresti consentire esplicitamente in uscita da questa rete guest isolata? Operiamo in base al principio del 'default deny'. Nulla passa a meno che non si crei una regola specifica di 'allow'. Ecco gli elementi essenziali. In primo luogo, la **Porta 53 per il DNS**. I tuoi ospiti devono essere in grado di risolvere i nomi di dominio come 'purple.ai' in indirizzi IP. Dovresti configurare la rete guest per utilizzare resolver DNS pubblici e attendibili, come l'8.8.8.8 di Google o l'1.1.1.1 di Cloudflare. Ciò impedisce agli utenti di utilizzare potenzialmente server DNS personalizzati per aggirare le tue policy o effettuare DNS tunnelling. Successivamente, e in modo più ovvio, le **Porte 80 e 443 per HTTP e HTTPS**. Questa è la spina dorsale di tutta la navigazione web. Quando un ospite si connette per la prima volta, la sua richiesta web iniziale è ciò che viene intercettato dal controller di rete e reindirizzato al tuo Captive Portal Purple. Senza l'accesso a queste porte, l'intero percorso dell'ospite fallisce prima ancora di iniziare. Per un'implementazione Purple di successo, devi anche assicurarti che la rete guest possa comunicare con i servizi cloud Purple e potenzialmente con il tuo controller WiFi on-premise. Ciò comporta in genere l'abilitazione del traffico in uscita sulle **Porte 8080 and 8443** per la gestione del controller e le statistiche. Infine, ci sono un paio di servizi di rete fondamentali. Le **Porte 67 e 68 per il DHCP**, che è il modo in cui ai dispositivi guest viene assegnato automaticamente un indirizzo IP. E la **Porta 123 per l'NTP**, o Network Time Protocol, che è fondamentale per mantenere accurati i timestamp dei dispositivi e dei log, un aspetto prezioso durante qualsiasi indagine di sicurezza. E per quanto riguarda le regole in entrata? Per la rete guest, la risposta è semplice: non consentirne nessuna. Non esiste alcun motivo legittimo per cui un dispositivo sull'internet pubblico debba avviare una connessione *verso* la tua rete guest. L'unica eccezione è se ospiti il tuo controller WiFi o il Captive Portal on-premise. In questo scenario specifico, dovresti creare una regola di Port Forwarding altamente restrittiva, nota anche come regola di Destination NAT, per indirizzare il traffico esterno all'indirizzo IP interno specifico del portale. Per configurazioni più avanzate che utilizzano l'autenticazione di livello enterprise, potresti anche aver bisogno di regole in entrata per **RADIUS sulle porte UDP 1812 e 1813**. Ricorda, la regola predefinita in fondo alla tua policy del firewall dovrebbe essere: **Deny All**. Se il traffico non corrisponde a una di queste regole specifiche di 'allow', viene scartato. **(Musica di transizione - breve, discreta)** **Host:** Ora parliamo di implementazione e di errori comuni. Queste raccomandazioni sono indipendenti dal fornitore. In primo luogo, utilizza sempre un firewall stateful. Un firewall stateful tiene traccia dello stato delle connessioni e consente automaticamente il traffico di ritorno per le sessioni stabilite, semplificando il set di regole. In secondo luogo, abilita l'isolamento dei client ('Client Isolation') sui tuoi access point wireless. Questa è una funzionalità fondamentale che impedisce ai dispositivi sulla stessa rete WiFi di comunicare tra loro. E in terzo luogo, pianifica verifiche periodiche delle regole del tuo firewall. Le regole inutilizzate o eccessivamente permissive rappresentano un debito di sicurezza che devi estinguere. Vediamo continuamente errori comuni. Il peccato originale è la regola 'allow any-to-any', spesso inserita temporaneamente per i test e poi dimenticata. È una porta spalancata per gli aggressori. Un altro errore è dimenticarsi dell'IPv6; assicurati che le regole del firewall si applicino sia al traffico IPv4 che a quello IPv6. E infine, non limitarti a configurare le regole per poi disinteressartene. I log del firewall sono il tuo sistema di allerta precoce. Monitorali per individuare pattern insoliti o connessioni negate ripetute. Lascia che ti faccia un rapido esempio reale. Abbiamo lavorato con una grande catena alberghiera che riceveva frequenti reclami dagli ospiti per via di un WiFi lento. Le regole del loro firewall erano troppo permissive, il che consentiva a tempeste di broadcast provenienti da dispositivi guest configurati male di inondare la rete. Implementando un rigoroso isolamento delle VLAN e le regole in uscita essenziali di cui abbiamo appena parlato, non solo hanno protetto la loro rete aziendale, ma hanno anche aumentato la velocità di trasmissione del WiFi guest di oltre il 30% e ridotto drasticamente le chiamate di supporto relative alla rete. **(Musica di transizione - breve, discreta)** **Host:** Passiamo a una sessione di domande e risposte rapide. Mi vengono poste continuamente. *Prima domanda: dovrei bloccare le VPN sulla rete guest?* Questa è una decisione di policy. Bloccarle offre maggiore visibilità sul traffico, ma può frustrare i viaggiatori d'affari che hanno bisogno di una VPN per lavoro. Un approccio equilibrato consiste nel consentirle, assicurandosi però che le altre regole siano restrittive. *Seconda: che dire dei dispositivi IoT come smart TV o altoparlanti sulla rete guest?* Trattali come altamente non attendibili. Idealmente, posizionali su una terza VLAN ancora più limitata, con regole del firewall che consentano solo la comunicazione con i loro server di gestione cloud specifici e nient'altro. *E terza: come si collega questo alla conformità PCI DSS per i nostri punti vendita?* Il PCI DSS impone la separazione completa e verificabile del Cardholder Data Environment. Una rete guest correttamente configurata e isolata, protetta da firewall rispetto alla VLAN utilizzata dai terminali di pagamento, è un controllo fondamentale e non negoziabile per la conformità. **(Musica di transizione - breve, discreta)** **Host:** Quindi, per riassumere. La sicurezza dell'intera rete aziendale dipende da come configuri il perimetro attorno al tuo WiFi guest. I principi fondamentali sono: **Isolare** il traffico guest sulla propria VLAN. **Applicare** una policy di 'default deny', consentendo solo le porte essenziali per la navigazione web, il DNS e i servizi Purple. **Prevenire** tutto il traffico in entrata e i movimenti laterali. E infine, **Verificare** le regole e monitorare i log continuamente. Seguendo queste indicazioni, potrai offrire un servizio prezioso ai tuoi visitatori proteggendo al contempo le risorse aziendali critiche, garantendo la conformità e offrendo un'esperienza utente superiore. Per una guida dettagliata di riferimento delle porte e per i diagrammi di rete, visita la guida tecnica di riferimento sul nostro sito web che accompagna questo briefing. **(Musica di chiusura - Vivace, professionale, sfuma in entrata)** **Host:** Grazie per aver partecipato a questo Purple Technical Briefing. Alla prossima. **(La musica sfuma)**