Installare e distribuire Sophos Protection for Linux

Importante distinzione tra prodotti: la guida di onboarding Sophos include una sezione Deployment to Linux all’interno del percorso Endpoint. I relativi collegamenti per Linux rimandano però a Server Protection e Sophos Protection for Linux (SPL) in Sophos Fusion. Linux non utilizza quindi l’installer Endpoint per Windows/macOS descritto nei capitoli adiacenti, ma un agente Linux Server specifico, con policy, requisiti, note di rilascio e procedure d’installazione propri.

Il processo complessivo, dalla preparazione del tenant alla gestione operativa, è descritto nel percorso di onboarding Endpoint. Questo articolo ne tratta esclusivamente il percorso per i server Linux.

Per un singolo server Linux, scegliere innanzitutto la modalità di protezione in My Environment > Installers: Download Linux Server Installer per la protezione antimalware completa oppure Download XDR Sensor Linux Server Installer per il solo XDR Sensor, privo di protezione antimalware propria. Rendere eseguibile l’installer SophosSetup.sh scaricato per il tenant e la modalità previsti e avviarlo con privilegi di root. Per più sistemi, distribuirlo tramite un sistema di distribuzione software controllato ed eseguire prima --test. Se SPL è già incluso nel template di una VM, occorre seguire il processo per gold image Linux documentato da Sophos, affinché ogni clone riceva un’identità dispositivo distinta. Per ambienti di auto-scaling, load balancing o grandi parchi di VM, Sophos consiglia di valutare questo approccio.

Prima del primo dispositivo pilota

Autorizzare l’installazione solo dopo aver verificato quanto segue:

• Licenza e livello di protezione desiderato: in Server Protection sono disponibili due download Linux distinti. XDR Sensor richiede una licenza XDR e, secondo Sophos, non protegge autonomamente dalle minacce; occorre quindi una protezione di terze parti. Verificare la modalità desiderata e la licenza disponibile prima del download.
• Piattaforma supportata: distribuzione, versione, architettura e kernel devono corrispondere all’attuale matrice di supporto SPL. Sophos elenca nelle note di rilascio le piattaforme testate e i requisiti di sistema correnti. Per varianti non elencate, hardened, minime, personalizzate o legacy esistono limiti di supporto specifici. SPL non va forzato sulle distribuzioni immutabili: per queste Sophos rimanda al prodotto distinto Sophos Linux Sensor.
• Requisiti di base: alla revisione dei contenuti del 14 settembre 2026, le note di rilascio SPL richiedevano 2,5 GB di spazio libero, 2 GB di memoria libera, architettura x86_64 o ARM64, un’istanza supportata di systemd in esecuzione, Bash e glibc 2.17 o successiva, oppure 2.18 o successiva su ARM64. ARM64 richiedeva inoltre kernel 5.3 o successivo. L’installer necessitava di curl; il plug-in AV richiedeva setcap dal pacchetto libcap2-bin, libcap o libcap-progs. Questa base datata non sostituisce l’attuale verifica per l’approvazione.
• Accesso alla rete: durante e dopo l’installazione il dispositivo deve poter raggiungere Sophos Fusion. Testare DNS, HTTPS, proxy, TLS Inspection ed eventualmente Message Relay e Update Cache da ogni rete server prevista secondo i requisiti di rete e proxy.
• Protezione esistente: Sophos Anti-Virus for Linux non può funzionare insieme a SPL. SAV va rimosso prima dell’installazione oppure migrato invocando l’installer con --uninstall-sav. Con il solo XDR Sensor deve invece rimanere attiva una protezione di terze parti, perché il sensore non offre protezione antimalware. Prima del pilota con la protezione antimalware SPL completa, valutare separatamente l’eventuale coesistenza di altri antivirus in base alle dichiarazioni di supporto dei rispettivi produttori.
• Piano di rollout: documentare prima dell’avvio gruppo di destinazione, gruppo Central, componenti da installare, dimensione del pilota, criteri di arresto, finestra di manutenzione e procedura di ripristino.

Mantenere aggiornate le informazioni su release, piattaforme e rete

Questo articolo costituisce la base di verifica interna per i requisiti specifici di Linux. Il responsabile controlla le note di rilascio SPL e la matrice di supporto di distribuzioni e kernel nel portale Sophos ogni mese e prima di ogni progetto pilota e di ogni ondata di rollout. Nel change vanno registrati data della verifica, responsabile, release, distribuzione, versione, architettura, kernel, risorse minime, scostamenti e decisione di approvazione. Se le informazioni correnti differiscono dalla base datata sopra, aggiornare i criteri del pilota e questo articolo prima dell’ondata successiva; i vecchi valori non costituiscono un’approvazione.

La guida di rete collegata gestisce il processo comune per allow list e proxy, comprese le destinazioni specifiche di Linux e dipendenti dalla licenza. Per pacchetti software, aggiornamenti graduali, Update Cache e Message Relay, seguire anche Aggiornamenti, cache e Message Relay di Sophos Endpoint. Il pilota Linux deve comunque convalidare il percorso effettivo e la versione SPL installata da ogni rete server prevista.

Verificare prima file system e risorse

Solo per la protezione antimalware completa con il prodotto antivirus installato: SPL può analizzare e mettere in quarantena in modo affidabile solo i file presenti su file system espressamente supportati. Alla verifica delle fonti del 20 settembre 2026, Sophos elencava bfs, btrfs, cifs, devtmpfs, ecryptfs, ext2, ext3, ext4, fuse, fuseblk, iso9660, jfs, jfs2, msdos, nfs, nfs4, overlay, squashfs, tmpfs, udf, vfat, xfs e zfs. Prima di ogni ondata, ricontrollare l’elenco nella documentazione SPL corrente. Sul dispositivo pilota con AV elencare tutti i punti di montaggio e i relativi tipi:

findmnt -rn -o TARGET,FSTYPE

In modalità AV, verificare non solo / e il percorso di installazione, ma ogni punto di montaggio con dati aziendali, container, condivisioni di rete o target di scansione previsti. Un file system non elencato non è approvato solo perché un primo test non rileva problemi. Sophos consiglia di escludere tali file system dalla scansione; il plug-in AV esclude automaticamente quelli con problemi noti e registra l’evento in soapd.log. Per il solo XDR Sensor, i target di scansione, la quarantena e questo log AV non sono criteri di accettazione.

SPL gestisce i limiti di CPU e memoria tramite i cgroup Linux. Secondo Sophos, i valori predefiniti sono adatti alla maggior parte degli ambienti: non impostare quindi limiti generici prima del pilota. Se esiste un requisito operativo, misurare prima carico e tolleranza dell’applicazione, quindi leggere il file installato localmente /opt/sophos-spl/base/etc/cgroup-resource-limits-README.txt. È il riferimento perché opzioni, componenti e valori validi possono cambiare. I valori personalizzati vanno in /opt/sophos-spl/base/etc/cgroup-limits.conf; la CPU è una percentuale con %, mentre la memoria può essere in MB o percentuale a seconda dell’opzione. SPL ignora i valori fuori dall’intervallo supportato e applica il valore predefinito. Per questo l’articolo non prescrive numeri universali.

Dopo l’installazione o una modifica, eseguire i controlli pertinenti alla modalità effettivamente installata:

1. Solo con antivirus: findmnt mostra un tipo attualmente supportato per ogni target di scansione previsto.
2. Se sono stati personalizzati i limiti cgroup: /opt/sophos-spl/logs/base/watchdog.log conferma la configurazione applicata ai componenti effettivamente installati e non riporta errori di configurazione.
3. Se sono stati personalizzati i limiti cgroup: il journal di sistema non riporta processi terminati dal cgroup SPL. Poiché non tutti i sistemi Linux conservano il journal dopo il riavvio, configurarne la persistenza secondo la policy operativa locale se occorre mantenere la cronologia degli errori.

Installazione singola tramite Sophos Fusion

1. In Sophos Fusion, aprire My Environment > Installers.
2. Nella sezione Server Protection, scegliere il download Linux appropriato: Download Linux Server Installer per la protezione antimalware completa oppure Download XDR Sensor Linux Server Installer per il solo XDR Sensor (richiede una licenza XDR e una protezione di terze parti attiva). Non usare l’installer Endpoint per Windows o macOS. Sophos Linux Sensor (SLS), disponibile separatamente, non è il sensore XDR di SPL.
3. Trasferire SophosSetup.sh sul server Linux previsto tramite un canale ad accesso controllato.
4. Passare alla directory di download e rendere il file eseguibile:

chmod +x SophosSetup.sh

5. Eseguire prima i controlli preliminari senza installare:

sudo ./SophosSetup.sh --test

6. Se i controlli hanno esito positivo, avviare l’installer:

sudo ./SophosSetup.sh

Senza --install-dir, SPL viene installato in /opt/sophos-spl/. Il completamento corretto del processo shell non equivale ancora all’accettazione del rollout: verificare quindi registrazione, componenti effettivamente installati, policy appropriate e stato di integrità sia in Central sia localmente. I controlli AV descritti più avanti non si applicano al solo XDR Sensor.

Scaricare l’installer direttamente sul server

Per il download manuale da shell, copiare in Sophos Fusion l’indirizzo del collegamento dell’installer Linux scelto in precedenza (protezione completa o XDR Sensor) e usarlo come segnaposto nel comando seguente:

wget '<LINUX-INSTALLER-LINK>' -O SophosSetup.sh
chmod +x SophosSetup.sh
sudo ./SophosSetup.sh --test
sudo ./SophosSetup.sh

Sostituire <LINUX-INSTALLER-LINK> con l’indirizzo copiato dal proprio tenant per la modalità scelta. L’URL e il file scaricato non devono essere inseriti in repository di script pubblici, ticket o condivisioni accessibili liberamente. Per distribuzioni ripetibili, fornire l’artefatto d’installazione tramite il sistema protetto di distribuzione dei pacchetti o dei secret della propria piattaforma.

Distribuire SPL su più sistemi Linux tramite script

Un rollout di massa inizia con pochi server rappresentativi. Il pilota deve includere differenze di distribuzione, kernel, architettura, hardening, percorso proxy, sede, workload e software di sicurezza già installato. Passare all’ondata limitata successiva solo dopo aver completato la verifica.

Lo script seguente è solo un esempio per la protezione antimalware completa con XDR dotato di licenza aggiuntiva, non per il solo XDR Sensor. Usa il Linux Server Installer scaricato per tale modalità, assegna il dispositivo al sottogruppo LinuxServers\Pilot e richiede i componenti antivirus e xdr:

#!/usr/bin/env bash
set -euo pipefail

if (( EUID != 0 )); then
  printf 'Questo script di distribuzione deve essere eseguito come root.\n' >&2
  exit 1
fi

installer='/var/tmp/SophosSetup.sh'
chmod 700 "$installer"

"$installer" --test
"$installer" \
  --group='LinuxServers\Pilot' \
  --products=antivirus,xdr \
  --tag=Rollout:wave-0 \
  --tag=ManagedBy:automation

Adattare il percorso del gruppo alla propria struttura Central. Se il gruppo o sottogruppo specificato non esiste ancora, l’installer lo crea. Il percorso va quindi controllato con precisione prima del rollout: un errore di battitura può creare un gruppo indesiderato invece di causare un errore. Con --products, i prodotti senza licenza non vengono installati; secondo l’attuale pagina CLI, i valori consentiti sono antivirus, mdr e xdr. Più argomenti --tag=<key>:<value> aggiungono i tag del dispositivo. In caso di chiavi duplicate, Central mostra solo l’ultimo valore passato.

In questo esempio, set -euo pipefail impedisce che lo script prosegua segnalando erroneamente un successo dopo un controllo preliminare o un’installazione non riusciti. Il sistema di distribuzione software deve propagare il reale stato di uscita e non deve tentare di reinstallare all’infinito sugli host in errore. Poiché Sophos non pubblica nella pagina CLI una tabella stabile dei codici di uscita numerici, l’esito non va deciso mediante associazioni inventate, ma combinando i controlli locali e quelli in Central.

Opzioni importanti dell’installer

Le variabili d’ambiente vanno indicate prima del comando dell’installer, le opzioni della riga di comando dopo.

Gli UID e GID degli account e dei gruppi creati da SPL possono essere specificati con --user-ids-to-configure e --group-ids-to-configure. Usare queste opzioni solo quando i requisiti locali di gestione delle identità o hardening impongono ID fissi; Sophos ne limita esplicitamente l’effetto agli account e ai gruppi SPL documentati.

Con --install-dir=<basis>, SPL viene installato in <basis>/sophos-spl. Tutti i successivi percorsi di log, versione, registrazione e disinstallazione vanno adattati di conseguenza; i percorsi /opt/sophos-spl/... mostrati nell’articolo valgono per l’installazione predefinita. I percorsi del plug-in AV valgono inoltre solo per host con il prodotto antivirus installato.

Specificare Message Relay e Update Cache

In genere, SophosSetup.sh contiene i relay e le cache configurati in Central. L’installer li ordina in base alla prossimità numerica rispetto all’indirizzo IP del dispositivo e usa il servizio raggiungibile più vicino; se nessuno è raggiungibile, contatta direttamente Central. Durante l’installazione è possibile sovrascrivere esplicitamente la scelta:

sudo ./SophosSetup.sh \
  --message-relays=192.0.2.10:8190 \
  --update-caches=192.0.2.10:8191

192.0.2.10 è un indirizzo riservato alla documentazione e deve essere sostituito. Sophos usa la porta 8190 per Message Relay e 8191 per Update Cache. Il valore none forza la connessione diretta a Central per la rispettiva opzione. L’override vale per l’installazione; in seguito l’agente torna a usare i servizi configurati raggiungibili più vicini, salvo assegnazione manuale del dispositivo in Central.

Gold image per sistemi Linux virtuali

Non clonare senza modifiche un sistema Linux già installato e registrato. Prima di salvare il template, deregistrare da Sophos Fusion la VM usata per la gold image. Ogni clone avviato da tale immagine si registra poi automaticamente con un’identità propria non appena parte e raggiunge la rete.

1. Preparare completamente sistema operativo e applicazioni della VM master.
2. In My Environment > Installers, scaricare Linux Server Installer oppure XDR Sensor Linux Server Installer, secondo la modalità di protezione prevista.
3. Installare SPL come descritto sopra e verificarne lo stato.
4. Passare alla directory di registrazione e deregistrare la VM master:

cd /opt/sophos-spl/base/bin/
sudo ./registerCentral --deregister

5. Arrestare immediatamente la VM e salvare l’immagine mentre è spenta.
6. Non riavviare la VM master dopo la deregistrazione. Un riavvio la registra nuovamente; in tal caso va deregistrata di nuovo prima di salvare l’immagine.
7. Avviare almeno due cloni dall’immagine salvata e verificare che compaiano in Central come dispositivi distinti.

Se il percorso d’installazione è stato modificato con --install-dir, sophos-spl si trova nella directory indicata. Il comando per la gold image deve quindi essere eseguito dalla corrispondente directory base/bin di tale installazione.

Verificare l’installazione

Un pilota è approvato solo quando tutti i controlli seguenti hanno esito positivo:

1. In My Products > Server > Servers, per ogni host compare esattamente il dispositivo previsto. Nella pagina dei dettagli del server, stato di integrità, ultima attività e componenti installati devono risultare plausibili.
2. Il dispositivo si trova nel gruppo previsto e riceve le policy server appropriate ai componenti effettivamente installati. Per la protezione antimalware completa deve essere efficace la Server Threat Protection Policy; per le policy di aggiornamento si applica la prima policy corrispondente.
3. Il servizio è in esecuzione localmente:

sudo systemctl status sophos-spl

4. Solo con il prodotto antivirus installato: la versione di Server Protection mostrata in Central corrisponde a quella riportata localmente:

sudo cat /opt/sophos-spl/plugins/av/VERSION.ini

Sophos indica espressamente questo file del plug-in AV per il confronto delle versioni. Per il solo XDR Sensor non presumerne la presenza: confrontare invece i componenti effettivamente installati, le versioni visualizzate, lo stato di integrità e l’ultima attività nella pagina dei dettagli del server con la modalità Sensor scelta. Verificare inoltre localmente la connessione a Sophos Fusion nel log MCS/di gestione corrispondente alla versione installata: /opt/sophos-spl/logs/base/sophosspl/management.log oppure, eventualmente per pacchetti LTS, i log precedenti mcsrouter.log e sophos_managementagent.log. Controllare nomi e percorsi dei log nel pacchetto installato; la sola presenza o assenza di un log o di un percorso AV non dimostra il funzionamento del sensore.

5. Solo con il prodotto antivirus installato: per il test EICAR On-Access devono essere abilitate nella Server Threat Protection Policy effettiva sia Real-time scanning - Local files and network shares sia Enable scan for Server Protection for Linux Agent; l’opzione specifica per Linux è disattivata per impostazione predefinita. Verificare quindi il rilevamento in /opt/sophos-spl/plugins/av/log/av.log e nella pagina Server Summary. Il solo XDR Sensor non offre né questo rilevamento antimalware né scansioni on-demand: verificare invece separatamente la protezione antimalware di terze parti ancora attiva secondo la procedura documentata dal produttore.

Interrompere l’ondata estesa se i dispositivi mancano, compaiono duplicati, restano non integri, non ricevono i componenti o le policy previsti oppure causano problemi ai workload aziendali critici.

Arrestare, ripristinare o rimuovere il rollout

Il rollback inizia interrompendo la distribuzione. Fermare nuove assegnazioni e tentativi automatici, delimitare l’ondata interessata e conservare l’ultimo stato funzionante della VM, del pacchetto o della configurazione. La disinstallazione non ripristina automaticamente un prodotto di protezione di terze parti rimosso o sostituito.

Per la procedura completa di rimozione locale, pulizia dei cgroup, verifica, gestione del record Central e ripristino, consultare Disinstallare completamente Sophos Protection for Linux. Mantenere i comandi di rimozione in quel runbook invece di copiarli in un processo di installazione o rollout.

Tamper Protection non è disponibile per Sophos Protection for Linux e non è quindi applicabile a questo rollback. Verificare comunque le policy server ancora applicate, ripristinare la protezione prevista e decidere come gestire il record del dispositivo in Central prima di chiudere la modifica.

Troubleshooting in base al sintomo

--test o l’installazione non riesce

Conservare comando esatto, distribuzione, kernel, architettura e output. Quando rileva un errore d’installazione, Thin Installer avvia automaticamente Sophos Diagnostic Utility (SDU) e crea il file sophos_diagnose.tgz nella directory di Thin Installer. L’archivio contiene log d’installazione e informazioni di sistema utili al supporto Sophos.

Eseguire il comando seguente solo su richiesta del supporto Sophos o per una riproduzione controllata: riavvia l’installer, abilita l’output di debug della shell e conserva la directory temporanea d’installazione.

sudo OVERRIDE_INSTALLER_CLEANUP=1 \
  DEBUG_THIN_INSTALLER=1 \
  bash -x ./SophosSetup.sh 2>&1 | tee install.log

OVERRIDE_INSTALLER_CLEANUP=1 conserva la directory temporanea /tmp/SophosCentralInstall_<uuid>. I log possono contenere nomi host, percorsi interni e dettagli di rete; controllarli prima di condividerli.

/tmp è montata con noexec

Non ridurre permanentemente le restrizioni di /tmp. Creare un percorso temporaneo eseguibile adatto e impostare TMPDIR solo per l’installer:

sudo TMPDIR=/var/tmp ./SophosSetup.sh --test
sudo TMPDIR=/var/tmp ./SophosSetup.sh

TMPDIR modifica solo la directory temporanea, non il percorso d’installazione predefinito /opt/sophos-spl.

Il dispositivo non compare in Sophos Fusion

Controllare prima DNS, TCP 443, proxy, TLS Inspection e l’elenco aggiornato dei domini consentiti. Cercare quindi il percorso di connessione scelto e l’esito positivo della connessione nel log MCS/di gestione corrispondente alla versione installata: /opt/sophos-spl/logs/base/sophosspl/management.log oppure, eventualmente per pacchetti LTS, i log precedenti mcsrouter.log e sophos_managementagent.log. Controllare nomi e percorsi dei log nel pacchetto installato. Nel management.log attuale Sophos mostra, ad esempio, Successful connection via environment proxy e Connection method: Proxy.

Se un dispositivo Linux non ancora gestito non può ottenere la configurazione proxy di Central, Sophos documenta come soluzione di bootstrap un file contenente http_proxy=https://<PROXY_ADDRESS>:<PROXY_PORT>: in /etc/default/sophos-spl sui sistemi Debian e in /etc/sysconfig/sophos-spl su RHEL, CentOS e Amazon Linux. Eseguire quindi:

sudo systemctl restart sophos-spl
sudo systemctl status sophos-spl

Controllare infine il log MCS/di gestione corrispondente alla versione installata (per i pacchetti LTS, eventualmente mcsrouter.log e sophos_managementagent.log).

La protezione antimalware completa è installata, ma Real-Time Scanning non funziona

Solo con il prodotto antivirus installato: aprire la Threat Protection Policy applicata in My Products > Server > Policies. Devono essere abilitate sia Real-time scanning - Local files and network shares sia Enable scan for Server Protection for Linux Agent. Per la diagnostica locale, Sophos indica i file di policy /opt/sophos-spl/base/mcs/policy/CORC_policy.xml e /opt/sophos-spl/plugins/av/var/on_access_policy.json, oltre al log /opt/sophos-spl/plugins/av/log/soapd.log. Per il solo XDR Sensor questo non è un guasto: la protezione antimalware deve essere fornita da terzi.

Il percorso d’installazione personalizzato non funziona con SELinux Enforcing

Non aggirare il problema usando --notest o disabilitando SELinux a livello globale. La nuova directory di base non deve essere un collegamento simbolico e non deve contenere già una sottodirectory sophos-spl. Dopo averla creata, trasferire il contesto SELinux di /opt al nuovo percorso:

sudo semanage fcontext -a -e /opt <PFAD_ZUM_NEUEN_INSTALLATIONSVERZEICHNIS>

Avviare quindi l’installer con il valore verificato di --install-dir. Se semanage non è disponibile, installare prima il pacchetto di amministrazione SELinux previsto dalla distribuzione; non disabilitare il controllo di sicurezza.

Un target di scansione AV non viene analizzato o alcuni processi vengono terminati

Solo con il prodotto antivirus installato: per un target di scansione non analizzato, controllare prima tipo e punto di montaggio con findmnt -rn -o TARGET,FSTYPE. Cercare is not supported and will be excluded from scanning in /opt/sophos-spl/plugins/av/log/soapd.log. Non usare --notest per forzare un file system escluso automaticamente o non documentato; lasciarlo fuori dalla scansione finché non si usa un tipo attualmente supportato o Sophos Support conferma la configurazione specifica.

Per una terminazione inattesa, controllare /opt/sophos-spl/logs/base/watchdog.log e poi il journal del kernel:

sudo journalctl -k -b

Conservare i messaggi oom-kill, Memory cgroup out of memory o relativi a valori rifiutati insieme alla cgroup-limits.conf effettiva e al carico del momento. Non cambiare numeri alla cieca: limiti SPL troppo ampi possono sottrarre risorse all’applicazione, mentre limiti troppo stretti possono terminare i processi di protezione. Modificare durante una finestra di manutenzione seguendo il README locale; Sophos richiede di arrestare sophos-spl.service prima della modifica e riavviarlo dopo. Ricontrollare lo stato del servizio, watchdog.log, il journal, lo stato Central e l’applicazione critica.

I cloni condividono un’identità o il template ricompare

Interrompere la distribuzione. Verificare che la VM master sia stata realmente arrestata dopo registerCentral --deregister e che l’immagine sia stata salvata mentre era spenta. Se la VM è stata riavviata, deregistrarla nuovamente prima di salvare. Non usare cloni errati come template successivi; ricrearli dalla gold image preparata correttamente.

Domande frequenti