Sophos Linux Sensor: raccogliere i dati di supporto in sicurezza

In caso di problemi con Sophos Linux Sensor (SLS), raccogliere un archivio di supporto e i log del sensore pertinenti, possibilmente mentre si verifica l’errore o subito dopo. La raccolta richiede circa 30 secondi. Innanzitutto identificare il tipo di deployment: con Helm la raccolta si esegue per ciascun nodo interessato, con Docker sull’host Docker e, per un’installazione diretta, sull’host Linux. Dopo il segnale di debug, il download deve seguire immediatamente; la finestra di debug temporanea dura 60 secondi.

Questa guida si applica esclusivamente a Sophos Linux Sensor. SLS non è Sophos Protection for Linux (SPL), né il suo XDR Sensor né il suo criterio Linux Runtime Detection. La collocazione nella panoramica dei server serve alla navigazione e non rende i prodotti equivalenti. Per SPL si applica la guida all’installazione e alla gestione separata; i comandi SLS riportati di seguito non devono essere utilizzati in quel contesto.

Verificare il sistema di destinazione e l’autorizzazione prima della raccolta

Prima di inviare un segnale o eseguire un riavvio, confermare tramite l’inventario dei deployment e l’istanza in esecuzione che sia effettivamente coinvolto SLS. Nel caso di supporto vanno registrati host o cluster, namespace, pod, nodo o container, versione del sensore installata e ora dell’errore con fuso orario. Le informazioni sulla versione presenti nell’archivio raccolto successivamente completano questa identificazione. Questa guida segue la procedura di supporto aggiornata il 5 ottobre 2026; ciò non implica una versione minima o un’approvazione per qualsiasi versione precedente del sensore, di Helm, Kubernetes o Docker. In caso di nomi o porte diversi oppure di endpoint di monitoraggio assente, chiarire prima con il supporto il deployment effettivo.

È necessaria una directory di lavoro con accesso protetto e spazio libero sufficiente. I nomi di file mostrati di seguito sono relativi a questa directory; prima di ripetere la raccolta, salvare separatamente i pacchetti esistenti per evitare che vengano sovrascritti. Limitare l’accesso ad archivio, log e profili alle persone incaricate e stabilire un periodo di conservazione. Per i download, gli indirizzi di monitoraggio devono rimanere locali. Non configurare servizi pubblici, Ingress o porte di debug accessibili a tutti.

Gli strumenti devono essere già approvati e disponibili. Se curl non è presente su un host Linux con installazione diretta, la procedura documenta questi comandi di installazione:

# Sistemi basati su Red Hat
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Utilizzare solo il comando appropriato per la distribuzione, nell’ambito del processo approvato di gestione dei pacchetti. L’installazione di un pacchetto modifica l’host; non fa parte della semplice verifica dell’articolo. Per Helm e Docker sono necessari anche tar e gzip. In assenza degli strumenti o delle autorizzazioni necessari, fermarsi prima di attivare il debug.

Helm: un pacchetto per ciascun nodo interessato

Sul computer di amministrazione, kubectl deve essere configurato per il cluster corretto. Le autorizzazioni devono consentire di elencare i pod, leggere i log dei pod, inoltrare le porte dei pod e aggiungere un container di debug effimero. Inoltre, il runtime dei container deve supportare il targeting del namespace dei processi di un altro container. Su questo computer sono necessari curl, tar e gzip.

Il cluster deve poter scaricare busybox:latest. Se questo registry non è approvato, copiare preventivamente l’immagine in un registry approvato e raggiungibile e sostituire solo il valore di --image con questo riferimento all’immagine verificata. Non allentare le regole di sicurezza dei registry per forzare la raccolta. Il container effimero costituisce una modifica al pod e richiede la relativa autorizzazione operativa.

Scegliere il pod e mantenere attivo il port-forward

Il chart Helm di SLS distribuisce un pod del sensore per ogni nodo Linux monitorato. Sostituire <namespace> con il namespace della release SLS:

kubectl --namespace <namespace> \
get pods \
--selector app=sophos-linux-sensor \
--output wide

L’output deve associare il pod del sensore al nodo interessato. <sensor-pod> indica esattamente questo pod, <node-name> il nome del suo nodo. Non utilizzare un pod qualsiasi funzionante della stessa release.

Nel primo terminale, inoltrare la porta di monitoraggio:

kubectl --namespace <namespace> \
port-forward pod/<sensor-pod> 9010:9010

Questo terminale deve rimanere aperto fino al completamento del download. Se la porta locale è già occupata, interrompere la procedura e risolvere il conflitto anziché terminare un processo estraneo. Non aggiungere binding a indirizzi accessibili pubblicamente. Se l’inoltro si interrompe, deve essere nuovamente attivo prima di ripetere il download.

Inviare il segnale, scaricare immediatamente e aggiungere i log

Nel secondo terminale, il container di debug viene indirizzato al container SLS. Il comando invia SIGUSR2 al processo del sensore; non è un’istruzione per terminare il sensore:

kubectl --namespace <namespace> \
debug pod/<sensor-pod> \
--image=busybox:latest \
--target=sophos-linux-sensor \
--attach=false -- \
pkill -USR2 -f '[s]ophoslinuxsensor'

Il pattern di ricerca [s]ophoslinuxsensor impedisce a pkill di individuare la propria riga di comando. Se il download dell’immagine, l’autorizzazione o il targeting dei processi non riescono, la raccolta non è stata attivata in modo affidabile. Non aggiungere alla cieca altri container di debug; chiarire prima il messaggio di errore.

Subito dopo, eseguire il download nel secondo terminale:

curl --fail --silent --show-error \
--max-time 120 \
http://127.0.0.1:9010/support.tar \
--output sophos-linux-sensor-support-<node-name>.tar

--max-time 120 limita la durata della chiamata HTTP, ma non prolunga la finestra di debug. Successivamente salvare i log attuali dello stesso container e nodo:

kubectl --namespace <namespace> \
logs pod/<sensor-pod> \
--container sophos-linux-sensor \
--timestamps \
> sophos-linux-sensor-<node-name>.log

Elencare il contenuto senza estrarlo:

tar -tf sophos-linux-sensor-support-<node-name>.tar

Dopo la verifica di completezza descritta di seguito, terminare il port-forward nel primo terminale con Ctrl+C. Per ogni ulteriore nodo interessato, utilizzare il relativo pod e un nome di file univoco.

Docker: verificare il container in esecuzione e la porta pubblicata

Tutti i comandi seguenti vengono eseguiti sull’host Docker con le autorizzazioni Docker approvate su quell’host. Il container SLS deve essere in esecuzione; la sua porta di monitoraggio deve essere già pubblicata sull’host. La porta predefinita nel container è 9010. Devono essere disponibili curl, tar e gzip. Questa procedura non prescrive la pubblicazione successiva di una porta o il riavvio di un container come intervento correttivo.

docker ps
docker port <sensor-container> 9010/tcp

<sensor-container> è il nome o l’ID del container SLS confermato. Il secondo output indica l’indirizzo e la porta dell’host. <host-port> va sostituito con questa porta, non automaticamente con 9010. Il download seguente presuppone che l’indirizzo pubblicato sia raggiungibile tramite 127.0.0.1 su questo host Docker. Se il binding è esclusivamente su un altro indirizzo o non viene restituito alcun output, verificare prima il deployment; non aggiungere una porta accessibile pubblicamente.

Il comando seguente modifica lo stato di debug per 60 secondi. In questo contesto, docker kill non deve essere eseguito senza --signal=SIGUSR2:

docker kill --signal=SIGUSR2 <sensor-container>

Subito dopo, scaricare dall’endpoint locale pubblicato:

curl --fail --silent --show-error \
http://127.0.0.1:<host-port>/support.tar \
--output sophos-linux-sensor-support.tar

I log e la verifica dell’archivio fanno parte dello stesso pacchetto:

docker logs <sensor-container> \
> sophos-linux-sensor.log 2>&1

tar -tf sophos-linux-sensor-support.tar

La modalità debug temporanea termina automaticamente. Una nuova interrogazione con docker ps deve continuare a mostrare il container previsto in esecuzione; questo da solo, tuttavia, non dimostra che il rilevamento funzioni.

Host Linux con installazione diretta: utilizzare la modalità debug temporanea

Questo ramo si applica a SLS in esecuzione direttamente sull’host, non a un container e non a /opt/sophos-spl. Sono necessari privilegi di root e accesso alla porta di monitoraggio locale. Per un’installazione systemd, verificare preventivamente con journalctl -u sophoslinuxsensor che il journal appartenga al servizio e all’host previsti. Se il servizio è assente o sono presenti più istanze del sensore, chiarirne prima l’associazione.

Il comando per l’host documentato agisce su tutti i processi attivi sull’host che corrispondono al pattern sophoslinuxsensor. Non limita l’azione a una singola istanza. Non eseguirlo senza autorizzazione per queste istanze o se i nomi dei processi non sono chiari.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

Il sensore rende quindi disponibili le informazioni di supporto e debug sull’endpoint di monitoraggio per 60 secondi. Eseguire immediatamente la raccolta nella directory di lavoro preparata:

curl -O http://localhost:9010/support.tar && gzip support.tar

La raccolta richiede circa 30 secondi. Dopo la compressione riuscita, è disponibile support.tar.gz. Questa chiamata sull’host non include né un controllo degli errori HTTP né un timeout; pertanto, l’esistenza di un file o il completamento riuscito di gzip non dimostrano che l’archivio sia completo. Per la verifica locale, senza estrarre il pacchetto:

tar -tzf support.tar.gz

I log dell’host si leggono con:

journalctl -u sophoslinuxsensor

Per l’osservazione continua è inoltre documentata questa chiamata:

journalctl -efu sophoslinuxsensor

Terminare l’osservazione con Ctrl+C e salvare le informazioni del journal necessarie per il periodo dell’errore tramite il percorso di esportazione approvato. Non considerare un output continuo senza limite come un pacchetto di supporto completato.

Verificare l’archivio, circoscrivere gli errori e trasmetterlo in sicurezza

Un archivio di debug completo contiene voci come runtimedetections.yaml, environment.json, goroutine.out e profile.out, oltre a informazioni sulle metriche e sulla versione. Le voci indicate sono esempi, non una garanzia di contenuti identici per ogni versione. tar deve poter elencare l’archivio senza errori. Una pagina di errore HTML, un pacchetto vuoto o un download interrotto non costituiscono un risultato utilizzabile.

Se il pacchetto contiene solo metrics.txt e version.json, la raccolta di debug non era attiva. Verificare l’istanza di destinazione, eventuali errori nell’invio del segnale e l’intervallo di tempo. Quindi inviare nuovamente SIGUSR2 nel ramo di deployment appropriato e ripetere immediatamente il download. Nel ramo Helm, il port-forward deve rimanere attivo per tutta la durata del download. In caso di errori ripetuti, inoltrare il problema al supporto con il messaggio di errore esatto, la versione del sensore e l’ora dell’errore; non aggirarlo tramite una modalità debug persistente o una porta di rete aperta.

Archivi, log e profili possono contenere configurazioni riservate, variabili d’ambiente e informazioni sull’host e sull’ambiente di esecuzione. Anche se alcune parti della configurazione vengono oscurate automaticamente, il pacchetto non è automaticamente anonimizzato per la condivisione pubblica.

Prima della trasmissione, verificare l’elenco dei file e, ove necessario, i contenuti in un ambiente isolato per individuare credenziali, token, nomi host interni e dati personali. Per gli oscuramenti utilizzare una copia separata e documentare le modifiche; non modificare i profili binari in modo incontrollato. Chiarire con il supporto quali contenuti devono rimanere invariati per la diagnosi. Conservare l’originale solo con accesso protetto e per il periodo concordato.

Trasmettere l’archivio e i log associati esclusivamente tramite il canale di supporto Sophos approvato e confermato nel caso di supporto. Verificare il destinatario e la destinazione di caricamento sulla base del caso esistente, non di un messaggio non richiesto. Non utilizzare ticket pubblici, forum, repository Git o archivi multimediali della KB. Il pacchetto deve includere tipo di deployment, nodi o host interessati, versione del sensore, ora dell’errore con fuso orario, sintomo e passaggi di raccolta già eseguiti; non inviare credenziali nel testo di accompagnamento.

Profili CPU e memoria solo per esigenze specifiche

Per un normale archivio di supporto è sufficiente il segnale temporaneo. I singoli profili seguenti costituiscono una procedura separata per problemi di CPU o memoria e utilizzano il formato pprof di Google. Per l’attivazione del debug configurata in modo persistente, occorre stabilire preventivamente come viene avviato il servizio SLS effettivo e come ripristinarne la configurazione.

Innanzitutto salvare il contenuto precedente di /etc/sophos/runtimedetections-rules.yaml, il valore precedente o l’assenza di debug e l’ambiente di avvio effettivo. In particolare, determinare se RUNTIMEDETECTIONS_DEBUG sia già impostata. Anche una copia di backup di questa configurazione è riservata. Non confonderla con il file dal nome simile runtimedetections.yaml nell’archivio di supporto.

Scegliere una delle modalità di attivazione documentate:

• Eseguire il sensore con RUNTIMEDETECTIONS_DEBUG=true nel suo ambiente di avvio effettivo. Un semplice export in una shell di amministrazione non modifica l’ambiente di un servizio già in esecuzione.
• Impostare debug: true in /etc/sophos/runtimedetections-rules.yaml, senza sostituire le altre regole o creare una seconda voce in conflitto.

Un riavvio interrompe il servizio SLS. Prima del riavvio, confermare l’autorizzazione alla manutenzione, la tollerabilità dell’interruzione del rilevamento e l’accesso alla configurazione originale. Questa chiamata systemd si applica all’installazione diretta sull’host; non è una procedura di riavvio per Helm o Docker.

Eseguire il riavvio documentato con privilegi di root:

systemctl restart sophoslinuxsensor

Successivamente controllare lo stato del servizio e il journal. Raccogliere i profili necessari sull’endpoint locale solo quando il servizio è in esecuzione e la configurazione è valida:

curl -s http://localhost:9010/debug/pprof/heap > heap.out
curl -s 'http://localhost:9010/debug/pprof/profile?seconds=60' > profile.out

heap.out raccoglie campioni dell’occupazione di memoria degli oggetti heap attivi; profile.out registra l’utilizzo della CPU per 60 secondi. Queste chiamate non includono un controllo degli errori HTTP: la sola creazione di un file non dimostra che il profilo sia valido. Non interpretare file vuoti o risposte di errore come valori misurati; verificare l’endpoint e la configurazione di debug effettiva e, se necessario, convalidare il formato con il supporto. Anche questi file restano riservati.

Le metriche, invece, non richiedono né la modalità debug né un riavvio dovuto al debug:

curl -s http://localhost:9010/metrics > metrics.out

Ripristinare lo stato di debug e lo stato operativo

Per la raccolta temporanea, non inviare altri segnali dopo la finestra di 60 secondi. Lasciare il sensore in esecuzione e verificare tramite i suoi log o il monitoraggio operativo esistente che continui a funzionare normalmente. Un processo in esecuzione o un endpoint delle metriche raggiungibile non costituiscono una prova completa del funzionamento del rilevamento e della trasmissione dei dati. In caso di comportamento anomalo, collaborare con il supporto.

Con il debug configurato in modo persistente, non avviene alcun ripristino automatico dopo 60 secondi. Ripristinare nel file YAML il valore di debug salvato in precedenza oppure la sua assenza originale e riportare allo stato precedente, nella configurazione di avvio effettiva, una variabile RUNTIMEDETECTIONS_DEBUG impostata appositamente per questa diagnosi. Non sovrascrivere indiscriminatamente altre impostazioni o l’intera configurazione eventualmente modificata nel frattempo. La modifica esatta dell’ambiente dipende dal meccanismo di avvio esistente; senza uno stato di riferimento noto non esiste un comando universale di ripristino sicuro.

Per il servizio systemd installato direttamente, dopo questo ripristino utilizzare nuovamente il comando systemctl restart sophoslinuxsensor mostrato sopra, nella finestra di manutenzione approvata. Verificare nel servizio e nel journal la presenza di errori di avvio o configurazione, confrontare l’impostazione di debug effettiva con lo stato precedente e controllare che non rimanga alcun accesso ai profili attivato appositamente per la diagnosi. Se il debug era già attivo in precedenza, disattivarlo è una decisione operativa aggiuntiva, non un ripristino.

Terminare il port-forward di Helm e confermare che il relativo processo nel terminale sia terminato. Il container di debug effimero non può essere rimosso dal pod esistente come un normale container; non eliminare un pod del sensore solo per ripulire l’ambiente dopo questa diagnosi. Se la policy locale del cluster richiede la sostituzione del pod, l’operatore responsabile deve pianificarla separatamente, tenendo conto dell’interruzione del rilevamento e del controllo del rollout.

Dopo la conferma di ricezione da parte del supporto e la scadenza del periodo di conservazione stabilito, rimuovere secondo la policy locale di eliminazione gli specifici file di archivio, log e profilo generati e le copie temporanee usate per gli oscuramenti. Non eseguire eliminazioni con caratteri jolly e non eliminare regole del sensore, log del prodotto o altri casi di supporto. L’eliminazione di un file non garantisce la sovrascrittura di backup, snapshot o blocchi SSD; la loro conservazione rientra nella policy di archiviazione e protezione dei dati pertinente.