Sophos NDR: Plattform wählen und Sensor richtig dimensionieren

Sophos NDR lässt sich als virtuelle Appliance auf VMware ESXi, Microsoft Hyper-V, AWS oder Nutanix sowie auf zertifizierter Hardware von Dell, NUC und OnLogic betreiben. Die Wahl fällt vor dem Deployment: Virtuelle und Cloud-Sensoren werden anhand von Bandbreite, Paketen und Flows dimensioniert; bei Hardware gelten ausschliesslich die zertifizierten Modelle und deren Kapazitätsstufen.

Schnellentscheid: Bis zu 500 Mbit/s, 70'000 Pakete pro Sekunde und 1'200 Flows pro Sekunde genügt für einen reinen virtuellen NDR-Sensor die Standardkonfiguration. Bis zu 1 Gbit/s, 300'000 Pakete pro Sekunde und 4'500 Flows pro Sekunde sind 8 vCPUs vorgesehen. Liegt auch nur eine Messgrösse darüber, werden mehrere virtuelle Appliances im Netzwerk benötigt. Für höhere Bandbreiten oder einen physischen Sensor wählt man zertifizierte Hardware anhand der tatsächlich gemessenen Dauer- und Spitzenlast.

Lizenz und Planungsgrundlagen

Für die Integration ist das Sophos Network Detection and Response integration license pack erforderlich. Sophos bemisst die NDR-Lizenz nach der Gesamtzahl der Benutzer und Server der Organisation. Die Software für virtuelle Appliances ist enthalten; innerhalb der Lizenz dürfen so viele NDR-Sensoren bereitgestellt werden, wie benötigt werden. Das ist wichtig, wenn eine grössere Umgebung wegen der dokumentierten VM-Grenzen auf mehrere Sensoren verteilt werden muss.

Vor der Plattformwahl werden folgende Werte erhoben:

• maximale und anhaltende Bandbreite des Verkehrs, der tatsächlich gespiegelt werden soll,
• Pakete pro Sekunde und Flows pro Sekunde für denselben Zeitraum,
• Kapazität des Switches beziehungsweise Mirror-Ports, von dem der Sensor den Verkehr erhält,
• geplante Anzahl und Position der Sensoren,
• weitere Log-Collector-Integrationen, die auf derselben Appliance laufen sollen,
• verfügbare CPU-Mikroarchitektur, CPU-Flags, Arbeitsspeicher und Storage,
• unterstützte Virtualisierungsplattform beziehungsweise exaktes zertifiziertes Hardwaremodell.

Ein Internet-Uplink allein ist keine ausreichende Bemessungsgrundlage. Der Sensor verarbeitet den an ihn gespiegelten Verkehr. Deshalb müssen die Messwerte am vorgesehenen Mirror-Punkt erhoben und als Dauer- sowie Spitzenlast dokumentiert werden.

Plattform wählen

Virtuelle Appliance oder Cloud

Eine virtuelle Appliance passt, wenn eine der getesteten Plattformen bereits vorhanden ist, die Last innerhalb der VM-Grenzen liegt oder sich sinnvoll auf mehrere Sensoren verteilen lässt. Unterstützt sind:

• VMware ESXi,
• Microsoft Hyper-V,
• Amazon Web Services (AWS),
• Nutanix.

Für AWS nennt die technische Sophos-NDR-Spezifikation den Instanztyp c5n.2xlarge. Die konkreten Bereitstellungsmechanismen, Netzwerkinterfaces und Traffic-Mirroring-Einstellungen stehen in der jeweiligen Deployment-Anleitung und werden nicht aus der Sizing-Entscheidung abgeleitet.

VMware Cloud wird nicht unterstützt. Für ESXi und Hyper-V gelten zusätzlich die unten beschriebenen Versions- und CPU-Voraussetzungen. Die vorliegenden Anforderungen enthalten dagegen keine gemeinsame Versionsmatrix für AWS und Nutanix; deren Deployment-Voraussetzungen müssen deshalb im jeweiligen Plattformzweig geprüft werden.

Zertifizierte Hardware

Hardware kommt infrage, wenn ein dedizierter physischer Sensor benötigt wird oder eine zertifizierte Kapazitätsstufe zur gemessenen Last passt. Sophos unterstützt NDR auf Hardware nur mit zertifizierten Systemen. Allgemeine x86-Server, ähnliche Modellvarianten oder selbst zusammengestellte Systeme sind daraus nicht als unterstützt abzuleiten.

Zertifiziert sind Systeme aus diesen Familien:

• Dell,
• NUC,
• OnLogic.

Entscheidend ist nicht nur der Herstellername. Vor der Beschaffung muss das exakte Modell mit der aktuellen Certified hardware specifications for NDR abgeglichen werden. Installation, Datenträgerabbild und herstellerspezifische Schritte folgen erst nach diesem Modellentscheid.

Virtuelle und Cloud-Sensoren dimensionieren

Mindestressourcen

Für ESXi und Hyper-V gelten folgende Mindestressourcen:

• 4 CPUs,
• 16 GB RAM,
• 160 GB Storage.

Die VMware-OVA ist für Sophos NDR und Log-Collector-Integrationen bereits auf diese Mindestwerte vorkonfiguriert. AWS verwendet den oben genannten Instanztyp. Für Nutanix nennt die verwendete Anforderungsquelle an dieser Stelle keine separaten Mindestressourcen. Mindestressourcen sind jedoch noch keine Kapazitätszusage. Für die Wahl zwischen Standardkonfiguration, 8 vCPUs und mehreren Appliances müssen alle drei Verkehrsgrössen berücksichtigt werden.

Die Grenzwerte bilden gemeinsam eine Lastklasse. Ein Sensor mit 400 Mbit/s, aber 100'000 Paketen pro Sekunde liegt nicht mehr vollständig in Medium. Sind die Werte höher als in Hoch, sieht Sophos mehrere virtuelle Appliances verteilt im Netzwerk vor; aus den Quellen lässt sich keine grössere Einzel-VM oberhalb dieser Grenze ableiten.

Die technische Spezifikation begrenzt einen virtuellen NDR-Sensor auf maximal 1 Gbit/s. Dieser Wert hebt die engeren Paket- und Flow-Grenzen nicht auf.

CPU und Hypervisor prüfen

Die folgenden Mikroarchitektur- und Flag-Anforderungen gelten für das System, auf dem die VM läuft. Bei ESXi, Hyper-V und anderen selbst verwalteten VM-Hosts müssen die CPU-Flags pdpe1gb und avx2 in der VM verfügbar sein. pdpe1gb wird für die Paketerfassung benötigt, avx2 für die Machine-Learning-Funktionen. Mehr vCPUs kompensieren fehlende Flags nicht.

Für AWS wird stattdessen der unterstützte Instanztyp samt AWS-Deployment-Anforderungen geprüft; physische Appliances werden über das exakte zertifizierte Modell und dessen freigegebene Konfiguration validiert. Daraus ist weder für AWS noch für zertifizierte Hardware ein zusätzlicher manueller Flag-Nachweis abzuleiten.

Sophos dokumentiert folgende CPU-Mikroarchitekturen:

• Intel: Skylake Generation 6, Kaby Lake Generation 7, Coffee Lake Generation 8, Coffee Lake Refresh und Cascade Lake Generation 9, Comet Lake Generation 10, Cannon Lake/Palm Cove Generation 10, Ice Lake/Sunny Cove Generation 10, Rocket Lake/Cypress Cove Generation 11, Alder Lake/Golden Cove Generation 12 und Raptor Lake/Raptor Cove Generation 13.
• AMD: Naples und Great Horned Owl mit Zen 1, Rome mit Zen 2, Milan mit Zen 3 sowie Genoa mit Zen 4.

Aktuellere CPUs können ebenfalls verwendet werden, sofern beide erforderlichen Flags bereitstehen. Sophos hält fest, dass seit dem ersten Quartal 2015 eingeführte CPUs funktionieren sollten; für die Freigabe zählt trotzdem der konkrete Nachweis der beiden Flags auf der vorgesehenen VM.

Für die Hypervisoren gelten diese Mindeststände und Grenzen:

• VMware ESXi: Version 6.7 Update 3 oder neuer und VM Hardware Version 11 oder höher. In einem EVC-Cluster muss Skylake generation or later gewählt sein. VMware Cloud wird nicht unterstützt.
• Microsoft Hyper-V: Version 6.0.6001.18016 auf Windows Server 2016 oder neuer. Processor Compatibility Mode wird nicht unterstützt.

Gemeinsame Appliance mit Log Collectors

Die VM-Werte für Medium und Hoch gelten für eine Appliance, auf der nur Sophos NDR läuft. Werden Log-Collector-Integrationen mitgehostet, beginnt die Planung mit der NDR-Grösse und addiert anschliessend deren Last. Dafür sind folgende Grenzen und Auswirkungen dokumentiert:

• Alle Log-Collector-Integrationen einer VM zusammen können maximal 8'000 Events pro Sekunde annehmen.
• Eine Log-Collector-Integration benötigt unter hoher Last ungefähr 400 MB RAM.
• Bei 4 CPUs übernimmt NDR 2 CPUs, bei 8 CPUs 3 CPUs. Andere Integrationen können diese CPUs dennoch nutzen und dadurch die von NDR verarbeitbare Verkehrsmenge beeinflussen.
• Bei 16 GB RAM dürfen Log-Collector-Integrationen zusammen höchstens 2 GB verwenden, damit NDR ausreichend Speicher behält.
• Ein Log Collector am Maximum der Eventrate benötigt auf einer VM mit den standardmässigen 4 CPUs ungefähr dieselbe Rechenleistung wie NDR unter mittelhoher Last.

Für gemischte Lasten gibt es keine einzelne allgemeingültige Grösse. Werden die NDR-Grenzwerte oder die verfügbaren Ressourcen voraussichtlich überschritten, sind zusätzliche Appliances einzuplanen. Bei mehreren Log-Collector-Integrationen oberhalb von insgesamt 8'000 Events pro Sekunde werden mehrere VMs eingesetzt. Überschreitet dagegen eine einzelne Integration diese Grenze, wird zuerst über die Syslog-Einstellungen des Quellsystems versucht, die Eventmenge zu reduzieren. Die dokumentierten Näherungswerte rechtfertigen keine frei erfundene Überbelegung.

Zertifizierte Hardware dimensionieren

Sophos leitet die Hardwarestufe aus der Kapazität am spiegelnden Switch sowie aus Dauer- und Spitzenlast ab. Der NDR-Sensor soll dieselbe Kapazität wie der Switch besitzen, von dem der gespiegelte Verkehr kommt. Die folgenden Empfehlungen basieren auf einer typischen Organisation mit 20 Prozent Power Usern, 60 Prozent typischen Benutzern und 20 Prozent Light Usern. Angenommen werden ausserdem VoIP, etwas Videostreaming, grosse Uploads und Downloads sowie Anwendungs- und Webserver.

Diese Namen und Leistungsstufen dienen nur der Vorauswahl. Eine Beschaffung ist erst freigegeben, wenn das exakte Modell und die exakte Konfiguration in der aktuellen Certified hardware specifications for NDR aufgeführt sind.

Für jede Zeile dokumentiert Sophos eine mögliche Spitzenlast vom Zwei- bis Dreifachen der typischen Last. Diese Spitzenangabe ist kein Ersatz für eine Messung und darf nicht mit der Kapazitätsstufe verwechselt werden. Bei zusätzlichem starken Video- und Musikstreaming kann die nächstgrössere Stufe erforderlich sein; entschieden wird anhand der gemessenen Dauer- und Spitzenlast sowie der aktuellen zertifizierten Grenzen. Bei überwiegend E-Mail-Nutzung kann eine kleinere Stufe passen, sofern die gemessene Dauer- und Spitzenlast sowie die Benutzerzahl innerhalb ihrer Werte bleiben.

Bandbreite und Benutzerzahl allein reichen für die Hardwareauswahl nicht. Zusätzlich sind in der aktuellen Zertifizierung die maximalen Verbindungen pro Sekunde und die freigegebene CPU-, RAM- und gegebenenfalls Sockelkonfiguration zu prüfen. Das ist insbesondere bei verbindungsintensivem Verkehr entscheidend. Beispielsweise nennt das Sophos-NDR-Datenblatt vom 19. Dezember 2024 für zwei R660-Konfigurationen denselben Nenndurchsatz, aber unterschiedliche Verbindungs- und Ressourcengrenzen:

Die Datenblatt-Konfigurationen mit Stand 19.12.2024 im Einzelnen:

Dell R660, 2 Sockel

• Max. Durchsatz: 40 Gbit/s
• Max. Verbindungen/s: 120'000
• CPUs: 64
• RAM: 128 GB

Dell R660, 1 Sockel

• Max. Durchsatz: 40 Gbit/s
• Max. Verbindungen/s: 80'000
• CPUs: 32
• RAM: 64 GB

Dell R650

• Max. Durchsatz: 20 Gbit/s
• Max. Verbindungen/s: 40'000
• CPUs: 24
• RAM: 64 GB

Dell R450

• Max. Durchsatz: 10 Gbit/s
• Max. Verbindungen/s: 20'000
• CPUs: 16
• RAM: 32 GB

Dell R350

• Max. Durchsatz: 4 Gbit/s
• Max. Verbindungen/s: 8'000
• CPUs: 8
• RAM: 32 GB

Intel NUC 13th Gen

• Max. Durchsatz: 2,5 Gbit/s
• Max. Verbindungen/s: 4'000
• CPUs: 12
• RAM: 32 GB

Diese datierten Werte zeigen alle technischen Sizing-Dimensionen und die Bedeutung der exakten Konfiguration, sind aber keine aktuelle Beschaffungs- oder Zertifizierungsmatrix. Für R360, R660xs, OnLogic und jede abweichende Variante werden die fehlenden Werte nicht aus ähnlichen Modellen abgeleitet, sondern ausschliesslich aus der aktuellen zertifizierten Spezifikation übernommen.

Die Hardwareempfehlungen sind ein Lastmodell, keine Garantie für jede Verkehrsverteilung. Streaming und grosse Backup-Flows erzeugen viel Volumen; Sophos NDR ist für solche Streaming- und «Elephant Flow»-Verkehre optimiert, während viele Bedrohungen in normalem Browsing- und Anwendungsverkehr erkannt werden. Deshalb werden Benutzerprofil und reale Netzwerkwerte zusammen bewertet.

Netzwerkvoraussetzungen vor dem Deployment

Die Appliance benötigt ausgehende Verbindungen zum Starten und für Updates. Wenn die Firewall Wildcards unterstützt, dokumentiert Sophos folgende Freigaben:

yum.oracle.com ist optional; ohne Zugriff verwendet die Appliance den Sophos-JFrog-Repository-Mirror. Unterstützt die Firewall keine Wildcards, darf diese kurze Tabelle nicht in einzelne vermutete Hosts übersetzt werden. Dann wird die aktuelle regionsabhängige Liste auf der Sophos-Seite Appliance requirements übernommen.

Auf der Integration Appliance werden weder ein Sophos Agent noch ein anderer Anti-Malware-Agent installiert. Betriebssystem- und Sicherheitsupdates werden ebenfalls nicht manuell eingespielt; Sophos verwaltet diese Updates.

Entscheidung validieren und übergeben

Vor dem Deployment sollte ein Planungsprotokoll mindestens diese Punkte enthalten:

1. Plattform: ESXi, Hyper-V, AWS, Nutanix oder exaktes zertifiziertes Hardwaremodell.
2. Messfenster: Zeitpunkt und Dauer der Messung sowie Dauer- und Spitzenwerte für Bandbreite, Pakete und Flows am vorgesehenen Mirror-Punkt.
3. Sizing: gewählte Lastklasse beziehungsweise Hardwarestufe und der jeweils knappste Grenzwert; bei Hardware zusätzlich die gemessenen maximalen Verbindungen pro Sekunde gegen die aktuelle zertifizierte Grenze.
4. Ressourcen nach Plattform:
   • ESXi, Hyper-V und andere selbst verwaltete VM-Hosts: vCPUs, RAM, Storage, CPU-Modell sowie die in der VM sichtbaren Flags pdpe1gb und avx2.
   • AWS: unterstützter Instanztyp c5n.2xlarge und Anforderungen des AWS-Deployment-Zweigs.
   • Zertifizierte Hardware: exaktes zertifiziertes Modell und freigegebene CPU-, RAM- und Sockelkonfiguration.
5. Zusatzlast: Namen und erwartete Events pro Sekunde aller mitgehosteten Log-Collector-Integrationen.
6. Netzwerk: vorgesehene Management- und Spiegelanbindung sowie bestätigte ausgehende Port- und Domainfreigaben.
7. Skalierung: Anzahl und Platzierung zusätzlicher Sensoren, falls ein virtueller Sensor die High-Grenzen überschreiten würde.

Die Entscheidung ist belastbar, wenn jeder Messwert innerhalb der gewählten Stufe liegt und die plattformspezifischen Voraussetzungen erfüllt sind. Bei selbst verwalteten VM-Hosts gehören dazu Hypervisor, CPU und die in der VM sichtbaren Flags. Bei AWS zählt der unterstützte Instanztyp samt Deployment-Anforderungen. Bei Hardware müssen exaktes Modell, CPU-/RAM-/Sockelkonfiguration, Durchsatz und maximale Verbindungen pro Sekunde mit der aktuellen Zertifizierung übereinstimmen. Bei einer gemeinsamen Appliance müssen zusätzlich Eventrate, RAM und CPU-Auswirkung der Log Collectors berücksichtigt sein.

Image-Erstellung, Installation, Registrierung, Traffic Mirroring und die erste Detection gehören in die nachfolgenden Deployment- und Validierungsschritte. Ein späterer Status Connected oder ein grüner Appliance-Status bestätigt nur den Zustand der Integration; er beweist weder vollständige Mirror-Abdeckung noch eine funktionierende Ende-zu-Ende-Erkennung.

Grenzen der dokumentierten Planung

Die Quellen liefern keine Formel, um aus Benutzerzahl, Bandbreite oder Events eine beliebige individuelle CPU- und RAM-Grösse oberhalb der genannten VM-Stufen zu berechnen. Oberhalb der High-Grenzen ist deshalb die dokumentierte Entscheidung mehrere virtuelle Appliances, nicht eine spekulativ grössere Einzel-VM.

Ebenso ersetzen die Hardwaretabellen nicht die aktuelle Zertifizierungsspezifikation. Sie nennen Vorauswahl- beziehungsweise datierte Datenblattwerte, aber keine Freigabe für ähnlich benannte Server, abweichende Komponenten oder eigene x86-Systeme. Wenn bei Hardware das exakte Modell und die freigegebene Konfiguration fehlen oder wenn keine belastbaren Verkehrs- und Verbindungswerte vorliegen, wird die Plattform noch nicht zur Bereitstellung freigegeben. Für einen selbst verwalteten VM-Host gilt dasselbe, wenn die erforderlichen CPU-Flags in der VM fehlen.