Sophos Firewall täglich prüfen: Admin-Checkliste für den Betrieb

Eine Sophos Firewall kann technisch erreichbar sein und trotzdem erste Warnzeichen zeigen: Eine WAN-Verbindung flappt, die Diskbelegung wächst, ein Dienst meldet einen Fehler oder fehlgeschlagene Admin-Logins häufen sich. Ein kurzer, wiederholbarer Betriebscheck macht solche Veränderungen sichtbar, bevor daraus ein längerer Ausfall oder ein Security Incident entsteht.

Dieser Ablauf behandelt den aktuellen Betrieb. Der Sophos Firewall Health Check beantwortet dagegen, ob ausgewählte Konfigurationen den Sophos- und CIS-Empfehlungen entsprechen. Beide Prüfungen ergänzen sich, ersetzen einander aber nicht.

Der Zehn-Minuten-Check

Für den täglichen Überblick genügt ein fester Ablauf:

1. Im Control Center Modell, Firmwareversion und Build notieren, neue Messages öffnen und die Statussymbole für Services, WAN, Interfaces und VPN anklicken.
2. Unter Diagnostics > System graphs CPU, Memory, Load Average, Disk und die wichtigen Interfaces mit der üblichen Baseline vergleichen.
3. Security-Dashboards und die genutzten Reports für den letzten vollständig verfügbaren Zeitraum auf neue IPS-, Web-, Application-, Zero-day- oder Active-Threat-Response-Ereignisse prüfen.
4. Oben rechts den Log Viewer öffnen, Modul und Zeitraum wählen und fehlgeschlagene administrative Anmeldungen, ungewöhnliche Quellen und die zugehörigen Dienste kontrollieren.
5. Bei HA den verarbeitenden Node und bei zentralem Reporting die erwartete Datenquelle berücksichtigen.
6. Jede relevante Abweichung mit Zeitpunkt, Firmware, Node, Quelle, betroffenem Dienst und nächstem Schritt dokumentieren.
7. Nicht aus einem einzelnen Peak heraus Dienste neu starten, Logs löschen oder Regeln verbreitern. Zuerst Trend, Logs und reale Funktion korrelieren.

Dieser Kurzcheck soll nicht jeden Morgen eine Konfigurationsänderung auslösen. Sein Wert liegt darin, Veränderungen früh zu erkennen und sauber zu entscheiden, ob Beobachtung, Diagnose oder Eskalation nötig ist.

Vier Ansichten, vier unterschiedliche Aussagen

Die wichtigsten Ansichten zeigen nicht dasselbe:

• Control Center: aktueller Überblick über System, Services, WAN, Interfaces, VPN, Uptime und handlungsrelevante Messages.
• System graphs: zeitlicher Verlauf von CPU, Memory, Load Average, Disk, WAN-Transfer und Interface-Zählern.
• Reports: verdichtete Auswertung eines abgeschlossenen Zeitraums. Einige Kacheln und Reportdaten werden nicht sekundengenau aktualisiert.
• Log Viewer: einzelne Ereignisse mit Zeit, Modul, Aktion, Quell- und Zielinformationen sowie je nach Logtyp Rule ID oder weiteren Details.

Eine rote Kachel ist ein Signal, noch keine vollständige Diagnose. Ebenso beweist ein grüner aktueller Status nicht, dass während der Nacht kein kurzer Fehler auftrat. Erst die Kombination aus aktuellem Zustand, Verlauf, Report und Einzelereignis ergibt ein belastbares Bild.

Systemzustand und Verfügbarkeit prüfen

Control Center zuerst lesen

Im Control Center beginnt die Prüfung bei neuen Messages. Sophos zeigt dort unter anderem Registrierungs-, Lizenz-, Reporting-, WAN- oder Upgrade-Probleme an. Einige Meldungen verschwinden nach der Behebung automatisch und lassen sich nicht einfach manuell löschen. Deshalb braucht jede relevante Message einen Owner und einen nachvollziehbaren nächsten Schritt.

Eine Registration-Message erscheint, wenn die Sophos Firewall nicht registriert ist. Eine Licenses-Message erscheint, wenn Firewall-Module keine Lizenz haben.

Einige Widget-Zähler im Control Center werden nach einem Firewall-Neustart zurückgesetzt. Ein niedriger Zählerstand nach dem Neustart beweist deshalb nicht, dass vorher keine Ereignisse aufgetreten sind. Zur Einordnung werden Uptime und dauerhaft gesicherte Logs für den betreffenden Zeitraum korreliert, etwa CSV-Exporte oder zentrale Logs im Rahmen ihrer Aufbewahrung. Die WebAdmin-Konsole zeigt keine Temperaturinformationen an.

Messages zeigt auch die seit der Erstellung einer Meldung vergangene Zeit. Je nach Typ oder Schweregrad verwendet dieses Widget die Indikatoren Alert, Warning und Available firmware versions. Beim Erfassen einer Meldung werden Indikator, vergangene Zeit und Meldungstext zusammen festgehalten; die unten beschriebenen Zählungen für Services und WAN/VPN gelten nicht für Messages.

Die Farbe wird immer zusammen mit dem Detail gelesen: Bei Services bedeutet Warning, dass mindestens ein Dienst gestoppt ist, Alert dagegen, dass mindestens ein Dienst nicht starten konnte. Bei WAN und VPN bedeutet Warning, dass bis zur Hälfte, und Alert, dass mehr als die Hälfte der konfigurierten Verbindungen down ist. Diese Zählung kennt die geschäftliche Bedeutung nicht. Ein einzelner ausgefallener Haupttunnel kann daher dringender sein als mehrere absichtlich inaktive Verbindungen. Ein Klick auf das jeweilige Symbol zeigt die betroffenen Einträge.

Danach werden die tatsächlich genutzten Services, WAN-Verbindungen, Interfaces und VPNs mit dem Sollzustand verglichen. Ein rotes Interface ist nicht automatisch ein Ausfall: Ein ungenutzter Port ohne IP-Adresse oder ein physisches Parent-Interface eines VLANs kann erwartungsgemäss rot erscheinen. Relevant ist die Abweichung vom dokumentierten Design.

Wenn LAGs eingesetzt werden, unter SFOS 23 das Symbol Interfaces öffnen und auch die einzelnen LAG-Mitglieder auf abgezogene Kabel prüfen. Die SFOS-23-Hilfe nennt diese Detailanzeige ausdrücklich; die zugeordnete SFOS-22-Hilfe tut dies nicht. Als betriebliche Einordnung gilt: Ein weiterhin erreichbares Aggregat beweist nicht, dass alle Mitglieder und damit die vorgesehene Redundanz und Kapazität verfügbar sind. Den betroffenen Member und die Abweichung vom Sollzustand im Ticket festhalten.

Bei eingesetzten RED-Tunneln und Wireless APs die Connection-status-Widgets mit dem Sollzustand vergleichen: RED zählt aufgebaute gegenüber konfigurierten Tunneln, Wireless APs aktive gegenüber konfigurierten Access Points. Ausstehende APs erscheinen zusätzlich in roten Klammern und sind nicht als aktive APs zu zählen. RED öffnet die Tunnelliste, Wireless APs führt zu Wireless > Access points. Connected remote users zählt über SSL VPN verbundene Benutzer und öffnet Current activities > Remote users; Live users zählt dagegen alle aktuellen Benutzer und öffnet Current activities > Live users. Diese Benutzerzahlen ersetzen keine RED- oder AP-Verfügbarkeitsprüfung.

Wenn DNS Protection vorgesehen ist, dessen Konfigurationsstatus im System-Widget prüfen. Die SFOS-22-Hilfe nennt fünf Zustände: Not subscribed bedeutet fehlende Lizenz; erforderlich ist Xstream Protection. Not configured verweist auf das Eintragen der DNS-Protection-IP-Adressen. Bei Unrecognized source die öffentliche Firewall-IP und ihre Location-Zuordnung in Sophos Fusion prüfen. Active meldet aktiven DNS Protection; ein Info-Symbol weist auf eine fehlende Fusion-Registrierung hin. Bei IP address conflict die in der Location eingetragene IP prüfen und einen nicht lösbaren Konflikt an Sophos Support eskalieren.

Die SFOS-23-Hilfe nennt Not subscribed, Not configured und Active und verweist bei fehlender Konfiguration auf Configure DNS servers; beim Active-Info-Symbol nennt sie die Registrierung in Sophos Central. Daraus folgt nicht, dass die beiden zusätzlich in SFOS 22 dokumentierten Zustände zur Laufzeit entfernt wurden. Den zur Version passenden Einrichtungs- und Troubleshooting-Pfad beschreibt DNS Protection mit Sophos Firewall einrichten: den Traditional-DNS-/Location-Pfad von SFOS 22 nicht unverändert auf den integrierten SFOS-23-Pfad übertragen.

Für DNS-Protection-Ereignisse im Log Viewer das Modul System wählen und nach DNS Protection filtern. Version, Widget-Status und relevante Logzeilen im Ticket sichern. Dieser Konfigurations- und Ereignischeck ersetzt weder die Funktionsprüfung der Namensauflösung und Filterwirkung noch die DNS-Protection-Reports; allgemeine Security-Reports allein belegen keine betriebsbereite DNS Protection.

Das Widget Messages wird als Aufgabenliste und nicht als allgemeiner Event-Feed behandelt. Fordert es zur Erstellung des Secure Storage Master Key auf, wird dieser angelegt, damit sensible Werte wie Passwörter den zusätzlichen Schutz erhalten. Eine WAN-Access-Message bedeutet, dass WebAdmin (HTTPS) und CLI (SSH) aus der WAN-Zone erreichbar sind: Ist externer Admin-Zugriff erforderlich, wird statt eines breiten WAN-Zugriffs ein VPN oder eine eng auf bestimmte Management-Hosts beziehungsweise -Netze begrenzte Local Service ACL Exception verwendet. Bei einer Message zur Reports-Disk muss die Belegung unter den unteren Schwellwert sinken; nur den oberen Schwellwert zu unterschreiten reicht nicht. An Anforderungen gebundene Messages verschwinden nach deren Erfüllung und lassen sich nicht manuell löschen.

Eine Upgrade-Fehlermeldung bei Software-, virtuellen und Cloud-Firewalls erfordert zuerst die Prüfung, ob die Firewall bereits in Sophos Central beansprucht wurde (Claim). Dieses Claiming ist eine Voraussetzung vor dem Upgrade, nicht erst eine Massnahme nach dessen Scheitern. Die SFOS-22-Dokumentation nennt das Portal «Sophos Fusion (previously Sophos Central)», die SFOS-23-Dokumentation «Sophos Central»; die Voraussetzung bleibt gleich. Claim-Status und Fehlermeldung werden im Ticket festgehalten, bevor ein weiterer Upgradeversuch nach dem Firmware-Runbook geplant wird.

Active threat response wird nach Feed und Aktion gelesen. MDR und Sophos X-Ops zeigen die Anzahl blockierter Bedrohungen, NDR Essentials dagegen überwachte Bedrohungen; Drittanbieter-Feeds zeigen zusätzlich den Synchronisierungsstatus. Configure führt zur Einrichtung des Schutzes, Reports zum zugehörigen Report und More details erweitert das Widget. Auf Modellen ohne lokales Reporting fehlt die Reports-Aktion. Eine überwachte Bedrohung ist nicht gleichbedeutend mit einer blockierten, und ein Synchronisierungsfehler muss getrennt von der Trefferzahl bewertet werden.

Das Widget Reports ist eine Verknüpfung zu bis zu fünf kritischen Reports, die von den abonnierten Modulen abhängen, und keine vollständige Live-Eventliste. Die Zuordnung lautet:

• High-risk applications — Web Protection
• Objectionable websites — Web Protection
• Web users — Web Protection
• Intrusion attacks — Network Protection
• Web server protection — Web Server Protection
• Email usage — Email Protection
• Email protection — Email Protection
• Traffic dashboard — Web Protection oder Network Protection
• Security dashboard — Web Protection oder Network Protection

High-risk applications, Objectionable websites, Intrusion attacks, Web server protection und Email protection beziehen sich auf gestern; Web users ordnet die zehn Benutzer mit den meisten gestern übertragenen Web-Bytes. Email usage zeigt übertragene E-Mail-Bytes, Traffic dashboard Traffic-Kategorien und Security dashboard abgewiesene Netzwerkaktivitäten. Eine fehlende Kachel kann daher auf ein fehlendes Abonnement zurückzuführen sein und bedeutet nicht zwangsläufig, dass keine Aktivität vorliegt. Der Reportname öffnet den Inhalt, das Downloadsymbol sichert den Report. Für die getrennten Zeitfenster und Drill-downs der Endpoint-, Benutzer-, Zero-Day-, TLS- und Session-Signale führt User & Device Insights richtig auswerten weiter.

Traffic insight fasst den in den letzten 24 Stunden verarbeiteten Traffic zusammen. Web activity zeigt Verlauf, Durchschnitt und Maximum der übertragenen Bytes; Cloud applications zeigt erkannte Apps sowie Bytes in und out und beim Darüberfahren die Zustände New, Sanctioned, Unsanctioned und Tolerated. Die weiteren Graphen ordnen die fünf wichtigsten erlaubten Application- und Web-Kategorien nach Bytes, blockierte Application-Kategorien nach Hits sowie Hosts, denen der Netzwerkzugriff aus Health-Gründen verweigert wurde. Ein Klick auf einen Cloud-Graphen oder Kategorienbalken öffnet die entsprechende Cloud-Application-Seite oder den gefilterten Report; dieser Drill-down gehört vor die Einstufung eines Peaks oder Top-five-Eintrags als Incident.

Zu einer täglichen Prüfung gehören mindestens:

• unerwartet gestoppte oder degradierte Services;
• WAN-Links, die down sind oder wiederholt den Status wechseln;
• produktive Interfaces mit neuen Errors, Drops oder Collisions;
• wichtige VPN-Verbindungen, die entgegen dem Betriebsplan getrennt sind;
• ein unerwarteter Neustart oder eine ungewöhnlich kurze Uptime;
• neue Messages, die noch keinen Owner oder kein Ticket besitzen.

System graphs gegen eine Baseline lesen

Unter Diagnostics > System graphs werden nicht nur einzelne Spitzen, sondern Muster gesucht. CPU, Memory und Load Average werden gemeinsam mit der Core-Anzahl, dem Traffic und dem betreffenden Zeitraum bewertet. Ein kurzer Peak während Backup, Reporting oder Pattern-Update hat eine andere Bedeutung als dauerhaft hohe Last bei normalem Traffic.

Bei Disk Usage zählt vor allem der Trend. Eine einmalige hohe Belegung und stetiges Wachstum sind unterschiedliche Fehlerbilder. Bei Interfaces helfen Traffic, Errors, Drops und Collisions dabei, eine Firewall-Last von einem Link-, Duplex-, Kabel- oder Switchproblem abzugrenzen.

Für einen vergleichbaren Nachweis werden Graph type und Zeitraum festgehalten und der gleiche Zeitraum wie im Ticket verwendet. Interface graphs zeigen für VLANs nur dann einen eigenen Graphen, wenn das VLAN in der WAN-Zone liegt; VLANs anderer Zonen fliessen in den Graphen ihres physischen Parent-Interfaces ein. Ein unauffälliger LAN-VLAN-Graph kann deshalb nicht erwartet werden, wenn SFOS ihn gar nicht separat führt.

Die vertiefte Einordnung von Load Average, Offloading, TLS Inspection und System graphs steht unter Sophos Firewall Leistungsdaten richtig interpretieren. Für Speichergrenzen und On-box-Reporting passt Sophos Firewall Speicher und Reports prüfen.

⚠️ Ein einzelner hoher Messwert ist noch kein Grund für einen Service-Neustart. Zeitpunkt, Dauer, wiederkehrendes Muster, betroffener Traffic und Logs müssen zuerst zusammenpassen. Vor einem Neustart werden relevante Logs und bei einem Incident ein CTR gesichert.

Security-Ereignisse und Admin-Logins prüfen

Reports nach Veränderung lesen

Der tägliche Security-Review konzentriert sich auf neue oder deutlich veränderte Muster. Je nach aktivierten Funktionen sind besonders diese Bereiche relevant:

• Reports > Dashboards > Security dashboard für den verdichteten Überblick;
• Reports > Network & threats > Intrusion attacks für IPS-Treffer;
• Reports > Network & threats > Active threat response für blockierte IoCs;
• Reports > Applications & web für riskante, unerwünschte oder blockierte Web- und Application-Nutzung;
• Zero-day-, Security-Heartbeat- oder Wireless-Reports, wenn diese Funktionen produktiv genutzt werden.

Im gewählten Report wird zuerst der passende Datumsbereich gesetzt und dann Generate angeklickt. Mit Filter lässt sich die relevante Quelle, Aktion oder Regel eingrenzen; die verfügbaren Downloadformate sichern den angezeigten Stand als Ticketbeleg. Zeitraum und Zeitzone gehören zum Export, damit ein späterer Vergleich nicht zwei unterschiedliche Fenster gegenüberstellt.

Nicht jeder Treffer ist ein Incident. Entscheidend sind Quelle, Ziel, Benutzer, Regel, Aktion, Häufigkeit und zeitlicher Zusammenhang. Ein einzelner Zugriff aus einem Land rechtfertigt keine pauschale Ländersperre. Wiederholte Angriffe auf einen exponierten Dienst oder ein neuer erlaubter High-Risk-Traffic verdienen dagegen eine konkrete Untersuchung.

Für die sichere Einordnung von Quellen und Ländern hilft Schädliche IP-Adressen und Länder blockieren. Wenn ein Paket verworfen wurde, führt Sophos Firewall verworfene Pakete analysieren von Log Viewer und Rule ID bis zur eigentlichen Drop-Ursache.

Fehlgeschlagene Admin-Logins bewerten

Fehlgeschlagene administrative Logins werden nach Zeit, Quell-IP, Zielservice, Benutzername und Wiederholung geprüft. Ein Tippfehler aus dem Managementnetz ist anders zu behandeln als verteilte Versuche aus dem Internet oder wiederholte Anmeldungen auf einem deaktivierten Konto.

Der Log Viewer wird oben rechts auf einer beliebigen WebAdmin-Seite geöffnet und erscheint in einem eigenen Vollbildfenster. Dort das passende Modul wählen, über Timer filter den Zeitraum setzen und mit Add filter Feld, Bedingung und Wert eingrenzen. Die Freitextsuche eignet sich für IP-Adresse, Benutzername, Port oder Regel. Vor weiteren Änderungen die gefilterten Einträge über Export als CSV sichern; Reset entfernt anschliessend alle Filter. Ein fehlender Session-Eintrag beweist nicht immer fehlenden Traffic, weil Firewall-Regeln Sessions normalerweise erst beim empfangenen Connection-Destroy-Ereignis protokollieren.

Bei auffälligen Versuchen werden zuerst Exposition und Identität geprüft:

1. Ist WebAdmin, SSH, User Portal oder VPN Portal aus der betroffenen Zone überhaupt vorgesehen?
2. Stammt die Quelle aus einem freigegebenen Managementnetz oder einer gezielten Local Service ACL Exception?
3. Ist MFA für den betroffenen administrativen Zugang aktiv?
4. Greifen CAPTCHA, Session Timeout und Block login wie geplant?
5. Gibt es zeitgleiche Konfigurationsänderungen oder erfolgreiche Logins desselben Kontos?

Die Netzfreigabe wird unter Sophos Firewall Device Access und Local Service ACL geprüft. Für Konten, Profile und Offboarding passt Lokale Administratoren und Device-Access-Profile, für den zweiten Faktor MFA für Sophos Firewall aktivieren.

⚠️ Block login kann nach Fehlversuchen die Quell-IP für mehrere Dienste sperren. Werte nicht während eines Incidents aggressiv verschärfen, solange kein getesteter alternativer Admin- und Recoveryweg besteht.

HA, Reporting und Modellgrenzen einordnen

In einem HA-Cluster speichert jeder Node nur die Logs und Reports für den Traffic, den er selbst verarbeitet hat. Bei einem Ereignis wird deshalb der zum Zeitpunkt aktive oder verarbeitende Node ermittelt. Ein leerer lokaler Report auf einem Node beweist nicht, dass im Cluster kein Ereignis stattgefunden hat.

Central Firewall Reporting in Sophos Fusion (ehemals Sophos Central) kann eine konsolidierte Sicht und längere Aufbewahrung bieten. Die lokale und zentrale Ansicht werden aber nicht als identische Echtzeitquelle behandelt. Central Firewall Reporting aktivieren und betreiben erklärt Logauswahl, Ankunft und Aufbewahrung.

Zusätzliche Grenzen:

• Control-Center-Reports werden periodisch aktualisiert und sind keine sekundengenaue Ereignisanzeige.
• Nach einem Upgrade von SFOS 20.0 oder älter auf SFOS 21.0 oder neuer kann die Reportkachel bis zum nächsten 24-Stunden-Update null oder weniger Daten zeigen, weil Sophos die Reports vor und nach dem Upgrade in getrennten Datenbanken speichert.
• XGS 87/87w und XGS 88/88w unterstützen keine On-appliance Reports. Dort werden zentrale Logs, SIEM und Monitoring entsprechend wichtiger.
• Fehlende Daten können an Logging, Reportzeitraum, Lizenz, Retention, Disk-Watermark oder dem falschen HA-Node liegen. Sie beweisen nicht automatisch, dass kein Traffic vorhanden war.

Firmwarestand und bekannte Fehler abgleichen

Wenn Beobachtung und Sollzustand nicht zusammenpassen, folgt der Abgleich dem Avanet-Runbook für Firmware-Entscheide. Dabei zählen der exakt installierte Build und das konkrete Symptom, nicht nur die Hauptversion. Issue-ID, betroffene und korrigierte Builds sowie ein allfälliger Workaround werden im Ticket dokumentiert und vor einem Eingriff mit Control-Center-Details, System graphs, Logs und einem Funktionstest korreliert. Beispiele für den täglichen Check:

• NC-181971: Unter SFOS 22.0 GA und neuer kann der IPS-Service in seltenen Fällen den Status Dead erreichen und nicht wieder starten. Sophos nennt keinen öffentlichen Selbsthilfe-Workaround, sondern die Eskalation an den Support.
• NC-181748: Unter SFOS 22.0 GA Build 411 werden für durch Web Policies blockierte Kategorien keine Web Instant Alert-E-Mails ausgelöst. Ein fehlender Alert darf auf diesem Build deshalb nicht als Beweis für fehlende Blocks dienen.
• NC-180066, NC-180110, NC-178745 und NC-172912: Die Release Notes führen für SFOS 22.0 MR2 Build 546 behobene Fehler zu gestoppten Antivirus-Diensten, Failsafe durch den Logging-Daemon, OOM-bedingten HA-Neustarts und flackernden System graphs auf. Passt das Symptom auf einen älteren Build, werden Issue-ID und Upgradepfad im Ticket dokumentiert; ein Firmwareupdate erfolgt nur im freigegebenen Wartungsfenster mit Backup und Rückweg.

Known Issues ändern sich unabhängig vom Artikel. Vor einer Eskalation wird der Eintrag deshalb erneut geöffnet und sein aktueller Status gesichert. Eine Issue-ID erklärt ein passendes Fehlerbild, ersetzt aber weder die Auswirkungsprüfung noch den Funktionsnachweis.

Abweichungen dokumentieren und eskalieren

Eine tägliche Prüfung ist erst abgeschlossen, wenn relevante Abweichungen einen nächsten Schritt haben. Für ein Ticket oder Betriebsjournal genügen meist diese Felder:

• Datum, Uhrzeit und Zeitzone;
• Firewallname, Modell, SFOS-Version und Build;
• bei HA: Node, Rolle und letzter Statuswechsel;
• betroffene Funktion, Zone, Interface, VPN oder Regel;
• beobachteter Zustand und erwarteter Sollzustand;
• Screenshot, Reportzeitraum, Logfilter oder Rule ID;
• Auswirkung auf Benutzer oder Dienste;
• Owner, Priorität, nächste Prüfung und Eskalationsweg.

Vor einer zustandsverändernden Massnahme werden der Detailstatus im Control Center, der Graph mit sichtbarem Zeitraum und die gefilterten Logzeilen beziehungsweise der CSV-Export gesichert. Für einen Supportfall lässt sich unter Diagnostics > Tools > Consolidated troubleshooting report mit System snapshot und den benötigten Logdateien ein CTR erzeugen: Grund eintragen, Generate wählen und die verschlüsselte Datei nach Abschluss herunterladen. Debug-Modus und Log-Purge gehören nicht in den täglichen Check; sie verändern den Diagnosezustand beziehungsweise vernichten Belege und werden nur gezielt nach Supportvorgabe eingesetzt.

Sofortige Eskalation ist sinnvoll, wenn ein produktiver WAN-Link oder kritischer VPN-Pfad unerwartet ausfällt, ein Schutzdienst gestoppt ist, Diskbelegung weiter wächst, Last dauerhaft hoch bleibt, wiederholte Admin-Angriffe mit erfolgreicher Anmeldung korrelieren oder ein neuer Security-Treffer zu erlaubtem schädlichem Traffic passt.

Beobachtung genügt eher bei einem kurzen erklärbaren Peak, einem absichtlich ungenutzten Interface oder einem bereits bekannten Ereignis mit dokumentiertem Owner und stabilem Funktionsnachweis.

Sinnvolle Prüffrequenz

Sophos schreibt keinen universellen täglichen Rhythmus für jede Ansicht vor. Die Frequenz folgt deshalb Risiko, Betriebszeit und vorhandener Überwachung:

• Täglich oder pro Schicht: neue Messages, gestoppte Services, WAN/VPN/HA, Uptime, kritische Security-Ereignisse und fehlgeschlagene Admin-Logins.
• Wöchentlich: Graph-Trends, Interface-Errors, Diskwachstum, Reportmuster, wiederkehrende Quellen und offene Tickets.
• Nach Changes, Upgrades oder Failover: betroffene Funktion, Logs, Reports, Alertweg und realer Traffic erneut abnehmen.
• Regelmässig ausserhalb des Kurzchecks: Health Check, Regelwerksreview, Backup-Restore-Test, Lizenz- und Zertifikatsablauf sowie Kapazitätsplanung.

E-Mail-Benachrichtigungen oder Monitoring verkürzen die Reaktionszeit, ersetzen die Prüfung aber nicht. Ein Alarmweg ist erst belastbar, wenn Transport, Ereignisauswahl, Empfänger und Reaktion getestet sind. Der vollständige Ablauf steht unter Sophos Firewall E-Mail-Benachrichtigungen einrichten und testen.

Betriebscheckliste

• Control Center auf neue Messages und unerwartete Statusänderungen prüfen.
• Services, produktive WAN-Links, Interfaces, VPNs und Uptime mit dem Sollzustand vergleichen.
• CPU, Memory, Load Average, Disk und wichtige Interface-Zähler gegen die Baseline lesen.
• Security-Reports für den letzten vollständig verfügbaren Zeitraum prüfen.
• Im Report den Zeitraum setzen, Generate wählen und auffällige Ergebnisse bei Bedarf exportieren.
• Im Log Viewer Modul, Timer filter und Add filter setzen; Quelle, Ziel, Benutzer, Aktion und Rule ID korrelieren und relevante Zeilen als CSV sichern.
• Fehlgeschlagene Admin-Logins nach Quelle, Service und Wiederholung bewerten.
• Bei HA den verarbeitenden Node und node-lokale Logs berücksichtigen.
• Build und passendes Symptom gegen aktuelle Release Notes und Known Issues prüfen; Issue-ID im Ticket festhalten.
• Keine Neustarts, Loglöschungen oder breiten Regeländerungen ohne Beweissicherung und Rückweg auslösen.
• Jede relevante Abweichung mit Owner, Priorität und nächstem Schritt dokumentieren.
• Nach einer Korrektur nicht nur den Status, sondern auch die reale Funktion erneut testen.

FAQ