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 Central. 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, scaricare SophosSetup.sh da My Environment > Installers, rendere il file eseguibile e avviarlo con privilegi di root. Per più sistemi, usare l’installer scaricato dal tenant di destinazione in una distribuzione software controllata ed eseguire prima il test con --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: a seconda della licenza, Server Protection offre la protezione completa contro il malware oppure un XDR Sensor. Sophos precisa che XDR Sensor non protegge autonomamente dalle minacce; è quindi necessario un prodotto di protezione di terze parti.
• 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 Central. 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.

Installazione singola tramite Sophos Central

1. In Sophos Central, aprire My Environment > Installers.
2. Nella sezione Server Protection, fare clic su Download Linux Server Installer. Non usare l’installer Endpoint per Windows o macOS.
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, policy e stato di integrità sia in Central sia localmente.

Scaricare l’installer direttamente sul server

Per il download manuale da shell, copiare in Sophos Central l’indirizzo del collegamento Download Linux Server Installer 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. 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.

Questo semplice esempio assegna il dispositivo al sottogruppo LinuxServers\Pilot e installa i componenti concessi in licenza 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.

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 Central 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. Scaricare Linux Server Installer da My Environment > Installers.
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 corrette. Per Linux, Sophos applica tra l’altro Server Threat Protection e Server Update Management; per le policy di aggiornamento si applica la prima policy corrispondente.
3. Il servizio è in esecuzione localmente:

sudo systemctl status sophos-spl

4. 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 per il confronto delle versioni.

5. Il test EICAR vale solo per i sistemi con la protezione antimalware, cioè con il prodotto antivirus, e non per un’installazione composta soltanto da XDR Sensor. Per il test 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.

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 una disinstallazione completa di SPL dal percorso standard, Sophos documenta l’uninstaller integrato:

cd /opt/sophos-spl/bin
sudo ./uninstall.sh

Sophos indica poi i comandi seguenti per rimuovere eventuali directory cgroup residue:

sudo rmdir /sys/fs/cgroup/sophos.slice
sudo rmdir /sys/fs/cgroup/cpuacct/sophos.slice
sudo rmdir /sys/fs/cgroup/cpu/sophos.slice
sudo rmdir /sys/fs/cgroup/memory/sophos.slice

rmdir elimina solo directory vuote. Non inserire questi comandi alla cieca in un normale processo di rollout. Prima di una rimozione in produzione, verificare separatamente Tamper Protection, policy server ancora applicate, ripristino della protezione prevista e trattamento desiderato dell’oggetto dispositivo in Central. Questo articolo tratta installazione e controllo del rollout; la disinstallazione di massa o la pulizia dei dispositivi a livello di tenant costituisce una modifica distinta.

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 Central

Controllare prima DNS, TCP 443, proxy, TLS Inspection e l’elenco aggiornato dei domini consentiti. Cercare quindi in /opt/sophos-spl/logs/base/sophosspl/management.log il percorso di connessione scelto e l’esito positivo della connessione. 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 management.log.

SPL è installato, ma Real-Time Scanning non funziona

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.

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.

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