Sophos Protection for Linux vollständig deinstallieren

Die vollständige Entfernung von Sophos Protection for Linux (SPL) besteht aus drei getrennten Arbeiten: den Agenten lokal mit dem integrierten Skript deinstallieren, den Schutz des Servers prüfen beziehungsweise ersetzen und erst danach den nicht mehr benötigten Datensatz in Sophos Fusion (ehemals Sophos Central) löschen. Das Löschen in Central deinstalliert SPL nicht vom Server.

Auch Actions > Manage software > Uninstall current protection ist keine vollständige lokale SPL-Deinstallation: Dabei werden Schutzkomponenten entfernt, während der Sophos Core Agent für Kommunikation und Richtlinienverwaltung installiert bleibt. Für die vollständige Entfernung den lokalen Uninstaller verwenden (Sophos: Computers and servers).

Dieser Ablauf gilt für den Linux-Server-Agenten Sophos Protection for Linux. Er ist kein Deinstallationsweg für Sophos Endpoint unter Windows oder macOS, Sophos Anti-Virus for Linux (SAV) oder den eigenständigen Sophos Linux Sensor.

Ablauf auf einen Blick

Wartungsfenster, Root-Zugriff, Installationspfad und Nachfolgeschutz bestätigen.
Den lokalen SPL-Zustand und benötigte Central-Daten sichern.
uninstall.sh aus der vorhandenen SPL-Installation als Root ausführen.
Nur die von Sophos genannten, leeren cgroup-Verzeichnisse mit rmdir entfernen.
Lokale Entfernung und aktiven Nachfolgeschutz prüfen.
Erst dann den veralteten Gerätedatensatz in Central löschen oder SPL aus einem aktuellen Tenant-Installer neu installieren.

Vor der Deinstallation

Ein Wartungsfenster vereinbaren und abhängige Workloads überwachen.
Root-Zugriff über eine Root-Shell oder sudo sicherstellen.
Softwareverteilung, Konfigurationsmanagement und Golden Images stoppen, die SPL sonst erneut installieren würden.
Alerts, Health-Status und für Untersuchungen benötigte Gerätedaten vor einer späteren Central-Löschung dokumentieren.
Den tatsächlichen Installationspfad feststellen. Ohne --install-dir liegt SPL unter /opt/sophos-spl; bei einer benutzerdefinierten Installation muss jeder unten gezeigte /opt/sophos-spl-Pfad angepasst werden.
Vorher festlegen, wie der Server nach der Entfernung geschützt wird. Eine Deinstallation aktiviert entfernte oder zuvor ersetzte Drittanbieter-Sicherheitssoftware nicht wieder.

Den Ausgangszustand lokal erfassen:

sudo systemctl status sophos-spl
sudo test -x /opt/sophos-spl/bin/uninstall.sh && printf 'SPL uninstaller found\n'

Die erste Abfrage darf einen aktiven Dienst zeigen. Die zweite Kontrolle muss den vorhandenen, ausführbaren Uninstaller bestätigen. Schlägt sie fehl, nicht einen fremden uninstall.sh kopieren und nicht mit manueller Dateibereinigung fortfahren, sondern zuerst Installationspfad und Agent-Zustand klären.

Tamper Protection und B-02: Sophos dokumentiert Tamper Protection für Windows und macOS, nicht für Sophos Protection for Linux. Deshalb gibt es in diesem Linux-Ablauf kein Central-Kennwort und keinen versprochenen kennwortfreien Sonderweg nach Lizenzablauf oder Gerätelöschung. Diese Zustände werden nicht von Windows- oder macOS-Verhalten auf Linux übertragen. Massgeblich bleibt der vorhandene lokale SPL-Uninstaller mit Root-Rechten.

Unterstützten SPL-Uninstaller ausführen

Sophos dokumentiert für den Standardpfad den integrierten Uninstaller. In einer administrativen Shell ausführen:

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

Bei einer benutzerdefinierten Installation zuerst in das entsprechende Verzeichnis <INSTALLATIONSBASIS>/sophos-spl/bin wechseln. <INSTALLATIONSBASIS> ist genau der bei der Installation mit --install-dir verwendete Basis-Pfad; das Skript wird nicht aus /opt auf eine andere Installation übertragen.

Den Exitstatus und die vollständige Terminalausgabe im Change oder Deployment-System sichern. Ein beendeter Shell-Prozess allein ist noch kein Erfolgsnachweis.

Verbliebene cgroup-Verzeichnisse sicher behandeln

Sophos nennt nach dem Uninstaller genau diese vier Befehle:

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 entfernt ausschliesslich leere Verzeichnisse. Meldet ein Befehl, dass der Pfad nicht existiert, ist dort nichts zu entfernen; seine Abwesenheit beweist keine vollständige Deinstallation. Je nach cgroup-Version und Distribution sind nicht alle vier Pfade anwendbar. Meldet rmdir, dass ein Verzeichnis nicht leer ist, oder einen anderen unerwarteten Fehler (etwa bei einem eingebundenen oder verwendeten cgroup-Pfad), die genaue Meldung und den Zustand sichern und wie unten beschrieben eskalieren. Nicht mit rm -rf, rekursiven Wildcards oder selbst erfundenen Service-, Paket- und Kernel-Cleanup-Befehlen weiterarbeiten.

Entfernung und Nachfolgeschutz prüfen

Nach dem Uninstaller werden mindestens diese Punkte kontrolliert:

sudo systemctl status sophos-spl
sudo test ! -e /opt/sophos-spl/bin/uninstall.sh
sudo test ! -d /sys/fs/cgroup/sophos.slice
sudo test ! -d /sys/fs/cgroup/cpuacct/sophos.slice
sudo test ! -d /sys/fs/cgroup/cpu/sophos.slice
sudo test ! -d /sys/fs/cgroup/memory/sophos.slice

Für einen benutzerdefinierten Installationspfad ist die zweite Zeile anzupassen. Erwartet wird, dass sophos-spl nicht mehr als aktiver Dienst läuft, der Uninstaller am verwendeten Installationsort nicht mehr vorhanden ist und die genannten cgroup-Verzeichnisse nicht mehr bestehen. Die Abwesenheit einzelner, je nach cgroup-Version nicht anwendbarer Pfade ist kein Erfolgsnachweis und hebt weder einen Fehler des Uninstallers noch eine unerwartete rmdir-Fehlermeldung auf. Ein einzelner verbliebener Ordner ausserhalb dieser belegten Prüfpfade ist weder ein Beweis für aktiven Schutz noch eine Freigabe zur manuellen Löschung.

Zusätzlich prüfen:

Das vorgesehene Nachfolgeprodukt läuft, ist aktuell und meldet einen gesunden Schutzstatus.
Geschäftsrelevante Dienste und Monitoring des Servers funktionieren nach dem Eingriff.
Kein Deployment-Auftrag installiert SPL ungeplant erneut.
Das Gerät sendet nach angemessener Wartezeit keine neue SPL-Aktivität an Central.

Gerät erst danach aus Sophos Fusion entfernen

Soll der Server endgültig stillgelegt oder durch ein anderes Geräteobjekt ersetzt werden, den Datensatz erst nach erfolgreicher lokaler Abnahme bereinigen. Stopp vor jeder Gerätelöschung: Auf Warnungen zu doppelten Geräten und auf weitere Einträge mit derselben Agent-Identität prüfen; ein eindeutiger Hostname allein genügt nicht. Besonders bei geklonten Servern beziehungsweise Golden Images zuerst die Identitäts- und Klonlage klären. Sophos warnt, dass das Löschen eines Geräts mit Duplikaten diese an der Kommunikation oder erneuten Registrierung hindern kann. Bei einem Duplikat oder unklarer Identität nicht löschen, sondern die Zuordnung klären und an Sophos Support eskalieren (Gerätelöschung, Duplikat-Ereignisse, Linux-Golden-Image-Verfahren). Das Deregistrieren einer Golden-Image-Vorlage ist ein eigener Imaging-Ablauf, kein Ersatz für uninstall.sh.

My Environment > Computers & Servers öffnen.
Nach bestandener Duplikat- und Identitätsprüfung den eindeutig zugeordneten Linux-Server auswählen.
Noch benötigte Alerts und Untersuchungsdaten sichern.
Actions > Delete device wählen und die Löschung bestätigen.
Prüfen, dass der Datensatz nicht mehr in der aktiven Geräteliste erscheint und nicht durch eine verbliebene oder erneut verteilte Installation zurückkehrt.

Bei einer vorübergehenden Reparatur oder geplanten Neuinstallation wird der Datensatz nicht vorschnell gelöscht. So bleibt der bisherige Zustand für Diagnose und Vergleich verfügbar.

Wenn die Deinstallation fehlschlägt

`uninstall.sh` fehlt oder startet nicht

Installationspfad, Dateirechte und die tatsächlich installierte SPL-Variante erneut prüfen. Wurde ein benutzerdefinierter Pfad verwendet, liegt das Skript dort unter sophos-spl/bin. Keine Skripte von einem anderen Server übernehmen und keine Dateien, Pakete, Benutzer oder Dienste auf Verdacht löschen.

Der Dienst läuft weiter oder SPL meldet sich erneut

Exitstatus und Terminalausgabe prüfen. Danach Softwareverteilung, Konfigurationsmanagement, Startskripte und Golden Images auf einen erneuten Installationsauftrag kontrollieren. Den Central-Datensatz nicht wiederholt löschen, solange noch ein lokaler Agent oder Rollout-Job aktiv sein kann.

Ein cgroup-Befehl meldet einen unerwarteten Fehler

Bei einem nicht leeren Verzeichnis oder einem anderen unerwarteten rmdir-Fehler keine rekursive Löschung erzwingen. Prozess- und Mount-Zustand, genaue Fehlermeldung, Distribution, Kernel, cgroup-Version, SPL-Version, Installationspfad und Zeitpunkt erfassen. Diese Informationen zusammen mit der Ausgabe von uninstall.sh an Sophos Support geben. Es werden keine zusätzlichen Residual-Cleanup-Befehle geraten.

Eskalationspunkt

Bleibt der Agent aktiv, endet der Uninstaller mit einem Fehler oder ist der Zustand widersprüchlich, den Server nicht als erfolgreich ausgebucht markieren. Nachfolgeschutz sicherstellen und bei einer Schutzlücke den Server gemäss eigenem Incident-Verfahren angemessen isolieren. An Sophos Support gehen mindestens Distribution und Version, Architektur, Kernel, SPL-Version, benutzerdefinierter oder Standardpfad, exakter Befehl, Exitstatus, vollständige Ausgabe, Zeitstempel, Service-Status und die genaue cgroup-Fehlermeldung.

Nur falls SPL noch installiert und das jeweilige Werkzeug verfügbar ist: Optional den Status über /opt/sophos-spl/bin/sophosctl status (Endpoint Self Help; bei benutzerdefinierter Installation Pfad anpassen) erfassen oder die Sophos Diagnostic Utility (SDU) für SPL- und Systemprotokolle nutzen. Diese Diagnostik ist keine Voraussetzung für eine erfolgreiche Entfernung und kein Ersatz für das Uninstaller-Protokoll (Sophos: SPL-Fehlerbehebung).

Neuinstallation und Rückweg

Eine Deinstallation hat keinen automatischen Rollback. Muss SPL wiederhergestellt werden, einen aktuellen, tenantgebundenen Linux Server Installer aus My Environment > Installers verwenden und dem Ablauf unter Sophos Protection for Linux installieren und ausrollen folgen. Nicht einen alten Installer, ein kopiertes Agent-Verzeichnis oder das entfernte uninstall.sh als Reparatur verwenden.

Die Wiederherstellung gilt erst als abgeschlossen, wenn der Dienst lokal läuft, der Server in Central mit der erwarteten Identität erscheint, die vorgesehenen Komponenten und Server-Richtlinien erhält und der benötigte Schutz nachweislich aktiv ist. Bis dahin bleibt der Change offen.