Linux Runtime Detection für Sophos-Server einrichten und prüfen

Linux Runtime Detection (RTD) beobachtet laufende Prozesse und Anwendungen auf Linux-Servern mit Sophos Protection for Linux (SPL). Eine RTD-Erkennung meldet verdächtige Aktivität; sie bedeutet nicht, dass der Prozess durch RTD blockiert oder bereinigt wurde. RTD ergänzt die Server Threat Protection, ersetzt aber weder deren Malware-Schutz noch den Linux-Echtzeitscan. Das Beenden schädlicher Prozesse bei einer Echtzeit-Malware-Erkennung ist eine separate Einstellung der Server Threat Protection, keine RTD-Wirkung. Eine gespeicherte Profilkonfiguration allein aktiviert keine Erkennung auf einem Server.

Kurzablauf: Lizenz und SPL-Server prüfen → in der wirksamen Server Threat Protection-Richtlinie Linux runtime detections aktivieren → für eine kleine Linux-Servergruppe eine Linux Runtime Detection-Richtlinie mit SophosLabs-Standarderkennungen oder einer ausdrücklich gewählten Profilversion einschalten → Zuweisung und Erkennungen prüfen → erst danach ausweiten.

Voraussetzungen und Entscheidung vor dem Pilot

RTD-Richtlinien gelten nur für Linux-Server, nicht für Windows-Server oder den separat konfigurierten Sophos Linux Sensor. Für die Sophos-Dokumentation zur RTD-Richtlinie sind Sophos XDR - Server oder Sophos MDR Plus - Server erforderlich. Eine allgemeine Server-Protection-, Endpoint- oder andere MDR-Lizenz darf daraus nicht als RTD-Berechtigung abgeleitet werden. Prüfe die konkrete Serverlizenz, die Verfügbarkeit im eigenen Tenant und den installierten SPL-Agent, bevor du den Pilot freigibst. Wenn Richtlinie oder Lizenz nicht verfügbar ist, nicht mit einer vermeintlich ähnlichen Endpoint- oder Sensor-Konfiguration ausweichen.

Wähle einen wenig kritischen, repräsentativen Linux-Server und eine eigene Pilotgruppe, etwa linux-rtd-pilot. Der Name ist frei wählbar; die Mitgliedschaft muss zu deinen tatsächlichen Servern passen. Halte die bisher wirksamen Richtlinien, Gruppenmitgliedschaft und – falls vorhanden – den Profilnamen samt Profile Version fest. So lässt sich die Änderung gezielt zurücknehmen, ohne die Schutzbasis anzutasten. Eine RTD-Regel kann legitime Betriebsabläufe melden; deshalb gehören Wartungs- und Automationsprozesse des Piloten in die Beobachtung.

Richtlinie und optionales Profil konfigurieren

Öffne in Sophos Fusion My Products > Server > Policies die für die Pilotserver wirksame Server Threat Protection-Richtlinie. Zeige mit Show filters > Operating System > Linux die passenden Optionen an. Prüfe unter Runtime Protection, dass Linux runtime detections eingeschaltet ist, und speichere die Richtlinie. Falls diese Richtlinie auch andere Server schützt, erstelle oder verwende eine auf die Pilotgruppe begrenzte Richtlinie statt unbemerkt die gesamte Flotte zu ändern. Der separate Schalter Enable scan for Server Protection for Linux agent steuert den Linux-Echtzeitscan auf Dateien; er ist nicht der RTD-Schalter und sollte für einen RTD-Test nicht ausgeschaltet werden.
Entscheide vor dem Erstellen der RTD-Richtlinie: Sophos Labs Default Detection nutzt SophosLabs-Standarderkennungen ohne eigenes Regel-Tuning. Wähle Linux Runtime Detection Profile nur, wenn du einzelne Regeln oder deren Allow-/Block-Listen bewusst anpassen und versionieren musst. Ein Profil baut ebenfalls auf SophosLabs-Inhalten auf; es ist kein Ersatz für die Richtlinie.
Nur für die Profilvariante: Öffne My Products > Global Settings > Protection and Remediation > Linux Profiles, klicke Create Profile, vergib etwa linux-rtd-pilot, prüfe Content Version, dokumentiere optional die Change Description und ändere nur verstandene Regeln. Save erzeugt zunächst Version 1. Eine spätere Änderung erzeugst du mit Create New Version; notiere, welche Profile Version für den Pilot freigegeben ist. Profilversion (deine Konfiguration) und Content Version (SophosLabs-Inhalt) sind verschiedene Dinge. Halte deshalb beides bei jeder Anpassung fest, statt die Profilversionsnummer als vollständigen Erkennungsstand zu lesen. SPL bezieht stets den neuesten SophosLabs-Standardinhalt; auch bestehende Profile werden mit neuen SophosLabs-Inhalten aktualisiert. Manuell gewählte Inhaltsupdates betreffen dagegen den separat verwalteten Sophos Linux Sensor – nicht die SPL-Serverrichtlinie. Prüfe eigene Regelanpassungen nach späteren Inhaltsupdates erneut.
Unter My Products > Server > Policies erstelle eine Linux Runtime Detection-Richtlinie. Öffne Settings, schalte Enable Linux Runtime Detection ein und wähle entweder Sophos Labs Default Detection oder Linux Runtime Detection Profile. Bei der Profilvariante wähle Profile und Version explizit. Schalte die Richtlinie ein, ordne sie nur der Pilotgruppe zu und klicke Save. Kontrolliere anschliessend die Zuweisung; das Speichern einer Richtlinie oder eines Profils allein beweist noch nicht, dass die Zielserver sie anwenden.

Reichweite prüfen: Ein Profil kann in mehreren RTD-Richtlinien verwendet werden. Vor einer neuen Version oder Regeländerung unter Linux Profiles die Anzeige Active aufklappen und die betroffenen Richtlinien prüfen. Eine Änderung an einer gemeinsam verwendeten Richtlinie kann mehrere Gruppen treffen. Keine breite Regelabschaltung oder globale Ausnahme als schnelle Antwort auf einen einzelnen Fehlalarm verwenden.

Wirkung und Erkennungen kontrollieren

Öffne My Products > Server > Servers > Server Groups, wähle linux-rtd-pilot und prüfe im Tab Policies, ob die eingeschaltete Threat-Protection- und die RTD-Richtlinie für die Gruppe gelten. Prüfe zusätzlich am betroffenen Server die tatsächlich zugewiesene Richtlinie und den aktuellen Agent-/Kontaktstatus. Bei Profilnutzung müssen Profile und Version der RTD-Richtlinie mit der freigegebenen Wahl übereinstimmen. Ein Eintrag unter Linux Profiles > Active zeigt die verwendenden Richtlinien, aber keinen erfolgreich ausgelösten Test auf dem Host.

Beobachte anschliessend im Threat Analysis Center > Detections die Erkennungen des Pilotservers und dokumentiere Zeitpunkt, Server, Regel, beobachteten Prozess und fachlichen Kontext einer Meldung. Die Ansicht benötigt hochgeladene Gerätedaten; wenn dort grundsätzlich nichts ankommt, prüfe auch die für den Server geltende Data-Lake-Datenübertragung. Eine passende RTD-Erkennung bestätigt, dass ein Ereignis gemeldet wurde, nicht, dass RTD es blockiert oder bereinigt hat. Keine Meldung bei normalem Betrieb ist weder ein Funktionsbeweis noch ein Fehlerbeweis. Löse zum Testen keine schädlichen Aktionen auf Produktionsservern aus.

Fehlen erwartete Daten, prüfe zuerst Lizenz/Tenant, SPL-Verbindung und die tatsächlich zugewiesenen beiden eingeschalteten Richtlinien. Bei einem Profil prüfe zusätzlich, ob eine passende Regel enthalten und Enabled ist. Unterschiedliche letzte Build-Ziffern zwischen Content Version in Fusion und rtd_content_version am Linux-Gerät bedeuten laut Sophos nicht zwingend einen veralteten Inhalt; nicht blind die Profilversion ändern. Bleibt ein Richtlinien-, Agent- oder Upload-Fehler unklar, übergib Zeitstempel und Richtlinienstand an Sophos Support statt einen nicht dokumentierten Testbefehl oder erzwungenen Agent-Neustart zu verwenden. Die Untersuchung einer verdächtigen Erkennung gehört zum eigenen Security-Team oder beauftragten MDR-Dienst; bei einem aktiven Vorfall greift der Incident-Response-Prozess.

Fehlalarme eingrenzen und sicher zurückgehen

Bei einer verdächtigen Meldung zuerst den Vorgang untersuchen: Ist der Prozess autorisiert, welcher Host und welche Regel sind betroffen, und gab es eine passende Wartung? Erst nach dieser Prüfung im Profil die konkrete Regel und ihre Allow/Block List betrachten. Eine eng begrenzte Anpassung ist besser als das pauschale Ausschalten der Regel; Umfang, Begründung und Version dokumentieren und erneut nur mit der Pilotgruppe prüfen. Das Ändern einer Allow-/Block-Liste kann die Erkennung reduzieren oder verändern. Wenn die Meldung nicht sicher als Fehlalarm einzuordnen ist, nicht freigeben, sondern durch das Security-Team oder den beauftragten MDR-Dienst weiter untersuchen lassen.

Für den Rückweg zunächst die Pilotzuweisung der RTD-Richtlinie oder deren profilbezogene Auswahl auf den dokumentierten vorherigen Stand zurücksetzen und die tatsächlich wirksame Richtlinie erneut prüfen. Falls eine neue Profilversion Probleme verursacht, die zuvor dokumentierte Profile Version in der Pilotrichtlinie wieder auswählen und speichern; die anderen Richtlinien, die dasselbe Profil nutzen, vorher prüfen. Das setzt nur die gespeicherte Profilkonfiguration bzw. Richtlinienzuweisung zurück: Bei SPL wird damit weder der inzwischen aktualisierte SophosLabs-Erkennungsinhalt zurückgerollt noch eine frühere Content Version fixiert. Prüfe Regelanpassungen erneut gegen den aktuellen Inhalt. Nur wenn der Pilot die zuvor deaktivierte Voraussetzung Linux runtime detections in einer eigens für ihn zugewiesenen Threat-Protection-Richtlinie aktiviert hat, kann dieser Schalter dort auf den vorherigen Zustand zurückgesetzt werden. Nicht den Linux-Echtzeitscan, die gesamte Server Threat Protection oder SPL als RTD-Rollback deaktivieren: Das würde einen anderen Schutzbereich entfernen. Danach Kontaktstatus, wirksame Richtlinien und weitere Erkennungen nochmals kontrollieren.