Comprendere e configurare in sicurezza le regole Sophos Firewall

Le regole del firewall sono il cuore dello Sophos Firewall. Queste regole determinano quale traffico tra zone, reti, utenti e servizi è consentito o bloccato e quali funzioni di protezione vengono applicate.

Questo articolo spiega una regola Sophos Firewall dall’alto al basso: Ordine, Gruppi, Azione, Registrazione, Origine, Destinazione, Services, Corrispondenza utente, Esclusioni, NAT, Filtro Web, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR e scansione e-mail.

Il percorso del menu è:

Rules and policies > Regole firewall > Aggiungi regola firewall > Nuova regola firewall

La maschera delle regole è divisa in diverse aree: area di intestazione, origine, destinazione, Services, riferimento utente, collegamento NAT e funzionalità di sicurezza. In pratica, è importante non vedere la maschera come un insieme di singoli agganci. Una regola funziona correttamente solo se la sorgente, la destinazione, il servizio, la sequenza, il logging e le funzioni di protezione attivate coincidono.

Prima di crearla, dovrebbe anche essere chiaro se si tratta di una regola IPv4 o IPv6. La visualizzazione delle regole viene selezionata di conseguenza nello WebAdmin. Negli ambienti dual-stack, IPv4 e IPv6 devono essere intenzionalmente pianificati e testati separatamente; una regola IPv4 funzionante non dimostra automaticamente che IPv6 sia ugualmente protetto.

Navigazione rapida

• Quali regole firewall controllano e cosa no
• Principio di base e sequenza
• Pianificare la base di regole prima della creazione
• Tipi di regole separate in modo pulito
• Esempio pratico fittizio
• Area intestazione: Stato, Nome, Azione e Registrazione
• Origine, zona e pianificazione
• Destinazione e servizi
• Match known users
• Aggiungi esclusione
• Create linked NAT rule
• Filtro web
• Battito cardiaco Synchronized Security
• Altre funzionalità di sicurezza
• Scansione contenuto e-mail
• Controlla dopo il salvataggio
• Funzionamento regolare e revisione
• Nuova regola, modificare o disattivare la regola esistente?
• Errori tipici
• Domande frequenti

Quale articolo sulla politica di rete è adatto?

Regole firewall, NAT, WAF, VLAN e routing sono strettamente intrecciati nello Sophos Firewall. È quindi importante che gli amministratori scelgano prima l’argomento giusto:

• Comprendere le regole del firewall da zero: Questo articolo.
• Classificare NAT, SNAT, DNAT, MASQ o PAT: Comprensione di NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT
• Pubblica il server interno tramite port forwarding: Pubblica server tramite DNAT su Sophos Firewall
• Protezione di un’applicazione Web pubblica: Sophos Firewall Configurazione e organizzazione del WAF
• La regola non si applica o appare Rule ID errato: Sophos Firewall La regola non si applica: verificare le cause
• Prova la regola specificatamente: Testare la regola firewall con Log Viewer, Policy Test e Packet Capture
• WebAdmin, VPN Portal, User Portal, SSH, DNS sicuro o SNMP del firewall: Sophos Firewall Protezione dell’accesso: configurare correttamente Device Access
• Pianificare zone, interfacce o VLAN: Sophos Firewall Configura zone e interfacce
• Gestisci il bridge con i tag VLAN: Utilizza il bridge Sophos Firewall con il tagging VLAN
• Controlla l’ordine di instradamento o i percorsi SD-WAN: Sophos Firewall Regola priorità instradamento
• I pacchetti di risposta o il traffico di sistema passano attraverso il percorso sbagliato: SD-WAN Routing per pacchetti di risposta e traffico di sistema

Questa separazione impedisce la tipica risoluzione dei problemi. Una regola NAT non consente il traffico, una regola firewall non traduce un indirizzo e una regola WAF non è la stessa cosa del normale port forwarding DNAT.

Quali regole firewall controllano e cosa no

Le regole del firewall controllano il traffico che scorre attraverso il firewall. Ma queste regole non sono l’unico punto di controllo in SFOS. Gran parte della risoluzione dei problemi avviene perché si cerca un comportamento nell’elenco delle regole del firewall, anche se è responsabile un’altra area.

• Traffico tra zone, reti, utenti e servizi: Regole del firewall. Qui si decide se il traffico di transito è consentito, rifiutato o controllato con caratteristiche di sicurezza.
• WebAdmin, User Portal, VPN Portal, SSH, DNS o SNMP al firewall stesso: Device Access e Local Service ACL. I servizi firewall locali non vengono trattati come il normale traffico da LAN a WAN o da WAN a DMZ.
• Traduzione dell’indirizzo o del porto: Regole NAT. NAT traduce il traffico ma non lo consente automaticamente.
• Selezione percorso, percorso di ritorno, percorsi SD-WAN e VPN: Routing, configurazione SD-WAN, Route Precedence e VPN. Una regola firewall adeguata non dimostra un modo efficace per tornare indietro.
• Categorie Web, gruppi URL e policy Web: Filtraggio Web e Politica Web. La regola del firewall integra la policy, ma la vera logica web risiede nella policy web.
• Decrittografia HTTPS: Regole di ispezione SSL/TLS e distribuzione CA. Scan HTTP and decrypted HTTPS esegue la scansione solo del traffico già decrittografato.
• Identità utente: Autenticazione, STAS, Captive Portal, Entra ID SSO o RADIUS. Una regola utente corrisponde solo se il firewall può assegnare l’utente al traffico.

Per i servizi di gestione e portale, Device Access e Local Service ACL è l’articolo centrale. Se una regola corrisponde ma la connessione non riesce ancora, La regola Sophos Firewall non funziona: controlla le cause e Verifica la regola firewall con Log Viewer, Policy Test e Packet Capture saranno utili. Soprattutto nelle reti miste IPv4/IPv6 è opportuno verificare anche se un’applicazione tramite IPv6 aggira una regola IPv4 più severa. Se IPv6 non viene utilizzato attivamente, la strategia IPv6 dovrebbe comunque essere documentata consapevolmente: disattivarla, bloccarla, regolamentarla adeguatamente o introdurla in modo controllato.

Principio e sequenza di base

Le regole del firewall controllano il traffico tra zone e reti. Le regole consentono, rifiutano o bloccano il traffico e possono applicare funzionalità di sicurezza aggiuntive.

Sophos Firewall controlla le regole del firewall dall’alto al basso. Non appena una regola corrisponde, le successive regole firewall non vengono più controllate. Ciò che è importante non è solo cosa c’è in una regola, ma anche dove si trova nell’elenco delle regole.

Una regola è valida solo se tutti i criteri rilevanti si applicano contemporaneamente:

• Zona di origine: Sì. LAN.
• Source networks and devices: Sì. net_LAN_Clients.
• Programma: Sì. All the time.
• Zona di destinazione: Sì. WAN.
• Destination networks: Sì. Any o un host FQDN.
• Services: Sì. HTTP, HTTPS, DNS.
• Corrispondenza utente: Solo se attivato. AD gruppo Internet-Users.
• Esclusioni: Se impostata, la regola può essere saltata. Escludi server di backup.

Vince la prima regola corrispondente. Se una regola generale LAN_to_WAN_Any è superiore a una regola LAN_to_WAN_Restricted specifica, la regola specifica non verrà mai raggiunta.

Pianifica la base di regole prima di crearla

È possibile creare rapidamente una singola regola firewall. Ciò che è più difficile è una base di regole che sia ancora comprensibile, verificabile e sicura dopo due anni. Pertanto, prima di introdurre nuove regole, è opportuno chiarire a quale zona di sicurezza, gruppo e logica di funzionamento appartiene la regola.

Domande guida utili:

• Che tipo di traffico dovrebbe essere realmente consentito?: Annotare origine, destinazione e Services prima di creare.
• Il traffico appartiene alla propria zona?: Separa consapevolmente server, client, ospiti, gestione, VPN e DMZ.
• Esiste già una regola specifica?: Controlla le regole esistenti invece di creare una seconda regola simile.
• NAT è coinvolto?: Pianifica insieme le regole firewall e le regole NAT, ma non confonderle.
• Come verrà controllato in seguito?: Attiva la registrazione e definisci traffico di prova specifico.
• Il rilascio è temporaneo?: Documentare la data di scadenza o il biglietto nella descrizione.

Per zone e interfacce pulite, Sophos Firewall Configura zone e interfacce si adatta per primo. Se una regola esistente non funziona, la lista di controllo Sophos Firewall La regola non funziona: controlla le cause sarà di aiuto.

⚠️ Un righello Any largo è spesso conveniente, ma raramente rappresenta una buona configurazione finale. Può aiutare a breve termine per i test. Dovrebbe quindi essere sostituito o rimosso nuovamente da fonti, destinazioni e servizi specifici.

Tipi di regole separati in modo chiaro

Una buona base di regole separa visibilmente i diversi rischi l’uno dall’altro. L’errore più comune non è una singola opzione errata, ma una regola generale che copre contemporaneamente client, server, VPN, ospiti e gestione. Funziona rapidamente all’inizio, ma in seguito diventa difficile da testare e difficile da rafforzare.

• Cliente Internet: Fonte tipica: Reti clienti; Obiettivo tipico: WAN; A cosa prestare attenzione?: Criteri Web, Application Control, IPS, TLS Inspection, QUIC, Registrazione.
• ServerInternet: Fonte tipica: Reti di server; Obiettivo tipico: obiettivi di aggiornamento, backup o cloud definiti; A cosa prestare attenzione?: più rigide delle regole del client, spesso senza riferimento all’utente.
• Ospite-WLAN: Fonte tipica: Zona ospiti; Obiettivo tipico: WAN; A cosa prestare attenzione?: nessun controllo consapevole degli obiettivi interni, della larghezza di banda e del DNS.
• Gestione: Fonte tipica: Reti di amministrazione; Obiettivo tipico: Firewall, server, switch, hypervisor; A cosa prestare attenzione?: non mescolarsi con le normali regole del client.
• VPN Accesso remoto: Fonte tipica: VPN o propria zona di accesso remoto; Obiettivo tipico: zone target interne; A cosa prestare attenzione?: solo obiettivi e servizi richiesti, accedendo alla fase introduttiva.
• Da sito a sito: Fonte tipica: zone VPN locali e remote o zone XFRM; Obiettivo tipico: Reti di partner o di localizzazione; A cosa prestare attenzione?: Controlla insieme routing, NAT, percorso di ritorno e registrazione.
• Sistema pubblicato: Fonte tipica: WAN o fonti definite; Obiettivo tipico: DMZ o zona server; A cosa prestare attenzione?: DNAT/WAF, IPS, logging, livello di patch e limitazione della sorgente.
• Accesso temporaneo: Fonte tipica: supporto definito o fonte del progetto; Obiettivo tipico: bersaglio ristretto; A cosa prestare attenzione?: Documento biglietto, data di scadenza, proprietario e smantellamento.

Se due connessioni hanno proprietari, funzioni di protezione o cicli di revisione diversi, le regole separate sono generalmente più pulite. Se per lo stesso scopo professionale è necessaria solo una prestazione aggiuntiva, è possibile ampliare una regola esistente.

Esempio pratico fittizio

Ad esempio, viene creata una regola client pulita:

Obiettivo: i client dallo LAN interno possono accedere a Internet. Il filtro Web, Application Control, IPS e la registrazione dovrebbero essere attivi. Server, ospiti e reti di gestione hanno le proprie regole e non sono mescolati con questa regola del client.

• Nome della regola: LAN_to_WAN_Clients. Cancella nome con origine e destinazione.
• Descrizione: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Più tardi saprai perché esiste la regola.
• Rule position: In base a specifiche regole di blocco e server. Prima dovrebbero entrare in vigore norme specifiche.
• Rule group: Internet Access. Migliore panoramica.
• Azione: Accept. Il traffico è consentito.
• Registra il traffico del firewall: Abilitato. Risoluzione dei problemi di Log Viewer.
• Source zones: LAN. Il traffico proviene dalla zona LAN.
• Source networks and devices: net_LAN_Clients. Non tutte le reti LAN, solo i client.
• Durante l’orario previsto: All the time. L’accesso a Internet dovrebbe essere permanente.
• Destination zones: WAN. L’obiettivo è Internet.
• Destination networks: Any. Per lo più pratico per client Internet.
• Services: HTTP, HTTPS, DNS, NTP. Solo servizi di base richiesti.
• Web policy: Default Workplace Policy. Controllare l’accesso al web in base alle categorie.
• Block QUIC protocol: Abilitato. Il filtraggio e la scansione web rimangono efficaci.
• IPS: Politica del cliente. Protezione dagli exploit per il traffico client in uscita.
• Controllo dell’app: Politica dell’applicazione client. Blocca le app indesiderate.
• Formare il traffico: Facoltativo. Solo se è necessaria la larghezza di banda.
• DSCP marking: Vuoto. Necessario solo se i dispositivi downstream valutano DSCP.

Questo esempio non è deliberatamente un biglietto gratuito Any. In pratica le reti client, le reti server, le reti ospiti, VoIP e il management andrebbero considerate separatamente. Per il primo test produttivo, questo esempio dovrebbe includere un breve test case: client definito, indirizzo di destinazione specifico, Rule ID previsto, NAT Rule ID previsto e uno sguardo a Log Viewer o Central/Syslog. Senza questo passaggio di approvazione non è chiaro se la regola elabori effettivamente la connessione prevista.

Area di intestazione: Stato, Nome, Azione e Registrazione

Stato della regola

Stato regola attiva o disattiva la regola.

Di solito è attiva una nuova regola. Per le regole predisposte è possibile disattivare lo stato e attivare la regola solo in un secondo momento. Le regole disattivate dovrebbero essere controllate regolarmente in modo che nella configurazione non rimangano vecchie regole di test o di migrazione.

Esempio pratico: viene preparata una nuova regola per un server, ma viene attivata solo nella finestra di manutenzione.

Nome della regola

Il nome dovrebbe chiarire immediatamente cosa fa la regola.

Bei nomi:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Nomi come Rule1, Test, Allow o Internet sono meno utili perché non è più possibile stabilire quale compito abbia la regola.

Descrizione

La descrizione è importante per le operazioni, il supporto e gli audit. Dovrebbe dire:

• perché esiste la norma
• che ha richiesto la norma
• quali restrizioni sono state deliberatamente fissate
• se esiste un ticket, un progetto o una data di scadenza

Esempio:

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

Come utilizzare correttamente questo campo e documentare le regole del firewall in modo comprensibile è descritto più dettagliatamente nell’articolo Sophos Firewall documentare in modo sensato le regole.

Rule position

Rule position specifica dove verrà inserita la nuova regola.

• Top: Solo per regole molto specifiche, regole di blocco o test.
• Bottom: Spesso utile per nuove regole standard.
• Above rule: Se una regola deve specificamente entrare in vigore prima di una regola esistente.
• Below rule: Se una regola deve seguire specificamente una regola esistente.

Regola fondamentale: specifico prima che generale. Una regola per un singolo server o un’applicazione specifica è solitamente più in alto rispetto a una regola generale di Internet.

Rule group

Rule group è un raggruppamento organizzativo. Il gruppo in sé non costituisce un confine di sicurezza o un proprio motore di policy. Il firewall continua a controllare ogni regola dall’alto verso il basso.

Esempi di gruppi utili includono:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

In ambienti piccoli None potrebbe essere sufficiente. Negli ambienti più grandi vale la pena raggruppare in modo chiaro fin dall’inizio, altrimenti la base delle regole diventa rapidamente confusa.

Azione

L’Azione determina cosa accade al traffico corrispondente.

• Accept: Il traffico è consentito. Regole di autorizzazione normali.
• Drop: Il traffico viene silenziosamente scartato. Regole di blocco in base alle quali il client non deve ricevere una risposta.
• Reject: Il traffico viene rifiutato e il client riceve una risposta. Risoluzione dei problemi o regole di blocco interne.
• Protect with web server protection: Viene applicata la protezione WAF. Protezione del server Web, non per le normali regole da LAN a WAN.

Per le normali regole client o server di solito si utilizza Accept. Per le regole di blocco, Drop è più silenzioso, Reject è spesso più piacevole per la risoluzione dei problemi.

Registra il traffico del firewall

Registra il traffico del firewall dovrebbe quasi sempre essere attivato per regole importanti.

Senza la registrazione, informazioni importanti mancheranno successivamente nel Visualizzatore registro. Molti casi di risoluzione dei problemi falliscono non a causa della regola stessa, ma perché non è stata effettuata alcuna registrazione e non è possibile vedere quale regola effettivamente applicata.

Importante: il firewall in genere registra le sessioni del firewall quando una connessione viene terminata e si verifica un evento Destroy. Non tutte le connessioni vengono visualizzate nel momento esatto in cui il client le avvia.

Affinché i registri siano visibili localmente, in Sophos Central o tramite Syslog, anche System services > Log settings deve essere configurato opportunamente. Per un’archiviazione più lunga, è opportuno utilizzare Sophos Central Firewall Reporting o un server Syslog. Ulteriori informazioni: Abilita reporting del firewall centrale e Invia Sophos Firewall Syslog in modo sicuro a SIEM.

Per le regole produttive, la registrazione non dovrebbe essere vista solo come un modo per risolvere i problemi. È anche la base per le revisioni: la regola è ancora utilizzata, a quali fonti si applica, quali obiettivi sono realmente perseguiti e se una regola è troppo ampia.

Sorgente, Zona e Programmazione

Nell’area Sorgente definisci da dove proviene il traffico.

Source zones

Source zones è la zona da cui proviene il traffico.

Esempi:

• LAN per reti client interne
• VPN per utenti con accesso remoto
• DMZ per reti server
• Guest per gli ospiti-WLAN
• WAN per il traffico Internet in entrata

Esempio pratico: LAN viene selezionato per una regola Internet dai client a Internet. Per una regola DNAT da un server esterno a un server interno, WAN viene solitamente utilizzata come zona di origine nella regola firewall associata.

Source networks and devices

Source networks and devices restringe la fonte in modo più preciso.

Possibili oggetti sono ad esempio:

• host individuali
• Reti
• Intervalli IP
• Gruppi ospitanti
• Host FQDN
• Oggetti di campagna

Per cominciare, Any sembra comodo, ma spesso è troppo largo. È preferibile una rete client specifica, un gruppo host o un oggetto di rete con un nome chiaro.

Esempio pratico: invece di Any nel sorgente, utilizzare net_LAN_Clients. Server, stampanti, ospiti e dispositivi di gestione hanno le proprie regole.

Durante l’orario programmato

Durante l’orario programmato determina quando si applica la regola.

Valori tipici:

• All the time
• Orario di lavoro
• Finestra di manutenzione
• rilasci temporanei

Gli orari sono utili se l’accesso deve essere consentito solo in determinati orari. Durante la risoluzione dei problemi è necessario verificare sempre se l’ora del firewall, il fuso orario e la pianificazione sono realmente corretti.

Esempio pratico: l’accesso di manutenzione esterno a un server è consentito solo durante una finestra di manutenzione definita.

Destinazione e servizi

Nell’area Destinazioni e servizi definisci dove è consentito il traffico e quali porte o protocolli sono consentiti.

Destination zones

Destination zones è la zona target.

Esempi:

• WAN per l’accesso a Internet
• DMZ per server in DMZ
• LAN per target interni
• VPN per utenti remoti o percorsi da sito a sito

Esempio pratico: WAN viene utilizzato per il traffico Internet del client. Server o DMZ possono essere utilizzati per consentire ai client di accedere a un server interno se queste zone vengono create di conseguenza.

Destination networks

Destination networks restringe il campo di destinazione in modo più preciso. Per le regole Internet del client, Any è spesso un buon inizio. Per server, reti di gestione o accesso VPN, gli obiettivi dovrebbero essere limitati in modo significativo.

Esempi:

• Any per l’accesso generale a Internet
• Host FQDN come updates.vendor.com
• Oggetto host di un server interno
• Oggetto di rete di una stazione remota tramite VPN
• Oggetto Paese per le regole Geo-IP

Esempio pratico: un server di backup può raggiungere solo le destinazioni di backup cloud del produttore e non Any.

Services

Services sono le definizioni di protocollo e porta.

Esempi:

• HTTP per TCP 80
• HTTPS per TCP 443
• DNS per TCP/UDP 53
• NTP per UDP 123
• possedere Services come Synology_5555

Services dovrebbe essere scelto nel modo più ristretto possibile. Any ha senso solo se tutti i protocolli devono essere realmente consentiti o se si lavora consapevolmente con altri controlli.

Esempio pratico: per i normali client web spesso è sufficiente un gruppo con HTTP, HTTPS, DNS e NTP. L’accesso al server da Internet è consentito solo per il servizio effettivamente pubblicato.

Match known users

Con Match known users, l’identità dell’utente diventa parte della corrispondenza. La regola quindi non vale più solo per gli indirizzi IP, ma anche per utenti o gruppi conosciuti.

Ciò ha senso se:

• Le policy Web devono essere applicate al gruppo AD
• Il reporting dovrebbe essere relativo all’utente
• Gruppi di utenti diversi ottengono diritti Internet diversi
• MFA, Captive Portal o SSO sono già configurati correttamente

Ostacolo: se l’autenticazione non funziona correttamente, la regola potrebbe non corrispondere. Quindi il traffico passa a una regola più generale di seguito o viene eliminato dalla regola drop-all.

Per i test iniziali, spesso è meglio iniziare senza la corrispondenza degli utenti e aggiungere i criteri degli utenti in un secondo momento.

Se viene utilizzata la corrispondenza degli utenti, non dovrebbe esserci una regola di fallback ampia che consenta lo stesso traffico senza riferimento all’utente. Altrimenti la regola utente appare pulita, ma gli utenti sconosciuti finiscono comunque con la regola generale. Una volta accettato, Log Viewer dovrebbe quindi mostrare l’utente, il gruppo e Rule ID.

Aggiungi esclusione

Con Aggiungi esclusione il traffico può essere escluso da una regola. Il firewall salta questa regola solo se tutti i criteri di esclusione impostati corrispondono e quindi controlla la regola successiva.

Le esclusioni possono includere Source zones, Source networks and devices, Destination zones, Destination networks e Services.

Esempio pratico: una regola Internet generale del client utilizza filtri web. Tuttavia, un server di aggiornamento specifico dovrebbe eseguire la propria regola con altre funzionalità di sicurezza. Quindi puoi escludere questo server dalla regola generale.

Le esclusioni sono potenti, ma rendono le regole più difficili da leggere. Se una regola contiene molte eccezioni, una regola specifica separata è spesso più comprensibile.

Create linked NAT rule

Con Create linked NAT rule è possibile creare una regola NAT di origine direttamente dalla regola firewall. Questa regola NAT collegata verrà quindi visualizzata nella tabella delle regole NAT.

Questo sembra conveniente per i principianti, ma in pratica le regole NAT indipendenti sono generalmente più chiare. Se una regola NAT generica copre già lo stesso traffico, non dovresti creare un’ulteriore regola NAT collegata.

Per una normale regola da client a Internet, la regola SNAT predefinita con MASQ è solitamente sufficiente, purché sia ​​attiva e si adatti correttamente alla rule base. Importante: NAT non consente il traffico da solo. NAT traduce indirizzi o porte. La regola firewall appropriata decide comunque se il traffico è consentito.

Maggiori informazioni su questo argomento: Comprensione di NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Filtraggio web

Nell’area Filtro web vengono configurati i criteri web, la scansione malware e il comportamento del filtro web.

Web policy

Web policy controlla l’accesso al web tramite categorie, utenti, gruppi, gruppi URL e regole.

Esempio pratico: per i client viene utilizzata una policy web che blocca malware, phishing, contenuti per adulti e categorie rischiose, ma consente le applicazioni aziendali.

Se non viene impostata alcuna policy web, il filtraggio web basato sulla categoria non verrà eseguito tramite questa opzione.

Come pianificare insieme categorie, gruppi URL, policy Web e avvisi istantanei è descritto in Sophos Firewall Utilizzo di categorie Web e avvisi istantanei.

Applica il modellamento del traffico basato sulle categorie web

Questa opzione applica la modellazione del traffico in base alle categorie web. Ha senso solo se vengono utilizzate regole di modellazione del traffico o politiche di categoria web appropriate.

Esempio pratico: le categorie di streaming sono limitate, le applicazioni aziendali restano preferite.

Block QUIC protocol

QUIC utilizza UDP 80 e UDP 443. Molti browser utilizzano QUIC per i servizi Google e altre applicazioni web moderne.

Se il filtraggio web o la scansione malware per il traffico web sono importanti, Block QUIC protocol dovrebbe essere lasciato abilitato in molti ambienti. I browser quindi di solito tornano al normale HTTPS su TCP, che è più facile da controllare e verificare.

Maggiori informazioni: Sophos Firewall Blocca QUIC e HTTP/3 correttamente.

Scan HTTP and decrypted HTTPS

Questa opzione esegue la scansione di HTTP e HTTPS già decrittografati alla ricerca di malware.

Importante: questa opzione non decrittografa automaticamente HTTPS. Affinché HTTPS possa essere effettivamente controllato, sono necessarie regole di ispezione SSL/TLS appropriate in Rules and policies > Regole di ispezione SSL/TLS.

Esempio pratico: se TLS Inspection è attivo per LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS può controllare i file scaricati nel traffico HTTPS decrittografato.

Maggiori informazioni: Distribuzione graduale da TLS Inspection a Sophos Firewall.

Utilizza la protezione zero-day

Utilizza protezione zero-day invia download sospetti a Sophos Zero-Day Protection per ulteriori analisi. Ciò è utile per le regole client e server che desiderano controllare i download da Internet.

La funzione richiede una licenza adeguata e può causare ritardi a seconda del tipo di file e della policy.

Scansiona l’FTP alla ricerca di malware

Questa opzione esegue la scansione del traffico FTP alla ricerca di malware. È rilevante solo se viene effettivamente utilizzato FTP e la corrispondenza Services è generalmente consentita.

FTP è diventato meno comune negli ambienti moderni, ma è ancora presente nei sistemi legacy, nei controlli delle macchine o nei meccanismi di aggiornamento più vecchi.

Utilizza proxy web invece di DPI engine

Sophos Firewall può controllare il traffico web tramite DPI engine o tramite proxy web.

Per le configurazioni moderne, DPI è solitamente la scelta predefinita migliore perché può gestire il traffico HTTP e SSL/TLS su tutte le porte. Il proxy web è comunque utile se sono necessarie funzioni proxy speciali, ad esempio l’applicazione SafeSearch, le restrizioni di YouTube, le restrizioni del dominio delle app Google, la protezione pharming, la cache web o il proxy principale.

Se Utilizza proxy web invece di DPI engine non è abilitato, la regola funziona in modalità DPI.

Decrittografa HTTPS durante il filtraggio del proxy web

Questa opzione appartiene alla modalità proxy web. È rilevante solo se Utilizza proxy web invece di DPI engine è attivato e HTTPS deve essere decrittografato in modalità proxy.

In modalità DPI, la decrittografia HTTPS non viene controllata qui, ma piuttosto tramite regole di ispezione SSL/TLS.

Synchronized Security Battito cardiaco

Con Configura Synchronized Security Heartbeat lo stato Sophos Endpoint può essere incluso nella regola del firewall.

Opzioni tipiche:

• Imposta lo stato minimo per i dispositivi sorgente
• Blocca i client senza battito cardiaco
• Imposta lo stato minimo per i dispositivi di destinazione
• Blocca le richieste verso destinazioni senza battito cardiaco

Questo è forte, ma ha senso solo se Sophos Endpoint, Sophos Central e Security Heartbeat sono impostati correttamente.

Esempio pratico: i client con Security Heartbeat rosso non possono più accedere ai server o non hanno più accesso a Internet.

Per una prima regola client, non dovresti attivare l’heartbeat alla cieca, altrimenti potresti bloccare i dispositivi che non possono affatto inviare un heartbeat.

Altre funzionalità di sicurezza

Identificare e controllare le applicazioni (controllo app)

Un criterio di filtro delle applicazioni viene selezionato tramite Identifica e controlla le applicazioni (controllo app).

Ciò consente di riconoscere e controllare le applicazioni, ad esempio:

• Visualizzatore della squadra
• Cancello
• Messaggeri
• Trasmissione in streaming
• Archiviazione nel cloud
• Strumenti di controllo remoto

Application Control richiede una licenza adeguata. In pratica, questa funzionalità è inclusa nei bundle Sophos Firewall con Web Protection, ad esempio Standard Protection, Xstream Protection o Epic Protection.

TLS Inspection è spesso fondamentale per il rilevamento delle applicazioni nel traffico crittografato. Senza decrittografia, a seconda del servizio, il firewall vede solo nomi host, SNI, informazioni sui certificati o IP e non il contenuto completo.

Il processo personalizzato per filtri, associazione di regole, registri e controllo dei falsi positivi è disponibile in Sophos Firewall Configurazione e test Application Control.

Apply application-based traffic shaping policy

Questa opzione applica il modellamento del traffico definito nella policy dell’applicazione o nell’oggetto dell’applicazione.

Esempio pratico: Microsoft Teams dovrebbe essere riconosciuto e prioritario con una specifica policy di traffic shaping. Successivamente è necessario selezionare la policy Application Control appropriata e applicare la policy di modellazione del traffico basata sull’applicazione.

Se hai già impostato una policy di modellazione del traffico esplicita nel campo Shape traffic, dovrebbe essere chiaramente documentato quale policy dovrebbe avere la precedenza e perché.

Rileva e previeni gli exploit (IPS)

Una policy IPS viene selezionata in Rileva e previeni exploit (IPS).

IPS controlla il traffico per individuare modelli di attacco ed exploit noti. Per il traffico client su Internet viene utilizzata una policy diversa rispetto a quella utilizzata per il traffico server o i servizi pubblicati.

Esempi pratici:

• Regola client LAN_to_WAN: politica IPS client o da LAN a WAN
• Regola DNAT per server web: criterio IPS del server o del web server
• Regola VoIP: testare attentamente perché i profili IPS aggressivi possono interrompere il VoIP

L’IPS non dovrebbe essere attivato ovunque con la politica più dura. Una policy IPS troppo ampia o errata può interrompere il traffico legittimo o creare un carico non necessario.

L’articolo dedicato Sophos Firewall Configura IPS e testalo in sicurezza spiega in modo più dettagliato l’attivazione globale, lo stato della licenza, la selezione delle policy, la registrazione e l’analisi dei falsi positivi.

Dai forma al traffico

Con Shape traffic è possibile applicare una policy di modellazione del traffico direttamente alla regola. Ciò è rilevante per:

• VoIP
• Incontri on-line
• Traffico di backup
• Ospite WLAN
• percorsi lenti WAN

Esempio pratico: l’ospite WLAN riceve una politica sui limiti in modo da non escludere il traffico aziendale.

Ulteriori informazioni: Configurare Application Traffic Shaping su Sophos Firewall.

DSCP marking

DSCP marking contrassegna i pacchetti per la qualità del servizio sui dispositivi di rete downstream.

Ciò ha senso solo se anche switch, router o dispositivi WAN valutano questi valori DSCP. Lo Sophos Firewall può marcare, ma il resto della rete deve trattare questi segni in modo coerente.

Esempio pratico: il traffico VoIP riceve un contrassegno DSCP in modo che gli switch e i router WAN trattino questo traffico in modo preferenziale.

Scansione con NDR Intelligence attiva sulle minacce

Scansione con NDR Intelligence sulle minacce attiva utilizza Sophos NDR Threat Intelligence per valutare ulteriormente il traffico di rete.

Questa opzione è utile solo se l’ambiente utilizza i componenti Sophos Central e NDR richiesti. In molti ambienti non è la prima opzione come regola di base, ma può rappresentare un’aggiunta preziosa nelle reti più altamente monitorate.

Scansione del contenuto dell’e-mail

L’area Scansiona contenuto email riguarda i protocolli email.

Opzioni possibili:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Se si attivano i protocolli lì, le porte standard appropriate devono essere incluse anche nel Services della regola o aggiunte tramite Aggiungi porte.

Quest’area spesso non è rilevante per le normali regole del client web. Dovresti pianificarlo consapevolmente per i server di posta o il traffico di posta dei client.

Esempio pratico: un server di posta interno può inviare SMTP all’esterno. Viene quindi creata una regola server separata, viene attivata la registrazione e viene verificata la scansione della posta elettronica per corrispondere all’architettura della posta.

Controlla dopo aver salvato

Dopo aver salvato, dovresti testare la regola e non dare per scontato che tutto funzioni correttamente.

Per verificare:

1. La regola è nella posizione corretta?
2. Registra traffico firewall è attivo?
3. Quando le regole sono cambiate, il contatore delle visite è stato azzerato o è stato creato un nuovo test chiaro?
4. La regola corrisponde nel Visualizzatore registro?
5. Viene visualizzato il firewall Rule ID previsto?
6. Si applica la regola NAT desiderata?
7. Il DNS funziona?
8. I filtri web, IPS, Application Control e TLS Inspection sono applicati come previsto?
9. Si verificano cali imprevisti o errori SSL/TLS?

L’articolo Test della regola firewall con Log Viewer, Policy Test e Packet Capture aiuta a effettuare un controllo pulito.

Quando si apportano modifiche produttive, è opportuno un piccolo confronto prima e dopo:

• Esiste un punto di backup o ripristino: Lo smantellamento resta possibile se la norma produce effetti collaterali.
• Traccia di controllo o modifica del biglietto annotato: in seguito sarà chiaro chi ha effettuato la modifica e quando.
• Caso di test definito in anticipo: Il successo non si giudica solo dal sentimento.
• Un solo cambio per test: Causa ed effetto rimangono comprensibili.
• Log Viewer o registri centrali controllati: sono visibili i veri Rule ID e NAT ID.
• Decisione di smantellamento documentata: le regole di test temporanee non rimangono permanentemente attive.

Se disponi di più firewall o gruppi gestiti centralmente, dovresti anche verificare se la modifica ha raggiunto l’appliance o il gruppo corretto. Per Sophos Central, la Coda attività di gestione del firewall aiuta; le modifiche locali possono essere monitorate con Registri di audit trail.

Funzionamento e revisione regolari

Una regola firewall non è pronta solo perché è stata salvata. Le buone regole hanno uno scopo chiaro, vengono registrate, sono verificabili e possono essere verificate nuovamente in seguito. Soprattutto negli ambienti maturi, molti rischi derivano non da un’unica regola errata, ma da vecchie eccezioni, regole troppo ampie o regole senza proprietario.

Per le revisioni regolari vale la pena seguire una semplice routine:

• La regola verrà comunque fatta?: Le regole inutilizzate possono spesso essere disabilitate e rimosse in seguito.
• La fonte è ancora corretta?: Le reti client, le reti server e le aree VPN cambiano nel tempo.
• Any è ancora giustificato?: Fonti generali, obiettivi o Services dovrebbero essere deliberatamente documentati.
• La registrazione è attiva e utile?: Senza log, le analisi e gli audit successivi sono significativamente più deboli.
• NAT, filtro web, IPS e TLS Inspection sono ancora adatti?: Le funzionalità di sicurezza potrebbero funzionare in modo diverso dopo aggiornamenti, modifiche alle app o modifiche ai certificati.
• C’è una data di scadenza?: Altrimenti, le regole temporanee del progetto o del supporto rimangono permanentemente attive.

Per le regole critiche, dovresti anche documentare chi è tecnicamente responsabile. Ciò è particolarmente importante per i servizi pubblicati, le regole VPN, l’accesso alla gestione, le condivisioni e le regole del fornitore di servizi con Any a Services o a destinazione.

Nuova regola, modifica o disattiva regola esistente?

Non tutte le nuove richieste necessitano immediatamente di una nuova regola firewall. Troppe regole simili rendono l’elenco confuso, ma le regole troppo riassunte diventano rapidamente troppo ampie. Una semplice decisione aiuta prima di salvare qualcosa nello WebAdmin:

• Stessa fonte, stessa destinazione, stesso scopo, solo un servizio in più: Estendi la regola esistente. La regola rimane tecnicamente coerente e più facile da testare.
• Stesse reti, ma requisiti di protezione diversi, registrazione diversa o proprietario diverso: Crea la tua regola. Filtri web, IPS, TLS Inspection, NDR o la registrazione possono essere controllati separatamente.
• Fornitore di servizi temporaneo o accesso al supporto: Crea la tua regola temporanea. Proprietario, biglietto, data di scadenza e finestra di prova rimangono chiaramente visibili.
• Sono interessati server, ospiti, VoIP, IoT o gestione: Controlla la tua regola o zona. Rischi diversi non dovrebbero scomparire in una regola Internet del client.
• Una regola non è chiara o è vecchia: Per prima cosa disattivare e osservare. L’eliminazione diretta toglie la possibilità di controllare riscontri, log e dipendenze in modo controllato.
• Una regola è certamente superflua dopo una revisione: Rimuovere dopo il backup e la documentazione. L’insieme di regole diventa più piccolo senza interrompere le dipendenze che funzionano ciecamente.

Per le normali modifiche operative, questo processo è robusto:1. Annotare lo scopo, il proprietario, il biglietto e il traffico previsto. 2. Controlla le regole esistenti per la stessa origine, destinazione, servizio e Rule group. 3. Decidi se una regola esistente viene estesa o se la tua regola è più pulita. 4. Per modifiche produttive, pianificare backup, audit trail e test case. 5. Dopo aver salvato Log Viewer, Rule ID, controllare la decisione NAT e le funzionalità di sicurezza interessate.

Se la decisione fallisce principalmente a causa della mancanza di documentazione, le regole Sophos Firewall dovrebbero essere documentate in modo significativo dovrebbero essere seguite per prime. Se non è chiaro se sia ancora necessaria una regola esistente, può essere utile un test controllato con Test regola firewall con Log Viewer, Policy Test e Packet Capture.

Disponi correttamente i contatori delle visite

I contatori delle visite aiutano nella pulizia, ma non sono una prova completa. Una regola di emergenza usata raramente può comunque essere importante. Al contrario, una regola ampia può avere molti riscontri positivi anche se ne consente troppi.

Per le revisioni dovresti sempre combinare i contatori di visite con Log Viewer, la descrizione delle regole e il caso d’uso effettivo. Se una regola non è chiara, non dovrebbe essere eliminata immediatamente. Meglio un processo controllato: chiarire lo scopo, attivare il logging, definire finestre di test, informare gli stakeholder e solo successivamente disattivarlo o rimuoverlo.

Rendi tracciabili le modifiche

Dovrebbe essere disponibile un backup prima di importanti modifiche alle regole. Audit Trail e Config Studio aiutano quindi a verificare le differenze in modo comprensibile. Il processo pratico è in Sophos Firewall Controllare i registri di audit trail e Sophos Firewall Utilizzare Config Studio.

Se vengono modificate molte regole, non dovresti solo confrontare la configurazione, ma anche eseguire casi di test reali. Una regola può essere sintatticamente corretta e tuttavia consentire traffico non corretto, utilizzare il percorso NAT sbagliato o interrompere un’applicazione tramite IPS, filtro Web o TLS Inspection.

Errori tipici

La regola è troppo in basso: una regola più generale sopra corrisponde prima al traffico.

La fonte è troppo ampia: Any funziona, ma rende le regole poco chiare e aumenta la superficie di attacco.

La destinazione è troppo ampia: Ai server o alle reti di gestione raramente dovrebbe essere consentito l’accesso a Internet con Any.

Services sono troppo larghi: Any consente molto più del necessario. Services specifici o gruppi di servizi sono migliori.

La registrazione non è attiva: Le informazioni più importanti mancano quindi nello Log Viewer.

IPv6 è stato dimenticato: IPv4 è adeguatamente regolamentato, ma IPv6 funziona secondo altre regole o rimane aperto inconsciamente.

Rule group è sicuramente confuso: Un gruppo di regole migliora solo la panoramica. Un gruppo di regole non costituisce un limite di sicurezza e non modifica la logica di valutazione.

HTTPS non viene scansionato: Scan HTTP and decrypted HTTPS è attivo, ma non esiste una regola di ispezione o decrittografia SSL/TLS appropriata.

Il filtro web non funziona: Nessuna politica web impostata, utente sbagliato, zona di origine sbagliata o QUIC non bloccato.

La corrispondenza degli utenti non funziona: L’autenticazione, AD SSO, captive Portal o la mappatura degli utenti non funzionano correttamente.

NAT mancante: la regola del firewall consente il traffico, ma SNAT/MASQ non è adatta.

La funzionalità di sicurezza non corrisponde al traffico: una policy IPS, un’opzione proxy o un’opzione di scansione della posta elettronica errati possono interrompere il traffico legittimo. Se dopo questi punti non è ancora chiaro il motivo per cui il traffico funziona in modo diverso dal previsto, è necessario eseguire ulteriori test strutturati con Log Viewer, Policy tester e Packet Capture. La procedura appropriata è in Test della regola firewall con Log Viewer, Policy Test e Packet Capture.

Domande frequenti