Sophos Server Protection: approvare in sicurezza le piattaforme Windows e Linux

Decisione in breve: includere un server nella successiva fase di installazione o aggiornamento solo se il suo sistema operativo specifico e l’agente sono conformi al supporto attuale di Sophos, le funzioni necessarie sono disponibili nel proprio tenant e un pilota rappresentativo resta in buone condizioni. Una voce nelle vecchie note di rilascio dimostra soltanto che in passato esistevano componenti per una piattaforma, non che oggi il suo sistema operativo sia supportato senza limitazioni. In mancanza di prove affidabili, escludere il server dalla fase e chiedere conferma a Sophos Support.

Questa guida serve a decidere se procedere prima di una nuova installazione, di un cambio di sistema operativo o di un aggiornamento dell’agente. Le procedure vere e proprie per Windows Server e Sophos Protection for Linux (SPL) sono nelle rispettive guide di installazione.

Verificare separatamente versione rilasciata e supporto della piattaforma

Alla verifica del 24 settembre 2026, le note di rilascio Sophos indicano 2026.2.2.1 (settembre 2026) come versione più recente del Server Core Agent per Windows, con sezioni distinte dedicate ai componenti per Windows Server 2016 e versioni successive e per le piattaforme legacy più vecchie. Le note di rilascio aggiornate del Windows Server Core Agent fanno fede per le modifiche alle versioni e ai componenti. Avvertono inoltre che la distribuzione del software può richiedere diverse settimane dopo la pubblicazione delle note. Una sezione sui componenti, storica o attuale, non equivale all’approvazione di una specifica edizione o build di Windows.

Secondo i requisiti di sistema Sophos per Windows Server (KBA-000003024, aggiornati il 7 maggio 2026), Windows Server 2016, 2019, 2022 e 2025 sono generazioni pienamente supportate. Windows Server 2008 R2, 2012 e 2012 R2 sono piattaforme legacy e richiedono una licenza Extended Support; alcune funzioni potrebbero non essere disponibili, supportate o aggiornate. Sensor Mode non è supportato sulle piattaforme legacy. Questa panoramica datata non approva indiscriminatamente tutte le edizioni, architetture o build. Prima della fase registrare quindi edizione esatta, build completa, architettura, versione dell’agente, modalità di protezione desiderata e, per gli host legacy, diritto effettivo all’Extended Support. Per la combinazione specifica, consultare i requisiti di sistema Windows Server correnti di Sophos, le varianti Windows supportate e il calendario dei ritiri. Se la pagina di supporto non è leggibile o manca una risposta univoca, sospendere l’approvazione e chiedere conferma a Sophos Support. Un agente avviato o una voce nelle note di rilascio non provano da soli il diritto al supporto.

Verificare le risorse in base alla licenza e alla modalità: al 7 maggio 2026, Sophos Endpoint – Server richiede almeno 8 GB di spazio libero, 8 GB di RAM e 2 core. Sophos EDR, XDR e MDR – Server richiedono almeno 10 GB di spazio libero, 8 GB di RAM e 2 core; sono consigliati 10 GB di spazio libero, 16 GB di RAM e 4 core. I requisiti valgono sia per Full Protection sia per Sensor Mode: la tabella delle risorse non annulla il divieto di Sensor Mode sulle piattaforme legacy. Sophos raccomanda vivamente un’unità SSD per il disco di avvio. Sono valori indicativi, non una garanzia di prestazioni sufficienti per ogni carico: rilevamento e rimozione del malware possono aumentare temporaneamente il carico su CPU, RAM e disco. Verificare riserve e comportamento nel proprio pilota.

Per Linux, le note di rilascio SPL indicano, alla stessa data di verifica, 2026.3 (settembre 2026) come versione più recente. Anche qui la disponibilità nel proprio tenant può seguire la pubblicazione delle note. La sezione System requirements indica attualmente almeno 2,5 GB di spazio libero su disco, 2 GB di memoria RAM libera, architettura x86_64 o ARM64, systemd in esecuzione, Bash e glibc dalla versione 2.17; su ARM64 servono glibc dalla versione 2.18 e kernel dalla versione 5.3. Questi valori sono una base di verifica datata, non una garanzia permanente di supporto per tutte le distribuzioni o i kernel Linux.

Le indicazioni Sophos sulle distribuzioni e sui kernel per SPL rimandano, per l’elenco aggiornato delle piattaforme, a System requirements > Supported platforms nelle note di rilascio: non costituiscono una seconda matrice di supporto indipendente. Distribuzione, versione major/minor, architettura, kernel in esecuzione e supporto del produttore devono essere compatibili tra loro. Alla data di verifica indicata, l’elenco delle piattaforme testate comprende, tra le altre, RHEL 8–10, Debian 11–13 e Ubuntu 22.04/24.04 LTS e 26.04; esiste inoltre un elenco legacy separato, che non comporta un’approvazione automatica. Sophos testa le più recenti versioni minor attive o i più recenti Service Pack; per x86_64 possono valere versioni minime del kernel specifiche per distribuzione. Un kernel 5.3 non è quindi un criterio di supporto generale per x86_64. Anche un kernel superiore alla versione minima può presentare problemi: le note attuali segnalano un difetto noto di ftrace tra 5.10.133 e 5.10.142, con possibile blocco del kernel. Non approvare questa combinazione solo perché l’installazione sembra riuscita: chiarire prima il kernel e le indicazioni Sophos.

Distinguere le eccezioni prima del pilota: se l’immagine Linux è immutable, non approvare SPL per questo caso: Sophos dichiara che SPL non è progettato per le distribuzioni immutable e rimanda, per tali piattaforme, al prodotto separato Sophos Linux Sensor (SLS). SLS non è il sensore XDR di SPL; questa guida non descrive l’installazione di SLS. Neppure le distribuzioni derivate non elencate, i kernel personalizzati o minimali e i sistemi sottoposti a hardening diventano automaticamente piattaforme testate: Sophos prevede per questi casi una valutazione secondo il miglior impegno economicamente ragionevole e può chiedere di riprodurre il problema su una piattaforma supportata o di eseguire un aggiornamento.

Per un host Linux legacy già in uso, verificare inoltre il diritto effettivo all’Extended Support, il pacchetto software installato e quello assegnato tramite Update Management. Al 24 settembre 2026, Sophos indica per le versioni legacy il pacchetto LTS supportato 2026.1.0.35 e ne raccomanda l’assegnazione tramite Update Management; in caso di problemi con un pacchetto più recente, per l’indagine potrebbe essere necessario tornare al pacchetto supportato. Prima di apportare modifiche, controllare le indicazioni Sophos valide in quel momento e la disponibilità effettiva del pacchetto: il titolo relativo a SPL 2026.3 non rende automaticamente tale versione un obiettivo per un host legacy, e 2026.1.0.35 non è né una garanzia permanente né un’istruzione generale per il downgrade.

Documentare l’approvazione per una fase specifica

Un breve verbale di verifica evita di scambiare un’installazione funzionante per una prova di supporto. Per ogni famiglia di server, distinguendo per esempio i server applicativi Windows dai server database Linux, registrare:

Stato attuale e obiettivo: ruolo del server, edizione del sistema operativo o distribuzione e versione minor, build completa o uname -r, architettura, agente installato con i relativi componenti e versione di destinazione prevista. Su Windows verificare tipo di licenza (Endpoint – Server o EDR/XDR/MDR – Server), Full Protection o Sensor Mode, spazio libero, RAM, core e disco di avvio. Su Linux controllare anche il tipo di immagine (immutable o modificabile), la RAM e lo spazio liberi sul volume di installazione effettivo, systemd in esecuzione, Bash e glibc. Per Linux legacy annotare separatamente il pacchetto software installato e quello assegnato.
Evidenze: annotare data e versione dei requisiti di sistema Windows e delle note di rilascio Windows o SPL, requisiti OS/kernel aggiornati, ciclo di vita ed Extended Support con il diritto effettivo per gli host legacy, oltre a licenza e funzioni del tenant necessarie. Per Windows, in assenza di una risposta chiara su edizione, build, architettura e modalità di protezione, segnare esplicitamente da chiarire, non «compatibile». Una nota di rilascio su una nuova funzione, per esempio l’impiego di Linux come Update Cache o Message Relay da SPL 2026.3, non ne dimostra la disponibilità effettiva nel tenant né sostituisce i requisiti specifici della funzione.
Decisione: «approvato per il pilota», «aggiornare prima OS/kernel» oppure «fermarsi e chiarire con il supporto». Indicare chi verifica, finestra di modifica, macchine pilota e criteri di arresto. La prima opzione richiede una conferma positiva del supporto della piattaforma; una build derivata non testata non equivale a una combinazione testata. Linux immutable resta escluso dalla fase SPL; per Linux legacy procedere solo dopo aver chiarito il diritto al supporto, l’assegnazione del pacchetto appropriato e la conferma aggiornata del supporto.

Sul server Linux pilota, eseguire questi comandi di sola lettura il più vicino possibile alla finestra di modifica e registrare gli output:

cat /etc/os-release
uname -r; uname -m
free -m
df -h -- /opt
ps -p 1 -o comm=; test -d /run/systemd/system && printf 'systemd läuft\n'
command -v bash; getconf GNU_LIBC_VERSION

Nell’output di free -m, confrontare la colonna available (non total) con i 2 GB di memoria libera richiesti. df -h -- /opt è pertinente per un’installazione standard solo se /opt si trova sul volume di destinazione effettivo; se si usa un mount separato o --install-dir, verificare invece un percorso già esistente sul volume di installazione effettivo con df -h -- <Pfad> e dimostrare che ci sono 2,5 GB liberi. Se non è ancora possibile individuare questo volume, non approvare le risorse. ps e la directory /run/systemd/system verificano il sistema init in esecuzione; Bash deve essere disponibile e la versione di glibc restituita deve soddisfare i requisiti per l’architettura. Accertare inoltre lo stato immutable dal tipo di immagine/OS nell’inventario di distribuzione: os-release da solo non dimostra che l’host sia modificabile. Per Windows salvare i dati completi su sistema operativo e agente dall’inventario gestito e dalle proprietà di sistema, insieme alle risorse richieste dalla licenza e dalla modalità di protezione previste. Ripetere la verifica se cambiano OS, kernel, agente, licenza o requisiti Sophos: non affidarsi solo alla data di questo articolo.

Pilota, stato di integrità e fase successiva

Scegliere anzitutto un server rappresentativo per ogni combinazione di piattaforma rilevante: stessa versione minor del sistema operativo, architettura e kernel, percorso di rete/proxy simile, ruolo e carico paragonabili. Prima del pilota verificare backup e procedura di ripristino, assicurare l’accesso alla console o fuori banda e riservare una finestra di manutenzione che includa un possibile riavvio. Un database con picchi particolari di I/O richiede una prova di carico adeguata; non basta avviare una VM di test vuota.

Dopo l’installazione o l’aggiornamento, in My Products > Server > Servers del tenant corretto verificare che il pilota compaia una sola volta, comunichi regolarmente, abbia i componenti di protezione attesi e il gruppo server previsto e non presenti allarmi persistenti sullo stato di integrità. Confrontare componenti e versioni installati sul dispositivo e in Fusion; verificare la policy server effettiva sull’host, non soltanto l’assegnazione al gruppo. Su Linux controllare inoltre sudo systemctl status sophos-spl. Solo se è installato il plugin antivirus, con il percorso standard leggere sudo cat /opt/sophos-spl/plugins/av/VERSION.ini (adattare il percorso se è stato cambiato --install-dir) e confrontarne la versione con il componente Server Protection, non con il componente base SPL, in Central. Su un sensore SPL solo XDR, privo del plugin AV, verificare invece in Central i componenti effettivamente installati, le loro versioni e lo stato di integrità: l’assenza del file AV non è un errore in questo caso. Un servizio funzionante da solo non conferma né l’attualità della protezione antimalware né l’efficacia di una policy. Solo se la protezione AV è installata e dopo aver verificato che nella Server Threat Protection Policy effettiva siano abilitate sia Real-time scanning - Local files and network shares sia Enable scan for Server Protection for Linux Agent, eseguire un test di rilevamento on-access pianificato e sicuro secondo la guida di installazione Linux; un sensore solo XDR non è adatto a questo test.

Confrontare quindi l’applicazione aziendale, il comportamento ai riavvii, le connessioni di rete e il carico normale con la situazione precedente. Per una nuova funzione dell’agente verificare prima se viene effettivamente offerta al pilota nel tenant. La successiva fase, di portata limitata, può iniziare solo dopo aver superato insieme le verifiche del supporto della piattaforma, della versione dell’agente e della policy, dello stato di integrità e dell’applicazione. Le note di rilascio possono precedere la disponibilità effettiva: se la versione proposta è diversa, verificare il motivo anziché forzare un download.

Fermarsi e preparare il ripristino

Prima della modifica, annotare le versioni funzionanti di OS/kernel e agente, per Linux legacy anche il pacchetto software installato e quello assegnato, nonché backup, finestra di manutenzione, modalità di protezione e referente. Non è detto che si possa tornare a un agente precedente solo perché la sua versione compare in vecchie note di rilascio. Per ripristinare OS o kernel occorre verificare separatamente la possibilità di avvio, la coerenza dei dati e il supporto della versione di destinazione. Anche se Sophos può richiedere, nei casi di assistenza per Linux legacy, il ritorno al pacchetto supportato, i pacchetti software Sophos o le policy di aggiornamento non sono un’opzione di downgrade valida in ogni caso: concordare in anticipo con Sophos una procedura di ritorno per l’host specifico.

In caso di registrazione mancante, stato di integrità persistentemente negativo, protezione non conforme alle attese, riavvii inattesi o malfunzionamento dell’applicazione server, interrompere subito la distribuzione e i tentativi automatici, individuare e circoscrivere gli host interessati e non avviare altre fasi. Verificare anzitutto tenant, connessione, policy effettiva, versione dell’agente proposta e differenze di OS/kernel rispetto al verbale. Limitare qualsiasi correzione della policy al pilota e ripetere poi la verifica; non disabilitare la protezione per l’intero tenant. Se è necessario tornare alla situazione precedente, usare la procedura di ripristino del sistema definita e testata in anticipo e il processo di supporto Sophos adatto alla specifica versione dell’agente. Non rimuovere componenti o driver per tentativi. Se il supporto della piattaforma o una procedura di ripristino supportata resta incerto, conservare log e dati della piattaforma e coinvolgere Sophos Support; fino ad allora la distribuzione rimane sospesa.