Diagnosticare l'appliance di integrazione e il sensore Sophos NDR

Questo runbook aiuta a circoscrivere i problemi dell’NDR Integration Appliance e del sensore NDR. Parte dallo stato esatto visualizzato in Sophos Fusion, interpreta gli stati e i valori misurati visibili e indica quando raccogliere i log per Sophos Support.

Lo stato Connected o il colore verde sono solo verifiche intermedie. Non dimostrano né la copertura completa del mirroring, né il corretto upload di ogni set di dati, né il funzionamento del rilevamento end-to-end.

Procedura rapida

1. Annotare il nome dell’appliance, il System ID, l’ora di inizio del problema con il fuso orario e il testo esatto del messaggio.
2. In Sophos Fusion controllare il colore e lo stato dell’appliance, senza ancora riavviare nulla.
3. In Appliance Manager consultare Status, NDR, Integrations e Advanced e acquisire screenshot con data e ora.
4. Ricondurre il sintomo a una categoria: piattaforma/CPU, egress/upload, SPAN, registrazione o risorse condivise.
5. Eseguire una sola correzione reversibile all’interno della categoria individuata.
6. Ricontrollare gli stessi indicatori con un carico paragonabile.
7. Se i segnali sono contraddittori, i container non sono pronti o la correzione non produce risultati, raccogliere i log ed eseguire l’escalation.

Sintomo, verifica e passo successivo

Interpretare correttamente rosso, giallo e verde

Rosso: l’integrazione non funziona

In presenza del colore rosso, il messaggio specifico è più importante del colore:

• NDR containers not ready, <specific container names>. indica che almeno un’applicazione necessaria non è pronta. Se viene indicato dragonfly o il suo stato visibile è anomalo, iniziare la verifica dalla compatibilità della CPU e dai requisiti della piattaforma.
• Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error> indica che l’appliance ha tentato un upload mediante un URL prefirmato verso un bucket S3 e ha ricevuto un codice di errore. Si tratta principalmente di un problema di egress/proxy.
• spanX: unhealthy span riconduce il problema all’ingresso della porta SPAN indicata. Verificare innanzitutto il componente di rete che invia il traffico o il percorso di mirroring virtuale.

Giallo: l’integrazione funziona con errori

spanX: packets being dropped compare quando viene scartato più del 10% dei pacchetti di rete. L’acquisizione e l’elaborazione dei pacchetti richiedono molte risorse CPU. Per una VM potrebbero servire vCPU aggiuntive; con hardware certificato, il carico può essere distribuito su un’altra appliance in base al piano di copertura approvato. I Log Collector presenti sulla stessa appliance possono consumare le medesime risorse.

Tuttavia, un semplice aumento della capacità non corregge origini di mirroring sovrapposte, un percorso di destinazione sovraccarico o una configurazione SPAN errata. Prima di scalare le risorse, confrontare quindi il profilo del traffico e la topologia.

Verde: nessun errore di integrazione attualmente segnalato

Il verde indica che NDR riceve traffico SPAN ed elabora i dati dei pacchetti senza segnalare problemi. L’attuale classificatore dello stato di integrità richiede che una porta SPAN sana riceva almeno il 2% di pacchetti unicast. Questo non dimostra che vengano acquisite tutte le VLAN, le sedi, le direzioni o gli intervalli temporali desiderati. La precedente indicazione secondo cui una porta dovrebbe mostrare il 100% di traffico unicast non viene utilizzata.

Per interpretare nel dettaglio i segnali relativi a integrità e capacità, consultare «Monitorare integrità e capacità di Sophos NDR».

Se, nonostante lo stato verde, i rilevamenti attesi non compaiono, eseguire prima il test di rilevamento NDR sicuro. Se anche questo test non fornisce riscontri e si sospetta un problema VLAN, raccogliere per Sophos Support l’intervallo temporale, la porta SPAN, la VLAN selezionata e lo stato visibile dell’appliance. Modificare VLAN Strip solo dopo che l’analisi ha confermato che al sensore arrivano sia la VLAN selezionata sia VLAN0; in caso contrario, lasciare invariata l’impostazione.

Circoscrivere gli eventi locali con NDR Query

Quando è necessario verificare separatamente acquisizione e upload, NDR Query in Appliance Manager può mostrare il livello degli eventi locali. La query viene eseguita sul database degli eventi NDR di questa VM dell’appliance, non sul Sophos Data Lake. Va distinta chiaramente dall’Investigation Console, distribuita separatamente, che rende disponibili per il threat hunting nella rete locale i dati di un’appliance NDR assegnata.

1. Annotare l’appliance interessata e l’intervallo temporale del problema.
2. Aprire NDR Query e, in Query, selezionare Example queries.
3. Copiare una query predefinita appropriata con Copy, incollarla nel campo di testo ed eseguirla con Go.
4. Salvare il risultato in Query Results con data e ora; se necessario, riordinare le colonne mediante trascinamento.
5. Confrontare il risultato con l’attività in NDR e con lo stato di Fusion nello stesso intervallo temporale.

Al momento, Appliance Manager supporta qui soltanto query predefinite. Non utilizzare query SQL personalizzate né query dell’Investigation Console. Un risultato locale in presenza di dati mancanti in Fusion indirizza la verifica successiva verso upload ed egress. Un risultato locale vuoto indirizza dapprima la verifica verso l’ingresso SPAN, l’intervallo temporale e la query predefinita selezionata; da solo non dimostra un errore.

Valutare i rilevamenti Nmap imprevisti

Se in altri prodotti di sicurezza compaiono nuove scansioni del sistema operativo basate su Nmap, controllare lo stato di OS Detection in Global NDR Settings. Questa opzione, disattivata per impostazione predefinita, una volta attivata esegue ogni due ore una scansione di tutti gli indirizzi IP interni rilevati da NDR. Di conseguenza, può generare rilevamenti in altri prodotti di sicurezza.

Confrontare l’ora di attivazione, l’appliance interessata, gli indirizzi IP di destinazione e l’ora dei rilevamenti. Se l’attivazione non è autorizzata, le destinazioni non sono consentite o si verificano impatti operativi, disattivare nuovamente OS Detection e documentare l’ora. Monitorare quindi che non compaiano nuovi eventi di scansione causati da questa funzione; gestire le segnalazioni già esistenti secondo la procedura del rispettivo strumento. Non ripetere manualmente i comandi Nmap e non creare eccezioni negli altri prodotti di sicurezza soltanto per nascondere il sintomo. Se la funzione deve rimanere attiva, sono necessarie l’autorizzazione documentata dei responsabili di rete e sicurezza e una convalida per almeno un intervallo completo di due ore.

Circoscrivere i sintomi di container e Dragonfly senza CLI

Dragonfly elabora i dati NDR. Ai fini della diagnosi sono rilevanti due situazioni visibili:

• Un messaggio rosso relativo a container non pronti può comparire se dragonfly è bloccato in un ciclo di riavvio perché mancano istruzioni CPU necessarie.
• Se in Fusion l’appliance è Connected, ma i dati non raggiungono il Data Lake e in Advanced Dragonfly risulta Pending, in un cluster VMware EVC occorre verificare la modalità EVC. Sophos richiede Skylake generation or later; Sandy Bridge non è supportato.

Per le VM NDR su VMware ESXi o Hyper-V devono essere disponibili i flag CPU pdpe1gb e avx2. pdpe1gb è necessario per l’acquisizione dei pacchetti, mentre avx2 serve per le funzionalità di machine learning. Aggiungere vCPU non compensa l’assenza dei flag. Su Hyper-V, Processor Compatibility Mode non è supportato. Per ESXi sono inoltre richiesti VM Hardware versione 11 o successiva e i requisiti di piattaforma documentati.

Verifica sicura:

1. In Advanced, documentare lo stato e il nome visibile del container interessato.
2. In Status, registrare utilizzo della CPU, memoria, Root Disk e Data Disk.
3. Confrontare hypervisor, modello CPU, impostazione EVC o di compatibilità e flag forniti alla VM con la documentazione della piattaforma approvata.
4. Correggere un’impostazione errata dell’hypervisor o della CPU solo durante una finestra di manutenzione pianificata; prima annotare il valore iniziale e la procedura di rollback.
5. Convalidare quindi lo stato della VM e dell’appliance tramite le normali interfacce operative.
6. Se dragonfly rimane Pending, un container non diventa pronto o è visibile un ciclo di riavvio, creare un bundle di log ed eseguire l’escalation.

I valori di piattaforma e i requisiti CPU supportati sono riepilogati in «Sophos NDR: scegliere la piattaforma e dimensionare correttamente il sensore».

Verificare l’upload S3 e la connessione in uscita

Un errore di upload S3 non significa che non arrivi traffico SPAN. Acquisizione e upload sono due fasi distinte. In Appliance Manager, sotto NDR, registrare quindi l’attività di acquisizione/dei flow e il valore Uploaded per lo stesso intervallo temporale.

Verificare il percorso di egress in questo ordine:

1. La configurazione dell’IP MGMT, tramite DHCP o manuale, corrisponde alla rete di gestione?
2. La risoluzione DNS e NTP funzionano tramite i servizi previsti?
3. La route predefinita passa dal percorso Internet o egress centrale previsto?
4. Network ACL, Security Group o firewall locale consentono il traffico HTTPS in uscita?
5. Il proxy Web consente l’accesso dell’appliance alle destinazioni necessarie senza modificare o bloccare la richiesta S3 prefirmata?
6. Le regole corrispondono alle eccezioni di porta e dominio Sophos attualmente pubblicate?

Non copiare da vecchi ticket l’elenco dei domini regionali senza caratteri jolly. Al momento della verifica, confrontarlo con gli Appliance requirements aggiornati. Un accesso temporaneo e indiscriminato a Internet non è un test sicuro. Applicare le modifiche una alla volta e, dopo ogni passaggio, eseguire la convalida usando lo stesso intervallo temporale del problema.

Rollback: al termine del test, ripristinare il valore iniziale di qualsiasi regola proxy, ACL o firewall modificata a scopo di verifica, a meno che la modifica non sia necessaria in modo permanente. Durante il ripristino devono continuare a funzionare i percorsi di gestione e upload delle altre integrazioni.

SPAN non integro, packet drop o flow mancanti

spanX: unhealthy span

Per la porta indicata, verificare:

• origine e direzione di mirroring previste;
• interfaccia di destinazione dedicata e cablaggio fisico;
• associazione della scheda di rete di acquisizione, del gruppo di porte o del vSwitch;
• per ERSPAN, indirizzo di destinazione, routing, MTU e valori GRE o VXLAN;
• ultime modifiche a VLAN, trunk, gruppo di porte, collocazione dell’host o sessione di mirroring;
• se la stessa destinazione è stata accidentalmente configurata di nuovo come origine del mirroring.

Da un host pilota, generare traffico unicast noto e innocuo e osservare, nello stesso intervallo temporale, la porta SPAN prevista e l’andamento dei flow. Se non si rileva attività, continuare la diagnosi su origine, direzione, filtro, trasporto o associazione dell’acquisizione. Valutare elaborazione e upload solo dopo aver dimostrato che il traffico arriva in ingresso.

spanX: packets being dropped

Quando i drop superano il 10%, raccogliere inoltre:

• vCPU assegnate e CPU per core;
• larghezza di banda, pacchetti/s e flow/s;
• origini di mirroring aggiunte di recente o sovrapposte;
• andamento di memoria, Root Disk e Data Disk;
• tutti i Log Collector presenti sulla stessa appliance, con Received, Filtered, Accepted e Uploaded.

Per un’appliance condivisa, il dimensionamento parte dai requisiti NDR; in seguito si considera il carico dei Collector. Come ulteriori valori limite, l’intera appliance supporta al massimo 8.000 eventi Collector al secondo e, con 16 GB di RAM, al massimo 2 GB per i Log Collector. Anche i core CPU occupati da NDR possono essere condivisi con altre integrazioni, riducendo la capacità NDR. Se è necessario distribuire il carico dei Collector, definire prima responsabilità e appliance di destinazione, quindi seguire la guida generale alle integrazioni; questo runbook non modifica origini syslog specifiche dei produttori.

Con 4 vCPU, DPDK mantiene normalmente un core al 100%; con 8 vCPU, ne mantiene due al 100%. Da solo, questo comportamento è normale. Un problema di capacità è dimostrato dalla concomitanza di drop, altri core saturi, upload in diminuzione o variazioni nell’andamento dei flow.

La catena di mirroring, la convalida con un host pilota e un rollback circoscritto sono descritti in «Pianificare e convalidare il mirroring del traffico per Sophos NDR».

Diagnosticare la registrazione e lo stato Connected

Una nuova appliance compare inizialmente come Waiting for deployment. Dopo il completamento del bootstrap e l’attivazione del percorso di gestione, lo stato dell’appliance in Threat Analysis Center > Integrations > Configured > Integration Appliances passa a Connected.

Se il passaggio non avviene:

1. identificare l’appliance corretta in base a nome, piattaforma e immagine o seed generato;
2. controllare che l’avvio della VM non presenti errori persistenti o cicli di riavvio;
3. verificare IP MGMT, VLAN, DHCP o valori manuali, gateway e DNS;
4. confrontare NTP ed egress necessario con gli attuali requisiti dell’appliance;
5. su ESXi, usare l’OVA generato da Fusion per un solo tentativo di deployment. Per le altre piattaforme, verificare la procedura di deployment aggiornata;
6. documentare l’orario, lo stato visibile e l’ultimo output del bootstrap, senza includere segreti.

Non eliminare né reinstallare l’appliance. Questo runbook non include volutamente procedure di dismissione o sostituzione. Connected conferma la connessione e l’associazione centrali, ma non la copertura SPAN, l’upload o il rilevamento.

Se l’appliance era già Connected e perde questo stato, verificare innanzitutto il percorso di gestione, l’egress e la disponibilità dell’appliance. Le impostazioni di mirroring non sono il primo elemento da controllare, perché SPAN e gestione seguono percorsi separati.

Verificare l’accesso ad Appliance Manager, non il sensore

Se Open Appliance Manager si apre ma l’accesso con zadmin non riesce, si tratta innanzitutto di un problema di autenticazione, non di una prova relativa a SPAN, upload o Dragonfly. Se la password è stata dimenticata, nel dialogo di conferma di Open Appliance Manager usare il collegamento reset it e impostare una nuova password. Salvare subito la nuova password nel sistema delle password; né la vecchia né la nuova password devono comparire in screenshot, registri operativi o casi di supporto.

Se l’account è stato bloccato a causa di troppi inserimenti errati della password, il percorso alternativo documentato è la console Web dell’hypervisor che ospita l’appliance: nella Weblink interface selezionare Unlock Account. Questo percorso alternativo presuppone un accesso già autorizzato alla console Web dell’hypervisor; il runbook non aggiunge comandi di shell, SSH o console e non ne deduce altri percorsi di accesso. Verificare quindi l’accesso una sola volta con la password conservata in modo sicuro. Se l’account resta bloccato, non provare altre password: documentare l’ora e il messaggio visibile e coinvolgere Sophos Support.

Configurazione di gestione offline come ultimo passaggio di ripristino locale

In Appliance Manager, Actions > Settings > Management può essere modificato localmente soltanto se la VM non dispone di connettività di rete. Se la connettività è disponibile, la modifica deve essere effettuata in Sophos Fusion. Il fatto che la VM sia offline non crea di per sé un nuovo accesso: la correzione locale presuppone una procedura di ripristino già esistente e autorizzata. In assenza di tale accesso, acquisire l’IP MGMT attuale, l’ultimo stato noto in Fusion e i dati della piattaforma, quindi eseguire l’escalation.

Prima di selezionare Save, confrontare i valori precedenti e quelli nuovi per IP Assignment, IPv4/Netmask, Gateway IP, DNS, DNS 2 e, se pertinenti, Enable Web Proxy, Web Proxy Type, Proxy URL e Port Number. Le credenziali del proxy devono restare nel sistema delle password. Modificare soltanto il valore di cui è stato accertato l’errore. Se l’interfaccia richiede di confermare un riavvio, si tratta di un riavvio dell’appliance: NDR e tutti i log collector vengono interrotti. Documentare quindi prima i carichi di lavoro condivisi, la finestra di manutenzione, il nuovo indirizzo IP previsto e il percorso di ripristino.

Dopo l’applicazione della modifica, verificare la raggiungibilità tramite il nuovo indirizzo IP, lo stato in Fusion, l’acquisizione e l’upload NDR e tutti i log collector. Se l’accesso di ripristino autorizzato è ancora disponibile e la verifica non riesce, annullare esattamente l’ultima modifica ripristinando i valori iniziali acquisiti. Se l’interfaccia non è più raggiungibile, non tentare indirizzi o valori proxy a caso: eseguire l’escalation con baseline, ora e impatto. I controlli preliminari e successivi completi sono descritti in «Gestire in sicurezza l’appliance e il sensore Sophos NDR».

Appliance condivisa: proteggere le altre integrazioni

Prima di qualsiasi riavvio o modifica delle risorse in Fusion, aprire la freccia accanto al nome dell’appliance e annotare tutte le integrazioni eseguite sulla stessa appliance. In Appliance Manager, Integrations ne mostra lo stato, l’ultimo riavvio e i contatori syslog.

• Un singolo Log Collector può essere riavviato separatamente tramite Restart; NDR e le altre integrazioni rimangono attivi.
• Restart All interessa tutti i Log Collector, ma non NDR.
• Restart NDR interessa il sensore NDR, non i Log Collector.
• Actions > Restart interessa l’intera VM e interrompe NDR e tutti i Log Collector.
• Actions > Shutdown arresta l’intera VM e tutte le integrazioni; è necessario disporre di un percorso di riaccensione verificato separatamente.

Il riavvio dell’intera VM non è il primo passo della diagnosi. Raccogliere prima stati e valori misurati e individuare il componente più piccolo interessato. Gli impatti e la sequenza operativa sicura sono descritti in «Gestire in sicurezza l’appliance e il sensore Sophos NDR».

Raccogliere dati diagnostici e log

Pacchetto di base

Prima di apportare modifiche, raccogliere:

• nome dell’appliance, System ID, Version, K3S Helm Chart version e Uptime;
• stato in Fusion e testo esatto dell’errore;
• ora di inizio, ora di riproduzione e fuso orario;
• in Status, CPU per core, memoria, Root Disk e Data Disk;
• in NDR, acquisizione per ogni porta SPAN configurata, Uploaded e andamento dei flow;
• in Integrations, tutti i Log Collector eseguiti sulla stessa appliance, con stato e contatori;
• in Advanced, stato visibile dei container e ora dell’ultimo riavvio visibile;
• piattaforma, risorse VM, profilo del traffico e ultime modifiche;
• risultato atteso, risultato effettivo e impatto sull’attività.

Se Appliance Manager non è accessibile

1. In Fusion aprire Threat Analysis Center > Integrations > Configured > Integration Appliances.
2. Nel menu con i tre puntini dell’appliance interessata selezionare Collect logs.
3. Nella colonna Log requested, aprire la notifica informativa e annotare il nome del file visualizzato.
4. Comunicare a Sophos Support il nome del file insieme all’appliance, all’intervallo temporale e al testo dell’errore.

Se Appliance Manager è accessibile

1. Nel menu con i tre puntini selezionare Open Appliance Manager, quindi Open.
2. In Appliance Manager selezionare Actions > Download Log File.
3. Trasmettere l’archivio dei log al caso esistente esclusivamente tramite il canale di supporto concordato.

Gli archivi dei log possono contenere indirizzi IP, nomi host e altri dati operativi riservati. Password di zadmin, token, chiavi private, credenziali proxy e altri segreti non devono mai essere inseriti in ticket, screenshot o allegati.

Abilitare Remote Assistance in modo controllato

Abilitare Remote Assistance solo per un caso di supporto specifico. L’appliance deve essere online.

1. In Fusion aprire Threat Analysis Center > Integrations > Configured > Integration Appliances.
2. Nel menu con i tre puntini selezionare Remote Assistance.
3. Nel dialogo attivare Enable.
4. Selezionare la conferma relativa alla Sophos Group Privacy Notice, quindi Save.
5. Attendere che venga visualizzato un Access ID.
6. Inviare a Sophos Support esclusivamente questo Access ID, tramite il canale concordato.

L’accesso termina automaticamente entro un massimo di sette giorni. Se l’analisi termina prima, disattivare Enable nello stesso dialogo e documentare la fine dell’accesso. Remote Assistance non sostituisce né un caso di supporto né il pacchetto diagnostico.

Convalidare e annullare una correzione in sicurezza

Modificare una sola ipotesi per ciclo. Prima di intervenire, annotare valore iniziale, persona responsabile, finestra di manutenzione e procedura di rollback. In seguito, con un carico paragonabile, verificare che:

• il precedente messaggio rosso o giallo non ricompaia;
• lo stato previsto dell’appliance e il percorso di gestione rimangano stabili;
• ogni porta SPAN prevista mostri un’attività coerente con il traffico pilota;
• andamento dei flow e upload rimangano stabili per un intervallo significativo;
• non ricompaia alcun messaggio relativo a più del 10% di drop;
• CPU al di fuori dei core DPDK previsti, memoria e spazio di archiviazione dispongano di margine sufficiente;
• tutti i Log Collector presenti sulla stessa appliance continuino a elaborare dati;
• una modifica della piattaforma renda disponibili i flag CPU necessari e la modalità supportata.

Se la verifica non riesce o compaiono nuovi effetti, annullare esattamente l’ultima modifica apportata. Se non è possibile ripristinare lo stato iniziale, non effettuare altre modifiche: raccogliere i dati diagnostici e aprire un caso presso Sophos Support.

Anche dopo la correzione tecnica, un’integrazione verde non costituisce una prova di rilevamento. Solo dopo aver stabilizzato la catena di mirroring e upload, eseguire la procedura «Generare e verificare un rilevamento di test Sophos NDR sicuro».

Eseguire l’escalation a Sophos Support

Aprire un caso presso Sophos Support se:

• NDR containers not ready persiste oppure dragonfly rimane visibilmente Pending o in un ciclo di riavvio;
• i flag CPU necessari non sono disponibili nonostante la piattaforma sia corretta;
• un errore di upload S3 persiste nonostante siano stati verificati DNS, proxy, firewall e percorso di egress;
• spanX: unhealthy span persiste nonostante siano state verificate origine, direzione e associazione della destinazione;
• i packet drop ricompaiono dopo un adeguato aumento della capacità o una corretta distribuzione del carico;
• lo stato Connected, l’upload locale e la ricezione nel Data Lake forniscono indicazioni contraddittorie;
• il bootstrap non completa la registrazione o l’appliance passa inaspettatamente da uno stato all’altro;
• una correzione sicura richiederebbe interventi di basso livello su container, Kubernetes o Dragonfly.

Allegare al caso il pacchetto di base, il nome del file di log o l’archivio dei log, i passaggi esatti e i risultati misurabili. Indicare chiaramente le ipotesi già escluse. Sophos Support gestisce i problemi del prodotto durante installazione, amministrazione e funzionamento; il caso non è una richiesta di indagine su un rilevamento.

Un rilevamento basato su XDR e gestito autonomamente rimane responsabilità del cliente. Solo un caso MDR gestito da Sophos viene analizzato e gestito da Sophos MDR. Per creare il caso ed eseguire l’escalation, consultare «Aprire un ticket Sophos con Support Assistant».