Distribuire Sophos NDR su VMware ESXi o Hyper-V

Sophos NDR viene eseguito su ESXi o Hyper-V come Integration Appliance virtuale. La VM richiede due percorsi chiaramente separati: MGMT ottiene un normale indirizzo IP e raggiunge Sophos Fusion (in precedenza Sophos Central) o Sophos Data Lake; SPAN1 e, facoltativamente, SPAN2 ricevono esclusivamente copie mirror del traffico da analizzare. Una VM verde o lo stato Connected in Central non confermano quindi, da soli, che NDR rilevi i pacchetti.

Procedura sintetica: verificare prerequisiti e capacità, creare la configurazione NDR in Sophos Fusion, predisporre il mirroring in base alla piattaforma, distribuire una sola volta l’immagine generata, attendere il completamento del primo avvio e del riavvio automatico, quindi convalidare separatamente i percorsi di gestione e SPAN.

Limite importante: il percorso SPAN non è inline e non deve essere usato come rete di gestione. Il mirroring viene configurato sullo switch e sull’hypervisor; l’appliance NDR non modifica il traffico di produzione originale. Per Hyper-V, in questa guida non vengono intenzionalmente forniti comandi PowerShell esterni per il mirroring. Implementare il progetto in Hyper-V secondo le linee guida Microsoft e Sophos approvate e verificarlo con traffico di test reale.

Verificare obbligatoriamente i prerequisiti

A entrambe le piattaforme si applicano inizialmente questi requisiti minimi:

• un’autorizzazione Sophos Network Detection and Response integration license pack attiva nel tenant utilizzato;
• 4 vCPU, 16 GB di RAM e 160 GB di spazio di archiviazione;
• i flag CPU pdpe1gb per Packet Capture e avx2 per le funzionalità di machine learning;
• una rete di gestione dedicata con DHCP o indirizzo statico, DNS, gateway predefinito e accesso a Internet in uscita;
• percorsi SPAN predisposti per copie bidirezionali di tutte le classi di traffico approvate: traffico virtuale interno e traffico fisico esterno, se entrambi rientrano nell’ambito di monitoraggio concordato;
• responsabilità documentate per Central, hypervisor, switch fisici e allowlist del firewall.

Se l’ambito approvato include effettivamente una sola di queste classi di traffico, documentare esplicitamente tale limite. In questo caso, un singolo percorso SPAN non deve essere considerato una copertura anche dell’altra classe.

Non installare sull’appliance un Sophos Agent aggiuntivo né altri agent antimalware. Sophos gestisce gli aggiornamenti del sistema operativo, della sicurezza e dell’appliance. Requisiti personalizzati di patching o hardening non devono modificare questo stato gestito senza una verifica preventiva.

Limiti delle piattaforme

VMware ESXi richiede:

• ESXi 6.7 Update 3 o versione successiva;
• VM hardware version 11 o successiva;
• in caso di utilizzo di Enhanced vMotion Compatibility, una modalità EVC Skylake o successiva;
• nessuna distribuzione in VMware Cloud, perché non è supportata.

I flag CPU devono restare visibili nella VM anche con la modalità EVC selezionata. Un processore fisico recente non è sufficiente se EVC nasconde le funzionalità necessarie.

Microsoft Hyper-V richiede:

• Hyper-V 6.0.6001.18016, corrispondente a Windows Server 2016, o versione successiva;
• Processor Compatibility Mode disattivata;
• non più di 8 core CPU e 32 GB di RAM per ogni VM NDR;
• al massimo un nodo NUMA e un socket CPU.

I limiti di Hyper-V non sono una raccomandazione ad assegnare sempre alla VM le risorse massime. Servono a evitare una topologia NUMA non supportata.

Dimensionare la VM in base al traffico

La configurazione standard con 4 vCPU è prevista per un’appliance dedicata esclusivamente a NDR fino ai seguenti valori indicativi:

• 500 Mbit/s,
• 70'000 pacchetti al secondo,
• 1'200 flussi al secondo.

Per carichi elevati fino a 1 Gbit/s, 300'000 pacchetti al secondo o 4'500 flussi al secondo, utilizzare 8 vCPU. Anche SPAN2 richiede almeno 8 vCPU. Se il carico supera questi valori, distribuirlo tra più appliance NDR in punti di rete appropriati; non aumentare le risorse di una singola VM oltre i limiti documentati.

Se sulla stessa appliance vengono eseguite anche integrazioni log collector, pianificarne separatamente il carico. NDR riserva con priorità elevata due CPU con 4 vCPU e tre CPU con 8 vCPU. Le altre integrazioni possono comunque gravare su queste CPU. Con 16 GB di RAM, le integrazioni log collector possono utilizzare complessivamente non più di 2 GB. Indipendentemente dal numero di integrazioni, un’appliance accetta al massimo 8'000 eventi di log al secondo. Per ogni appliance è possibile una sola integrazione NDR.

Consentire le connessioni in uscita

Se il firewall supporta i caratteri jolly, l’appliance richiede le seguenti destinazioni:

yum.oracle.com è facoltativo perché, se non riesce a raggiungerlo, l’appliance utilizza il mirror JFrog di Sophos. Non estendere indiscriminatamente i caratteri jolly ad altre zone. Se il firewall non consente i caratteri jolly, prima della modifica aggiungere all’allowlist l’elenco completo e aggiornato degli hostname Sophos specifici per la regione e verificarlo dalla zona MGMT mediante test DNS e di connettività. Un elenco abbreviato o copiato da un’altra regione non è un’alternativa sicura.

Creare l’integrazione e l’immagine in Sophos Fusion

1. In Sophos Fusion, aprire Threat Analysis Center > Integrations > Marketplace.
2. Selezionare Sophos Network Detection and Response (NDR).
3. In Data Ingest (Security Alerts), fare clic su Add Configuration.
4. In Step 1, inserire un nome univoco e una descrizione dell’integrazione.
5. In Step 2, selezionare un’appliance esistente oppure fare clic su Create new appliance. Un’appliance esistente non deve già disporre di un’altra integrazione NDR.
6. Per una nuova appliance, scegliere un Appliance name univoco, una descrizione e la piattaforma corretta, VMware ESXi o Microsoft Hyper-V.
7. In Internet-facing network port settings, configurare DHCP oppure Manual. Un indirizzo assegnato tramite DHCP deve essere riservato.
8. In Step 3, inserire un Exclusion list name. Questo nome è obbligatorio anche se inizialmente l’elenco è vuoto.
9. Concludere facendo clic su Save.

Per Manual, compilare i campi IP address, Subnet mask, Gateway address, DNS 1 e, facoltativamente, DNS 2. Ecco un esempio interno:

• IP address: 10.0.252.5
• Subnet mask: 255.255.255.0
• Gateway address: 10.0.252.1
• DNS 1: 10.0.252.53
• DNS 2: 10.0.252.54

Sostituire questi valori con indirizzi disponibili e server DNS raggiungibili della propria rete di gestione. Verificare preventivamente l’indirizzo statico rispetto al pool DHCP, all’IPAM e agli host esistenti.

In Domain exclusions è possibile inserire un nome di dominio. Protocol exclusions dispone di un campo per il protocollo principale, ad esempio TCP o UDP, e di un campo per il sottoprotocollo, ad esempio facebook; quando sono specificati entrambi, Central li unisce con un singolo punto. Non escludere un intero protocollo principale soltanto per ridurre il volume dei dati. Ogni esclusione richiede un falso positivo confermato o una decisione motivata relativa alla capacità, un responsabile e una data di revisione.

Dopo il salvataggio, nella colonna Actions selezionare il download specifico per la piattaforma: Download OVA file per ESXi oppure il pacchetto ZIP per Hyper-V. Lo stato a sinistra dell’integrazione passa a Waiting for deployment. L’immagine contiene la configurazione specifica dell’appliance e non deve essere riutilizzata tra tenant o appliance diversi.

Distribuire su VMware ESXi

1. Preparare i port group SPAN

Per il traffico virtuale interno, creare un port group dedicato sullo standard vSwitch interessato:

1. Aprire Networking > Virtual switches e selezionare il vSwitch previsto.
2. In Port groups, fare clic su Add port group.
3. Assegnare un nome univoco.
4. Impostare VLAN ID su 4095.
5. In Security, impostare Promiscuous mode su Accept.
6. Salvare il port group.

Per il traffico sottoposto a mirroring da uno switch fisico, utilizzare un vSwitch separato con un proprio port group SPAN configurato nello stesso modo. In vSwitch topology, utilizzare Add uplink per assegnare una NIC fisica libera. Collegare direttamente la porta di destinazione mirror dedicata dello switch fisico a questa NIC dell’host ESXi.

Sullo switch fisico, selezionare come sorgenti mirror esclusivamente le porte o le VLAN approvate e scegliere entrambe le direzioni. La porta di destinazione trasporta le copie alla NIC ESXi e non deve essere utilizzata contemporaneamente come normale porta di accesso, trunk o gestione. La sintassi esatta dello switch dipende dal produttore e non deve essere copiata da un esempio relativo a un modello diverso.

Se SPAN fisico e vMotion vengono utilizzati insieme, la VM NDR deve rimanere sull’host ESXi la cui NIC fisica riceve il traffico mirror. Una migrazione involontaria su un altro host può rimuovere senza segnali evidenti il percorso SPAN, anche se MGMT continua a funzionare.

2. Importare l’OVA e associare le interfacce

L’OVA scaricato è legato a questa configurazione di Central e può essere utilizzato una sola volta. Per una sostituzione o una nuova distribuzione, generare un nuovo OVA in Central.

1. Sull’host ESXi, aprire Virtual Machines > Create/Register VM.
2. Selezionare Deploy a virtual machine from an OVF or OVA file.
3. Inserire un nome per la VM e selezionare ndr-sensor.ova.
4. Selezionare Standard come tipo di storage, quindi scegliere il datastore previsto.
5. In Deployment options, associare con attenzione le reti:
   • SPAN1: primo port group SPAN predisposto;
   • SPAN2: secondo port group SPAN, se effettivamente necessario;
   • SYSLOG: per un’appliance dedicata esclusivamente a NDR, selezionare un port group segnaposto e disconnettere l’adattatore dopo l’importazione;
   • MGMT: il port group di gestione con DHCP o con i parametri di rete statici inseriti in Central.
6. Impostare Disk Provisioning su Thin.
7. Attivare Power on automatically.
8. Ignorare Additional settings senza apportare modifiche e importare facendo clic su Finish.

Prima di accendere la VM per la prima volta, documentare nuovamente l’associazione, lo stato del collegamento e gli indirizzi MAC di tutte le vNIC. MGMT non deve trovarsi su un port group SPAN. Se si utilizza SPAN2, la VM deve disporre di almeno 8 vCPU.

Distribuire su Microsoft Hyper-V

1. Preparare il progetto di mirroring

Prima di eseguire lo script, stabilire la funzione di ogni vSwitch:

• un normale vSwitch per MGMT con DHCP o con il percorso di rete statico pianificato;
• un percorso di destinazione per SPAN1;
• facoltativamente, un secondo percorso di destinazione per SPAN2, in tal caso con almeno 8 vCPU;
• nessun percorso SYSLOG attivo, a meno che la stessa appliance non elabori anche integrazioni di prodotti di terze parti approvate.

Per Hyper-V, la configurazione del mirroring comprende concettualmente quattro elementi: una porta di mirroring del traffico, una SPAN Virtual Interface collegata al vSwitch, la Microsoft NDIS Capture Extension attivata e le modalità di mirroring Source e Destination configurate correttamente. L’implementazione dipende dalla versione di Windows/Hyper-V, dal tipo di vSwitch e dall’origine del traffico da sottoporre a mirroring. Per questo motivo, non utilizzare comandi PowerShell non verificati e provenienti da altri ambienti.

Prima di avviare NDR, il team della piattaforma verifica il percorso previsto come smoke test della distribuzione mediante un flusso di test bidirezionale noto. La copia deve arrivare al percorso di destinazione previsto senza modificare il flusso di produzione originale. Solo a quel punto questo vSwitch viene selezionato come destinazione SPAN nello script Sophos. Questo singolo test non conferma la copertura completa del mirroring.

2. Estrarre lo ZIP ed eseguire lo script Sophos

1. Estrarre lo ZIP scaricato da Central in una cartella locale protetta sull’host Hyper-V. Contiene dischi virtuali, seed.iso e ndr-sensor.ps1.
2. Nella cartella, avviare ndr-sensor.ps1 con Run with PowerShell.
3. Quando viene visualizzato Security Warning, verificare il file locale scaricato direttamente da Central e autorizzarlo con Open.
4. Inserire un nome univoco per la VM.
5. Controllare la nuova directory della VM visualizzata nel percorso predefinito per i dischi virtuali e immettere C per crearla.
6. Specificare 4 CPU per la configurazione standard oppure 8 CPU per un carico elevato o SPAN2.
7. Specificare 16 GB di RAM come valore standard; non superare il limite Hyper-V di 32 GB.
8. Dall’elenco numerato dei vSwitch, selezionare prima il vSwitch MGMT.
9. Per SYSLOG su un’appliance dedicata esclusivamente a NDR, selezionare un vSwitch segnaposto e disconnettere questo adattatore dopo la creazione.
10. Selezionare il vSwitch predisposto per SPAN1 e, se previsto, quello per SPAN2.
11. Attendere Installation Completed Successfully, quindi premere un tasto qualsiasi per terminare lo script.
12. Aprire la nuova VM in Hyper-V Manager e, prima di avviarla, verificare CPU, RAM, adattatori di rete, vSwitch collegati e adattatore SYSLOG disconnesso.

I dischi virtuali e seed.iso generati da Sophos costituiscono un unico insieme. Non sostituire singoli file con file omonimi di un download precedente.

Primo avvio e smoke test della distribuzione

Durante il primo avvio, l’appliance verifica le reti assegnate e l’accesso a Internet, quindi si riavvia automaticamente. Questa procedura può richiedere fino a dieci minuti.

Non interrompere il primo avvio e il riavvio automatico. Spegnere manualmente la VM durante questa fase può lasciarla in uno stato incompleto e non costituisce un passaggio per la risoluzione dei problemi.

Eseguire lo smoke test tecnico della distribuzione nel seguente ordine:

1. Console della VM: il processo di avvio termina senza un ciclo persistente di errori o riavvii.
2. Percorso di gestione: l’indirizzo MGMT configurato o riservato, DNS, NTP e le destinazioni in uscita richieste sono raggiungibili.
3. Percorso di controllo Central: in Threat Analysis Center > Integrations > Configured > Integration Appliances o nella pagina dell’integrazione NDR, l’appliance passa da Waiting for deployment a Connected.
4. Percorso SPAN: per ogni percorso SPAN distribuito, generare un flusso di test annunciato e innocuo in entrambe le direzioni tra due sistemi di test noti. Sullo switch o sull’hypervisor, Source, Direction e Destination devono corrispondere alla modifica; sull’appliance, l’adattatore SPAN associato deve ricevere traffico.
5. Plausibilità: confrontare l’intervallo temporale, gli indirizzi di origine e destinazione e la direzione del flusso di test osservato. Il percorso distribuito in questione è confermato per questo smoke test soltanto se tali valori corrispondono.
6. Carico: durante una prima finestra di carico appropriata, confrontare throughput, pacchetti e flussi con il livello di dimensionamento selezionato. Lo stato Connected non dimostra la capacità.

Per lo smoke test della distribuzione non è necessaria una singola detection artificiale. Ciò che conta è un percorso di gestione stabile e la prova del traffico bidirezionale sull’interfaccia SPAN corretta. Il flusso di test non contiene malware né dati reali dei clienti in un Packet Capture.

Questo smoke test dimostra soltanto i percorsi sottoposti specificamente a test. L’accettazione completa di tutte le sorgenti, VLAN, direzioni e classi di traffico previste rientra nel runbook separato Pianificare e convalidare il mirroring del traffico per Sophos NDR; né Connected né un singolo flusso riuscito vengono qui considerati prova di una copertura mirror completa.

Risolvere i problemi in base al sintomo

Lo stato rimane Waiting for deployment

1. Verificare che sia stata distribuita l’immagine corretta, appena scaricata da questa configurazione.
2. Controllare la console e lo stato di alimentazione della VM e attendere almeno dieci minuti senza interruzioni per il primo avvio.
3. Confrontare la vNIC MGMT, il port group o il vSwitch e la prenotazione DHCP o i campi statici.
4. Verificare DNS, gateway, NTP, TCP 443, TCP 22 e UDP 123 dalla rete di gestione in base all’allowlist.
5. Ripetere la distribuzione solo dopo questi controlli. Su ESXi è necessario un OVA appena generato; non importare di nuovo l’OVA già utilizzato.

Connected, ma nessun traffico NDR

Su ESXi, verificare innanzitutto l’associazione SPAN1/SPAN2, VLAN ID 4095, Promiscuous mode: Accept, l’uplink fisico e la porta di destinazione mirror. Se si utilizza vMotion, controllare che la VM sia ancora in esecuzione sull’host con la NIC SPAN collegata.

Su Hyper-V, il team della piattaforma controlla SPAN Virtual Interface, NDIS Capture Extension, la modalità Source/Destination e il vSwitch selezionato nello script Sophos. Non aggiungere regole firewall o comandi di mirroring inventati sulla base di supposizioni.

Su entrambe le piattaforme, non restringere immediatamente il filtro di test: controllare prima i contatori degli adattatori e un flusso bidirezionale chiaramente identificabile. Il traffico MGMT sull’adattatore MGMT non dimostra che SPAN funzioni.

È visibile una sola direzione o una sola rete

• La sorgente mirror deve includere sia l’invio sia la ricezione.
• Con il routing asimmetrico, il percorso di ritorno può utilizzare un uplink diverso.
• Il traffico virtuale interno e quello fisico esterno possono richiedere percorsi SPAN separati.
• Se è configurato SPAN2, il secondo vSwitch o port group deve essere associato correttamente e devono essere disponibili almeno 8 vCPU.

Dopo ogni correzione, ripetere esattamente lo stesso flusso di test. In questo modo è possibile individuare la modifica che ha prodotto l’effetto.

Dragonfly rimane Pending

Se Central è già Connected ma NDR non funziona, verificare lo stato del servizio Dragonfly nella Sophos VA Console. Prima di questo passaggio, l’accesso locale alla console deve essere stato predisposto secondo il runbook separato Gestire Sophos NDR Integration Appliance e il sensore. A tale scopo, non riutilizzare senza verifica le credenziali dell’hypervisor o di Central; questo runbook di distribuzione non crea né comunica credenziali locali dell’appliance.

In caso di stato Pending in un cluster EVC ESXi, verificare innanzitutto la modalità EVC e le funzionalità CPU visibili. Sandy Bridge non è supportato per questo utilizzo; sono richiesti Skylake o versione successiva, nonché pdpe1gb e avx2.

Su Hyper-V, verificare inoltre Processor Compatibility Mode, i limiti di CPU e RAM e la topologia con non più di un nodo NUMA e un socket CPU. Non tentare di «correggere» la VM aggiungendo CPU o RAM oltre i limiti supportati.

Sotto carico mancano pacchetti o risultati

Confrontare throughput, pacchetti e flussi correnti con i limiti di dimensionamento. Se una destinazione SPAN è più lenta dell’insieme delle sue sorgenti, la copia può perdere pacchetti mentre il traffico di produzione continua senza interruzioni. In tal caso, restringere la selezione delle sorgenti, suddividere i percorsi SPAN o utilizzare più appliance. Esclusioni estese di protocolli non sostituiscono un dimensionamento corretto.

Rollback locale limitato di questa distribuzione

I passaggi seguenti sono una raccomandazione prudente per il rollback locale della distribuzione passiva descritta in questa guida. Non costituiscono una procedura completa di dismissione o offboarding documentata da Sophos. Il rollback è intenzionalmente limitato agli oggetti del sensore e del mirroring appena creati nell’ambito della modifica:

1. Salvare le prove dei test e gli ultimi stati noti: stato di Central, risorse della VM, associazione delle interfacce, sorgenti e direzioni del mirroring.
2. Disattivare innanzitutto la sessione SPAN o di mirroring sullo switch o sull’hypervisor. Durante l’operazione, non eliminare né ricablare porte sorgente, VLAN o vSwitch di produzione.
3. Verificare che il traffico originale continui a funzionare e che non arrivino più copie al percorso di destinazione NDR.
4. Quindi arrestare correttamente la VM NDR.
5. Rimuovere port group, vSwitch, uplink o file della VM dedicati soltanto dopo aver confermato che siano utilizzati esclusivamente da questa appliance. Gli oggetti condivisi di gestione o produzione rimangono invariati.
6. Rimuovere la prenotazione DHCP statica, le voci dell’allowlist del firewall e i record DNS introdotti per la distribuzione mediante modifiche separate, dopo averne verificato i riferimenti.

L’integrazione o l’appliance in Central non viene eliminata nell’ambito di questo rollback locale. Tale eliminazione non rientra nel rollback della distribuzione e richiede un processo di offboarding separatamente convalidato e approvato. Analogamente, un OVA esistente non viene considerato un’immagine di rollback: per una nuova distribuzione ESXi, generare una nuova immagine in Central.

Dopo un primo avvio non riuscito, il rollback locale limitato consiste quindi nell’interrompere il mirroring, spegnere la VM, rimuovere esclusivamente gli oggetti di rete chiaramente associati a questa modifica e individuare la causa prima di una nuova distribuzione. Non trasformare spontaneamente un test NDR passivo in un altro progetto di rete o in un percorso inline.