Sophos Fusion: Server Threat Protection sicher einrichten und prüfen

Nach der Installation eines Server-Agents ist die sichtbare Richtlinie noch kein Beweis für wirksamen Schutz. Falls Installation und Agent-Abnahme noch ausstehen: Für Windows Server gilt die Windows-Server-Installation und Abnahme; Linux-Server benötigen stattdessen den eigenen SPL-Installationsweg. Für eine sichere Baseline in Sophos Fusion (ehemals Sophos Central) zuerst den tatsächlichen Server und dessen Plattform prüfen, dann die empfohlenen Einstellungen in einer kleinen Pilotgruppe beibehalten und schliesslich am Policies-, Status- und Events-Tab des Servers kontrollieren, was angekommen ist. Windows- und Linux-Server teilen sich eine Policy-Oberfläche, aber nicht alle Schutzfunktionen.

Vor der Änderung: Plattform und Geltungsbereich festhalten

Notieren Sie Tenant, Servername, Betriebssystem, installierten Agent, vorhandene Lizenz beziehungsweise gebuchte Funktionen, Serverrolle und aktuelle Richtlinie. Vergleichen Sie je einen Windows- und einen Linux-Pilotserver mit demselben Produktionsprofil; Datenbankserver, Domain Controller und Linux-Containerhosts verdienen wegen unterschiedlicher Last und Dateizugriffe getrennte Tests. Die Beispiele Pilot-Windows-App und Pilot-Linux-App sind frei wählbare Servergruppennamen, keine von Sophos vorgegebenen Werte. Unter My Products > Server > Servers öffnen Sie den Tab Server Groups und wählen Add Server Group. Legen Sie je eine Gruppe an und weisen Sie einzelne Server zu. Ein Server kann nur in einer Gruppe sein: Die Zuweisung zu einer Pilotgruppe entfernt ihn aus seiner bisherigen Gruppe und kann auch andere wirksame Richtlinien verändern. Vorher je Server die alte Gruppe, die angewendeten Policies und deren Reihenfolge, Zuweisungen und Einstellungen als Rückbau-Basis dokumentieren. Nehmen Sie zuerst nur wenige repräsentative Server auf, nicht die gesamte Produktion.

Die Base Policy schützt Server, wenn keine höher priorisierte passende Richtlinie greift. Zusätzliche Policies eignen sich für gezielte Abweichungen. Sophos Fusion wendet pro Policy-Typ die erste passende aktive Policy von oben an; Einstellungen mehrerer Threat-Protection-Policies werden nicht kombiniert. Das gemeinsame Auswahlmodell erklärt der Richtlinien-Grundlagenartikel; für diesen Pilot sind jedoch Server-Policies und Servergruppen massgeblich, nicht Endpoint-Computergruppen. Platzieren Sie die spezifische Pilot-Policy über einer allgemeinen Richtlinie und belassen Sie den Rest in der empfohlenen Baseline. Änderungen an einer gemeinsam genutzten Policy treffen alle ihr zugewiesenen Server – prüfen Sie die Zuweisung vor Save.

Server Threat Protection im Pilot konfigurieren

Öffnen Sie My Products > Server > Policies und wählen Sie Add Policy. Falls eine Auswahl erscheint, wählen Sie Threat Protection; für eine vorhandene Richtlinie öffnen Sie erst den Policy-Typ und dann den Namen. Legen Sie die neue Policy unter Assigned to für die kleine Pilotgruppe an und prüfen Sie Excluded from, falls angezeigt. Ändern Sie nicht unbemerkt die Base Policy für alle Server.
Öffnen Sie Settings und lassen Sie die Policy aktiviert. Wählen Sie Show filters > Operating System zuerst Windows, klicken Sie Apply, wiederholen Sie dies für Linux und klicken Sie erneut Apply. Der Filter zeigt verfügbare Einstellungen für die jeweilige Plattform; er schaltet keine Funktion am Agent frei. Recommended und Enabled/Disabled helfen, Abweichungen sichtbar zu machen.
Belassen Sie Live Protection, Deep Learning und Real-time Scanning - Local Files and Network Shares nach Möglichkeit auf den empfohlenen Einstellungen. Unter Real-time Scanning - Local Files and Network Shares steuert Scan die Echtzeitprüfung lokaler und über das Netzwerk angesprochener Dateien; Local beschränkt sie auf Dateien des Geräts. Ein Wechsel zu Local braucht einen begründeten Anwendungsfall und einen Test der betroffenen Freigaben.
Linux-On-Access-Schutz ist standardmässig ausgeschaltet. Für einen Linux-Pilot mit Schutz beim Dateizugriff muss das SPL-Produkt antivirus beziehungsweise dessen AV-Plugin installiert sein. In der wirksamen Server-Threat-Protection-Policy müssen unter Real-time Scanning - Local Files and Network Shares sowohl Scan als auch Enable scan for Server Protection for Linux Agent aktiviert sein; die zweite Option ist ab Werk aus. Prüfen Sie die installierte AV-Komponente am Pilotserver wie im verlinkten SPL-Installationsartikel beschrieben. Ohne Komponente oder eine der beiden aktivierten Optionen ist der Pilot nicht als on-access-geschützt abzunehmen; dokumentieren Sie die Lücke und stoppen Sie die Ausweitung. Ein geplanter Scan ersetzt den Echtzeitscan nicht: Er prüft zu festen Zeiten, nicht beim Dateizugriff. Enable scheduled scan ist für beide Plattformen verfügbar; wählen Sie bei Bedarf ein lastarmes Zeitfenster. Die Uhrzeit richtet sich nach der lokalen Zeit des Geräts. Auf Linux verwendet der geplante Scan Live Protection unabhängig von der entsprechenden Policy-Einstellung.
Lassen Sie Enable event journals nach Möglichkeit eingeschaltet: Ohne diese Aufzeichnungen fehlen Daten für nachgelagerte Untersuchungen während des ausgeschalteten Zeitraums; auch Threat Graphs und – sofern eingesetzt – Server File Integrity Monitoring funktionieren dann nicht. Konfigurieren Sie hier keine globalen Journalgrössen. Speichern Sie die Änderung und prüfen Sie die wirksame Policy am Gerät, bevor Sie weitere Server zuweisen.

Nicht gleichsetzen: Internet-Echtzeitscan, HTTPS-Entschlüsselung, CryptoGuard-/Exploit-Schutz, AMSI, Adaptive Attack Protection und Security Heartbeat sind in dieser Policy als Windows-Funktionen dokumentiert. Daraus folgt keine entsprechende Linux-Wirkung. Linux runtime detections sind eine separate Linux-Funktion mit geeigneter Lizenz; aus der sichtbaren Option allein lässt sich weder Berechtigung noch aktive Laufzeiterkennung ableiten. Prüfen Sie die konkrete Lizenz und den Agent-/Tenant-Status, bevor Sie diese Funktion einplanen. Die Linux-Optionen zum Echtzeitscan und zum Beenden damit verbundener schädlicher Prozesse sind ebenfalls nicht mit den Windows-Laufzeitschutzmodulen identisch.

Ausnahmen nur für einen belegten Konflikt

Eine Scan-Ausnahme reduziert Schutz, auch wenn andere Prüfungen für das ausgenommene Objekt weiterhin greifen können. Bei einer Fehl-Erkennung suchen Sie im Events-Tab nach Zeitstempel, Erkennung und betroffenem Pfad; gleichen Sie das mit Anwendungsversion, Herstellerhinweis und reproduzierbarem Fehler ab. Eine Datenbankanwendung kann aber auch ohne Erkennungs-Event durch häufige Dateizugriffe messbar unter Scans leiden: Vergleichen Sie reproduzierbar Laufzeit, Last und betroffene Zugriffe vor und nach einem zeitlich begrenzten Test in der Pilotgruppe. Ein bloss langsamer Dienst ohne nachvollziehbare Scan-Zuordnung rechtfertigt keinen Ausschluss.

Unter Settings > Exclusions > Add Exclusion wählen Sie Exclusion Type und tragen nur das konkret betroffene Objekt ein. Bei File or folder beschränken Sie Active for auf Real-time Scanning oder Scheduled Scanning, wenn nicht beide nachweislich betroffen sind. Bei belegter Windows-Datenbanklast prüfen Sie zuerst Process (Windows) mit dem vollständigen Anwendungspfad nach Herstellerangaben: Nur von diesem Prozess genutzte Dateien werden bei dessen Zugriff ausgenommen, statt einen ganzen Dateibaum für andere Prozesse freizugeben. Für Linux unterstützt File or folder (Linux) Datei- und Ordnerpfade sowie ? und *; ein vollständig benannter Pfad wie /mnt/hgfs/excluded ist ein Syntaxbeispiel aus der Sophos-Dokumentation, keine allgemeine Empfehlung, diesen Ordner auszunehmen. Ersetzen Sie ihn ausschliesslich durch einen verifizierten Pfad auf dem betroffenen Server. Übernehmen Sie Windows-Prozess- oder Exploit-Ausnahmen nicht als Linux-Äquivalent. Nutzen Sie Detected Exploits- oder Hashing-Ausnahmen nicht als pauschalen Scan-Workaround; bei Hashing-Ausnahmen zuerst Sophos Support einbeziehen. Eine Policy-Ausnahme gilt nur für die Server, auf welche diese Policy angewendet wird; eine Global Exclusion hat dagegen tenantweiten Geltungsbereich. Legen Sie bei der Event-Prüfung nicht über Don’t detect this again eine globale Erkennungsausnahme an. Die gemeinsame Anleitung zu Endpoint- und Server-Ausnahmen erklärt Typen, Geltungsbereich und Rückbau; die Auswahl hier bleibt eine Server-Policy-Entscheidung. Dokumentieren Sie Erkennungs-Event oder reproduzierbare Leistungsdaten, Herstellerhinweis, Grund, Verantwortliche, betroffene Server, Test und geplantes Ablaufdatum. Prüfen Sie nach dem Speichern den betroffenen Arbeitsablauf und entfernen Sie die Ausnahme wieder, sobald die Ursache behoben ist und der Rückbau geprüft wurde.

Wirkung am konkreten Server nachweisen

Öffnen Sie My Products > Server > Servers, wählen Sie den Pilotserver und kontrollieren Sie:

Policies: Steht unter Threat Protection wirklich die beabsichtigte Policy? Wenn nicht, Zuweisung, Aktivierung und Reihenfolge prüfen. Ein Klick auf die Policy öffnet deren Einstellungen; Änderungen dort wirken auch auf andere zugewiesene Server.
Status: Bei neueren Windows-Servern zeigen Health status und Bewertungen zu Communication, Operations, Services, System, Threat und Update mögliche Probleme. Bei Linux und älteren Windows-Servern zeigt Security Health unter anderem den letzten Kontakt zu Sophos Fusion und laufende Sophos-Dienste; die Anzeige ist nicht dieselbe Windows-Detailbewertung. Grün allein beweist keinen geprüften Angriffsschutz.
Events: Kontrollieren Sie für das relevante Zeitfenster Meldungen, erfolgreiche Updates und gegebenenfalls eine bereits vorhandene Erkennung über Details. Die Abwesenheit eines Malware-Events ist kein Funktionstest. Lösen Sie auf einem Produktivserver nicht eigens Malware- oder Exploit-Aktionen aus. Der angezeigte Zeitpunkt Last active kann hinter einem Event zurückliegen, weil er ungefähr stündlich aktualisiert wird.

Für Linux zusätzlich lokal das installierte antivirus-Produkt/AV-Plugin und die übernommene Policy prüfen (Prüfpfade im SPL-Installationsartikel). Policies, Status, Events und eine grüne Health-Anzeige belegen allein weder die aktive On-Access-Prüfung noch deren Erkennungswirkung. Nur auf einem freigegebenen Nicht-Produktionssystem kann ein kontrollierter Funktionstest mit der harmlosen EICAR-Testdatei nach Sophos-Anleitung die Reaktion beim Dateizugriff, den AV-Log-Eintrag und den Alert in Fusion prüfen; Testdatei entfernen und den Test-Alert nach lokalem Verfahren bearbeiten. Ohne solchen Test bleibt die Erkennungswirkung unbestätigt; keine Malware-Tests in Produktion.

Zusätzlich zeigt Account Health Check Abweichungen der Server-Threat-Protection-Policies von Sophos’ Empfehlungen. Öffnen Sie bei einer Warnung die genannte Policy, prüfen Sie die rot markierten Einstellungen und korrigieren Sie sie gezielt. Fix automatically setzt alle Optionen betroffener Policies auf empfohlene Einstellungen und kann absichtlich gewählte Pilotabweichungen überschreiben; vor der Bestätigung betroffene Server und den Änderungsumfang prüfen. Prüfen Sie separat die Warnung zu riskanten Policy exclusions: Der Check erfasst nur besonders unsichere Ausnahmen, ein grüner Status bescheinigt nicht die Unbedenklichkeit aller Ausnahmen. Auch dort keine automatische Korrektur ohne Prüfung des gesamten betroffenen Policy-Scopes; sie kann Ausnahmen aus allen betroffenen Policies entfernen. Das Audit-Log dokumentiert automatische Änderungen. Nach jeder Korrektur erneut Policy, Status und Events am Pilotserver prüfen.

Wenn das Ergebnis nicht zur Konfiguration passt

Falsche oder keine erwartete Policy: Tenant, Servergruppe, aktivierte Policy und Listenpriorität prüfen. Den richtigen Namen im Policies-Tab des Servers ablesen; nicht aus der Policy-Liste allein auf die Wirkung schliessen.
Linux-Echtzeitscan unklar: In der wirksamen Linux-gefilterten Policy unter Real-time Scanning - Local Files and Network Shares Scan und Enable scan for Server Protection for Linux Agent sowie lokal SPL-AV-Plugin/Produkt antivirus prüfen. Fehlt etwas oder bleibt die Wirkung unklar, keinen On-Access-Schutz behaupten, Pilot nicht ausweiten und Agent-/Lizenzdetails und Diagnose an Sophos Support übergeben.
Warnung oder rote Health-Bewertung: Bei Windows die konkrete Bewertung für Communication, Services oder Update öffnen; bei Linux letzte Fusion-Aktivität, laufende Dienste und Alerts vergleichen. Erst Kommunikations- oder Updateprobleme beheben, dann erneut den Empfang der Policy kontrollieren.
Anwendung reagiert langsam oder Datei wird blockiert: Bei Blockade zeitgleiches Event und Pfad prüfen; bei Leistungseinbruch ohne Event reproduzierbare Last- und Zugriffsvergleiche samt Herstellerhinweis sichern. Keine ganze Verzeichnisstruktur oder tenantweite Ausnahme auf Verdacht setzen. Ein enger Pilot-Ausschluss ist nur mit belegter Ursache und Rückweg vertretbar. Bleibt die Abweichung bestehen, Befund, Policy-Zuweisung und Agentstatus dokumentieren und eskalieren.

Pilot stoppen und zurückbauen

Stoppen Sie die Erweiterung bei fehlendem Linux-On-Access-Schutz, falscher wirksamer Policy, anhaltend ungesundem Agent, ungeklärten Blockaden oder messbarer Störung eines geschäftskritischen Workloads. Erfassen Sie betroffene Server und die Abweichung; stimmen Sie den Rückbau im Änderungsfenster mit den Workload-Verantwortlichen ab. Setzen Sie jeden verschobenen Server in seine vorherige Gruppe zurück beziehungsweise entfernen Sie ihn aus der Pilotgruppe, wenn er zuvor keiner Gruppe angehörte. Falls Pilot-Änderungen eine bestehende Policy, deren Priorität oder Zuweisung verändert haben, stellen Sie zusätzlich die dokumentierte Reihenfolge, Zuweisung und Einstellungen wieder her; die Rückkehr in die alte Gruppe allein repariert eine bearbeitete Policy nicht. Ziehen Sie Pilot-Ausnahmen nach Prüfung des betroffenen Workloads gezielt zurück: Erst sicherstellen, dass der frühere Block oder Leistungseinbruch dadurch nicht wiederkehrt; nötigenfalls Ursache klären und bis dahin den eng begrenzten, befristeten Restbedarf dokumentieren statt unkontrolliert zu entfernen. Kontrollieren Sie danach an jedem betroffenen Server Gruppenmitgliedschaft, wirksame Policies, Status/Health, Events und den zuvor gestörten Arbeitsablauf. Ohne erfolgreichen Nachweis bleibt der Rollout gestoppt und der Vorfall wird eskaliert.