Sophos Linux Sensor: Support-Daten sicher sammeln

Bei einem Problem mit Sophos Linux Sensor (SLS) sammelt man ein Support-Archiv und die passenden Sensor-Logs, möglichst während des Fehlers oder unmittelbar danach. Die Sammlung benötigt ungefähr 30 Sekunden. Zuerst die Bereitstellung bestimmen: Bei Helm wird pro betroffenem Node gesammelt, bei Docker auf dem Docker-Host und bei einer direkten Installation auf dem Linux-Host. Nach dem Debug-Signal muss der Download sofort folgen; das temporäre Debug-Fenster beträgt 60 Sekunden.

Diese Anleitung gilt ausschliesslich für Sophos Linux Sensor. SLS ist weder Sophos Protection for Linux (SPL) noch dessen XDR Sensor oder dessen Linux-Runtime-Detection-Richtlinie. Die Einordnung in der Server-Übersicht dient der Navigation und macht die Produkte nicht gleichwertig. Für SPL gilt die separate Installations- und Betriebsanleitung; die folgenden SLS-Befehle dürfen dort nicht übernommen werden.

Zielsystem und Freigabe vor der Sammlung prüfen

Vor einem Signal oder Neustart bestätigt man anhand des Deployment-Inventars und der laufenden Instanz, dass tatsächlich SLS betroffen ist. Host beziehungsweise Cluster, Namespace, Pod, Node oder Container, installierte Sensor-Version und Fehlerzeit mit Zeitzone werden im Support-Fall festgehalten. Die Versionsinformationen im späteren Archiv ergänzen diese Zuordnung. Diese Anleitung folgt dem am 5. Oktober 2026 aktualisierten Support-Ablauf; daraus ergibt sich keine Mindestversion oder Freigabe für jede ältere Sensor-, Helm-, Kubernetes- oder Docker-Version. Bei abweichenden Namen, Ports oder einem fehlenden Monitoring-Endpunkt zuerst die tatsächliche Bereitstellung mit Support klären.

Man benötigt ein zugriffsgeschütztes Arbeitsverzeichnis mit ausreichend freiem Speicher. Die unten gezeigten Dateinamen sind relativ zu diesem Verzeichnis; vorhandene Pakete vor einer Wiederholung getrennt sichern, damit sie nicht überschrieben werden. Zugriff auf Archiv, Logs und Profile auf die zuständigen Personen begrenzen und eine Aufbewahrungsfrist festlegen. Für Downloads bleiben die Monitoring-Adressen lokal. Keinen öffentlichen Service, Ingress oder allgemein erreichbaren Debug-Port einrichten.

Die Werkzeuge müssen bereits freigegeben und verfügbar sein. Fehlt curl auf einem direkt installierten Linux-Host, dokumentiert der Ablauf diese Installationsbefehle:

# Red-Hat-basierte Systeme
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Nur den zur Distribution passenden Befehl im genehmigten Paketmanagement-Prozess verwenden. Eine Paketinstallation verändert den Host; sie gehört nicht zur blossen Prüfung des Artikels. Für Helm und Docker werden zusätzlich tar und gzip benötigt. Ohne erforderliche Werkzeuge oder Berechtigungen vor der Debug-Aktivierung stoppen.

Helm: ein Paket je betroffenem Node

Auf dem Administrationsrechner muss kubectl für den richtigen Cluster eingerichtet sein. Die Berechtigung muss Pods auflisten, Pod-Logs lesen, Pod-Ports weiterleiten und einen ephemeren Debug-Container hinzufügen dürfen. Ausserdem muss die Container-Runtime das Targeting des Prozess-Namespace eines anderen Containers unterstützen. curl, tar und gzip werden auf diesem Rechner gebraucht.

Der Cluster muss busybox:latest beziehen können. Ist diese Registry nicht genehmigt, wird das Image vorher in eine freigegebene, erreichbare Registry gespiegelt und nur der Wert von --image durch diese geprüfte Image-Referenz ersetzt. Nicht die Registry-Sicherheitsregeln lockern, um die Sammlung zu erzwingen. Der ephemere Container ist eine Änderung am Pod; sie benötigt die passende Betriebsfreigabe.

Pod wählen und Port-Forward offen halten

Der SLS-Helm-Chart stellt einen Sensor-Pod je überwachtem Linux-Node bereit. <namespace> durch den Namespace des SLS-Releases ersetzen:

kubectl --namespace <namespace> \
get pods \
--selector app=sophos-linux-sensor \
--output wide

Die Ausgabe muss den Sensor-Pod dem betroffenen Node zuordnen. <sensor-pod> ist genau dieser Pod, <node-name> dessen Node-Name. Nicht irgendeinen gesunden Pod desselben Releases verwenden.

Im ersten Terminal den Monitoring-Port weiterleiten:

kubectl --namespace <namespace> \
port-forward pod/<sensor-pod> 9010:9010

Dieses Terminal bleibt bis zum abgeschlossenen Download offen. Wenn der lokale Port bereits belegt ist, den Vorgang stoppen und den Konflikt klären, statt einen fremden Prozess zu beenden. Keine Bindung an öffentlich erreichbare Adressen ergänzen. Bricht die Weiterleitung ab, muss sie vor dem erneuten Download wieder laufen.

Signal senden, sofort herunterladen und Logs ergänzen

Im zweiten Terminal wird der Debug-Container auf den SLS-Container ausgerichtet. Der Befehl sendet SIGUSR2 an den Sensorprozess; er ist keine Anweisung, den Sensor zu beenden:

kubectl --namespace <namespace> \
debug pod/<sensor-pod> \
--image=busybox:latest \
--target=sophos-linux-sensor \
--attach=false -- \
pkill -USR2 -f '[s]ophoslinuxsensor'

Das Suchmuster [s]ophoslinuxsensor verhindert, dass pkill seine eigene Befehlszeile trifft. Scheitern Image-Pull, Berechtigung oder Prozess-Targeting, wurde die Sammlung nicht zuverlässig aktiviert. Nicht blind weitere Debug-Container hinzufügen; zuerst die Fehlermeldung klären.

Direkt anschliessend im zweiten Terminal herunterladen:

curl --fail --silent --show-error \
--max-time 120 \
http://127.0.0.1:9010/support.tar \
--output sophos-linux-sensor-support-<node-name>.tar

--max-time 120 begrenzt den HTTP-Aufruf, verlängert aber nicht das Debug-Fenster. Danach die aktuellen Logs desselben Containers und Nodes sichern:

kubectl --namespace <namespace> \
logs pod/<sensor-pod> \
--container sophos-linux-sensor \
--timestamps \
> sophos-linux-sensor-<node-name>.log

Den Inhalt ohne Entpacken auflisten:

tar -tf sophos-linux-sensor-support-<node-name>.tar

Nach der unten beschriebenen Vollständigkeitsprüfung den Port-Forward im ersten Terminal mit Ctrl+C beenden. Für jeden weiteren betroffenen Node einen eigenen Pod und eindeutigen Dateinamen verwenden.

Docker: laufenden Container und veröffentlichten Port prüfen

Alle folgenden Befehle laufen auf dem Docker-Host mit der dort genehmigten Docker-Berechtigung. Der SLS-Container muss laufen; sein Monitoring-Port muss bereits zum Host veröffentlicht sein. Der Standardport im Container ist 9010. curl, tar und gzip müssen vorhanden sein. Eine nachträgliche Port-Veröffentlichung oder ein Container-Neustart wird hier nicht als Reparatur angeordnet.

docker ps
docker port <sensor-container> 9010/tcp

<sensor-container> ist Name oder ID des bestätigten SLS-Containers. Die zweite Ausgabe nennt Hostadresse und Hostport. <host-port> wird durch diesen Port ersetzt, nicht automatisch durch 9010. Der folgende Download setzt voraus, dass die veröffentlichte Adresse über 127.0.0.1 auf diesem Docker-Host erreichbar ist. Bei ausschliesslich anderer Bindung oder fehlender Ausgabe zuerst das Deployment prüfen; keinen öffentlich erreichbaren Port hinzufügen.

Der folgende Befehl verändert den Debug-Zustand für 60 Sekunden. docker kill darf dabei nicht ohne --signal=SIGUSR2 ausgeführt werden:

docker kill --signal=SIGUSR2 <sensor-container>

Sofort danach den veröffentlichten lokalen Endpunkt abrufen:

curl --fail --silent --show-error \
http://127.0.0.1:<host-port>/support.tar \
--output sophos-linux-sensor-support.tar

Logs und Archivprüfung gehören zum selben Paket:

docker logs <sensor-container> \
> sophos-linux-sensor.log 2>&1

tar -tf sophos-linux-sensor-support.tar

Der temporäre Debug-Modus endet automatisch. Eine erneute Abfrage mit docker ps muss weiterhin den vorgesehenen laufenden Container zeigen; dies allein beweist allerdings noch keine funktionierende Erkennung.

Direkt installierter Linux-Host: temporären Debug-Modus verwenden

Dieser Zweig gilt für den direkt auf dem Host laufenden SLS, nicht für einen Container und nicht für /opt/sophos-spl. Root-Berechtigung und Zugriff auf den lokalen Monitoring-Port werden benötigt. Bei einer systemd-Installation vorab mit journalctl -u sophoslinuxsensor prüfen, ob das Journal zum erwarteten Dienst und Host gehört. Fehlt der Dienst oder gibt es mehrere Sensorinstanzen, erst deren Zuordnung klären.

Der dokumentierte Host-Befehl trifft alle aktiven Prozesse mit dem Muster sophoslinuxsensor auf dem Host. Er grenzt nicht auf eine einzelne Instanz ein. Ohne Freigabe für diese Instanzen oder bei unklaren Prozessnamen nicht ausführen.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

Der Sensor bietet Support- und Debug-Informationen danach für 60 Sekunden am Monitoring-Endpunkt an. Sofort im vorbereiteten Arbeitsverzeichnis sammeln:

curl -O http://localhost:9010/support.tar && gzip support.tar

Die Sammlung benötigt ungefähr 30 Sekunden. Nach erfolgreicher Kompression liegt support.tar.gz vor. Dieser Host-Aufruf enthält weder einen HTTP-Fehlercheck noch ein Timeout; ein vorhandener Dateiname oder erfolgreicher gzip-Aufruf ist deshalb kein Beweis für ein vollständiges Archiv. Für die lokale Prüfung, ohne das Paket zu entpacken:

tar -tzf support.tar.gz

Die Host-Logs liest man mit:

journalctl -u sophoslinuxsensor

Für eine laufende Beobachtung ist zusätzlich dieser Aufruf dokumentiert:

journalctl -efu sophoslinuxsensor

Die Beobachtung mit Ctrl+C beenden und die für den Fehlerzeitraum benötigten Journalinformationen über den genehmigten Exportweg sichern. Keine unbegrenzte laufende Ausgabe als abgeschlossenes Support-Paket behandeln.

Archiv prüfen, Fehler eingrenzen und sicher übergeben

Ein vollständiges Debug-Archiv enthält Einträge wie runtimedetections.yaml, environment.json, goroutine.out und profile.out, zusätzlich Metrik- und Versionsinformationen. Die genannten Einträge sind Beispiele, kein Versprechen identischer Inhalte für jede Version. tar muss das Archiv ohne Fehler auflisten können. Eine HTML-Fehlerseite, ein leeres Paket oder ein abgebrochener Download sind kein verwertbares Ergebnis.

Enthält das Paket nur metrics.txt und version.json, war die Debug-Sammlung nicht aktiv. Zielinstanz, Signalfehler und Zeitabstand prüfen. Danach im passenden Deployment-Zweig erneut SIGUSR2 senden und unmittelbar neu herunterladen. Beim Helm-Zweig muss der Port-Forward während des gesamten Downloads laufen. Wiederholte Fehlschläge mit exakter Fehlermeldung, Sensor-Version und Fehlerzeit an Support eskalieren; nicht durch dauerhaften Debug-Modus oder einen offenen Netzwerkport umgehen.

Archive, Logs und Profile können vertrauliche Konfiguration, Umgebungsvariablen, Host- und Laufzeitinformationen enthalten. Auch wenn Teile der Konfiguration automatisch redigiert werden, ist das Paket nicht automatisch für öffentliche Weitergabe anonymisiert.

Vor der Übermittlung die Dateiliste und, soweit nötig, die Inhalte in einer abgeschotteten Umgebung auf Zugangsdaten, Tokens, interne Hostnamen und personenbezogene Daten prüfen. Für Redaktionen eine getrennte Kopie verwenden und Änderungen dokumentieren; binäre Profile nicht unkontrolliert verändern. Mit Support klären, welche Inhalte zur Diagnose unverändert benötigt werden. Das Original nur zugriffsgeschützt und nach der vereinbarten Frist behalten.

Archiv und zugehörige Logs ausschliesslich über den im Support-Fall bestätigten, genehmigten Sophos-Support-Kanal übermitteln. Den Empfänger und Upload-Ziel anhand des bestehenden Falls verifizieren, nicht anhand einer unaufgeforderten Nachricht. Kein öffentliches Ticket, Forum, Git-Repository oder KB-Medienablage verwenden. Zum Paket gehören Deployment-Typ, betroffene Nodes beziehungsweise Hosts, Sensor-Version, Fehlerzeit mit Zeitzone, Symptom und bereits ausgeführte Sammlungsschritte; keine Zugangsdaten als Begleittext senden.

CPU- und Speicherprofile nur bei gezieltem Bedarf

Für ein normales Support-Archiv genügt das temporäre Signal. Die folgenden Einzelprofile sind ein separater Weg für CPU- oder Speicherprobleme und verwenden Googles pprof-Format. Für die dauerhaft konfigurierte Debug-Aktivierung muss vorab feststehen, wie der tatsächliche SLS-Dienst gestartet wird und wie seine Konfiguration zurückgestellt werden kann.

Zuerst den bisherigen Inhalt von /etc/sophos/runtimedetections-rules.yaml, den bisherigen Wert beziehungsweise das Fehlen von debug und die wirksame Startumgebung sichern. Insbesondere feststellen, ob RUNTIMEDETECTIONS_DEBUG bereits gesetzt ist. Eine Sicherung derselben Konfiguration ist ebenfalls vertraulich. Nicht mit der ähnlich benannten Datei runtimedetections.yaml im Support-Archiv verwechseln.

Eine der dokumentierten Aktivierungen wählen:

• Den Sensor mit RUNTIMEDETECTIONS_DEBUG=true in seiner tatsächlichen Startumgebung ausführen. Ein blosses export in einer Administrationsshell stellt die Umgebung eines bereits laufenden Dienstes nicht um.
• debug: true in /etc/sophos/runtimedetections-rules.yaml setzen, ohne die übrigen Regeln zu ersetzen oder einen widersprüchlichen zweiten Eintrag anzulegen.

Ein Neustart unterbricht den SLS-Dienst. Wartungsfreigabe, tolerierbare Erkennungslücke und Zugriff auf die ursprüngliche Konfiguration müssen vorher feststehen. Dieser systemd-Aufruf gilt für die direkte Host-Installation; er ist kein Helm- oder Docker-Neustartrezept.

Mit Root-Berechtigung den dokumentierten Neustart ausführen:

systemctl restart sophoslinuxsensor

Danach Dienstzustand und Journal kontrollieren. Erst bei laufendem Dienst und gültiger Konfiguration die benötigten Profile am lokalen Endpunkt sammeln:

curl -s http://localhost:9010/debug/pprof/heap > heap.out
curl -s 'http://localhost:9010/debug/pprof/profile?seconds=60' > profile.out

heap.out erfasst Stichproben der Speicherbelegung lebender Heap-Objekte; profile.out erfasst CPU-Nutzung über 60 Sekunden. Diese Aufrufe enthalten keinen HTTP-Fehlercheck: Eine erzeugte Datei allein beweist kein gültiges Profil. Leere Dateien oder eine Fehlerantwort nicht als Messwert interpretieren; den Endpunkt und die wirksame Debug-Konfiguration prüfen und das Format gegebenenfalls mit Support validieren. Auch diese Dateien bleiben vertraulich.

Metriken benötigen dagegen keinen Debug-Modus und keinen Debug-bedingten Neustart:

curl -s http://localhost:9010/metrics > metrics.out

Debug-Zustand und Betriebszustand wiederherstellen

Bei der temporären Sammlung nach dem 60-Sekunden-Fenster keine weiteren Signale senden. Den Sensor weiterlaufen lassen und anhand seiner Logs beziehungsweise des vorhandenen Betriebsmonitorings prüfen, ob er weiterhin normal arbeitet. Ein laufender Prozess oder erreichbarer Metrik-Endpunkt ist kein vollständiger Nachweis für Erkennung und Datenübermittlung. Bei abweichendem Verhalten mit Support arbeiten.

Bei dauerhaft konfiguriertem Debug gibt es keinen automatischen Rückweg nach 60 Sekunden. Den zuvor gesicherten debug-Wert beziehungsweise dessen ursprüngliches Fehlen in der YAML-Datei wiederherstellen und eine für diese Diagnose neu gesetzte RUNTIMEDETECTIONS_DEBUG-Variable in der tatsächlichen Startkonfiguration auf den vorherigen Zustand zurückstellen. Nicht pauschal andere Einstellungen oder die ganze inzwischen geänderte Konfiguration überschreiben. Die genaue Umgebungsänderung hängt vom vorhandenen Startmechanismus ab; ohne bekannte Baseline gibt es keinen universellen sicheren Rücksetzbefehl.

Für den direkt installierten systemd-Dienst nach dieser Wiederherstellung erneut den oben gezeigten systemctl restart sophoslinuxsensor im genehmigten Wartungsfenster verwenden. Dienst und Journal auf Start- oder Konfigurationsfehler prüfen, die wirksame Debug-Einstellung mit dem vorherigen Zustand vergleichen und kontrollieren, dass kein für die Diagnose neu aktivierter Profilzugang bestehen bleibt. War Debug bereits vorher aktiv, ist seine Deaktivierung eine zusätzliche Betriebsentscheidung und keine Wiederherstellung.

Den Helm-Port-Forward beenden und bestätigen, dass dessen Terminalprozess abgeschlossen ist. Der ephemere Debug-Container lässt sich nicht als normaler Container aus dem bestehenden Pod entfernen; keinen Sensor-Pod nur zur Bereinigung dieser Diagnose löschen. Falls die lokale Cluster-Richtlinie eine Pod-Erneuerung verlangt, muss der zuständige Betreiber sie separat mit Erkennungslücke und Rollout-Kontrolle planen.

Nach bestätigter Übernahme durch Support und Ablauf der festgelegten Aufbewahrung die konkret erzeugten Archiv-, Log- und Profildateien sowie temporäre Redaktionskopien nach der lokalen Löschrichtlinie entfernen. Keine Wildcard-Löschung und keine Löschung von Sensorregeln, Produktlogs oder anderen Support-Fällen durchführen. Eine Dateilöschung garantiert nicht das Überschreiben von Backups, Snapshots oder SSD-Blöcken; diese Aufbewahrung gehört zur zuständigen Speicher- und Datenschutzrichtlinie.