Sophos NDR Health und Kapazität überwachen

Ein grüner Sophos-NDR-Status ist ein wichtiger Zwischencheck, aber noch kein Beleg für vollständige Spiegelabdeckung oder eine funktionierende Erkennungskette. Für eine belastbare Beurteilung müssen sechs Signalgruppen getrennt betrachtet werden: Sophos Fusion, Appliance Manager, SPAN-Eingang, Upload, Compute und Storage sowie – falls vorhanden – die eigenständige Investigation Console.

Schnellprüfung: Zuerst den NDR-Status in Sophos Fusion lesen. Danach im Appliance Manager unter NDR die Werte für jeden erwarteten SPAN-Port, Uploaded und den Flow-Verlauf prüfen. Unter Status folgen CPU, Memory, Root Disk und Data Disk. Ein gelber Hinweis spanX: packets being dropped bedeutet, dass mehr als 10 % der von NDR verarbeiteten Netzwerkpakete verworfen werden. Ein grüner SPAN-Port erfüllt aktuell den Produktklassifikator von mindestens 2 % Unicast-Paketen. Keine dieser Aussagen beweist für sich allein, dass alle vorgesehenen Netze gespiegelt werden oder eine Detection Ende-zu-Ende ankommt.

Die Anzeigen richtig zuordnen

Den Appliance Manager öffnet man in Sophos Fusion über Threat Analysis Center > Integrations > Configured > Integration Appliances. In der Zeile der Appliance wählt man über die drei Punkte Open Appliance Manager. Der Kopfbereich zeigt unter anderem Version, K3S Helm Chart version, Uptime und System ID. Diese Angaben gehören in jede Störungsdokumentation, weil zwei Appliances mit ähnlich wirkenden Symptomen unterschiedliche Softwarestände oder Laufzeiten haben können.

Fusion-Status als Einstieg verwenden

Sophos Fusion unterscheidet drei Zustände:

• Rot: Die NDR-Integration funktioniert nicht. NDR containers not ready, <specific container names> weist auf nicht bereite Anwendungen hin. Upload to s3 failed ... betrifft den Cloud-Upload. spanX: unhealthy span betrifft den Traffic-Eingang vom spiegelnden Netzwerkgerät.
• Gelb: Die Integration arbeitet, aber mit Fehlern. spanX: packets being dropped wird angezeigt, wenn mehr als 10 % der Netzwerkpakete verworfen werden.
• Grün: Die Integration empfängt SPAN-Traffic und verarbeitet Paketdaten ohne gemeldeten Fehler. Ein SPAN-Port wird derzeit als gesund klassifiziert, wenn mindestens 2 % der beobachteten Pakete Unicast-Pakete sind.

Die beiden Prozentwerte haben unterschiedliche Nenner und dürfen nicht miteinander verrechnet werden. Die 2-%-Grenze klassifiziert die Zusammensetzung des am Sensor ankommenden Traffics. Sie bedeutet weder, dass 2 % des gesamten Unternehmensverkehrs genügen, noch dass NDR 98 % verlieren darf. „Mindestens 2 %“ schliesst genau 2 % ein. Die Drop-Meldung beschreibt dagegen den Anteil der bereits bei NDR ankommenden Pakete, den die Verarbeitung wegen fehlender Ressourcen nicht bewältigt. Sophos dokumentiert die Warnung für mehr als 10 %, nicht für „10 % oder mehr“.

Wichtig: Die Schwelle von mehr als 10 % ist ein Produktstatus und kein Zielwert oder akzeptables Verlustbudget. Auch ein Wert unterhalb der Meldeschwelle kann eine Verschlechterung gegenüber der eigenen Baseline sein. Ebenso kann ein grüner Port falsch oder unvollständig gespiegelten Traffic liefern, solange die beobachtete Mischung den Unicast-Klassifikator erfüllt.

SPAN-Eingang und Upload getrennt prüfen

Im Appliance Manager zeigt der Tab NDR für jeden konfigurierten SPAN-Port einen Erfassungswert. SPAN Port 2 erscheint nur, wenn ein zweiter Port konfiguriert wurde. Der Graph der gesamten Network Flows wird in 30-Sekunden-Intervallen dargestellt.

Diese Anzeigen beantworten drei getrennte Fragen:

1. Kommt auf jedem erwarteten SPAN-Port Traffic an? Ein fehlender oder plötzlich stark abweichender Wert lenkt die Prüfung zuerst zum Quell-Switch, zur Mirror- beziehungsweise SPAN-Session, zur Zuordnung der virtuellen Netzwerkkarte und zu kürzlich geänderten VLANs oder Portgruppen.
2. Ist die Verkehrsmischung plausibel? Grün bestätigt nur den aktuellen Unicast-Klassifikator. Der Flow-Verlauf muss zusätzlich zu den üblichen Tageszeiten, Standorten und erwarteten Traffic-Spitzen passen.
3. Kann NDR die Pakete verarbeiten? Die gelbe Drop-Meldung zeigt einen Verarbeitungsengpass. Sie ist nicht dasselbe wie ein überbuchter Mirror-Port oder Packet Loss im produktiven Pfad.

Der ebenfalls im Tab NDR sichtbare Upload-Prozentsatz ist eine nachgelagerte Stufe. Ein gesunder SPAN-Eingang bei fallendem Upload deutet nicht auf dieselbe Fehlerklasse wie ein leerer SPAN-Port. Bei Upload to s3 failed. Request was received but an error code was returned prüft man den ausgehenden Internetzugriff der Appliance sowie Firewall- und Web-Proxy-Regeln. NDR lädt die Daten über eine vorab signierte URL in einen S3-Bucket hoch. Bleibt der Fehler nach der Netz- oder Proxy-Korrektur bestehen, ist dies ein Fall für Sophos Support.

Die Karten unter Integrations zählen bei Drittanbieter-Log-Collector-Integrationen Received, Filtered, Accepted und Uploaded. Diese Syslog-Zähler sind nicht der NDR-Uploadwert und nicht der SPAN-Capture-Wert. Sie sind trotzdem wichtig, weil eine stark belastete, gemeinsam betriebene Log-Collector-Integration CPU und Memory derselben Appliance beansprucht.

CPU, Memory und Storage beurteilen

Unter Status zeigt der Appliance Manager die Nutzung von CPUs, Memory, Root Disk und Data Disk. Einzelne dauerhaft ausgelastete CPU-Kerne sind bei NDR erwartbar: Das Data Plane Development Kit (DPDK) arbeitet auf reservierten Kernen im Poll Mode. Es fragt dort fortlaufend nach Paketen, statt im Leerlauf auf Interrupts zu warten.

Sophos nennt dafür zwei konkrete Beispiele:

• Bei einer VM mit 4 CPU-Kernen bleibt ein Kern bei 100 %.
• Bei einer VM mit 8 CPU-Kernen bleiben zwei Kerne bei 100 %.

Eine solche per-Core-Auslastung ist daher allein kein Beleg für Überlastung und verschwindet nicht zwingend bei wenig Traffic. Umgekehrt darf „DPDK ist normal“ nicht jede hohe CPU-Auslastung erklären. Kritisch wird die Kombination aus zunehmendem Traffic, ausgelasteten weiteren Kernen, der Meldung packets being dropped, sinkendem Upload oder einem gegenüber der Baseline veränderten Flow-Verlauf.

Für virtuelle Appliances gelten als Kapazitätsorientierung:

Alle drei Grössen sind gemeinsam zu betrachten. Eine Umgebung kann die Bandbreitengrenze unterschreiten und wegen sehr kleiner Pakete trotzdem viele Pakete pro Sekunde erzeugen. Liegen die Werte über dem High-Profil, empfiehlt Sophos mehrere virtuelle Appliances im Netzwerk.

Die Grössen gelten für eine VM, auf der nur NDR läuft. Unter hoher Last benötigt jede zusätzlich gehostete Log-Collector-Integration ungefähr 400 MB RAM und kann weitere CPU-Kapazität beanspruchen. Deshalb werden vor einer Vergrösserung auch die Karten unter Integrations geprüft. Bei dauerhaft gemischter Last kann die Trennung auf mehrere Appliances sinnvoller sein als wiederholtes Nachrüsten derselben VM.

Für Memory, Root Disk und Data Disk gibt die hier verwendete Produktdokumentation keine allgemeine Warnschwelle vor. Es wäre deshalb irreführend, einen beliebigen Prozentwert als Sophos-Limit zu behandeln. Entscheidend sind Trend, freier Spielraum und gleichzeitige Symptome. Bei stetigem Disk-Wachstum werden keine Dateien oder Container manuell gelöscht; zuerst werden Zustand und Zeitraum dokumentiert und bei unklarer Ursache Logs für Sophos Support gesichert.

Eine verwertbare Baseline aufbauen

Eine Momentaufnahme unterscheidet normalen Tagesgang nicht von einer beginnenden Überlastung. Nach der Inbetriebnahme und nach jeder relevanten Änderung werden deshalb vergleichbare Messpunkte erfasst:

• Datum, Uhrzeit und Zeitzone sowie erwartete Lastphase,
• Fusion-Farbe und exakter Meldungstext,
• Erfassungswert für jeden konfigurierten SPAN-Port,
• Upload-Prozentsatz und Form des Flow-Verlaufs,
• CPU je Kern sowie Gesamtbild, Memory, Root Disk und Data Disk,
• zugewiesene vCPUs und RAM der VM,
• geschätzte beziehungsweise am Quellsystem gemessene Mbit/s, Pakete/s und Flows/s,
• gleichzeitig laufende Drittanbieter-Integrationen und deren Aktivität,
• Änderungen an Switch, Hypervisor, Proxy, Firewall oder Appliance.

Sinnvoll sind Messungen in einer ruhigen Phase, bei normaler Geschäftslast und während einer bekannten Spitze. Es geht nicht um einen universellen Sollwert, sondern um den Vergleich derselben Appliance unter ähnlichen Bedingungen. Ein plötzlicher Rückgang eines SPAN-Ports ist damit sichtbar, auch wenn Fusion noch Grün zeigt. Nach einer Kapazitätsänderung bildet man erst dann eine neue Baseline, wenn der Zustand stabil ist.

Störungen in sicherer Reihenfolge beheben

1. Umfang festhalten: Betroffene Appliance, SPAN-Port, Beginn, exakten Fusion-Text und letzte Änderung dokumentieren. Vor einem Restart Screenshots oder Messwerte sichern.
2. Eingang prüfen: Bei unhealthy span, fehlenden Flows oder einer Abweichung vom Port-Basiswert zuerst Mirror-Quelle, Zielport beziehungsweise virtuelle Netzwerkkarte und die erwarteten Netze prüfen. Zusätzliche CPU behebt keine falsch konfigurierte SPAN-Quelle.
3. Upload prüfen: Bei einem S3-Uploadfehler ausgehenden Internetzugriff, Firewall und Web Proxy kontrollieren. Ein erfolgreicher Upload behebt umgekehrt keine fehlende Spiegelabdeckung.
4. Kapazität prüfen: Bei mehr als 10 % Drops Traffic-Profil, weitere ausgelastete Kerne, vCPU-Zuweisung und mitbetriebene Integrationen vergleichen. Bei einer VM zusätzliche vCPUs zuweisen; für das dokumentierte High-Profil sind 8 vCPUs vorgesehen. Bei zertifizierter Hardware kann eine weitere Appliance bereitgestellt und der SPAN-Traffic aufgeteilt werden. Vor dieser Aufteilung ist ein freigegebener Abdeckungsplan Pflicht: Er ordnet jedes vorgesehene Netzwerk, VLAN und jede Mirror-Quelle eindeutig der Ziel-Appliance zu und verhindert Lücken sowie unbeabsichtigte doppelte Einspeisungen. Bei gemischten Workloads kann man NDR und Log Collectors auf getrennte Appliances verteilen.
5. Restart abgrenzen: Läuft NDR nach der Ursachenbehebung weiterhin nicht korrekt, kann ein gezielter NDR-Restart nach der zuständigen Betriebs- oder Troubleshooting-Anleitung erwogen werden. Währenddessen findet keine normale NDR-Verarbeitung statt; ein Restart ersetzt keine Kapazitätskorrektur. Ein Restart oder Shutdown der ganzen VM hat einen grösseren Wirkungsbereich und gehört nicht in den ersten Fehlerbehebungsschritt.

Werden vCPUs oder die Traffic-Verteilung geändert, erfolgt dies in einem freigegebenen Wartungsfenster nach den Vorgaben der verwendeten Virtualisierungsplattform. Die Änderung wird einzeln durchgeführt, damit ihre Wirkung messbar bleibt. Nach einer Traffic-Aufteilung wird der Abdeckungsplan gegen jeden resultierenden SPAN-Port geprüft; zusätzlich wird der freigegebene Ende-zu-Ende-Testpfad validiert.

Investigation Console nicht mit der NDR-Appliance verwechseln

Die Investigation Console ist eine separate Komponente. Ihr Zustand belegt weder den Zustand der NDR-Integration noch die Vollständigkeit der SPAN-Quellen oder die erfolgreiche Datenlieferung. Dieser Artikel beschränkt sich deshalb auf diese Abgrenzung: SPAN, NDR-Upload, DPDK und Packet Drops werden an der NDR-Integration und im Appliance Manager geprüft; Prüfung und Fehlerbehebung der Investigation Console gehören in die dafür zuständige Konsolen-Betriebsdokumentation.

Nach jeder Massnahme validieren

Die Prüfung wird unter einer mit der Ausgangsmessung vergleichbaren Last wiederholt. Eine Korrektur gilt erst als wirksam, wenn:

• Fusion den erwarteten Zustand ohne die vorherige rote oder gelbe Meldung zeigt,
• jeder erwartete SPAN-Port sichtbar ist und wieder zum eigenen Basisverlauf passt,
• der Unicast-Klassifikator nicht fälschlich als Abdeckungsnachweis verwendet wurde,
• die Meldung für mehr als 10 % Packet Drops nicht erneut auftritt,
• Upload und Network Flows über einen aussagekräftigen Beobachtungszeitraum stabil bleiben,
• CPU ausserhalb der erwarteten DPDK-Kerne, Memory sowie Root und Data Disk ausreichend Spielraum zeigen,
• mitbetriebene Drittanbieter-Integrationen weiterhin erwartete Daten verarbeiten,
• nach einer Traffic-Aufteilung jedes vorgesehene Netzwerk, VLAN und jede Mirror-Quelle gemäss freigegebenem Abdeckungsplan genau der vorgesehenen Appliance zugeführt wird und der freigegebene Ende-zu-Ende-Testpfad funktioniert.

Diese Kontrollen validieren den Betriebszustand, aber noch keine vollständige Detection-Kette. Für einen Ende-zu-Ende-Nachweis ist zusätzlich ein freigegebener NDR-Test mit Kontrolle der resultierenden Detection erforderlich.

Wann Sophos Support übernehmen sollte

Sophos Support sollte einbezogen werden, wenn Container nicht bereit werden, ein S3-Uploadfehler trotz bestätigtem Internet- und Proxy-Pfad bleibt, ein SPAN-Port trotz korrigierter Quellkonfiguration unhealthy bleibt, Packet Drops nach angemessener Kapazitätserhöhung wiederkehren oder Ressourcen und Statusmeldungen einander widersprechen.

Für die Eskalation werden mindestens folgende Daten vorbereitet:

• Appliance-Name, System ID, Version, K3S Helm Chart version und Uptime,
• genauer Status- und Fehlertext mit Beginn und Zeitzone,
• betroffener SPAN-Port, Capture-/Uploadwerte und Flow-Verlauf,
• CPU je Kern, Memory, Root Disk und Data Disk vor und nach der Massnahme,
• VM-Zuweisung, beobachtetes Traffic-Profil und mitbetriebene Integrationen,
• letzte Switch-, Hypervisor-, Firewall- oder Proxy-Änderungen,
• durchgeführte Massnahmen und ihr messbares Resultat,
• bei Problemen einer separaten Investigation Console die Nachweise, die deren zuständige Betriebsdokumentation verlangt.

Passwörter, private Schlüssel und andere Zugangsdaten gehören nicht in das Ticket. Niedrigstufige Kubernetes-Befehle oder manuelle Änderungen an Containern werden nicht auf Verdacht ausgeführt; bei NDR containers not ready werden die vorhandenen Beobachtungen gesammelt und mit Sophos Support abgestimmt.