Pianificare e convalidare il mirroring del traffico per Sophos NDR

Il Traffic Mirroring fornisce a Sophos NDR una copia del traffico di rete. Nelle reti locali o virtualizzate, in genere viene eseguito tramite SPAN; per le sorgenti remote, tramite ERSPAN incapsulato su GRE o VXLAN; in AWS, tramite VPC > Traffic mirror sessions. L’obiettivo non è eseguire indiscriminatamente il mirroring del maggior numero possibile di porte. NDR richiede le relazioni di traffico corrette, senza loop, duplicati superflui o un percorso di destinazione sovraccarico.

La procedura sicura consiste nel:

definire le relazioni e i confini del traffico da monitorare,
scegliere esattamente un punto di osservazione adatto per ogni relazione,
verificare la capacità dalla sorgente al sensore NDR,
iniziare con il mirroring di una piccola sorgente pilota,
convalidare per fasi la catena dalla sorgente all’elaborazione,
ampliare le sorgenti solo in modo controllato ed eseguire nuove misurazioni dopo ogni modifica.

Prima dell’attivazione, è necessario approvare e documentare la sorgente, la direzione, il filtro, la destinazione, la finestra di manutenzione, l’ambito dei dati consentito e la responsabilità del rollback. I dati sottoposti a mirroring possono contenere payload e altre informazioni sensibili. Di conseguenza, segmenti non previsti relativi a utenti, amministrazione, identità o altri dati sensibili non devono essere sottoposti a mirroring esteso in via precauzionale o «per sicurezza». La sorgente pilota viene limitata all’ambito operativo e di tutela dei dati approvato.

Selezionare le sorgenti e i punti di osservazione

Prima della configurazione è utile creare una breve matrice di copertura. Anziché elencare semplicemente tutte le porte degli switch, la matrice riporta i percorsi di comunicazione rilevanti, ad esempio:

dai client a Internet e ai servizi esterni,
dai client ai server interni,
tra server, soprattutto attraverso i confini dei segmenti o delle zone di sicurezza,
dal data center alle filiali o alle reti cloud,
traffico est-ovest tra macchine virtuali che non attraversa un uplink fisico.

Per ogni percorso si sceglie un punto in cui siano visibili entrambe le direzioni. In genere si tratta di un trunk, una VLAN o una porta vicina al confine di un segmento. Un uplink Internet offre una buona visibilità sul traffico nord-sud, ma non rileva il traffico locale all’interno della stessa VLAN. Uno switch fisico, a sua volta, non rileva il traffico che rimane all’interno dello stesso vSwitch. Queste lacune non possono essere dedotte da uno stato verde del sensore: devono emergere dalla topologia e dalla matrice di test.

Sorgente e direzione

A seconda della piattaforma, una sorgente SPAN può essere una porta, un gruppo di porte o una VLAN. Se possibile, si esegue il mirroring in modalità both, ovvero del traffico in entrata e in uscita. Il mirroring di una sola direzione può escludere risposte, errori e parti di una sessione.

Un trunk o un’intera VLAN semplifica la copertura, ma aumenta il volume dei dati e la probabilità di duplicati. Le singole porte di accesso sono più mirate, ma possono essere dimenticate più facilmente quando i sistemi vengono spostati o i carichi di lavoro sono dinamici. La scelta deve quindi basarsi sulla relazione di traffico, non sul numero di sorgenti disponibili.

Destinazione

La destinazione del mirroring è esclusivamente il percorso di acquisizione del sensore NDR:

per una VM, il gruppo di porte o il vSwitch a cui è collegato SPAN1 o SPAN2,
per una connessione fisica, la porta switch dedicata collegata all’interfaccia SPAN,
per ERSPAN, l’indirizzo di destinazione GRE o VXLAN configurato per il sensore,
in AWS, il NDR SPAN Target creato dallo stack CloudFormation.

L’interfaccia di gestione non deve essere inclusa in questa catena come destinazione SPAN. Inoltre, la porta di destinazione non deve essere utilizzata come normale sorgente e non deve inviare traffico di produzione nella rete.

Evitare loop e pacchetti duplicati

Il Port Mirroring copia i pacchetti, ma non deve reimmetterli nel percorso di inoltro della rete di produzione. Ad esempio, può crearsi un loop se la destinazione SPAN viene nuovamente sottoposta a mirroring o utilizzata come normale uplink. I dati duplicati sono più comuni: lo stesso pacchetto viene acquisito sulla porta di accesso e sull’uplink, su entrambi i lati del confine di un segmento oppure contemporaneamente tramite SPAN locale ed ERSPAN.

Prima dell’attivazione, verificare quanto segue:

L’interfaccia di destinazione è esclusivamente una destinazione e non è mai una sorgente per la stessa sessione o per una sessione sovrapposta.
Se possibile, il mirroring di un percorso di traffico end-to-end viene eseguito esattamente in corrispondenza di un solo confine significativo.
Due porte SPAN non ricevono sorgenti sovrapposte, a meno che la sovrapposizione non sia documentata e prevista per un test di durata limitata.
Il traffico broadcast e multicast non viene raccolto in più punti dello stesso dominio Layer 2.
In presenza di un cluster o di vMotion, è chiaro quale host e quale uplink ricevano il traffico sottoposto a mirroring fisico. Una VM NDR che utilizza SPAN standard da uno switch fisico deve rimanere sull’host ESXi che riceve questo traffico.
In AWS, per ogni ENI e ambito di traffico previsto esiste solo la sessione necessaria. Vengono verificati anche l’ordine delle sessioni e i filtri.

I duplicati consumano capacità di acquisizione, tunnel e CPU senza migliorare la copertura operativa. Se, dopo l’aggiunta di una sorgente, il tasso di pacchetti o byte quasi raddoppia nonostante il traffico di produzione sia rimasto invariato, si tratta di un segnale sospetto. In tal caso, disattivare l’ultima sorgente aggiunta e verificare la presenza di sovrapposizioni nella topologia.

Configurare SPAN localmente o nell’hypervisor

La sintassi esatta varia a seconda dello switch e dell’hypervisor. Indipendentemente dalla piattaforma, il modello rimane invariato: selezionare la sorgente e la direzione, definire una destinazione dedicata e assicurarsi che il gruppo di porte virtuali di acquisizione consenta la ricezione promiscua.

Per una sessione Sophos Switch, una piccola configurazione pilota potrebbe, ad esempio, eseguire il mirroring delle porte da 1 a 4 in entrambe le direzioni sulla porta 8:

configure terminal
monitor session 1 destination interface gigabitethernet 0/8 allow-ingress
monitor session 1 source interface gigabitethernet 0/1 both
monitor session 1 source interface gigabitethernet 0/2 both
monitor session 1 source interface gigabitethernet 0/3 both
monitor session 1 source interface gigabitethernet 0/4 both
save
end
show monitor session 1

I numeri delle interfacce sono esempi e devono corrispondere al cablaggio effettivo. Prima di salvare, verificare che 0/8 conduca esclusivamente al percorso di acquisizione NDR. Per gli altri produttori, utilizzare i relativi comandi SPAN documentati; nomi simili non implicano automaticamente una semantica identica.

Per un ESXi Standard vSwitch, impostare il gruppo di porte di acquisizione su VLAN ID 4095 e, in Security, impostare Promiscuous mode su Accept. Il traffico sottoposto a mirroring fisico richiede inoltre un uplink dedicato dallo switch al vSwitch appropriato. Il traffico interno delle VM può richiedere una sorgente di mirroring virtuale distinta. In Hyper-V, l’interfaccia di acquisizione NDR deve essere collegata al vSwitch corretto come destinazione del mirroring delle porte; verificare la configurazione della piattaforma separatamente dall’impostazione del sensore NDR.

Sophos NDR abilita SPAN Port 1 per impostazione predefinita; la SPAN Port 2 è disabilitata per impostazione predefinita. Una seconda porta SPAN è utile solo se riceve una sorgente distinta, senza sovrapposizioni superflue. Per SPAN Port 2, la VM richiede almeno 8 vCPU.

Utilizzare ERSPAN con GRE o VXLAN

ERSPAN trasporta al sensore, attraverso una rete IP, le copie provenienti da sorgenti remote. Il percorso di trasporto diventa quindi parte dell’analisi della capacità e degli errori: MTU, routing, ACL e l’eventuale frammentazione possono influire sull’acquisizione anche se la sessione della sorgente è configurata correttamente.

In Sophos Appliance Manager, configurare l’interfaccia di acquisizione appropriata in Settings:

VXLAN

Abilitare Enable ERSPAN accanto alla porta SPAN prevista.
In Tunnel Protocol, selezionare vxlan.
In IP Address, immettere l’indirizzo dell’interfaccia VTEP.
Impostare VXLAN ID e VXLAN Port esattamente come nella sorgente di incapsulamento.
Selezionare Save.

GRE

Abilitare Enable ERSPAN accanto alla porta SPAN prevista.
In Tunnel Protocol, selezionare gre.
In IP Address, immettere l’indirizzo dell’interfaccia di destinazione GRE.
Immettere la GRE Port corrispondente alla configurazione della sorgente.
Selezionare Save.

Le modifiche alle impostazioni SPAN diventano effettive solo dopo il riavvio della VM. Prima del riavvio, verificare se la stessa appliance elabora altre integrazioni: anche la relativa raccolta dati verrà interrotta. In seguito, convalidare nuovamente i parametri del tunnel e l’elaborazione.

L’uso congiunto di SPAN e VXLAN sulla stessa appliance è un’architettura comune. Utilizzare contemporaneamente VXLAN e GRE sulla stessa appliance solo se le sorgenti, la capacità e i domini di errore sono chiaramente separati e documentati.

Comprendere AWS Traffic Mirroring

In AWS, il modello architetturale rimane invariato: Mirror Source è l’ENI del carico di lavoro approvato, non l’ENI di gestione del sensore NDR; Mirror Target e il filtro devono appartenere all’architettura NDR distribuita. Limitare il filtro all’ambito di dati previsto. La distribuzione AWS vera e propria e la creazione della Traffic Mirror Session sono descritte in «Distribuire Sophos NDR in AWS» e non vengono ripetute qui.

Per l’accettazione, utilizzare la catena di evidenze descritta di seguito. La semplice esistenza di una sessione AWS non dimostra né il flusso dei pacchetti verso la destinazione né l’elaborazione, il caricamento o il rilevamento.

Valutare i limiti di capacità prima dell’accettazione

SPAN Port 2 non costituisce un aumento della capacità: per abilitarla, la VM richiede almeno 8 vCPU, ma il secondo ingresso aggiunge traffico e quindi carico di elaborazione. Utilizzarla solo per una sorgente distinta e non sovrapposta. Se il tasso di traffico o la perdita di pacchetti aumentano dopo l’attivazione, verificare se SPAN2 ha introdotto un carico aggiuntivo o duplicato.

«Monitorare l’integrità e la capacità di Sophos NDR» spiega come valutare i segnali relativi a stato, traffico unicast e scarti e come determinare la capacità. Per la risoluzione dei problemi in base ai sintomi, consultare «Diagnosticare la NDR Integration Appliance e il sensore». A seconda della piattaforma, le misure relative alla capacità possono includere CPU aggiuntive per la VM o una distribuzione non sovrapposta su un’altra appliance; le altre integrazioni a uso intensivo di CPU devono essere pianificate separatamente. La sola aggiunta di SPAN2 non aumenta la capacità di elaborazione.

Convalida: dalla sorgente al rilevamento

Eseguire la verifica con un host pilota noto e una finestra temporale definita. In questo modo è possibile ricondurre un errore a una fase specifica, anziché modificare contemporaneamente switch, tunnel, sensore e Sophos Fusion.

1. Configurazione e topologia

Confrontare sorgente, direzione e destinazione con la matrice di copertura.
Verificare lo stato indicato dal produttore per la sessione SPAN o AWS.
Assicurarsi che la destinazione non sia inclusa come sorgente.
Per ERSPAN, verificare l’indirizzo di destinazione, i parametri GRE o VXLAN e il percorso di rete.
Per le piattaforme virtuali, verificare l’assegnazione della NIC di acquisizione, del gruppo di porte o del vSwitch.

2. Pacchetti alla destinazione

Utilizzare traffico di test unicast controllato dall’host pilota per verificare che i pacchetti raggiungano la destinazione di acquisizione prevista. Come evidenze, registrare la finestra temporale, l’interfaccia di destinazione, gli indirizzi di origine e destinazione previsti e, se applicabile, entrambe le direzioni. Questa fase dimostra che i pacchetti verificati hanno raggiunto la destinazione prevista, ma non ancora che siano stati elaborati o caricati. Il solo traffico broadcast non costituisce un test affidabile. Se mancano dei pacchetti, limitare inizialmente l’analisi a sorgente, filtro, direzione, trasporto e gruppo di porte virtuali.

3. Acquisizione e flusso sulla porta SPAN prevista

In Sophos Appliance Manager > NDR, registrare per la specifica porta SPAN prevista il valore di acquisizione visualizzato in percentuale e l’attività nel grafico Total Flow durante la finestra di 30 secondi. Entrambi devono coincidere temporalmente con il traffico pilota. Ciò dimostra la presenza di attività sull’ingresso selezionato; le indicazioni non dimostrano né l’acquisizione completa dei pacchetti né l’ambito corretto dei dati, entrambe le direzioni o il corretto caricamento.

L’attuale classificazione Sophos considera integra una porta SPAN quando almeno il 2% dei pacchetti di rete è unicast. Questo valore è esclusivamente il classificatore minimo di integrità: si limita a escludere una percentuale unicast pari a zero nel campione osservato. Anche un flusso errato, parziale, duplicato, obsoleto o inadatto allo scopo può soddisfare la soglia del 2%. Il valore non dimostra quindi la sorgente e la direzione previste, la presenza di traffico utile, la copertura, il valore di acquisizione visualizzato, il caricamento o il rilevamento. I riferimenti precedenti al 100% di traffico unicast non vengono utilizzati come requisito attuale.

4. Elaborazione e caricamento

In Sophos Appliance Manager > NDR, registrare il valore di caricamento visualizzato in percentuale per la stessa finestra temporale e confrontarne la tempistica con l’attività di acquisizione e flusso. In questo modo si documenta l’attività di caricamento, ma non si dimostra che ogni pacchetto sottoposto a mirroring sia stato caricato o che venga successivamente generato un rilevamento. Connected conferma principalmente la connessione dell’appliance e non sostituisce queste evidenze. Se i segnali relativi a integrità, acquisizione, caricamento e scarti non coincidono, seguire la diagnosi sistematica dell’appliance e del sensore.

5. Copertura operativa

Per ogni riga della matrice di copertura, generare traffico di test mirato e consentito e registrare l’ora, il dispositivo di test, il segmento previsto, la sorgente, la destinazione e la direzione. Associare a questo test le evidenze delle fasi da 2 a 4. Solo questi campioni dimostrano che, in linea di principio, i percorsi verificati vengono acquisiti; non costituiscono una prova per segmenti o finestre temporali non verificati.

6. Rilevamento end-to-end innocuo

Solo dopo aver completato correttamente l’accettazione del mirroring, eseguire la procedura separata e approvata «Generare e verificare un rilevamento di test sicuro per Sophos NDR». La generazione del test non viene descritta in questa sede. Verificare il risultato relativo al dispositivo di test e alla finestra temporale previsti in Threat Analysis Center > Detections e collegarlo alla precedente catena di evidenze. Un rilevamento di test osservato in questa sezione dimostra il funzionamento del percorso end-to-end verificato; non garantisce né il rilevamento di ogni tecnica di attacco né la copertura di altri percorsi.

Circoscrivere le discrepanze fase per fase

Se l’accettazione non riesce, esaminare solo la prima fase priva delle evidenze previste: il percorso effettivo della sorgente, la direzione e il filtro; quindi il cablaggio della destinazione o l’assegnazione dell’acquisizione virtuale; per ERSPAN, successivamente il trasporto e i valori corrispondenti del tunnel; poi l’acquisizione e il flusso sulla porta prevista; infine il caricamento e il rilevamento. Uno stato verde o almeno il 2% di traffico unicast non consente di saltare nessuna di queste fasi. Apportare una sola modifica alla volta ed eseguire una nuova misurazione con lo stesso sistema pilota e la stessa finestra temporale.

Se manca solo una direzione o un segmento, confrontare la matrice di copertura con il percorso fisico o virtuale effettivo, senza aggiungere preventivamente altri segmenti sensibili o tutte le porte. Se la frequenza è insolitamente elevata, confrontare singolarmente le sovrapposizioni documentate con i contatori e la visibilità del traffico pilota. Questa procedura termina con l’accettazione del mirroring e la localizzazione dell’errore; in caso di errori del sensore, di caricamento o della piattaforma, proseguire con la diagnosi dell’appliance e del sensore.

Eseguire in sicurezza il rollback delle modifiche apportate con questa procedura

Prima di ogni ampliamento, registrare ID sessione, sorgenti, direzioni, filtri, destinazione, parametri del tunnel e tassi di riferimento. Il seguente rollback riguarda esclusivamente le modifiche di mirroring introdotte da questa procedura; non fornisce istruzioni per la rimozione di un’appliance, di uno stack cloud o di altre infrastrutture.

In caso di problemi, eseguire il rollback in ordine inverso:

rimuovere l’ultima sorgente locale aggiunta; eliminare una AWS Traffic Mirror Session creata appositamente per questa procedura,
ripristinare l’ultimo filtro ampliato all’ambito pilota documentato,
disabilitare ERSPAN se è stato appena abilitato oppure ripristinare i valori precedenti del tunnel,
disabilitare SPAN Port 2 se ha introdotto il nuovo carico o la sovrapposizione,
ripristinare la sessione precedente dello switch se è stato modificato un mirroring fisico,
verificare nuovamente il flusso dei pacchetti, il tasso di scarto, lo stato dell’integrazione e il traffico pilota.

Anche per il rollback delle impostazioni SPAN di Sophos sono necessari Save e il riavvio della VM prima che la modifica diventi effettiva. È inoltre necessario considerare l’impatto sulle altre integrazioni della stessa appliance. Il rollback è completo solo quando non soltanto lo stato è tornato verde, ma anche i percorsi pilota precedentemente documentati sono visibili senza nuovi duplicati e senza perdite di pacchetti tali da causare problemi.