Scegliere, installare e verificare Sophos Linux Sensor

Sophos Linux Sensor (SLS) raccoglie eventi di runtime Linux e li elabora con il Detection Content per generare alert o risposte configurate. Può integrarsi con l’infrastruttura esistente di log e avvisi. SLS è un sensore distinto: non è Sophos Protection for Linux (SPL), il suo XDR Sensor o una policy SPL di rilevamento a runtime.

Per un primo pilota si verificano piattaforma e diritto, si sceglie il metodo e si distribuiscono sensore e contenuto. Si segue poi un alert di prova fino al destinatario effettivamente previsto. Un servizio attivo non basta. Questa guida descrive il percorso diretto su host systemd; container e Kubernetes seguono un’altra modalità di distribuzione.

Chiarire licenza e modello operativo

Le istruzioni Sophos verificate il 27 ottobre 2026 indicano Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) o Sophos MDR Plus (Server) per accedere a SLS. Le licenze di valutazione non sono ammesse. Una qualunque licenza endpoint o la sola presenza di un server Linux non dimostrano il diritto.

SLS è concesso in licenza per dispositivo. Tuttavia, secondo Sophos, le istanze non compaiono nell’elenco server Fusion, nella vista Devices o nel relativo conteggio licenze. Occorre quindi un inventario separato dei sensori installati. Fusion può ricevere dettagli di rilevamento e alert SLS, ma non gestisce il sensore. L’assenza di una voce server SLS non equivale a una registrazione SPL fallita.

Per un normale agente server gestito con i componenti SPL richiesti, si usa Sophos Protection for Linux. SLS si valuta separatamente per immagini immutabili o particolari piattaforme container: citare un caso d’uso non approva ogni combinazione di distribuzione, kernel e runtime.

Preparare piattaforma e pilota

Alla data di verifica, le note SLS richiedono almeno 2 GB di spazio disco libero, 2 GB di memoria libera e x86_64 o ARM64. ARM64 richiede kernel 5.3 o successivo. Distribuzione precisa, minor release attuale e kernel in esecuzione devono inoltre corrispondere all’elenco delle piattaforme testate. Il kernel minimo di un’altra distribuzione non è un’approvazione universale. Le piattaforme legacy hanno condizioni di supporto separate.

Prima del pilota si registrano ruolo dell’host, distribuzione, architettura, kernel, protezione presente, profilo di carico e destinatario degli alert. L’installazione diretta richiede privilegi root/gestione pacchetti, un sistema systemd adeguato e il sottosistema di debug Linux necessario a SLS disponibile o autorizzato. Non si indebolisce preventivamente un host protetto per far proseguire uno script.

Sophos fornisce un percorso Helm specifico per Kubernetes; anche Docker, CRI-O e containerd hanno istruzioni dedicate. Si verificano accesso al registro, visibilità sull’host, privilegi, immagine del contenuto e runtime. Un comando di pacchetti di questo esempio host non va incollato invariato in un container del sensore.

Preparare il token del registro nel tenant corretto

SLS usa un Package Registry API Token distinto che inizia con SLS-. Non è l’access token OAuth temporaneo né il Client Secret di un’identità API.

La procedura SLS attuale richiede un Super Admin nella dashboard Fusion Admin del cliente, non in quella Partner o Enterprise. In Global Settings > Administration > API Credentials Management > Add Credential si crea l’identità necessaria con Service Principal Super Admin. Il responsabile deve autorizzare prima questo ampio requisito del produttore; non diventa il ruolo standard per ogni progetto API. Client ID e Client Secret, visibile una volta sola, si conservano in sicurezza.

Il processo di credenziali API e OAuth permette di ottenere il bearer token e individuare l’ID univoco del tenant cliente tramite whoami/v1. Per questo percorso, idType deve confermare il tenant cliente. Un identificatore partner non è adatto. Si invia poi un POST a /accounts/v1/access-tokens sull’host API globale Sophos, con autenticazione Bearer, X-Tenant-ID e questo JSON:

{
  "label": "SLS Pilot",
  "type": "sophosLinuxSensor"
}

label è un nome amministrativo libero; type è il valore API fisso. Nella risposta si usa il campo token per il registro, non l’ID dell’oggetto. L’eventuale expiresAt si sceglie secondo il piano di accesso; Sophos indica che una data oltre la scadenza della licenza server viene ridotta a tale scadenza. Un esempio con una data lontana non dimostra un diritto permanente.

Si controllano stato e contenuto della risposta HTTP. Token e segreti non devono finire nella cronologia shell, diagnostica proxy, ticket o screenshot. Si chiariscono prima errori di tenant, diritto o token; non si modificano alla cieca protezioni o permessi nell’intero tenant.

Installare direttamente sull’host tramite pacchetti

Si predispone prima l’accesso al registro SLS nella gestione pacchetti autorizzata. Sophos documenta packages.sophos.com/sophos-linux-sensor/release/ e la chiave sophos-linux-sensor-archive-keyring.gpg. La chiave viene ottenuta attraverso il percorso autenticato del produttore e salvata in /etc/sophos-linux-sensor.gpg. Prima dell’uso si verificano origine e fingerprint attuale tramite la catena di fiducia approvata. gpg --list-packets mostra solo un pacchetto di chiave leggibile: non ne dimostra da solo l’origine affidabile.

Host Debian supportati

In un file .list adatto sotto /etc/apt/sources.list.d/ si inserisce:

deb [signed-by=/etc/sophos-linux-sensor.gpg] https://packages.sophos.com/sophos-linux-sensor/release/ stable main

Il token associato si conserva in un file .conf con accesso limitato sotto /etc/apt/auth.conf.d/:

machine packages.sophos.com login <SLS-REGISTRY-TOKEN>

Il segnaposto si sostituisce con il token ricevuto. Solo i processi privilegiati necessari alla gestione pacchetti devono leggere il file; non si aggiunge il token anche all’URL del repository. Dopo aver verificato fiducia della firma, sorgente e permessi, nella finestra autorizzata si esegue:

sudo apt-get update
sudo apt-get install sophoslinuxsensor-systemd sophoslinuxcontent

Host RPM supportati

Il percorso RPM usa un file .repo separato sotto /etc/yum.repos.d/. Nome della sezione e nome visualizzato sono esempi liberi; URL, verifica firma e percorso chiave corrispondono al metodo documentato:

[sls]
name=Sophos Linux Sensor
baseurl=https://<SLS-REGISTRY-TOKEN>@packages.sophos.com/sophos-linux-sensor/release/
gpgcheck=1
enabled=1
gpgkey=file:///etc/sophos-linux-sensor.gpg

Si sostituisce il segnaposto con il token ricevuto. Il file che lo contiene ha accesso limitato. L’URL non deve comparire in log diagnostici, ticket o screenshot. Non si sostituiscono i repository della distribuzione e non si disabilitano i controlli di firma. Il nome visualizzato non autorizza una particolare distribuzione o versione.

Configurata correttamente la sorgente, Sophos indica questi pacchetti:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Si usa soltanto il metodo adatto alla distribuzione effettivamente supportata. Sensore e contenuto sono entrambi necessari. Il messaggio Zero policies configured significa che la verifica del rilevamento non è superata, anche se il processo è attivo. Vecchi numeri di versione negli esempi del produttore non sono requisiti di installazione attuali.

Configurare tenant e uscita degli alert

In /etc/sophos/runtimedetections.yaml si imposta customer_id all’ID verificato. Si integrano le impostazioni YAML in modo mirato, senza sovrascrivere tutto il file con un esempio. Prima dell’avvio si verificano finalità e autorizzazione dei dati di telemetria e delle destinazioni. Sophos descrive l’uscita verso stdout per impostazione predefinita; questo non collega automaticamente ogni destinatario desiderato.

Per la prima verifica controllata si documenta l’uscita reale: journal locale, sistema di logging esistente o destinatario Sophos configurato esplicitamente. Credenziali, destinazione e formato vengono predisposti per quell’uscita. La registrazione del token non dimostra l’inoltro degli alert.

Per il percorso diretto systemd si avvia e verifica:

sudo systemctl start sophoslinuxsensor
sudo systemctl status sophoslinuxsensor
sudo journalctl -u sophoslinuxsensor

In caso di errore all’avvio si controllano prima piattaforma, pacchetti, YAML effettivo e privilegi indicati nel journal. La guida d’installazione descrive le Linux Capabilities necessarie; non si sostituiscono con container indiscriminatamente privilegiati o setcap non verificati su file qualsiasi.

Verificare il rilevamento fino al destinatario

Con Default Content installato e sensore attivo si può generare l’alert documentato su un pilota autorizzato. Prima si verifica la sintassi per la versione installata: in un punto la guida d’installazione mostra -test-alert, mentre la guida di test dedicata usa --test-alert. Il comando seguente si usa solo se quella versione supporta questa forma:

sophoslinuxsensor --test-alert

Il test genera volutamente un evento. Va quindi concordato con il team ricevente, non eseguito di nascosto in produzione. È atteso Alert Tester nell’uscita configurata. Host, orario e destinatario devono corrispondere; l’esecuzione riuscita o un log locale non provano la consegna remota.

Se la sintassi non è supportata o manca l’alert, non si ricorre a vero codice malevolo o a un attacco incontrollato.

La verifica documenta almeno versioni sensore/contenuto, regole effettive, avvio senza errori, alert di prova e ricezione reale. Conferma quel percorso, non ogni rilevamento, situazione di carico o diritto a un’indagine MDR. Ulteriore carico del pilota e funzionamento delle applicazioni si confrontano con lo stato iniziale.

Regole, aggiornamenti e problemi operativi

Il contenuto standard si trova in /var/lib/sophos/content/runtimedetections-content.yaml ed è sovrascritto dagli aggiornamenti. Le personalizzazioni vanno in /etc/sophos/runtimedetections-rules.yaml, non nel file del produttore. Secondo la documentazione delle detection, Sophos supporta il contenuto standard invariato; l’assistenza per regole modificate o personalizzate va chiarita separatamente.

Core ed Enhanced differiscono per profondità e impatto sul carico. Più contenuto non è automaticamente migliore per qualsiasi server senza un pilota. Sensore e contenuto si aggiornano mediante il rollout di pacchetti o container appropriato e si verificano nuovamente; un controllo iniziale non sostituisce la gestione degli aggiornamenti.

Se mancano alert si analizzano separatamente contenuto, regole caricate, evento, uscita e inoltro. Raccogliere in sicurezza i dati di supporto SLS descrive log e pacchetti diagnostici, incluse le procedure distinte per Helm, Docker e host. Un ritiro pianificato si prepara con valori iniziali documentati, esigenze di protezione residue e procedura di disinstallazione pertinente. Non si cancellano servizi o credenziali di altri host.