Sophos Linux Sensor auswählen, installieren und prüfen

Sophos Linux Sensor (SLS) erfasst Linux-Laufzeitereignisse und verarbeitet sie mit Detection Content zu Alerts beziehungsweise konfigurierten Reaktionen. Er kann mit vorhandener Logging- und Alert-Infrastruktur verbunden werden. SLS ist ein eigenständiger Sensor: Er ist weder Sophos Protection for Linux (SPL) noch dessen XDR Sensor oder eine SPL-Runtime-Detection-Richtlinie.

Für einen ersten Pilot werden Plattform und Anspruch geprüft, der passende Installationsweg gewählt und Sensor plus Content bereitgestellt. Danach wird ein Testalert bis zum tatsächlich vorgesehenen Empfänger verfolgt. Ein laufender Dienst allein genügt nicht. Diese Anleitung beschreibt den direkten systemd-Host-Pfad; Container- und Kubernetes-Installationen verwenden einen anderen Bereitstellungsweg.

Lizenz und Betriebsmodell zuerst klären

Die am 27. Oktober 2026 geprüfte Sophos-Anleitung nennt für den SLS-Zugang Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) oder Sophos MDR Plus (Server). Evaluierungslizenzen berechtigen nicht dazu. Eine beliebige Endpoint-Lizenz oder das blosse Vorhandensein eines Linux-Servers ist kein Anspruchsnachweis.

SLS wird pro Gerät lizenziert. Seine Instanzen erscheinen jedoch laut Hersteller weder in der Fusion-Serverliste noch in der dortigen Devices-Ansicht beziehungsweise deren Lizenzzählung. Deshalb führt man ein eigenes Inventar der installierten Sensoren. Sophos Fusion (ehemals Sophos Central) kann SLS-Detection-Details und Alerts empfangen, verwaltet den Sensor aber nicht. Ein fehlender SLS-Servereintrag ist somit nicht mit fehlgeschlagener SPL-Registrierung gleichzusetzen.

Für einen klassischen verwalteten Serveragent mit den gewünschten SPL-Komponenten führt der Weg zu Sophos Protection for Linux. Bei immutable Images oder speziellen Containerplattformen wird SLS separat auf Eignung geprüft; die Erwähnung eines solchen Einsatzfalls ist keine Freigabe jeder Distribution oder jeder Kernel-/Runtime-Kombination.

Plattform und Pilot vorbereiten

Die aktuellen SLS-Release-Notes nennen zum Prüfstand mindestens 2 GB freien Plattenplatz, 2 GB freien Arbeitsspeicher sowie x86_64 oder ARM64. Für ARM64 ist Kernel 5.3 oder neuer erforderlich. Die konkrete Distribution, deren aktueller Minor-Stand und der laufende Kernel müssen zusätzlich zur getesteten Plattformliste passen. Eine Kernel-Untergrenze einer anderen Distribution ist keine allgemeine Freigabe. Legacy-Plattformen haben gesonderte Supportbedingungen.

Vor dem Pilot erfasst man Hostrolle, Distribution, Architektur, Kernel, vorhandene Schutzsoftware, Lastprofil und den vorgesehenen Alert-Empfänger. Bei direkter Host-Installation müssen Root-/Paketverwaltungsrechte, ein passender systemd-Betrieb und der von SLS benötigte Linux-Debug-Unterbau vorhanden beziehungsweise freigegeben sein. Ein gehärtetes System wird nicht vorsorglich entschärft, nur damit ein Installationsskript weiterläuft.

Für Kubernetes stellt Sophos einen eigenen Helm-Weg bereit; Docker, CRI-O und containerd haben ebenfalls spezifische Anleitungen. Dabei gehören Registry-Zugang, Hostsicht, Berechtigungen, Content-Image und Runtime zur Prüfung. Ein Paketbefehl aus diesem Host-Beispiel wird nicht unverändert in einen Sensorcontainer übernommen.

Registry-Token im richtigen Tenant bereitstellen

SLS verwendet einen eigenen Package Registry API Token, dessen Wert mit SLS- beginnt. Er ist nicht dasselbe wie der kurzlebige OAuth-Access-Token oder das Client Secret einer API-Identität.

Die aktuelle SLS-Anleitung verlangt einen Super Admin im Fusion-Admin-Dashboard des Kunden, nicht im Partner- oder Enterprise-Dashboard. Unter Global Settings > Administration > API Credentials Management > Add Credential wird die benötigte Identität mit Service Principal Super Admin erstellt. Diese weitreichende Herstelleranforderung wird vorab durch die verantwortliche Stelle freigegeben und nicht als Standardrolle für beliebige API-Projekte übernommen. Client ID und nur einmal sichtbares Client Secret werden geschützt abgelegt.

Über den API-Credentials- und OAuth-Ablauf beschafft man das Bearer-Token und ermittelt mit whoami/v1 die eindeutige Kunden-Tenant-ID. Für diesen Weg muss idType den Kunden-Tenant bestätigen. Ein Partner-Identifier ist dafür nicht geeignet. Anschliessend wird beim globalen Sophos-API-Host ein POST auf /accounts/v1/access-tokens mit Bearer-Authentisierung, X-Tenant-ID und JSON-Inhalt angelegt:

{
  "label": "SLS Pilot",
  "type": "sophosLinuxSensor"
}

label ist ein frei wählbarer Verwaltungsname, type dagegen der feste API-Wert. In der Antwort wird das Feld token als Registry-Zugang verwendet, nicht die Objekt-ID. Ein optionales expiresAt wird nach dem eigenen Zugriffsplan gewählt; ein über die Serverlizenz hinaus gesetztes Datum wird laut Sophos auf deren Ablauf begrenzt. Aus einem Beispiel mit weit entferntem Datum folgt keine dauerhafte Berechtigung.

Im HTTP-Client werden Status und Antwortinhalt geprüft. Tokens und Secrets dürfen nicht in Shell-History, Proxy-Diagnosen, Tickets oder Screenshots gelangen. Ein Fehler bei Tenant, Anspruch oder Token wird zuerst geklärt; Schutzfunktionen oder Berechtigungen werden nicht auf Verdacht tenantweit geändert.

Direkten Host über die Paketverwaltung installieren

Für den folgenden Ablauf wird der SLS-Registry-Zugang zuerst im freigegebenen Paketmanagement bereitgestellt. Sophos dokumentiert dafür packages.sophos.com/sophos-linux-sensor/release/ und den Schlüssel sophos-linux-sensor-archive-keyring.gpg. Der Schlüssel wird über den authentisierten Herstellerweg bezogen und unter /etc/sophos-linux-sensor.gpg abgelegt. Vor Verwendung werden Herkunft und aktueller Fingerprint über die genehmigte Vertrauenskette geprüft. gpg --list-packets zeigt lediglich ein lesbares Schlüsselpaket; das allein beweist keine vertrauenswürdige Herkunft.

Debian-basierte, unterstützte Hosts

In einer passenden .list-Datei unter /etc/apt/sources.list.d/ wird die Quelle eingetragen:

deb [signed-by=/etc/sophos-linux-sensor.gpg] https://packages.sophos.com/sophos-linux-sensor/release/ stable main

Der zugehörige Registry-Token wird in einer zugriffsbeschränkten .conf-Datei unter /etc/apt/auth.conf.d/ hinterlegt:

machine packages.sophos.com login <SLS-REGISTRY-TOKEN>

Der Platzhalter wird durch den tatsächlich erhaltenen Registry-Token ersetzt. Die Datei darf nur für die benötigten privilegierten Paketmanagement-Prozesse lesbar sein; Token nicht zusätzlich in die Repository-URL schreiben. Nach Prüfung von Signaturvertrauen, Quelle und Dateirechten werden im genehmigten Änderungsfenster ausgeführt:

sudo apt-get update
sudo apt-get install sophoslinuxsensor-systemd sophoslinuxcontent

Unterstützte RPM-basierte Hosts

Der RPM-Weg verwendet eine separate .repo-Datei unter /etc/yum.repos.d/. Der folgende Abschnittsname und Anzeigename sind frei gewählte Beispiele; URL, Signaturprüfung und Schlüsselpfad entsprechen dem dokumentierten Registry-Weg:

[sls]
name=Sophos Linux Sensor
baseurl=https://<SLS-REGISTRY-TOKEN>@packages.sophos.com/sophos-linux-sensor/release/
gpgcheck=1
enabled=1
gpgkey=file:///etc/sophos-linux-sensor.gpg

Der Platzhalter wird durch den erhaltenen Registry-Token ersetzt. Die tokenhaltige Datei wird zugriffsbeschränkt bereitgestellt. Ihre URL darf nicht in Diagnoseprotokollen, Tickets oder Screenshots offengelegt werden. Vorhandene Distribution-Repositories werden nicht ersetzt und Signaturprüfungen nicht ausgeschaltet. Der Anzeigename ist keine Freigabe einer bestimmten Distribution oder Version.

Nach der korrekt eingerichteten Quelle nennt Sophos folgende Pakete:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Nur den zur tatsächlich unterstützten Distribution passenden Paketweg verwenden. Sensor und Content sind zwei notwendige Bestandteile. Meldet der Dienst Zero policies configured, ist die Detection-Abnahme nicht bestanden, auch wenn der Prozess läuft. Alte Versionsnummern aus Hersteller-Beispielausgaben sind keine aktuelle Installationsvorgabe.

Tenant und Alert-Ausgabe konfigurieren

In /etc/sophos/runtimedetections.yaml wird customer_id auf die zuvor geprüfte Tenant-ID gesetzt. Bestehende YAML-Einstellungen werden gezielt ergänzt, statt die komplette Datei mit einer Beispielkonfiguration zu überschreiben. Telemetrieübermittlung und Alert-Ausgänge werden vor dem Start auf Zweck und Datenfreigabe geprüft. Sophos beschreibt standardmässig eine Alert-Ausgabe nach stdout; daraus folgt keine automatische Anbindung an jeden gewünschten Empfänger.

Für eine kontrollierte Erstprüfung wird der konkrete Ausgang festgehalten: lokales Journal, ein vorhandenes Logging-System oder der ausdrücklich konfigurierte Sophos-Empfänger. Zugangsdaten, Ziel und Format werden passend zu diesem Ausgang eingerichtet. Das Registrieren eines Tokens ist noch kein Nachweis einer funktionierenden Alert-Weiterleitung.

Beim direkten systemd-Host-Pfad startet und prüft man danach:

sudo systemctl start sophoslinuxsensor
sudo systemctl status sophoslinuxsensor
sudo journalctl -u sophoslinuxsensor

Bei Startfehlern werden zunächst Plattform, Pakete, wirksame YAML-Konfiguration und die im Journal genannten Rechte geprüft. Die Herstellerinstallation beschreibt benötigte Linux-Capabilities; sie werden nicht mit pauschalen privilegierten Containerrechten oder einem ungeprüften setcap auf beliebige Dateien ersetzt.

Erkennung bis zum Empfänger abnehmen

Nach installiertem Default Content und laufendem Sensor kann auf einem freigegebenen Pilot der dokumentierte Testalert erzeugt werden. Vorher die Syntax gegen die installierte Version prüfen: Die Installationshilfe zeigt an einer Stelle abweichend -test-alert; die eigene Testanleitung verwendet --test-alert. Der folgende Aufruf wird nur verwendet, wenn die installierte Version diese Schreibweise unterstützt:

sophoslinuxsensor --test-alert

Der Test erzeugt bewusst ein Ereignis. Deshalb wird er mit dem empfangenden Team abgestimmt und nicht als heimlicher Funktionstest im Produktivbetrieb ausgeführt. Erwartet wird der Alert Tester im konfigurierten Ausgang. Host, Zeitpunkt und Empfänger müssen zusammenpassen; eine erfolgreiche Befehlsausführung oder ein lokaler Logeintrag allein bestätigt keine entfernte Zustellung.

Fehlt diese Unterstützung oder bleibt der erwartete Alert aus, wird nicht mit echtem Schadcode oder einem unkontrollierten Angriff nachgeholfen.

Die Abnahme dokumentiert mindestens Sensor-/Content-Version, wirksame Regeln, fehlerfreien Start, den Testalert und dessen tatsächlichen Empfang. Ein solcher Test bestätigt diesen Weg, nicht jede Detection, jede Lastsituation oder einen MDR-Untersuchungsanspruch. Weitere Pilotlast und Anwendungsbetrieb werden gegen den Ausgangszustand verglichen.

Regeln, Updates und Fehler im Betrieb

Das Standard-Content-Paket liegt unter /var/lib/sophos/content/runtimedetections-content.yaml und wird bei Updates überschrieben. Anpassungen gehören in die vorgesehene /etc/sophos/runtimedetections-rules.yaml, nicht direkt in die Herstellerdatei. Sophos unterstützt laut Detection-Hilfe den unveränderten Standard-Content; für modifizierte oder selbst geschriebene Regeln ist gesonderte Unterstützung zu klären.

Core- und Enhanced-Detections haben unterschiedliche Tiefe und Lastwirkung. Mehr Content wird nicht ohne Pilot als bessere Einstellung für jede Serverlast behandelt. Sensor und Content werden über den jeweiligen Paket- oder Container-Rollout kontrolliert aktualisiert und danach erneut geprüft; ein einmaliger Installationsnachweis ersetzt keinen Updatebetrieb.

Bei fehlenden Alerts werden Content, geladene Regeln, Ereignis, Ausgang und Weiterleitung getrennt untersucht. Für tiefergehende Logs und Diagnosepakete gilt SLS-Supportdaten sicher sammeln. Dort stehen auch die getrennten Helm-, Docker- und Host-Diagnosewege. Ein geplanter Rückbau wird mit den dokumentierten Ausgangswerten, verbleibendem Schutzbedarf und dem passenden Hersteller-Deinstallationsweg vorbereitet. Dienste oder Credentials anderer Hosts werden dafür nicht gelöscht.