Sophos Firewall User & Device Insights richtig auswerten

Control Center > User & device insights ist eine Triage-Ansicht, kein gemeinsamer Alarmstatus. Die Kacheln stammen aus verschiedenen Zeiträumen und Datenquellen. Ein roter Endpoint, ein hoher User Threat Quotient (UTQ), ein TLS-Fehler und eine hohe Sessionzahl können zusammengehören – müssen es aber nicht.

Der sichere Ablauf lautet: betroffene Kachel und Zeitraum notieren, in die Detailansicht wechseln, Benutzer/IP/Hostname und Zeitpunkt mit Logs sowie der tatsächlich getroffenen Regel abgleichen und erst dann eine Policy oder Ausnahme ändern. Vor jeder Änderung werden Screenshot oder Export, Filter, Fehlerzahl, Ziel, Owner und erwartetes Ergebnis gesichert.

Was die Signale beweisen – und was nicht

• Security Heartbeat meldet den von Sophos verwalteten Endpoints übermittelten Gesundheitszustand. Er beweist weder, dass jede Verbindung dieses Geräts blockiert wurde, noch dass ein grünes Gerät frei von jeder Bedrohung ist.
• Synchronized Application Control zeigt von verwalteten Geräten gemeldete Anwendungen. Ein Eintrag beweist eine Erkennung, aber noch keine Regelwirkung oder bösartige Aktivität.
• Zero-day protection zählt analysierte Dateien und Findings. Ein Scan-Zähler beweist nicht, dass jeder Download sichtbar oder schädlich war.
• UTQ priorisiert auffällige Benutzerkonten anhand der Browsing-Aktivität der letzten sieben Tage. Er ist ein Untersuchungshinweis, kein Schuld- oder Kompromittierungsnachweis.
• SSL/TLS connections beschreibt beobachtete Verbindungen und ausgewählte entschlüsselungsbezogene Fehler. Prozentwerte sind keine Aussage über den Schutz jedes einzelnen Flows.
• Firewall sessions zeigt aktive Verbindungen und Kapazitätsnähe. Viele Sessions beweisen allein weder einen Angriff noch eine Überlastung.

Prüfe deshalb immer mindestens zwei passende Belege, etwa Kachel plus Detail-Log oder Endpoint-Event plus Firewall Rule ID. Für einzelne aktive Flows hilft Live Connections und Connection List.

Security Heartbeat und Anwendungen prüfen

Security Heartbeat unterscheidet vier Zustände:

• At risk (rot): aktive Malware wurde erkannt.
• Missing (rot): der Endpoint erzeugt Traffic, sendet aber keinen Gesundheitsstatus.
• Warning (gelb): inaktive Malware wurde erkannt oder Malware wurde erkannt und bereinigt.
• Connected (grün): es wurde keine Malware erkannt und der Endpoint meldet einen fehlerfreien Gesundheitsstatus.

Die Kachel zählt alle Zustände. Ein Klick öffnet jedoch nur Details für rote und gelbe Endpoints mit Hostname, IP-Adresse, Benutzer und Zeit seit dem Statuswechsel. Sind alle verbundenen Geräte grün, bleibt diese Detailansicht daher leer. Das ist kein Datenfehler und keine vollständige Inventarliste.

Verlässt ein Endpoint das Netzwerk, während sein Heartbeat Missing ist, bleibt dieser Zustand im Control Center und in Reports bestehen. Er ändert sich erst, wenn sich der Endpoint erneut verbindet. Für nachweislich veraltete Einträge dokumentiert man vor der Bereinigung Endpoint-Name, Alter des Status, letzten bekannten Benutzer und Zeitpunkt sowie den Stand in Control Center und Report. Erst nach der Ursachenprüfung öffnet man die CLI und wählt 4. Device Console. Dort kann man entweder alle Missing-Einträge ab einem bestimmten Alter von 1 bis 90 Tagen oder genau einen Endpoint-Namen entfernen:

system synchronized-security missing-endpoints delete days-missing 7
system synchronized-security missing-endpoints delete name endpoint1

7 und endpoint1 sind Beispiele und müssen durch das freigegebene Alter beziehungsweise den exakten Namen ersetzt werden. Der Altersbefehl betrifft alle Einträge, die seit diesem Wert oder länger Missing sind, und kann damit mehr Geräte als beabsichtigt aus Control Center und Reports entfernen; der Namensbefehl ist bei einem einzelnen bekannten Altgerät enger. Das Löschen repariert weder Endpoint noch Heartbeat und stellt den entfernten Verlauf nicht wieder her. Danach Control Center und den betroffenen Report neu laden, bestätigen, dass nur die vorgesehenen Einträge verschwunden sind, und bei einem weiterhin aktiven Gerät die erneute Verbindung sowie den neuen Heartbeat-Status prüfen.

Bei einem roten oder gelben Eintrag zuerst den Zeitpunkt und Endpoint in Sophos Fusion (ehemals Sophos Central) prüfen. Danach kontrollieren, ob die getroffene Firewall-Regel überhaupt eine Heartbeat-Bedingung enthält. Die reine Sichtbarkeit bewirkt noch keine Blockierung. Registrierung, Voraussetzungen und Regelwirkung erklärt Sophos Firewall mit Sophos Fusion verbinden; dauerhafte Missing-Meldungen werden mit Missing Heartbeat Alerts richtig prüfen eingegrenzt.

Die Kachel Synchronized Application Control zeigt New, Categorized und die Gesamtzahl erkannter Anwendungen. Ein Klick führt zu Applications > Synchronized Application Control. Dort eine neue Anwendung anhand von Gerät, Benutzer und Erkennungszeit bewerten, kategorisieren und erst danach über einen passenden Application Filter steuern. Eine direkte Datenbankbereinigung ist kein Triage-Schritt; bei Erfassungs- oder Speicherproblemen gilt der sichere Ablauf aus Synchronized Application Control: Datenbankproblem prüfen. Die eigentliche Regelzuweisung steht unter Application Control einrichten und testen.

Zero-Day-Zähler und UTQ einordnen

Die Zero-Day-Kachel setzt eine aktive Zero-Day Protection-Subscription voraus. Unter Administration > Licensing muss das Modul Subscribed oder Evaluating anzeigen; ohne Subscription kann man über den Link im Control Center eine kostenlose 30-Tage-Evaluation starten.

Die Zero-Day-Kachel verwendet unterschiedliche Zeitfenster:

• Recent: neue Reports zu malicious, suspicious oder PUA in den letzten sieben Tagen.
• Incidents: alle als malicious, suspicious oder PUA markierten Dateien; Incident-Reports bleiben bis zu sechs Monate erhalten. Die Frist ist unter Report settings > Data management konfigurierbar.
• Scanned: gesamter von Zero-Day Protection erfasster Traffic einschliesslich sauberer Dateien; der Zeitraum hängt von der Aufbewahrung der Datenbankeinträge ab.

Die Hilfe zu SFOS 22 hält ausdrücklich fest, dass sich die Zero-Day-Protection-Zähler nicht zurücksetzen lassen. In der vorliegenden Hilfe zu SFOS 23 fehlt dieser Hinweis; daraus lässt sich keine Unterstützung für einen Reset ableiten. Reset ‘Failed’ count gehört ausschliesslich zum separaten SSL/TLS-Fehlerzähler, nicht zu Zero-Day Protection. Für die Untersuchung bleiben Zählerstände und Logs erhalten: Ein Neustart, das Löschen von Daten, eine Änderung der Aufbewahrung oder ein CLI-Reset sind keine empfohlenen Wege, diese Zähler zurückzusetzen – auch nicht unter SFOS 23.

Die Zahlen sind deshalb nicht direkt voneinander abzuziehen. Öffne über die Kachel Zero-day protection > Downloads and attachments, gleiche Datei, Urteil, Benutzer/IP und Zeitpunkt ab und prüfe den betroffenen Web- oder Mailpfad. Fehlende Treffer können auch an Lizenz, Policy, nicht entschlüsseltem Traffic oder Aufbewahrung liegen. Konfiguration und Incident-Behandlung beschreibt Zero-Day Protection verstehen und betreiben.

UTQ betrachtet die Browsing-Aktivität der letzten sieben Tage. Die Kachel meldet entweder keine riskanten Benutzer oder die Anzahl der Benutzer, die zusammen 80 Prozent des Netzwerkrisikos ausmachen. Ein Klick führt zu Reports > Dashboards mit Benutzern und Threat Score. Prüfe dort konkrete Kategorien, Ziele, Zeitpunkte und die Zuverlässigkeit der Benutzerzuordnung. Ein gemeinsames Konto, NAT oder fehlende Authentifizierung kann die Zuordnung verzerren; ein hoher Score rechtfertigt nicht automatisch das Sperren eines Benutzers.

SSL/TLS-Verbindungen sicher analysieren

Die Kachel aktualisiert Entschlüsselungsdetails alle fünf Minuten. Falls Daten in Control Center und Log Viewer fehlen, kontrolliere unter Rules and policies > SSL/TLS inspection rules, dass SSL/TLS inspection aktiv ist, und unter SSL/TLS inspection settings > Advanced settings > SSL/TLS engine, dass die Engine Enabled ist.

• Of traffic ist der Anteil SSL/TLS-verschlüsselten Traffics am gesamten Firewall-Traffic.
• Decrypted ist der Anteil entschlüsselter Verbindungen an allen SSL/TLS-Verbindungen.
• Failed zählt fehlgeschlagene SSL/TLS-Verbindungen. Der Zähler wird um Mitternacht automatisch zurückgesetzt und kann über Reset ‘Failed’ count manuell zurückgesetzt werden.

Ein manueller Reset lässt sich nicht rückgängig machen und stellt den alten Zähler nicht wieder her. Vorher Wert, Uhrzeit und aktiven Test dokumentieren. Nach dem Reset denselben Testflow ausführen, mindestens einen Aktualisierungszyklus abwarten und Detail-Logs prüfen. Der Reset behebt keine Ursache.

Der Drill-down zeigt Sessions der letzten 24 Stunden und Fehler der letzten 7 Tage. Die Sessiongrafik und die Fehlerdaten schliessen Verbindungen über den Web Proxy aus. Top websites und Top users beziehungsweise IP-Adressen helfen beim Eingrenzen; ein Klick auf die Fehlerzahl öffnet passend gefilterte Logs mit dem Ziel in Server name. Die Liste enthält nur Fehler, die durch eine SSL/TLS-Inspection-Regel lösbar sein können oder auf fehlendes CA-/Application-Trust am Client hinweisen. Web-Policy- oder andere Security-Policy-Blocks fehlen hier.

Unter Fix errors kann man Websites, Benutzer oder IPs aus der Fehlerliste ausblenden. Hide ändert nur die Sicht, nicht die Entschlüsselung. Mit Show hidden und Unhide ist dies reversibel. Dokumentiere trotzdem den Filter, damit ein verschwundener Eintrag nicht mit einem behobenen Fehler verwechselt wird.

Exclude from decryption ist eine Sicherheitsänderung. Add domain oder Add subdomain fügt das Ziel zur URL Group Local TLS exclusion list hinzu; bearbeiten lässt sie sich unter Web > URL groups. Vorher exakten FQDN, betroffene Clients, Fehler-ID, Owner, Ablaufdatum und Positiv-/Negativtest erfassen. Bevorzuge die spezifischere Subdomain, wenn nur dieser Host betroffen ist. Danach prüfen, dass die Anwendung funktioniert, der Flow nicht mehr entschlüsselt wird und andere Domains weiterhin der vorgesehenen TLS-Regel folgen. Der sichere Rollout steht unter TLS Inspection schrittweise einführen.

Für den Rückweg entfernt man nur den exakt hinzugefügten Eintrag – und erst nachdem Owner und aktuelle Nutzung bestätigt wurden. Anschliessend denselben Test wiederholen und auf neue Trust- oder TLS-Fehler achten. Eine geteilte oder bereits vorher vorhandene Ausnahme darf nicht als vermeintlicher Rollback gelöscht werden.

Firewall-Sessions und Entschlüsselungskapazität

Die Sessiongrafik bietet Live, 24h, 48h, Week, Month und Year. Live aktualisiert alle 30 Sekunden, die anderen Zeiträume alle fünf Minuten. Die Kategorien sind Other traffic, Undecrypted SSL/TLS und Decrypted SSL/TLS.

Decryption peak ist die höchste Zahl gleichzeitig entschlüsselter Verbindungen im gewählten Zeitraum und erscheint nur, wenn der tatsächliche Traffic nahe daran oder darüber liegt. Decryption limit ist die maximale Zahl der Verbindungen, die das konkrete Firewall-Modell entschlüsseln kann; auch diese Linie erscheint nur bei Annäherung. Eine fehlende Linie bedeutet daher nicht unbegrenzte Kapazität. Ein kurzer Peak beweist noch keine Überlastung: Zeitraum wechseln, wiederkehrendes Muster prüfen und gleichzeitig Latenz, Ressourcen, Drops sowie Benutzerfehler abgleichen.

Änderungen validieren und sauber zurückbauen

1. Ausgangswert, Zeitraum, Filter, Benutzer/IP/Hostname, Fehler-ID und betroffene Rule ID sichern.
2. Nur eine Hypothese und eine möglichst enge Änderung umsetzen.
3. Den identischen Positivtest wiederholen; bei einer Ausnahme zusätzlich einen Negativtest ausserhalb ihres Scopes durchführen.
4. Den Aktualisierungszyklus der Kachel beachten und Detail-Logs statt nur Prozentwerte vergleichen.
5. Bei ausbleibender Wirkung die Änderung zurückbauen und Datenquelle, Zeitfenster, Web-Proxy-Pfad, Authentifizierung und Regelmatch neu prüfen.

Hide/Unhide ist vollständig reversibel. Eine neu angelegte TLS-Ausnahme wird durch Entfernen genau dieses Eintrags zurückgebaut, sofern sie niemand sonst verwendet. Ein manuell zurückgesetzter Failed-Zähler kann dagegen nicht restauriert werden; seine Vorher-Dokumentation ist der einzige belastbare historische Bezug.