Sophos Firewall Configura zone e interfacce

Le zone e le interfacce sono tra i fondamenti più importanti di un Sophos Firewall. Se li pianifichi attentamente, renderai molto più semplici le successive regole del firewall, NAT, VPN, protezione web e risoluzione dei problemi. Se li si mettono insieme troppo velocemente, spesso si crea un ambiente in cui le regole diventano confuse o i servizi di gestione sono accessibili nei posti sbagliati.

Una Zona è un gruppo di sicurezza logico. Un’Interfaccia è una connessione fisica o virtuale, ad esempio Port1, una VLAN, un Bridge, un LAG, un Alias, un’interfaccia RED o un’interfaccia XFRM per VPN basata su route. Ogni interfaccia è assegnata esattamente ad una zona. Le regole del firewall funzioneranno successivamente molto con queste zone, quindi la struttura delle zone non dovrebbe essere pianificata solo dal punto di vista tecnico, ma anche in termini di sicurezza.

Quale articolo di progettazione di rete è adatto?

Le zone e le interfacce sono spesso il punto di partenza, ma non sempre l’obiettivo effettivo della configurazione. A seconda dell’attività, un articolo più specifico si adatta meglio:

• Pianifica sostanzialmente zone, interfacce, VLAN, bridge, LAG o RED: questo articolo.
• Configura l’interfaccia VLAN con l’interfaccia principale, DHCP, Device Access e regole: Sophos Firewall Configura e testa la VLAN.
• Crea e comprendi le regole firewall tra le zone: Comprendere e configurare correttamente le regole Sophos Firewall.
• Verificare il comportamento del bridge VLAN secondo SFOS 22: Sophos Firewall Utilizza bridge con tagging VLAN.
• Servizi di gestione sicuri come WebAdmin, SSH, User Portal o DNS: Sophos Firewall Accesso sicuro: Configurare correttamente Device Access.
• Classificare NAT, SNAT, DNAT o MASQ con interfacce e zone: Comprendere il NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.
• Pubblica server interno su WAN o DMZ: Pubblica il server tramite DNAT su Sophos Firewall.
• Controlla DNS per domini interni o zone AD: Configura i percorsi di richiesta DNS su Sophos Firewall.
• Imposta le opzioni DHCP per VoIP, PXE o client speciali: Configurare le opzioni DHCP su Sophos Firewall.
• Pianificare VPN da sito a sito con interfacce tunnel: Sophos Firewall Configura VPN IPsec da sito a sito.
• Il traffico non attraversa la zona o la regola prevista: Sophos Firewall La regola non vale: verificare le cause.Questa separazione previene i tipici errori di progettazione. Una zona non sostituisce una regola firewall, una VLAN non sostituisce un concetto di sicurezza e Device Access non è la stessa cosa del normale traffico tra due reti. In primo luogo, dovrebbe essere chiaro quali aree di sicurezza esistono. Interfacce, VLAN, regole, NAT, DNS e accesso di gestione vengono quindi costruiti di conseguenza.

Perché le zone sono importanti

Le zone su Sophos Firewall sono più di un semplice raggruppamento visivo. Ciò definisce le aree di sicurezza che vengono utilizzate in diversi luoghi:

• Le regole del firewall funzionano con la Zona di origine e la Zona di destinazione.
• Device Access controlla quali servizi firewall locali sono accessibili per zona.
• NAT, SD-WAN, VPN, protezione web e registri sono resi più facili da comprendere grazie alle zone pulite.
• La risoluzione dei problemi diventa più chiara perché puoi immediatamente vedere da quale area di sicurezza proviene un pacchetto e dove dovrebbe andare.

Una buona zonizzazione non previene automaticamente ogni errore, ma impone confini chiari. Una rete client, una rete server, una WiFi ospite e una DMZ non dovrebbero essere tutte trattate semplicemente come una “LAN” se presentano rischi e regole diversi. In caso contrario, in seguito si verificheranno regole di autorizzazione di grandi dimensioni, eccezioni poco chiare e accesso di gestione aperto inutilmente.

Le zone valide rispondono sempre a questa domanda: Quali reti hanno lo stesso livello di fiducia e possono essere trattate in modo simile? Se due reti necessitano di diritti di accesso, requisiti di registrazione o accesso di gestione diversi, ha senso una zona separata o almeno un concetto di regole molto consapevole.

È importante separare zona e oggetto di rete. La zona descrive attraverso quale area di sicurezza un pacchetto entra nel firewall o verso dove deve andare. L’oggetto di rete descrive la sorgente IP concreta o la destinazione concreta. Una regola è pulita solo quando entrambe le cose sono corrette: Source zone non deve essere solo un generico LAN mentre Source networks and devices resta su Any. Al contrario, un oggetto di rete corretto serve poco se il traffico entra da una zona diversa da quella prevista.

Comprendere le zone standard

Sophos Firewall è dotato di diverse zone standard:

• LAN: Reti interne, client, server e reti di gestione.
• WAN: Uplink Internet, router del provider, PPPoE, DHCP o indirizzi WAN statici.
• DMZ: Server accessibili pubblicamente, proxy inversi e servizi isolati.
• WiFi: Reti Wi-Fi, Sophos Access Points e segmenti wireless.
• VPN: Remote Access VPN, VPN da sito a sito e altri contesti di tunnel.

Le zone standard le trovate sotto Network > Zones. È possibile creare zone personalizzate come tipo LAN o DMZ. Ulteriori zone WAN o VPN non possono essere create semplicemente liberamente perché questi tipi di zone hanno funzioni speciali nel firewall.

Importante: una zona non è un’autorizzazione automatica. A seconda della direzione e dello scenario sono necessarie regole firewall adeguate anche tra due interfacce nella stessa zona. Il traffico tra due interfacce di zona LAN non è consentito automaticamente, ma richiede una regola LAN-to-LAN adeguata.

Sophos Firewall supporta zone personalizzate, ma non come sostituto illimitato di regole pulite. Il limite ufficiale è di massimo 100 zone. In pratica non conviene arrivare a questo limite. Se quasi ogni VLAN riceve una propria zona, anche se molte richiedono regole identiche e lo stesso Device Access, il rulebase diventa spesso più difficile da mantenere, non più sicuro.

Pianifica le zone prima della creazione

Prima della configurazione, dovresti notare quali reti hanno requisiti di sicurezza diversi. Esempi tipici:

• LAN sul posto di lavoro
• Rete di server
• Rete di gestione
• Zona demilitarizzata
• Wi-Fi per gli ospiti
• VoIP
• Telecamera o rete IoT
• Rete produttiva
• Client VPN
• MPLS o connessioni di posizione

Una zona separata ha senso se una rete necessita di regole proprie, di un proprio Device Access o di un altro livello di fiducia. Tuttavia, se devono essere trattate allo stesso modo, nella stessa zona possono trovarsi anche più VLAN. Troppe zone non rendono automaticamente una configurazione più sicura. Le zone sono utili solo se vi sono regole chiare dietro di esse.

Per molti ambienti di piccole e medie dimensioni, questa struttura di base è un buon inizio:

• LAN o Client: normali client workstation.
• Server: server interni, NAS, server applicazioni e controller di dominio.
• Management: PC di amministrazione, monitoraggio, backup, gestione switch e firewall.
• Guest o WiFi: Reti WiFi ospiti o BYOD con accesso limitato.
• DMZ: Sistemi che devono essere accessibili da Internet o da più reti.
• WAN: Connessioni Internet e provider.
• VPN: Remote Access VPN o contesti VPN da sito a sito.

Non tutte le VLAN necessitano automaticamente della propria zona. Se più VLAN client ottengono esattamente le stesse regole firewall, policy web e Device Access, possono rimanere in una zona client comune. Tuttavia, se una VLAN può raggiungere i server, un’altra può solo accedere a Internet e una terza non deve avere accesso ai servizi firewall locali, la separazione dovrebbe essere modellata consapevolmente.

Un buon modello è:

• Altro livello di fiducia: controlla la tua zona.
• Accesso di gestione al firewall: controlla la tua zona o la tua regola ACL.
• Altre funzioni di registrazione o altre funzioni di protezione: la propria zona può essere utile.
• Solo un intervallo IP diverso, ma la stessa politica di sicurezza: il concetto di zona comune può essere sufficiente.

Traduce il modello di zona in una matrice di accesso

Dopo la pianificazione delle zone, è necessario determinare brevemente a quale zona è consentito comunicare con quale altra zona. Questa matrice di accesso è spesso più utile della creazione immediata di regole in WebAdmin perché rende visibili le contraddizioni.

Un semplice esempio:

• Client a WAN: Consentito per Web, DNS, NTP e applicazioni richieste.
• Client a Server: Solo porte di applicazione definite, non Any.
• Guest a WAN: Consentito, principalmente con policy web e registrazione.
• Guest a Server: Normalmente bloccato.
• IoT a Server: Solo per servizi definiti con precisione, ad esempio MQTT, DNS o NTP.
• Management a LAN, Server, DMZ: Accesso amministrativo, ristretto e registrato.
• DMZ a LAN: Bloccato per impostazione predefinita, consente solo connessioni di ritorno esplicite.
• VPN a Server: Solo obiettivi e servizi interni richiesti.

La matrice non deve essere grande. Ciò che è importante è che ogni direzione consentita abbia uno scopo. Se una voce non può essere spiegata, non dovrebbe costituire una regola generale del firewall.

Per ogni riga dovresti anche notare:

• servizi e porti richiesti
• se è necessaria la corrispondenza dell’utente o del gruppo
• se è coinvolto il NAT
• se la registrazione deve rimanere permanentemente attiva
• quali funzionalità di sicurezza sono adatte, ad esempio IPS, Web Policy o Application Control
• chi è tecnicamente responsabile dell’accesso

Da questa matrice vengono quindi create le regole firewall effettive. Le opzioni dettagliate e gli errori tipici per ordine delle regole, origine, destinazione, NAT e registrazione sono descritti in Comprendere e configurare correttamente le regole Sophos Firewall.

Controllo della pianificazione prima delle modifiche

Prima che zone o interfacce vengano create, spostate o cancellate, le dipendenze dovrebbero essere chiarite per iscritto. Molti errori successivi non sono causati dall’indirizzo IP stesso, ma da regole firewall dimenticate, regole NAT, server DHCP, Device Access o decisioni di routing.

Per ogni nuova zona o interfaccia, è necessario rispondere almeno a queste domande:

• Livello di fiducia della rete: La zona, le regole del firewall e Device Access dipendono da questo.
• Utenti e sistemi in rete: Client, server, ospiti, IoT, VoIP e gestione necessitano di regole diverse.
• Gateway predefinito: Il firewall è spesso il gateway per le VLAN, ma a volte non per le migrazioni.
• Sorgente DHCP: Sophos Firewall, il server DHCP interno o il relè DHCP devono essere pianificati deliberatamente.
• Server DNS: il DNS influisce sul filtraggio web, sulla risoluzione dei nomi e sulla risoluzione dei problemi.
• Servizi firewall locali: Device Access per DNS, Ping, HTTPS, SSH o portali devono corrispondere.
• Regole e percorsi NAT: Senza firewall e regole NAT adeguate, l’interfaccia è disponibile solo tecnicamente.
• Flusso di test: Un client di test, una destinazione di test e una voce di registro prevista consentono di risparmiare molto tempo di ricerca.

Dovrebbe essere disponibile un backup attuale anche per modifiche produttive. Se le interfacce sono già in uso, l’utilizzo dell’oggetto è obbligatorio prima di modificare nome, associazione di zona, indirizzo IP o tipo di interfaccia.

Crea una nuova zona

Apri Network > Zones e clicca su Aggiungi.

1. Assegnare un nome breve e univoco, ad esempio Server, Guest, Management o MPLS.
2. Selezionare LAN o DMZ come tipo.
3. Sotto Device Access, specificare consapevolmente quali servizi firewall locali possono essere accessibili da questa zona.
4. Salva.

Dopo il salvataggio, la zona dovrebbe essere verificata direttamente in due punti: in Network > Zones per nome, tipo e Device Access e più tardi in una regola firewall di test come Source zone o Destination zone selezionabile. Se la zona esiste ma non contiene alcuna interfaccia, non passerà ancora traffico produttivo.

LAN o DMZ come tipo di zona?

Per le proprie zone solitamente è possibile scegliere tra LAN e DMZ su Sophos Firewall. Entrambi i tipi raggruppano le interfacce in modo che possano essere successivamente utilizzate in modo pulito nelle regole, Device Access e nelle policy. La differenza sta principalmente nell’idea di sicurezza che sta dietro alla zona.

LAN viene utilizzato per reti interne fondamentalmente affidabili. Questi includono, ad esempio, reti client, reti di server interni, reti di gestione, VoIP, stampanti o VLAN interne. Lo stesso vale per una zona LAN: il traffico tra le interfacce non è consentito automaticamente. Se due zone LAN o due interfacce all’interno di una zona LAN devono comunicare tra loro, sono necessarie adeguate regole firewall.DMZ viene utilizzato per reti con rischio più elevato o isolamento chiaro. Esempi tipici sono server Web accessibili pubblicamente, proxy inversi, gateway di posta, host jump o sistemi che devono essere accessibili da più aree di sicurezza. Una DMZ dovrebbe essere progettata in modo tale da ricevere solo le connessioni interne necessarie. Se nella DMZ si trova un server compromesso, ciò non dovrebbe comportare automaticamente un accesso diffuso alla LAN interna.

Come semplice regola pratica:

• LAN: reti interne generalmente attendibili e che comunicano principalmente in uscita o internamente.
• DMZ: reti esposte o particolarmente isolate dove l’accesso interno dovrebbe essere strettamente limitato.

Anche le interfacce HA appartengono a una zona DMZ. Per le normali reti di amministrazione o client, LAN è solitamente il tipo più adatto.HTTPS può essere utile per una rete amministrativa interna. Per le normali reti client o ospiti, l’accesso di gestione dovrebbe essere evitato. Ping/ping6 è spesso utile per la risoluzione dei problemi, ma dovrebbe essere attivato consapevolmente. DNS è necessario solo se i client in questa zona utilizzano il firewall come server DNS.

⚠️ Device Access non è la stessa cosa di una regola firewall. L’accesso ai servizi firewall locali, ad esempio WebAdmin, SSH, User Portal, DNS o Ping, è controllato tramite Administration > Device access ed eccezioni ACL locali.

Configura l’interfaccia

Le interfacce si trovano sotto Network > Interfaces. Ad esempio, una porta fisica può essere utilizzata come LAN, WAN o DMZ. Vengono create anche interfacce virtuali come VLAN, Bridge, LAG, RED o XFRM.

Questi punti sono particolarmente importanti per un’interfaccia fisica:

• Name: nome descrittivo per regole e log successivi.
• Hardware: porta fisica, ad esempio Port1, Port2 o PortA.
• Network zone: Zona di sicurezza in cui si trova l’interfaccia.
• IPv4 configuration: Statico, DHCP o PPPoE.
• IPv6 configuration: Statico, DHCP o Delegato, a seconda dell’ambiente.
• Gateway: rilevante solo per le interfacce WAN.
• MTU / MSS: importante per problemi di PPPoE, VPN, SD-WAN e frammentazione.

Solo le interfacce nella zona WAN ricevono una configurazione gateway. Le interfacce interne vengono solitamente indirizzate in modo statico. DHCP o PPPoE possono essere utili per le connessioni del provider.

Se il provider fornisce IPv6 tramite delega del prefisso, è necessario pianificare le restrizioni e il processo separatamente. L’articolo pratico a riguardo è Configurare la delega del prefisso IPv6 su Sophos Firewall.

I nomi significativi sono importanti. PortD significa poco tra sei mesi. Server VLAN, MPLS Provider, Guest WiFi o Core Switch Trunk aiutano molto di più in esercizio.

Un’interfaccia fisica esistente si modifica così:

1. Aprire Network > Interfaces.
2. Aprire il menu della porta desiderata e selezionare Edit interface.
3. Verificare Name, Network zone, configurazione IP, gateway e MTU/MSS.
4. Per le interfacce WAN verificare anche nome gateway e IP gateway.
5. Salvare e poi controllare link status, gateway status e Log Viewer.

Prima di modificare un’interfaccia produttiva va aperto Object usage. Le modifiche alle interfacce possono influire su zone binding, DNS, gateways, SD-WAN routes, host basati su interfaccia, interfacce VLAN, Dynamic DNS, regole firewall e NAT. Quando si elimina un’interfaccia virtuale, Sophos può inoltre rimuovere configurazioni dipendenti come regole firewall, riferimenti DHCP o routing. Proprio lì nascono le interruzioni spiacevoli quando si aveva in mente solo il nome della porta.

Prima dei firmware upgrade bisogna inoltre assicurarsi che nomi di interfacce, hardware e branch non terminino con un lungo blocco di numeri. Nelle release notes SFOS è documentato un errore di visualizzazione WebAdmin se questi nomi terminano con dieci o più cifre, ad esempio VLAN_1234567890. Controllare Sophos Firewall prima dell’aggiornamento a SFOS 22 è adatto per la progettazione di upgrade e test specifici.

Crea l’interfaccia VLAN

Per un processo mirato con interfaccia genitore, switch tagging, DHCP, Device Access, regole e test firewall, Sophos Firewall Configura e testa la VLAN è adatto. La sezione seguente classifica le VLAN all’interno del modello di interfaccia e zona più ampio.

Viene creata un’interfaccia VLAN in Network > Interfaces > Add interface > Add VLAN. L’interfaccia principale, la zona, l’ID VLAN e la configurazione IP sono particolarmente importanti.

L’interfaccia genitore è la porta fisica o un LAG su cui arriva la VLAN taggata. Se lo switch invia la VLAN su una porta diversa, senza tag o con un ID VLAN errato, il firewall vede un’interfaccia VLAN, ma i client non possono raggiungerla in modo affidabile.

Per le VLAN interne viene solitamente utilizzato un indirizzo IP statico sul firewall, ad esempio come gateway predefinito per questa VLAN. La zona decide successivamente quali regole firewall, politiche web e impostazioni Device Access applicare. Proprio per questo motivo quando si crea una VLAN non si dovrebbe solo inserire l’indirizzo IP, ma anche considerare direttamente se la VLAN richiede Client, Server, Management, Guest, DMZ o un’altra zona.

Un esempio pratico concreto con profili di porta switch, comportamento con/senza tag, DHCP e sequenza di test è disponibile in Configura VLAN su Sophos Firewall e UniFi Switch.

Su hardware XGS, Sophos non indica un numero fisso e rigido di interfacce VLAN per interfaccia fisica. Questo però non significa che una singola parent port sia sempre la scelta operativa migliore. Per performance, troubleshooting e manutenibilità, le VLAN dovrebbero essere distribuite in modo sensato su porte fisiche o LAG, soprattutto con molte VLAN, molto traffico est-ovest o design HA.

Implementazione pulita della VLAN

Una VLAN è considerata completa solo quando non è stata creata solo l’interfaccia, ma anche lo switch, il DHCP, il DNS, le regole del firewall e il logging sono tutti compatibili. Soprattutto con le nuove reti è facile cercare nel posto sbagliato: la regola del firewall sembra corretta, ma lo switch invia senza tag. Oppure il client ottiene un indirizzo IP, ma Device Access non consente l’accesso DNS al firewall.

Per ogni nuova VLAN è necessario verificare questi punti:

• Interfaccia firewall: ID VLAN, interfaccia principale, zona, indirizzo IP e maschera di sottorete corrispondono al design.
• Cambia porta: Il collegamento in salita al firewall è configurato come trunk e ha la VLAN contrassegnata.
• Porta di accesso o SSID: La porta client o l’SSID WLAN associa i client alla VLAN corretta.
• Gateway: L’IP del firewall nella VLAN è il gateway predefinito previsto oppure il routing è documentato in modo diverso.
• DHCP: Il server DHCP, il relè DHCP o il server DHCP esterno distribuisce IP, gateway, DNS e lease corretti.
• DNS: i client possono risolvere nomi interni ed esterni come previsto.
• Device Access: Dalla zona sono consentiti solo i servizi firewall locali richiesti, ad esempio DNS o Ping.
• Regola firewall: La zona di origine, la rete di origine, la zona di destinazione, i servizi e la registrazione corrispondono al flusso di test.
• NAT: Attivo solo se il traffico ha realmente bisogno di essere tradotto. Per il normale traffico interno, il NAT è solitamente sbagliato.
• Test: Log Viewer mostra il firewall previsto Rule ID; se necessario Packet Capture conferma il flusso dei pacchetti.

Come test di accettazione non è sufficiente che un client riceva un indirizzo IP. Un test utile consiste in diversi passaggi: connettere il client tramite DHCP, eseguire il ping del gateway, controllare il DNS, testare una connessione interna consentita, verificare che l’accesso proibito sia deliberatamente bloccato e quindi controllare l’accesso a Internet. In questo modo puoi vedere se VLAN, zona, Device Access, regola firewall e NAT corrispondono davvero.

Se vengono create più VLAN contemporaneamente, è necessario utilizzare un client di test separato o almeno un IP di test univoco per ciascuna VLAN. Altrimenti Log Viewer e Packet Capture creeranno inutilmente confusione. Testare la regola firewall con Log Viewer, Policy Test e Packet Capture è adatto per il controllo effettivo del flusso dei pacchetti.

Leggi correttamente lo stato dell’interfaccia

Sotto Network > Interfaces, Sophos Firewall visualizza i messaggi di stato. Questi messaggi di stato sono molto utili durante la risoluzione dei problemi perché puoi vedere rapidamente se un’interfaccia è semplicemente configurata in modo errato o se non esiste davvero alcun collegamento.

• Not configured: L’interfaccia non è assegnata ad una zona. Quindi non può essere utilizzato in alcun modo significativo finché una zona non è stata delimitata.
• Connected: L’interfaccia è configurata e connessa.
• Connecting: È attualmente in fase di acquisizione un nuovo indirizzo IP, ad esempio tramite DHCP.
• Disconnected: L’indirizzo IP è stato rilasciato.
• Disconnecting: L’indirizzo IP è attualmente in fase di rilascio.
• Unplugged: Non esiste alcuna connessione fisica. Per il WiFi può anche significare che non è connesso alcun Access Point oppure non è assegnata alcuna rete wireless.
• Not available: Le porte FleXi sono state configurate, ma il modulo porta FleXi corrispondente non è più presente.

Se un’interfaccia mostra inaspettatamente Not configured o Unplugged, non cercare prima le regole del firewall. Per prima cosa controllare il collegamento della zona, il collegamento, l’SFP/transceiver, il cavo, la porta dello switch e, per DHCP/PPPoE, l’assegnazione dell’indirizzo.

Classifica VLAN, Bridge, LAG, Alias e RED

Sophos Firewall supporta diversi tipi di interfaccia. Per i principianti, la cosa più importante è quando quale tipo ha senso.

• VLAN: ​​​​Standard per reti segmentate su una porta trunk.
• Bridge: connessione trasparente di più porte, spesso per semplici configurazioni o migrazioni.
• LAG: raggruppamento di più collegamenti fisici per ridondanza o larghezza di banda.
• Alias: indirizzo IP aggiuntivo su un’interfaccia esistente.
• RED: Remote Ethernet Device per sedi esterne.
• XFRM: interfaccia VPN IPsec basata su percorso.

Le interfacce Alias vengono spesso sottovalutate. Sono particolarmente utili quando un provider fornisce più indirizzi IP pubblici nella stessa subnet. Più interfacce WAN separate nella stessa subnet causano problemi ARP su Sophos Firewall e possono rendere irraggiungibili i gateway. In questi design, un alias sull’interfaccia WAN esistente o un LAG pianificato correttamente è di solito la scelta migliore.

Per le nuove installazioni, la VLAN su un uplink chiaramente definito allo switch è solitamente più pulita di un grande bridge su molte porte. Un bridge può essere utile per migrazioni o configurazioni molto semplici perché più porte vengono trattate come un segmento Layer 2 comune. Ma proprio questo è lo svantaggio: i confini di sicurezza, i campi di trasmissione e le fonti di errore diventano meno visibili.

Pertanto consigliamo i ponti solo in modo specifico e non come struttura standard. In pratica, i ponti presentano diversi svantaggi:

• Più porte condividono lo stesso segmento Layer 2, consentendo alle trasmissioni e alle interferenze di incidere più facilmente su più dispositivi.
• Le regole del firewall stanno diventando meno chiare perché la separazione non è più chiaramente visibile tra le proprie interfacce, VLAN e zone.
• La risoluzione dei problemi diventa più difficile poiché il flusso dei pacchetti, l’apprendimento del MAC, i problemi STP e la configurazione dello switch devono essere considerati insieme.
• La segmentazione successiva diventa più complessa se da un semplice bridge si devono creare reti client, server, guest o di gestione separate.
• I progetti HA, VLAN, DHCP o di accesso ai dispositivi diventano rapidamente confusi se troppe funzioni vengono eseguite su un bridge.

Su Sophos Firewall possono essere creati ponti tramite interfacce fisiche, interfacce RED, VLAN o LAG e gestiti con o senza un proprio indirizzo IP. È proprio qui che spesso nascono i malintesi:

• Senza indirizzo IP il bridge funziona in modo trasparente, ma non può essere utilizzato come una normale interfaccia routing.
• Se è necessario il routing su un bridge, al bridge deve essere assegnato un indirizzo IP.
• Per il traffico tra membri del bridge sono comunque necessarie regole firewall adeguate tra le zone interessate, ad esempio LAN to LAN.
• STP può essere utile se ci sono percorsi ridondanti e si dovrebbero prevenire i loop del bridge. Con HA attivo, però, STP non può essere abilitato sulle interfacce Bridge.
• I filtri VLAN e i filtri EtherType possono aiutare a limitare il traffico Layer 2 che passa attraverso un bridge. Se un filtro VLAN è attivo ma non sono inserite VLAN consentite, il firewall scarta il traffico taggato di tutte le VLAN. Il traffico untagged non è interessato.
• Il traffico sulle interfacce bridge senza indirizzo IP può essere interrotto se colpisce una regola firewall con filtro proxy Web o una regola NAT. Tali eliminazioni non vengono registrate. Con NAT devi prestare particolare attenzione alla traduzione di origine o sovrascrivere la traduzione di origine.

Quest’ultimo punto è importante: se all’improvviso non vedi più nessun registro su un ponte, anche se il traffico sembra non funzionare, il problema non è sempre con Log Viewer. Potrebbe essere dovuto alla modalità bridge, al NAT o al filtro proxy web.

Se esistono già VLAN sullo switch, il firewall dovrebbe adottare consapevolmente queste VLAN come proprie interfacce VLAN. Ciò si traduce in zone più chiare, regole firewall più pulite ed è solitamente più facile da mantenere a lungo termine.

SFOS 22: controllare il traffico su ponti, SNAT e tornanti

Con SFOS 22 esiste un ulteriore caso speciale del bridge che viene rapidamente trascurato nelle migrazioni. Il routing su un’interfaccia del bridge può non riuscire se SNAT o MASQUERADE vengono applicati al traffico sul bridge e l’origine e la destinazione sono raggiungibili tramite lo stesso membro del bridge fisico. In questo scenario a tornante, i pacchetti di risposta possono essere rilasciati sul bridge senza che la consegna sia chiaramente visibile in drppkt.

Questo non è un normale problema di corrispondenza delle regole. Se Log Viewer mostra poco, la regola sembra corretta e tuttavia solo alcune connessioni su un bridge falliscono, dovresti controllare insieme NAT e topologia del bridge:

• SNAT o MASQUERADE sono davvero necessari sul traffico sui ponti?
• L’origine e la destinazione provengono dallo stesso elemento fisico del ponte?
• Esiste un solo membro del ponte utilizzato attivamente?
• Un design indirizzato o un’interfaccia fisica dedicata sarebbero più puliti?
• È possibile testare il traffico senza la traduzione della fonte?

Esiste anche un caso SFOS 22 separato per il traffico contrassegnato da VLAN verso il firewall stesso. La procedura pratica è in Sophos Firewall Controllare le VLAN bridge secondo SFOS 22.

Ponte RED: estende la rete tra più località

È tecnicamente possibile includere le interfacce RED in un bridge e quindi estendere una rete Layer 2 su più posizioni. Ciò può essere d’aiuto in casi particolari, ad esempio quando un’applicazione deve rimanere nella stessa sottorete o quando una migrazione deve avvenire senza modifiche immediate dell’IP.

Consigliamo questo design solo con molta cautela. Un ponte su RED estende il dominio di Livello 2 sul tunnel. Ciò fa sì che trasmissioni, ARP, pacchetti unicast sconosciuti e altri effetti di livello 2 vengano eseguiti su una connessione WAN o Internet. Ciò può peggiorare le prestazioni e rendere gli errori più difficili da comprendere. Se il tunnel RED è instabile, ciò influenzerà direttamente anche la rete allungata.

Nella maggior parte dei casi, una progettazione con routing è migliore: ogni posizione ha le proprie sottoreti, i percorsi firewall tra le reti e le regole firewall definiscono specificamente ciò che è consentito. Questo è più pulito, più scalabile e molto più conveniente durante la risoluzione dei problemi.

LAG: pianificare correttamente la ridondanza e la larghezza di banda

Un Gruppo di aggregazione collegamenti (LAG) combina diverse porte fisiche in un’interfaccia logica. Ciò ha senso se è necessaria ridondanza per lo switch principale o si desidera fornire più larghezza di banda tra il firewall e lo switch. Ma il GAL non sostituisce la zonizzazione pulita. Alla fine l’interfaccia LAG è ancora solo un’interfaccia sulla quale è possibile, ad esempio, gestire VLAN o assegnare una zona.

Sophos Firewall supporta principalmente due modalità operative tipiche:

• Active-Backup: Un collegamento è attivo, un altro subentra se fallisce. Questo è semplice e utile per la ridondanza.
• LACP (802.3ad): È possibile utilizzare più collegamenti in parallelo. Ciò richiede LACP su entrambi i lati, cioè sul firewall e sullo switch.

È importante: LACP funziona correttamente solo se l’altro lato è configurato correttamente. Sullo switch, le porte devono trovarsi nello stesso gruppo LAG, utilizzare la stessa velocità e modalità duplex e corrispondere alla configurazione del firewall. Se si crea solo un LAG sul firewall ma non si configura adeguatamente lo switch, spesso si verificano perdite di pacchetti difficilmente comprensibili o problemi di connessione asimmetrica.

Ai GAL si applicano alcune limitazioni pratiche:

• Un LAG su Sophos Firewall è costituito da da due a quattro interfacce fisiche.
• Come membri sono adatte solo le interfacce fisiche non legate con configurazione statica.
• Le interfacce PPPoE, WAN cellulare e WLAN non possono essere utilizzate come membri LAG.
• Per LACP (802.3ad) le porte aderenti devono avere lo stesso tipo e velocità.
• xmit-hash-policy determina la modalità di distribuzione delle sessioni sui collegamenti. Una singola sessione TCP normalmente non diventa improvvisamente più veloce perché solitamente rimane su un collegamento.

Per gli ambienti di piccole dimensioni, spesso è sufficiente una sola porta del bagagliaio pulita. Il LAG è particolarmente utile se lo switch principale deve essere collegato in modo ridondante, se molte VLAN funzionano sullo stesso uplink o se il firewall necessita davvero di più throughput verso lo switch.

XFRM: comprensione di IPsec basato su route come interfacciaUn’interfaccia XFRM appartiene all’argomento VPN IPsec basata su percorso. Non è progettata come una normale VLAN o porta fisica, ma viene creata nel contesto di una connessione IPsec. Sophos Firewall crea automaticamente un’interfaccia XFRM quando sia la sottorete locale che quella remota sono impostate su Any su una connessione IPsec.

Questa è una differenza importante rispetto ai classici tunnel IPsec basati su policy. Con la VPN basata sul percorso, non solo la policy IPsec, ma anche il routing, le regole del firewall e l’interfaccia XFRM decidono dove va il traffico. Ciò rende più flessibili le connessioni ai siti più complessi, ma richiede un’attenta pianificazione:

• L’interfaccia XFRM si trova nella zona VPN.
• Sotto Administration > Device access deve essere abilitato IPsec per la zona WAN affinché la connessione possa essere stabilita.
• Se le sottoreti locali o remote non sono Any, non viene creata alcuna interfaccia XFRM.
• MTU e MSS sono particolarmente importanti per le VPN basate su route poiché IPsec crea un sovraccarico aggiuntivo. La procedura della prova pratica è in Sophos Firewall Controllare MTU e MSS per problemi VPN.
• Un’interfaccia XFRM non viene disattivata direttamente sotto Network > Interfaces, bensì tramite la connessione IPsec associata sotto Site-to-site VPN > IPsec.

XFRM è particolarmente rilevante per gli amministratori quando il routing SD-WAN, il routing dinamico o più reti devono essere adeguatamente controllati tramite un tunnel di posizione. Se tutto ciò di cui avete bisogno è un collegamento da sito a sito molto semplice con due reti fisse, un classico tunnel basato su policy è spesso più facile da capire.

RED: posizioni esterne come concetto di interfaccia separato

Le interfacce RED non sono una normale porta switch. RED sta per Dispositivo Ethernet Remoto e viene utilizzato per connettere una postazione esterna a Sophos Firewall tramite un tunnel crittografato. Questo può essere implementato con hardware SD-RED dedicato o con connessioni RED da firewall a firewall.

Prima della pianificazione, dovrebbe essere chiaro quale modalità operativa è richiesta:

• Standard/Unified: Il firewall gestisce la rete remota. Il traffico passa attraverso il firewall centrale. Molto facile da controllare, ma dipende dal tunnel.
• Standard/Split: Solo le reti target definite attraversano il tunnel, il traffico Internet esce localmente nella posizione. Meno larghezza di banda tra le sedi centrali, ma meno controllo centrale.
• Transparent/Split: RED si blocca in modo trasparente in una rete esistente. Buono per casi speciali, ma più difficile da comprendere e non adatto a tutti i progetti.
• Manual/Split: Ulteriore configurazione manuale della rete. Il sito può continuare a funzionare localmente se il tunnel fallisce.

Per molte aziende Standard/Unified è l’opzione più pulita se la sede deve essere completamente protetta tramite il firewall centrale. Lo svantaggio è chiaro: se il tunnel RED fallisce, la sede perde, a seconda della versione, anche l’accesso a Internet controllato centralmente. Standard/Split riduce questa dipendenza, ma significa anche che il traffico Internet locale non viene più completamente filtrato e registrato tramite la centrale Sophos Firewall.

Con RED dovresti controllare presto questi punti:

• Il servizio RED deve essere attivato al System services > RED.
• Per la connessione sono generalmente richiesti TCP 3400, UDP 3410 e NTP 123.
• I dispositivi SD-RED necessitano dell’ora esatta, altrimenti l’handshake TLS e la creazione del tunnel potrebbero fallire.
• Alla prima messa in servizio, il DHCP sull’uplink è solitamente più semplice perché il dispositivo deve effettuare il provisioning.
• Le VLAN non sono ugualmente utili in tutte le modalità RED. Standard/Split e Transparent/Split non sono destinati ai frame con tag VLAN. Se dietro un SD-RED sono necessarie VLAN, è necessario scegliere la modalità operativa con particolare attenzione.
• Se un dispositivo RED si trova dietro il router di un provider, le connessioni in uscita e DNS/NTP devono funzionare.

Il RED è molto comodo per i piccoli siti, ma non dovresti trattarlo come un normale cavo LAN. Il fattore decisivo è se il luogo debba essere protetto centralmente, autonomo localmente o collegato solo parzialmente tramite tunnel. Questa decisione influisce su DHCP, DNS, VLAN, routing, regole del firewall, registrazione e risoluzione dei problemi.

Device Access limitare in modo pulitoSotto Administration > Device access puoi vedere quali servizi firewall locali sono accessibili da quali zone. Questi includono, tra gli altri:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

Per gli ambienti produttivi, meno servizi locali possono essere raggiunti da una zona, meglio è. In particolare, HTTPS e SSH dovrebbero essere consentiti solo da reti di gestione affidabili o tramite una regola di eccezione ACL del servizio locale.

Se è necessario SSH, questa guida aiuterà: Stabilire una connessione SSH al Sophos Firewall.

Per le zone personalizzate, Device Access può essere visibile anche direttamente durante la creazione o la modifica della zona. Tecnicamente si tratta comunque di servizi locali del firewall, non di normale traffico di transito. Se i client usano il firewall come server DNS, DNS deve essere consentito per questa zona. Se gli amministratori devono raggiungere WebAdmin, non dovrebbe essere abilitato in modo ampio per tutta la zona client, ma tramite una rete di management o un’eccezione Local Service ACL.

Tieni a mente le dipendenze

Le modifiche alle interfacce sono raramente isolate. Zone binding, DNS, gateways, SD-WAN routes, host basati su interfaccia, interfacce VLAN, Dynamic DNS, regole firewall e regole NAT possono dipendere dalla stessa interfaccia. Prima di modifiche importanti bisogna verificare in Object usage dove un’interfaccia, una zona o un oggetto host è già utilizzato. Sophos Firewall mostra l’utilizzo degli oggetti e collega direttamente molte configurazioni dipendenti.

È necessario prestare particolare attenzione quando si disattivano o eliminano:

• Se un’interfaccia viene disattivata, la configurazione viene mantenuta e lo stato è ancora visibile.
• I tunnel IPsec da sito a sito in cui il firewall è l’iniziatore vengono immediatamente disconnessi.
• I tunnel IPsec da sito a sito come risponditori e le connessioni di accesso remoto vengono disconnessi al più tardi a causa di inattività o rilevamento di peer morti.
• Le interfacce Alias ​​e XFRM non possono essere disattivate direttamente come le normali interfacce. Le interfacce alias seguono l’interfaccia fisica, le interfacce XFRM vengono disattivate tramite Site-to-site VPN > IPsec.
• Quando un’interfaccia virtuale viene eliminata, è possibile rimuovere con essa le regole firewall dipendenti, le configurazioni DHCP, le voci ARP, i percorsi, gli host dell’interfaccia e altri riferimenti.

Pertanto, prima dell’eliminazione, è necessario verificare sempre se l’interfaccia viene utilizzata nelle regole firewall, nelle regole NAT, nel DHCP, nel routing, nella SD-WAN, nel DNS dinamico o negli oggetti host. Una cancellazione imprudente può rimuovere qualcosa di più della semplice interfaccia stessa.

Implementa le modifiche in modo sicuro

I cambiamenti dell’interfaccia dovrebbero essere graduali. Le sedi remote, i cluster HA, le interfacce WAN, i trunk VLAN, le interfacce XFRM e le reti di gestione sono particolarmente critici. Una piccola modifica al collegamento della zona può essere sufficiente affinché le regole del firewall, Device Access o i percorsi SD-WAN non funzionino più come previsto.

Processo collaudato:

1. Documentare la configurazione attuale dell’interfaccia e della zona.
2. Controllare le dipendenze tramite Object usage e annotare direttamente i risultati più importanti.
3. Crea backup.
4. Definire la finestra di manutenzione o il tempo di fallback.
5. Aggiungere prima una nuova zona o una nuova interfaccia, non eliminare immediatamente la vecchia configurazione.
6. Preparare il client di prova o il traffico di prova.
7. Dopo la modifica, controllare lo stato del collegamento, l’indirizzo IP, il gateway, DHCP e DNS.
8. Convalidare la regola firewall, la regola NAT e Device Access con Log Viewer o Packet Capture.
9. Rimuovere le vecchie regole, interfacce o oggetti solo quando il nuovo percorso è stabile.

Un backup è solo una parte del percorso di ritorno. Prima di modifiche critiche dell’interfaccia o della zona, è necessario documentare anche quale vecchio indirizzo IP, zona, ID VLAN, gateway, percorso, percorso SD-WAN, regola firewall e regola NAT devono essere ripristinati in caso di interruzione. Sophos Firewall Crea o ripristina il backup è adatto per l’effettivo processo di backup e ripristino.

• La zona di gestione o Device Access viene modificata: L’accesso amministrativo alternativo viene testato prima che la vecchia accessibilità venga rimossa.
• L’interfaccia WAN o il gateway vengono modificati: Il vecchio percorso del provider, i valori PPPoE/DHCP/statici e il percorso SD-WAN sono documentati.
• Il trunk VLAN è in fase di conversione: Il vecchio ID VLAN, la VLAN nativa, il profilo della porta dello switch e l’interfaccia del firewall sono tracciabili.
• Bridge, LAG o RED vengono modificati: Lo stato del collegamento, le porte coinvolte e l’accesso alla posizione possono essere controllati in modo indipendente.
• L’interfaccia XFRM o VPN è stata modificata: Le regole di tunnel, routing e firewall vengono convalidate prima di eliminare il vecchio percorso.

Particolare attenzione dovrebbe essere prestata al comportamento con/senza tag durante le migrazioni VLAN. Se lo switch e il firewall utilizzano ID VLAN, VLAN native o profili trunk diversi, il firewall non vede alcun traffico oppure il traffico finisce nella zona sbagliata.

Per le posizioni remote, dovrebbe sempre essere presente un percorso di accesso esterno all’interfaccia appena modificata. Può trattarsi di Sophos Central, di un secondo accesso WAN, di un amministratore locale in loco o di una rete di gestione separata.

Tipici ostacoli

L’interfaccia non è associata o è disabilitata: Controlla innanzitutto se è assegnata una zona. Non è possibile eliminare un’interfaccia fisica, ma è possibile rimuoverne la configurazione impostando la zona su None.

VLAN non funzionante: Controlla l’ID VLAN, la porta dello switch, la configurazione con/senza tag, la VLAN nativa e l’interfaccia principale.

I client non possono raggiungere il firewall tramite ping o HTTPS: Non controllare prima le normali regole del firewall. Administration > Device access e le eccezioni ACL locali sono cruciali.

Il traffico tra due reti interne non funziona: Controlla la zona di origine, la zona di destinazione, gli oggetti di rete, il routing e la posizione della regola del firewall.

Il gateway WAN non si attiva: Controlla la configurazione IP, l’IP del gateway, lo stato del collegamento, le credenziali PPPoE, il DNS e, se necessario, il Gestore del collegamento WAN.

Più interfacce WAN nella stessa sottorete: se più interfacce WAN utilizzano indirizzi IP della stessa sottorete, potrebbero verificarsi problemi ARP e i gateway potrebbero diventare irraggiungibili. Se un provider fornisce più IP pubblici sulla stessa sottorete, le interfacce alias o LAG sono generalmente più pulite rispetto a più interfacce WAN separate sulla stessa rete.

SFP, velocità della porta o breakout non corrispondono: La velocità della porta sullo switch, sul router, sul ricetrasmettitore e sul firewall deve corrispondere. Una porta da 25 Gbit/s non può essere collegata direttamente a una porta da 40 Gbit/s senza una tecnologia adeguata. Per i modelli con porte 40G o 100G, i cavi breakout possono essere utili se una porta deve essere suddivisa in più porte più piccole.

Problemi MTU con VPN o PPPoE: Controlla MTU e MSS. Nel traffico VPN un valore MTU troppo alto può portare alla perdita di pacchetti, che nella vita di tutti i giorni assomiglia a problemi di connessione casuali. Sophos Firewall Controllare MTU e MSS per problemi VPN è adatto alla limitazione sistematica.

Risoluzione dei problemi

Questo ordine è pratico per la risoluzione dei problemi:

1. Network > Interfaces: Verifica stato collegamento, indirizzo IP, zona e gateway.
2. Network > Zones: Controllare Device Access e il tipo di zona.
3. Host e servizi: controlla se gli oggetti host e servizio sono corretti.
4. Rules and policies > Firewall rules: Verifica zona di origine, zona di destinazione, servizi e ordine.
5. Rules and policies > NAT rules: Se è coinvolto NAT, confrontare attentamente l’originale e la traduzione.
6. Visualizzatore registro: controlla quale regola o eliminazione si applica.
7. Diagnostics > Tools > Packet capture: Controlla se i pacchetti arrivano e dove vengono inoltrati.

Se le zone e le interfacce sono disposte correttamente, il passo successivo diventa molto più semplice: Comprendere e configurare correttamente le regole Sophos Firewall. Se il traffico non funziona nonostante la zona apparentemente corretta, la checklist La regola del firewall non funziona: controlla l’ordine, la corrispondenza e i registri verrà in aiuto. Per un’analisi più approfondita potete utilizzare anche Utilizzare Packet Capture in WebAdmin e per traduzioni o port forwarding l’articolo Comprendere il NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Lista di controllo operativa

• Modello di zona documentato: client, server, gestione, ospite, DMZ, WAN e VPN deliberatamente separati o deliberatamente combinati.
• Nuove VLAN documentate con ID VLAN, interfaccia principale, profilo porta switch e IP gateway.
• Zona e oggetto host IP concreto documentati per ogni rete importante.
• Device Access controllato per zona, in particolare per HTTPS, SSH, DNS, Ping, User Portal e VPN Portal.
• Regole firewall create con zona di origine, zona di destinazione, servizi e registrazione.
• Alias verificato invece di un’ulteriore interfaccia WAN quando si usano più IP pubblici nella stessa subnet del provider.
• Regole NAT controllate se è coinvolto l’accesso a Internet, DNAT, SNAT o VPN.
• DHCP, DNS e NTP testati per le nuove reti.
• Utilizzo degli oggetti controllato prima delle modifiche alle interfacce esistenti.
• Stato del collegamento, Log Viewer e Packet Capture controllati per eventuali modifiche.
• Accesso gestionale assicurato tramite percorso indipendente.
• Backup disponibile prima di modifiche importanti.

Domande frequenti