Configurare Sophos Firewall Discover Mode con TAP e SPAN

In Discover Mode, Sophos Firewall riceve una copia del traffico di rete tramite un’interfaccia TAP. Lo switch replica le porte o le VLAN selezionate su una porta SPAN o mirror collegata a una porta libera del firewall. Il firewall non è inline e non modifica il percorso dei pacchetti di produzione.

Procedura rapida: Garantire un accesso di gestione separato, configurare sullo switch una porta SPAN bidirezionale, scegliere una porta libera del firewall, eseguire system discover-mode tap add PortD nella Device Console e verificare prima l’ingresso con Packet Capture. Successivamente esaminare Current Activity, i report e, se necessario, un Security audit report.

⚠️ Discover Mode è una modalità di osservazione. Al traffico sull’interfaccia TAP non si possono applicare Security Policies e il firewall non può bloccarlo né scartarlo. HTTPS non è supportato in questa modalità. Un report senza rilievi non dimostra quindi né una visibilità completa né una protezione efficace.

PortD è un esempio usato in questa guida. Occorre utilizzare la porta fisica effettivamente libera sull’appliance.

Discover Mode in otto passaggi

1. Verificare una porta di gestione indipendente del firewall e un percorso di ripristino sicuro per l’amministrazione.
2. Definire sullo switch quali porte o VLAN devono essere replicate in entrambe le direzioni.
3. Collegare una porta mirror dedicata a una porta fisica libera del firewall.
4. Nella Device Console, registrare lo stato iniziale con system discover-mode tap show.
5. Attivare la porta di esempio come TAP con system discover-mode tap add PortD.
6. In Network > Interfaces, verificare il tipo Discover, physical (TAP).
7. Generare un flusso di prova noto e confermarne i pacchetti sull’interfaccia TAP.
8. Solo dopo valutare report, attribuzione utenti e un Security Audit Report.

Lo switch e il firewall vengono configurati separatamente. Un’interfaccia TAP visibile non dimostra ancora che lo switch replichi i frame corretti.

Quando TAP è adatto e quando non lo è

Discover Mode è adatto per un inventario passivo, una proof of concept o un’analisi preliminare prima di una successiva implementazione inline. Gli obiettivi tipici sono:

• rendere visibili le relazioni di traffico e le applicazioni attive;
• classificare le categorie web e applicative entro i limiti tecnici;
• osservare i rilevamenti IPS senza modificare il percorso dati;
• raccogliere report per la successiva pianificazione di policy e segmentazione;
• valutare un nuovo firewall in parallelo all’infrastruttura esistente.

TAP non è la scelta corretta se il traffico deve già essere bloccato, decifrato, modificato tramite NAT o controllato con regole basate sugli utenti. Servono una modalità gateway, bridge o un altro funzionamento inline con regole firewall adeguate.

Discover Mode può essere combinato con le modalità gateway, mixed e bridge. Le regole di sicurezza si applicano quindi alle normali interfacce inline, non all’interfaccia TAP. Pianificare zone e interfacce di Sophos Firewall spiega come si collegano porte fisiche, zone, bridge e altri tipi di interfaccia.

Topologia di esempio e valori sostituibili

L’esempio utilizza questi componenti:

• Switch core: SW-Core-01
• Uplink da replicare: Switch-Port 1, ricezione e trasmissione
• Destinazione SPAN: Switch-Port 24
• TAP del firewall: PortD, libera e senza configurazione IP
• Gestione del firewall: PortA - 10.10.10.16/24
• Client di prova: 10.20.30.40

I nomi e gli indirizzi sono esempi. Conta la funzione: la porta TAP riceve solo i frame replicati. Gestione, aggiornamenti, DNS e invio dei report utilizzano un’altra interfaccia configurata normalmente.

La porta mirror deve essere almeno veloce quanto il traffico osservato. Se più porte sorgente molto utilizzate vengono replicate verso una porta di destinazione più lenta, lo switch può scartare pacchetti dalla copia. La connessione di produzione continua a funzionare, ma il report rimane incompleto. TAP non è quindi una cattura forense senza perdite e l’assenza di un evento non dimostra che non sia avvenuto.

Requisiti e limiti di sicurezza

Prima dell’attivazione occorre chiarire questi punti:

• Uno switch gestito supporta SPAN o port mirroring.
• Una porta fisica del firewall è libera e non viene utilizzata in produzione.
• L’amministrazione rimane raggiungibile tramite un’interfaccia separata.
• Il firewall accede a Internet per la classificazione cloud, gli aggiornamenti IPS e la generazione del Security Audit Report.
• Se il report deve mostrare utenti anziché solo indirizzi IP, è integrata una fonte di autenticazione esterna adeguata.
• Scopo, conservazione e destinatari dei dati replicati rispettano i requisiti di privacy.

I frame replicati possono esporre indirizzi interni, query DNS, protocolli non cifrati e relazioni di comunicazione. Packet capture e report vengono quindi conservati solo per il tempo necessario e trasferiti in modo protetto.

Comprendere correttamente Port Affinity

Per alcune piattaforme, la guida Sophos raccomanda di associare l’interfaccia TAP a una CPU con bind-with prima dell’attivazione. Le appliance XGS non richiedono Port Affinity manuale, perché l’elaborazione viene distribuita automaticamente tra i core della CPU.

Su altre appliance e piattaforme virtuali, un’assegnazione CPU adeguata dipende da hardware, adattatore e carico. Non bisogna copiare un valore CPU da un esempio estraneo. Se la piattaforma richiede un’assegnazione manuale, questa viene pianificata prima del rollout TAP usando le indicazioni appropriate per il dispositivo o del supporto. Un comando generico set port-affinity non fa parte della normale procedura rapida.

Per un firewall virtuale occorre inoltre assicurarsi che hypervisor, vSwitch e scheda di rete virtuale consegnino effettivamente i frame replicati alla VM. Il solo stato della scheda di rete virtuale non lo conferma; è decisiva la prova dei pacchetti in SFOS.

Preparare SPAN o port mirroring sullo switch

La configurazione esatta dipende dal produttore. Sullo switch vengono definiti almeno questi valori:

1. Source: la porta fisica da osservare o le VLAN previste.
2. Direction: ricezione e trasmissione, affinché siano visibili entrambe le direzioni.
3. Destination: la porta dedicata collegata a PortD del firewall.
4. Session status: attivato.

La porta di destinazione non viene utilizzata contemporaneamente come normale porta access o trunk per gli endpoint. Anche la porta di gestione del firewall non viene collegata alla porta mirror. In caso contrario, i percorsi di gestione e osservazione si mescolano o lo switch crea un’infrastruttura Layer 2 inattesa.

Prima di configurare il firewall è opportuno documentare quali VLAN e direzioni lo switch replichi realmente. Su uplink di grandi dimensioni, è preferibile iniziare il pilot con una singola VLAN di prova o una porta chiaramente limitata anziché con tutto il traffico core.

Attivare l’interfaccia TAP su Sophos Firewall

In Network > Interfaces, la porta selezionata deve avere la zona None e non deve avere una configurazione IP o dipendenze di produzione. Non liberare una porta in uso solo per la prova: questa operazione può interrompere interface host, DHCP, routing, regole o altri servizi.

Dopo l’accesso SSH a Sophos Firewall, aprire Option 4: Device Console. Prima leggere lo stato corrente:

system discover-mode tap show

Quindi attivare la porta di esempio prevista e verificarla di nuovo:

system discover-mode tap add PortD
system discover-mode tap show

Sophos documenta il messaggio Discover Interface added successfully per un’attivazione riuscita. La porta appare quindi in Network > Interfaces come Discover, physical (TAP).

Il comando non configura SPAN sullo switch. Se la porta mostra lo stato SFOS corretto ma non riceve traffico, controllare prima il lato switch invece di creare una regola firewall sulla base di un sospetto.

Verificare traffico e report

1. Eseguire una verifica controllata dei pacchetti

Sul client di prova 10.20.30.40 viene generato un test DNS chiaro o HTTP non cifrato. In Diagnostics > Packet capture si utilizza un filtro BPF ristretto:

host 10.20.30.40

La cattura deve mostrare pacchetti con In interface PortD. Con il mirroring bidirezionale compaiono richiesta e risposta. Una Firewall Rule ID o uno stato Forwarded non è un criterio di successo sul percorso TAP passivo, perché SFOS non inoltra questo traffico né vi applica una Security Policy.

Packet Capture in Sophos Firewall WebAdmin spiega funzionamento, filtri e limiti di esportazione. La cattura viene arrestata dopo la prova e conserva solo l’intervallo necessario.

2. Verificare la visibilità nel contesto

Dopo la prova dei pacchetti, esaminare Current activities e i report locali appropriati. Le aspettative devono corrispondere al protocollo:

• gli indirizzi sorgente e destinazione visibili corrispondono alla prova;
• una categoria applicativa o web è prevista solo dove SFOS può classificare il traffico;
• un rilevamento IPS è un’osservazione, non un blocco;
• gli utenti compaiono solo con una fonte di identità funzionante e un’attribuzione corretta;
• i contenuti HTTPS non sono supportati in Discover Mode.

La fonte utenti esterna viene testata separatamente. Per Active Directory è utile collegare Active Directory a Sophos Firewall. In caso contrario, l’assenza di un nome utente non significa automaticamente che manchi il traffico TAP.

3. Generare un Security Audit Report

In Reports > Show report settings > Report scheduling > Add, selezionare Security audit report come tipo. Inserire consapevolmente destinatari e organizzazione, quindi verificare separatamente il trasporto email e il contenuto del report.

Pianificare i report di Sophos Firewall e inviarli tramite email spiega i limiti di Send test mail, Generate now, privacy, lingua e comportamento HA. Un’email di prova riuscita dimostra solo il percorso email. Solo un report generato con dati plausibili conferma il percorso completo.

HA e modalità operative miste

Discover Mode supporta solo HA active-passive. HA active-active non è possibile quando uno dei firewall opera in Discover Mode.

Non si può creare un cluster active-passive mentre l’interfaccia TAP è attiva. Per configurare HA, disattivare la porta TAP su entrambe le appliance, creare HA e poi riattivare singolarmente l’interfaccia TAP su entrambi i dispositivi. Sophos segnala inoltre che l’interfaccia TAP rimane attiva anche sull’appliance passiva.

Per questo motivo, cablaggio, mirroring dello switch e ricezione dati vengono ricontrollati dopo un cambio di ruolo pianificato. Non si presume che un periodo di report esistente o un’osservazione TAP continui senza interruzioni sull’altro nodo. Configurare HA su Sophos Firewall descrive ruoli, sincronizzazione e comportamento locale dei nodi.

Anche in un design gateway o bridge misto il limite rimane chiaro: le interfacce normali possono inoltrare e proteggere il traffico. L’interfaccia TAP riceve solo la copia replicata.

Risolvere i problemi in base al sintomo

L’interfaccia TAP non mostra alcun pacchetto

1. Verificare la porta configurata con system discover-mode tap show.
2. In Network > Interfaces, controllare il tipo Discover, physical (TAP) e il collegamento fisico.
3. Confrontare destinazione dello switch, porte sorgente o VLAN e direzione di mirroring.
4. Ripetere un flusso di prova noto senza un filtro di cattura troppo ristretto.
5. In una VM, verificare se il percorso di rete virtuale consegna al firewall i frame estranei replicati.

Una regola firewall non è la soluzione, perché il traffico TAP non viene inoltrato tramite il normale Rule Engine.

È visibile una sola direzione

Spesso la sorgente mirror dello switch è impostata solo su RX o TX. Impostare la sessione su both, cioè entrambe le direzioni, e ripetere la stessa prova. Con routing asimmetrico, il percorso di ritorno può inoltre utilizzare un altro uplink fisico che non viene replicato.

I pacchetti sono visibili, ma i report sono vuoti o incompleti

Controllare prima intervallo temporale, tipo di report, accesso a Internet, stato dei pattern e protocolli effettivamente replicati. HTTPS non è supportato in Discover Mode. Una destinazione SPAN sovraccarica può inoltre perdere copie senza influire sul traffico di produzione.

Se mancano utenti, proseguire con la fonte di autenticazione. Se non funziona solo l’invio email, controllare prima le notifiche email. Non riavviare i servizi di reporting sulla base di un sospetto e non eliminare i dati dei report locali come primo passo.

Un report mostra rischi, ma non viene bloccato nulla

È il comportamento previsto. Discover Mode valuta una copia. Un finding diventa una successiva policy inline, segmentazione o altra misura di protezione solo dopo una valutazione tecnica. Il firewall TAP non può interrompere in seguito il flusso originale osservato.

Rimuovere Discover Mode in sicurezza

Prima del rollback, salvare report, intervalli temporali e risultati necessari. Quindi:

1. Disattivare la sessione SPAN sullo switch affinché non arrivino altre copie.
2. Rimuovere la porta di esempio nella Device Console:

system discover-mode tap delete PortD
system discover-mode tap show

3. In Network > Interfaces, verificare che la porta non appaia più come Discover, physical (TAP).
4. Rimuovere in modo controllato le pianificazioni Security Audit non più necessarie.
5. Riutilizzare normalmente la porta di destinazione dello switch solo dopo una verifica documentata.
6. Se la porta del firewall verrà utilizzata in produzione, pianificare e testare zona, IP, dipendenze e regole come modifica separata.

Non mescolare un rollback TAP con una migrazione inline improvvisata. La modalità gateway o bridge modifica routing, regole e rischio di interruzione e richiede un piano di migrazione separato.

Checklist

• L’accesso di gestione separato funziona.
• La porta TAP è fisica, libera e non viene utilizzata altrove.
• Sorgente, direzione e destinazione SPAN sono documentate.
• La destinazione mirror non è sovraccarica.
• system discover-mode tap show mostra la porta prevista.
• Packet Capture vede un flusso di prova noto in entrambe le direzioni.
• I report vengono valutati solo entro la visibilità supportata.
• HTTPS e l’assenza di enforcement sono documentati.
• L’attribuzione degli utenti è stata testata separatamente, se necessaria.
• I destinatari e la conservazione dei report sono approvati.
• I limiti HA o VM sono stati testati nell’ambiente reale.
• Rollback e successiva migrazione inline sono modifiche separate.

FAQ