Sophos Server Protection: Windows- und Linux-Plattformen sicher freigeben

Kurzentscheidung: Ein Server kommt nur in die nächste Installations- oder Update-Welle, wenn sein konkretes Betriebssystem und sein Agent zur aktuellen Sophos-Freigabe passen, die benötigten Funktionen im eigenen Tenant verfügbar sind und ein repräsentativer Pilot gesund bleibt. Eine Zeile in alten Release Notes belegt lediglich, dass es einmal Komponenten für eine Plattform gab – nicht, dass deren Betriebssystem heute ohne Einschränkung unterstützt wird. Fehlt ein belastbarer Nachweis, bleibt der Server aus der Welle und die Plattformfrage geht an Sophos Support.

Diese Anleitung hilft bei der Freigabeentscheidung vor Neuinstallation, Betriebssystemwechsel oder Agent-Aktualisierung. Die eigentlichen Schritte für Windows Server und Sophos Protection for Linux (SPL) stehen in den jeweiligen Installationsanleitungen.

Release-Stand und Support-Stand getrennt prüfen

Beim Abgleich am 24. September 2026 zeigen die Sophos Release Notes für den Windows Server Core Agent als oberste Version 2026.2.2.1 (September 2026), mit getrennten Komponentenabschnitten für Windows Server 2016 und neuer sowie für ältere Legacy-Plattformen. Die aktuellen Windows Server Core Agent Release Notes sind für Versions- und Komponentenänderungen massgeblich. Sie warnen auch, dass die Software nach Veröffentlichung der Notes über mehrere Wochen ausgerollt wird. Ein historischer oder aktueller Komponentenabschnitt ist keine Freigabe einer bestimmten Windows-Edition oder eines Builds.

Laut Sophos Windows Server System Requirements (KBA-000003024, Stand 7. Mai 2026) gelten Windows Server 2016, 2019, 2022 und 2025 als vollständig unterstützte Servergenerationen. Windows Server 2008 R2 sowie 2012 und 2012 R2 sind Legacy-Plattformen und benötigen eine Extended-Support-Lizenz; einzelne Funktionen können dort fehlen oder nicht unterstützt beziehungsweise aktualisiert werden. Sensor Mode wird auf Legacy-Plattformen nicht unterstützt. Diese datierte Übersicht ist keine pauschale Freigabe jeder Edition, Architektur oder Build-Variante. Deshalb vor der Welle die exakte Edition, den vollständigen OS-Build, die Architektur, Agent-Version, den gewünschten Schutzmodus und bei Legacy-Hosts die tatsächliche Extended-Support-Berechtigung erfassen. Für die konkrete Kombination vor der Freigabe die aktuellen Windows Server System Requirements bei Sophos, die Angaben zu unterstützten Windows-Varianten und den Retirement-Kalender prüfen. Ist die Sophos-Support-Seite nicht lesbar oder fehlt eine eindeutige Aussage, die Freigabe aussetzen und Sophos Support befragen. Ein startender Agent oder ein Release-Notes-Eintrag allein beweist keinen Supportanspruch.

Ressourcen nach Lizenz und Modus prüfen: Zum Stand 7. Mai 2026 gelten für Sophos Endpoint – Server mindestens 8 GB freier Speicherplatz, 8 GB RAM und 2 Kerne. Für Sophos EDR, XDR und MDR – Server gelten mindestens 10 GB freier Speicherplatz, 8 GB RAM und 2 Kerne; empfohlen werden 10 GB freier Speicherplatz, 16 GB RAM und 4 Kerne. Diese Anforderungen gelten sowohl für Full Protection als auch für Sensor Mode – die Ressourcentabelle hebt das Sensor-Verbot auf Legacy-Plattformen nicht auf. Für das Bootlaufwerk empfiehlt Sophos nachdrücklich eine SSD. Die Werte sind allgemeine Richtwerte, keine Garantie für ausreichende Leistung bei jeder Serverlast: Besonders bei Malware-Erkennung und Bereinigung können CPU-, RAM- und Plattenlast vorübergehend steigen. Reserven und Verhalten im eigenen Pilot prüfen.

Für Linux nennen die SPL Release Notes am selben Prüftag 2026.3 (September 2026) als oberste Version. Auch hier kann die Bereitstellung im eigenen Tenant erst nach Veröffentlichung der Notes erfolgen. Unter System requirements stehen aktuell mindestens 2,5 GB freier Speicherplatz, 2 GB freier Arbeitsspeicher, x86_64 oder ARM64, laufendes systemd, Bash und glibc ab 2.17; auf ARM64 gelten glibc ab 2.18 und Kernel ab 5.3. Diese Werte sind eine datierte Prüfbasis, keine dauerhafte Freigabe aller Linux-Distributionen oder Kernel.

Die Sophos-Hinweise zu SPL-Distributionen und Kerneln verweisen für die aktuelle Plattformliste auf System requirements > Supported platforms der Release Notes; sie sind keine zweite unabhängige Freigabematrix. Distribution, Major-/Minor-Stand, Architektur, laufender Kernel und Herstellersupport müssen zusammenpassen. Die getestete Liste umfasst beim genannten Prüftag unter anderem RHEL 8–10, Debian 11–13 und Ubuntu 22.04/24.04 LTS sowie 26.04; daneben gibt es eine separat ausgewiesene Legacy-Liste, die keine automatische Freigabe ist. Sophos testet die neuesten aktiven Minor-Releases beziehungsweise Service Packs; für x86_64 können distributionsspezifische Kerneluntergrenzen gelten. Ein Kernel 5.3 ist deshalb keine allgemeine x86_64-Freigabe. Auch ein Kernel oberhalb einer Mindestgrenze kann problematisch sein: Die aktuellen Notes nennen für 5.10.133 bis 5.10.142 einen bekannten ftrace-Fehler mit möglichem Kernel-Hänger; diese Kombination nicht durch einen unauffälligen Setup-Lauf freigeben, sondern vorab Kernel und Sophos-Hinweise klären.

Ausnahmen vor dem Pilot trennen: Ist das Linux-Image immutable, SPL hier nicht freigeben – Sophos bezeichnet SPL als nicht für immutable Distributionen ausgelegt und verweist für diese Plattformen auf das separate Produkt Sophos Linux Sensor (SLS). SLS ist nicht der SPL-XDR Sensor; diese Anleitung beschreibt keine SLS-Installation. Nicht gelistete Downstream-Distributionen, eigene oder minimale Kernel und gehärtete Systeme werden ebenfalls nicht automatisch zu getesteten Plattformen: Sophos beschreibt dafür eine Prüfung nach bestem wirtschaftlich vertretbarem Aufwand und kann eine Reproduktion auf einer unterstützten Plattform oder ein Upgrade verlangen.

Für einen bestehenden Legacy-Linux-Host zusätzlich den tatsächlichen Extended-Support-Anspruch und das installierte sowie das per Update Management zugewiesene Softwarepaket prüfen. Am 24. September 2026 nennt Sophos für Legacy-Versionen das unterstützte LTS-Paket 2026.1.0.35 und empfiehlt dessen Zuweisung über Update Management; bei Problemen mit einem neueren Paket kann die Rückkehr zum unterstützten Paket für die Untersuchung nötig sein. Vor einer Änderung die dann gültigen Sophos-Hinweise und die konkrete Paketverfügbarkeit prüfen: Die SPL-2026.3-Überschrift ist für einen Legacy-Host kein automatisches Ziel und 2026.1.0.35 keine dauerhafte Zusage oder generelle Downgrade-Anleitung.

Freigabe für eine konkrete Welle dokumentieren

Ein kleines Prüfprotokoll verhindert, dass eine funktionierende Installation irrtümlich als Supportbeleg gilt. Pro Serverfamilie – etwa Windows-Anwendungsserver und Linux-Datenbankserver getrennt – erfassen:

Ist- und Zielzustand: Serverrolle, OS-Edition beziehungsweise Distribution und Minor-Version, vollständiger Build beziehungsweise uname -r, Architektur, installierter Agent samt Komponenten und beabsichtigtes Zielrelease. Bei Windows Lizenztyp (Endpoint – Server oder EDR/XDR/MDR – Server), Full Protection oder Sensor Mode sowie freien Plattenplatz, RAM, Kerne und Bootlaufwerk prüfen. Bei Linux auch Image-Typ (immutable oder veränderbar), freien RAM/Platz auf dem tatsächlichen Installationsvolume, laufendes systemd, Bash und glibc prüfen. Bei Legacy-Linux installiertes und zugewiesenes Softwarepaket getrennt erfassen.
Nachweise: Datum und Stand der Windows-Systemanforderungen und der Windows- oder SPL-Release Notes, aktuelle OS-/Kernel-Anforderungen, Lifecycle/Extended Support samt tatsächlichem Anspruch für Legacy-Hosts sowie benötigte Lizenz und Tenant-Funktionen festhalten. Für Windows ohne eindeutigen Nachweis für Edition, Build, Architektur und Schutzmodus ausdrücklich offen statt „kompatibel“ eintragen. Ein Release-Hinweis auf eine neue Funktion – beispielsweise Linux als Update Cache oder Message Relay ab SPL 2026.3 – ersetzt weder deren tatsächliche Verfügbarkeit im Tenant noch deren separate Voraussetzungen.
Entscheid: „freigegeben für Pilot“, „zuerst OS/Kernel aktualisieren“ oder „stoppen und Support klären“. Prüfer, Änderungsfenster, Pilotgeräte und Stop-Kriterien benennen. Die erste Option setzt einen positiven Plattformnachweis voraus; ein nicht getesteter Downstream-Build ist kein gleichwertiger Ersatz für eine getestete Kombination. Immutable Linux bleibt ausserhalb der SPL-Welle; für Legacy-Linux nur mit geklärtem Anspruch, passender Paketzuweisung und aktuellem Supportnachweis weitergehen.

Auf dem Linux-Pilot diese lesenden Befehle am Zielserver möglichst nah am Änderungsfenster ausführen und die Ausgaben protokollieren:

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

Bei free -m die Spalte available (nicht total) mit den geforderten 2 GB freiem Speicher vergleichen. df -h -- /opt ist nur für eine Standardinstallation sinnvoll, wenn /opt auf dem tatsächlichen Zielvolume liegt; bei separatem Mount oder --install-dir stattdessen einen bereits existierenden Pfad auf dem tatsächlichen Installationsvolume mit df -h -- <Pfad> prüfen und 2,5 GB frei nachweisen. Ist dieses Volume noch nicht bestimmbar, keine Ressourcenfreigabe erteilen. ps und das /run/systemd/system-Verzeichnis prüfen das laufende Init-System; Bash muss auflösbar und die ausgegebene glibc-Version muss zur Architektur passen. Den immutable-Status zusätzlich anhand des Image-/OS-Typs im Deployment-Inventar klären; os-release allein beweist keinen veränderbaren Host. Für Windows die vollständigen OS- und Agent-Daten aus dem verwalteten Inventar und den Systemeigenschaften sowie die Ressourcenwerte für den vorgesehenen Lizenz- und Schutzmodus sichern. Die Prüfung wiederholen, wenn OS, Kernel, Agent, Lizenz oder Sophos-Anforderungen sich ändern – nicht allein auf das Datum dieses Artikels vertrauen.

Pilot, Health und nächste Welle

Zuerst einen repräsentativen Server je relevanter Plattformkombination wählen: gleiche OS-Minor-Version, Architektur und Kernel, ähnlicher Netzwerk-/Proxyweg sowie vergleichbare Serverrolle und Belastung. Vor dem Pilot Backup und Wiederherstellungsweg prüfen, Konsolen- oder Out-of-Band-Zugang sichern und ein Wartungsfenster inklusive möglichem Neustart reservieren. Eine Datenbank mit besonderen E/A-Spitzen braucht einen passenden Lasttest; ein leerer Test-VM-Start reicht nicht.

Nach Installation oder Aktualisierung in My Products > Server > Servers am richtigen Tenant prüfen, ob der Pilot einmalig erscheint, aktuell kommuniziert, die erwarteten Schutzkomponenten und die vorgesehene Servergruppe hat und keinen anhaltenden Health-Alarm zeigt. Installierte Komponenten und Versionen am Gerät und in Fusion abgleichen; die wirksame Server-Richtlinie am Host statt nur die Gruppenzuweisung prüfen. Auf Linux zusätzlich sudo systemctl status sophos-spl kontrollieren. Nur wenn das Antivirus-Plugin installiert ist, bei Standardpfad sudo cat /opt/sophos-spl/plugins/av/VERSION.ini lesen (bei geändertem --install-dir Pfad anpassen) und dessen Version mit der Server-Protection-Komponente, nicht der SPL-Basiskomponente, in Central vergleichen. Auf einem reinen SPL-XDR-Sensor ohne AV-Plugin stattdessen die tatsächlich installierten Komponenten und ihren Versions-/Health-Stand in Central prüfen; eine fehlende AV-Datei ist dort kein Fehler. Ein gesunder Dienst allein bestätigt weder aktuellen Malware-Schutz noch die Wirksamkeit einer Richtlinie. Nur bei installiertem AV-Schutz und nach Prüfung, dass in der wirksamen Server Threat Protection Policy sowohl Real-time scanning - Local files and network shares als auch Enable scan for Server Protection for Linux Agent aktiv sind, einen geplanten, sicheren On-Access-Erkennungstest nach der Linux-Installationsanleitung durchführen; ein reiner XDR Sensor ist dafür kein geeigneter Kandidat.

Anschliessend die Geschäftsanwendung, Neustartverhalten, Netzwerkverbindungen und normale Last gegen den Vorher-Zustand vergleichen. Bei einem neuen Agent-Feature zuerst im Tenant prüfen, ob es dem Pilot tatsächlich angeboten wird. Die nächste, begrenzte Welle beginnt erst, wenn Plattformnachweis, Agent- und Policy-Stand, Health und Anwendungstest gemeinsam bestanden sind. Release Notes können vor der Bereitstellung erscheinen; eine abweichende tatsächlich angebotene Version ist Anlass zum Nachprüfen, nicht zum Erzwingen eines Downloads.

Stoppen und Rückweg vorbereiten

Vor der Änderung den funktionierenden OS-/Kernel- und Agent-Stand, bei Legacy-Linux auch installiertes und zugewiesenes Softwarepaket, Backup, Wartungsfenster, Schutzmodus und zuständige Person notieren. Die Rückkehr auf einen alten Agent ist nicht allein deshalb möglich, weil dessen Version in historischen Release Notes steht. Für OS- oder Kernel-Rollback müssen Bootfähigkeit, Datenkonsistenz und die Unterstützung des Zielstands separat geprüft sein. Auch wenn Sophos bei Legacy-Linux für Supportfälle eine Rückkehr zum unterstützten Paket verlangen kann: Sophos-Softwarepakete oder Update-Richtlinien sind kein pauschaler Downgrade-Schalter; einen Rückweg für den konkreten Host vorab mit Sophos klären.

Bei fehlender Registrierung, dauerhaft schlechtem Health, falschem Schutzumfang, unerwarteten Neustarts oder einer gestörten Serveranwendung Verteilung und automatische Wiederholungen sofort stoppen, betroffene Hosts abgrenzen und keine weitere Welle starten. Zuerst Tenant, Verbindung, wirksame Richtlinie, angebotene Agent-Version und OS-/Kernel-Abweichung gegen das Protokoll prüfen. Eine Policy-Korrektur wird eng auf den Pilot begrenzt und danach erneut abgenommen; Schutz nicht tenantweit deaktivieren. Ist ein Wechsel zurück nötig, den vorher festgelegten, getesteten System-Wiederherstellungsweg und den zur konkreten Agent-Version passenden Sophos-Support-Ablauf verwenden. Keine Komponenten oder Treiber auf Verdacht entfernen. Falls die Plattformfrage oder ein unterstützter Rückweg offen bleibt, Logs und Plattformdaten sichern und Sophos Support einschalten; bis dahin bleibt die Rollout-Welle angehalten.