Sophos NDR auf VMware ESXi oder Hyper-V bereitstellen

Sophos NDR läuft auf ESXi oder Hyper-V als virtuelle Integration Appliance. Die VM benötigt zwei klar getrennte Pfade: MGMT bezieht eine normale IP-Adresse und erreicht Sophos Fusion (ehemals Sophos Central) beziehungsweise den Sophos Data Lake; SPAN1 und optional SPAN2 empfangen nur gespiegelte Kopien des zu untersuchenden Traffics. Eine grüne VM oder der Central-Status Connected bestätigt deshalb noch nicht, dass NDR Pakete sieht.

Kurzablauf: Voraussetzungen und Kapazität prüfen, die NDR-Konfiguration in Sophos Fusion anlegen, das Mirroring passend zur Plattform vorbereiten, das erzeugte Image genau einmal bereitstellen, den ersten Start bis zum automatischen Neustart abwarten und danach Management- und SPAN-Pfad getrennt abnehmen.

Wichtige Grenze: Der SPAN-Pfad liegt nicht inline und darf nicht als Managementnetz verwendet werden. Das Mirroring wird auf Switch und Hypervisor eingerichtet; die NDR-Appliance verändert den produktiven Originaltraffic nicht. Für Hyper-V werden hier bewusst keine externen PowerShell-Mirroring-Befehle angegeben. Das Design wird in Hyper-V nach den freigegebenen Microsoft- und Sophos-Vorgaben umgesetzt und über echten Testtraffic geprüft.

Voraussetzungen verbindlich prüfen

Für beide Plattformen gelten zunächst diese Mindestwerte:

• aktive Sophos Network Detection and Response integration license pack-Berechtigung im verwendeten Tenant;
• 4 vCPUs, 16 GB RAM und 160 GB Storage;
• CPU-Flags pdpe1gb für Packet Capture und avx2 für die Machine-Learning-Funktionen;
• ein eigenes Managementnetz mit DHCP oder statischer Adresse, DNS, Default Gateway und ausgehendem Internetzugang;
• vorbereitete SPAN-Pfade für bidirektionale Kopien aller freigegebenen Traffic-Klassen: virtueller interner Traffic und physischer externer Traffic, sofern beide zum vereinbarten Beobachtungsumfang gehören;
• dokumentierte Zuständigkeit für Central, Hypervisor, physische Switches und Firewall-Allowlisting.

Enthält der freigegebene Umfang tatsächlich nur eine dieser Traffic-Klassen, wird diese Grenze ausdrücklich dokumentiert. Ein einzelner SPAN-Pfad darf dann nicht als Abdeckung der jeweils anderen Klasse gelten.

Auf der Appliance wird kein zusätzlicher Sophos Agent und kein anderer Antimalware-Agent installiert. Betriebssystem-, Security- und Appliance-Updates verwaltet Sophos. Eigene Patch- oder Hardening-Vorgaben dürfen diesen verwalteten Zustand nicht ungeprüft verändern.

Plattformgrenzen

VMware ESXi benötigt:

• ESXi 6.7 Update 3 oder neuer;
• VM hardware version 11 oder neuer;
• bei Enhanced vMotion Compatibility einen EVC-Modus Skylake oder neuer;
• keine Bereitstellung in VMware Cloud, da diese nicht unterstützt wird.

Die CPU-Flags müssen auch durch den gewählten EVC-Modus in der VM sichtbar bleiben. Ein aktueller physischer Prozessor allein genügt nicht, wenn EVC benötigte Fähigkeiten ausblendet.

Microsoft Hyper-V benötigt:

• Hyper-V 6.0.6001.18016, entsprechend Windows Server 2016, oder neuer;
• deaktivierten Processor Compatibility Mode;
• höchstens 8 CPU-Cores und 32 GB RAM pro NDR-VM;
• maximal einen NUMA-Node und einen CPU-Socket.

Die Hyper-V-Obergrenzen sind keine Empfehlung, die VM grundsätzlich maximal auszustatten. Sie verhindern eine nicht unterstützte NUMA-Topologie.

VM nach Traffic dimensionieren

Die Standardgrösse mit 4 vCPUs ist für eine reine NDR-Appliance bis zu diesen Richtwerten vorgesehen:

• 500 Mbit/s,
• 70'000 Pakete pro Sekunde,
• 1'200 Flows pro Sekunde.

Für hohe Last bis 1 Gbit/s, 300'000 Pakete pro Sekunde oder 4'500 Flows pro Sekunde werden 8 vCPUs verwendet. SPAN2 erfordert ebenfalls mindestens 8 vCPUs. Liegt die Last über diesen Werten, wird sie auf mehrere NDR-Appliances an geeigneten Netzpunkten verteilt; eine einzelne VM wird nicht über die dokumentierten Grenzen hinaus vergrössert.

Laufen zusätzlich Log-Collector-Integrationen auf derselben Appliance, ist deren Last separat einzuplanen. NDR reserviert bei 4 vCPUs zwei und bei 8 vCPUs drei CPUs mit hoher Priorität. Andere Integrationen können diese CPUs trotzdem belasten. Bei 16 GB RAM dürfen Log-Collector-Integrationen zusammen höchstens 2 GB verwenden. Eine Appliance nimmt unabhängig von der Anzahl Integrationen höchstens 8'000 Log-Events pro Sekunde an. Pro Appliance ist nur eine NDR-Integration möglich.

Ausgehende Verbindungen freigeben

Wenn die Firewall Wildcards unterstützt, benötigt die Appliance diese Ziele:

yum.oracle.com ist optional, weil die Appliance bei fehlender Erreichbarkeit den Sophos-JFrog-Mirror verwendet. Wildcards werden nicht blind auf weitere Zonen übertragen. Erlaubt die Firewall keine Wildcards, muss vor dem Change die vollständige aktuelle, regionsabhängige Sophos-Hostname-Liste in die Allowlist übernommen und durch einen DNS- und Verbindungstest von der MGMT-Zone geprüft werden. Eine gekürzte oder aus einer anderen Region kopierte Liste ist kein sicherer Ersatz.

Integration und Image in Sophos Fusion erstellen

1. In Sophos Fusion Threat Analysis Center > Integrations > Marketplace öffnen.
2. Sophos Network Detection and Response (NDR) wählen.
3. Unter Data Ingest (Security Alerts) auf Add Configuration klicken.
4. In Step 1 einen eindeutigen Namen und eine Beschreibung der Integration eingeben.
5. In Step 2 eine bestehende Appliance wählen oder Create new appliance anklicken. Eine bestehende Appliance darf noch keine andere NDR-Integration besitzen.
6. Für eine neue Appliance einen eindeutigen Appliance name, eine Beschreibung und die richtige Plattform, VMware ESXi oder Microsoft Hyper-V, wählen.
7. Unter Internet-facing network port settings entweder DHCP oder Manual konfigurieren. Eine per DHCP vergebene Adresse muss reserviert werden.
8. In Step 3 einen Exclusion list name eintragen. Dieser Name ist auch dann erforderlich, wenn die Liste zunächst leer bleibt.
9. Mit Save abschliessen.

Bei Manual sind die Felder IP address, Subnet mask, Gateway address, DNS 1 und optional DNS 2 auszufüllen. Ein internes Beispiel lautet:

• IP address: 10.0.252.5
• Subnet mask: 255.255.255.0
• Gateway address: 10.0.252.1
• DNS 1: 10.0.252.53
• DNS 2: 10.0.252.54

Diese Werte sind durch freie Adressen und erreichbare DNS-Server des eigenen Managementnetzes zu ersetzen. Die statische Adresse wird vorab gegen DHCP-Pool, IPAM und bestehende Hosts geprüft.

Unter Domain exclusions lässt sich ein Domainname eintragen. Protocol exclusions besitzt ein Feld für das Master-Protokoll, zum Beispiel TCP oder UDP, und ein Feld für das Subprotokoll, zum Beispiel facebook; bei zwei Angaben verbindet Central sie mit einem einzelnen Punkt. Ein komplettes Master-Protokoll wird nicht ausgeschlossen, nur um Datenmenge zu reduzieren. Jede Ausnahme benötigt einen bestätigten False Positive oder eine begründete Kapazitätsentscheidung, einen Owner und ein Review-Datum.

Nach dem Speichern in der Spalte Actions den plattformspezifischen Download wählen: Download OVA file für ESXi oder das ZIP-Paket für Hyper-V. Der Status links neben der Integration wechselt auf Waiting for deployment. Das Image enthält die konkrete Appliance-Konfiguration und wird nicht zwischen Tenants oder Appliances wiederverwendet.

VMware ESXi bereitstellen

1. SPAN-Portgruppen vorbereiten

Für virtuellen internen Traffic wird auf dem betroffenen Standard-vSwitch eine dedizierte Portgruppe angelegt:

1. Networking > Virtual switches öffnen und den vorgesehenen vSwitch wählen.
2. Unter Port groups auf Add port group klicken.
3. Einen eindeutigen Namen vergeben.
4. VLAN ID auf 4095 setzen.
5. Unter Security den Promiscuous mode auf Accept setzen.
6. Die Portgruppe speichern.

Für gespiegelten Traffic eines physischen Switches wird ein separater vSwitch mit eigener SPAN-Portgruppe nach demselben Muster verwendet. Unter vSwitch topology mit Add uplink eine freie physische NIC zuweisen. Der dedizierte Mirror-Destination-Port des physischen Switches wird direkt mit dieser NIC des ESXi-Hosts verbunden.

Auf dem physischen Switch werden als Mirror-Quellen nur die freigegebenen Ports oder VLANs und beide Richtungen ausgewählt. Der Destination-Port transportiert die Kopien zur ESXi-NIC und wird nicht gleichzeitig als normaler Access-, Trunk- oder Managementport verwendet. Die konkrete Switch-Syntax ist herstellerspezifisch und wird nicht aus einem Beispiel eines anderen Modells übernommen.

Wenn physisches SPAN und vMotion zusammen eingesetzt werden, muss die NDR-VM auf dem ESXi-Host bleiben, dessen physische NIC den Mirror-Traffic empfängt. Eine unbeabsichtigte Migration auf einen anderen Host kann den SPAN-Pfad lautlos entfernen, obwohl MGMT weiterhin funktioniert.

2. OVA importieren und Interfaces zuordnen

Das heruntergeladene OVA ist an diese Central-Konfiguration gebunden und kann nur einmal verwendet werden. Für einen Ersatz- oder Neuaufbau wird in Central ein neues OVA erzeugt.

1. Auf dem ESXi-Host Virtual Machines > Create/Register VM öffnen.
2. Deploy a virtual machine from an OVF or OVA file wählen.
3. Einen VM-Namen eingeben und ndr-sensor.ova auswählen.
4. Als Storage-Typ Standard und danach den vorgesehenen Datastore wählen.
5. Unter Deployment options die Netzwerke bewusst zuordnen:
   • SPAN1: erste vorbereitete SPAN-Portgruppe;
   • SPAN2: zweite SPAN-Portgruppe, falls wirklich benötigt;
   • SYSLOG: bei einer reinen NDR-Appliance eine Platzhalter-Portgruppe wählen und den Adapter nach dem Import trennen;
   • MGMT: die Management-Portgruppe mit DHCP beziehungsweise den in Central eingetragenen statischen Netzparametern.
6. Disk Provisioning auf Thin setzen.
7. Power on automatically aktivieren.
8. Additional settings unverändert überspringen und mit Finish importieren.

Vor dem ersten Einschalten werden Zuordnung, Linkstatus und MAC-Adressen aller vNICs nochmals dokumentiert. MGMT darf nicht auf einer SPAN-Portgruppe liegen. Wird SPAN2 verwendet, muss die VM mindestens 8 vCPUs besitzen.

Microsoft Hyper-V bereitstellen

1. Mirroring-Design vorbereiten

Vor dem Scriptlauf muss feststehen, welcher vSwitch welchen Zweck erfüllt:

• ein normaler vSwitch für MGMT mit DHCP oder dem statisch geplanten Netzweg;
• ein Zielpfad für SPAN1;
• optional ein zweiter Zielpfad für SPAN2, dann mit mindestens 8 vCPUs;
• kein aktiver SYSLOG-Pfad, sofern dieselbe Appliance nicht auch freigegebene Drittprodukt-Integrationen verarbeitet.

Für Hyper-V umfasst die Mirroring-Konfiguration konzeptionell vier Teile: einen Traffic-Mirroring-Port, ein an den vSwitch angeschlossenes SPAN Virtual Interface, die aktivierte Microsoft NDIS Capture Extension sowie korrekt gesetzte Source- und Destination-Mirroring-Modi. Die Umsetzung hängt von Windows-/Hyper-V-Version, vSwitch-Typ und Quelle des zu spiegelnden Traffics ab. Deshalb werden keine unbestätigten PowerShell-Befehle aus fremden Umgebungen übernommen.

Vor dem NDR-Start prüft das Plattformteam den vorgesehenen Pfad als Deployment-Smoke-Test mit einem bekannten bidirektionalen Testflow. Dabei muss die Kopie am vorgesehenen Destination-Pfad ankommen, ohne dass sich der produktive Originalflow verändert. Erst danach wird dieser vSwitch im Sophos-Script als SPAN-Ziel ausgewählt. Dieser einzelne Test bestätigt nicht die vollständige Mirroring-Abdeckung.

2. ZIP entpacken und Sophos-Script ausführen

1. Das aus Central geladene ZIP in einen lokalen, geschützten Ordner auf dem Hyper-V-Host entpacken. Es enthält virtuelle Disks, seed.iso und ndr-sensor.ps1.
2. Im Ordner ndr-sensor.ps1 mit Run with PowerShell starten.
3. Bei Security Warning die lokale, direkt aus Central geladene Datei prüfen und mit Open freigeben.
4. Einen eindeutigen VM-Namen eingeben.
5. Das angezeigte neue VM-Verzeichnis im Standardpfad für virtuelle Disks kontrollieren und mit C erstellen lassen.
6. 4 CPUs für die Standardgrösse oder 8 CPUs für hohe Last beziehungsweise SPAN2 angeben.
7. 16 GB RAM als Standardwert angeben; die Hyper-V-Grenze von 32 GB nicht überschreiten.
8. Aus der nummerierten vSwitch-Liste zuerst den MGMT-vSwitch wählen.
9. Für SYSLOG bei einer reinen NDR-Appliance einen Platzhalter-vSwitch wählen und diesen Adapter nach der Erstellung trennen.
10. Den vorbereiteten vSwitch für SPAN1 und, falls geplant, denjenigen für SPAN2 wählen.
11. Auf Installation Completed Successfully warten und das Script mit einer beliebigen Taste beenden.
12. Die neue VM in Hyper-V Manager öffnen und vor dem Start CPU, RAM, Netzadapter, verbundene vSwitches und getrennten SYSLOG-Adapter prüfen.

Die von Sophos erzeugten virtuellen Disks und seed.iso gehören zusammen. Einzelne Dateien werden nicht durch gleichnamige Dateien eines älteren Downloads ersetzt.

Erster Start und Deployment-Smoke-Test

Die Appliance prüft beim ersten Start die zugeordneten Netzwerke und den Internetzugang und startet danach automatisch neu. Dieser Vorgang kann bis zu zehn Minuten dauern.

Den ersten Start und den automatischen Neustart nicht unterbrechen. Ein manuelles Ausschalten in diesem Fenster kann einen unvollständigen Zustand erzeugen und ist kein Troubleshooting-Schritt.

Der technische Deployment-Smoke-Test erfolgt in dieser Reihenfolge:

1. VM-Konsole: Der Bootvorgang endet ohne dauernde Fehler- oder Neustartschleife.
2. Managementpfad: Die konfigurierte oder reservierte MGMT-Adresse, DNS, NTP und die erforderlichen ausgehenden Ziele sind erreichbar.
3. Central-Kontrollpfad: Unter Threat Analysis Center > Integrations > Configured > Integration Appliances beziehungsweise auf der NDR-Integrationsseite wechselt die Appliance von Waiting for deployment auf Connected.
4. SPAN-Pfad: Pro bereitgestelltem SPAN-Pfad einen angekündigten, ungefährlichen Testflow zwischen zwei bekannten Testsystemen in beiden Richtungen erzeugen. Auf dem Switch beziehungsweise Hypervisor müssen Source, Direction und Destination zum Change passen; auf der Appliance muss der zugeordnete SPAN-Adapter Traffic empfangen.
5. Plausibilität: Zeitfenster, Quell- und Zieladressen sowie Richtung des beobachteten Testflows vergleichen. Erst wenn diese Werte stimmen, ist der jeweilige bereitgestellte Pfad für diesen Smoke-Test bestätigt.
6. Last: Während eines ersten geeigneten Lastfensters Durchsatz, Pakete und Flows gegen die gewählte Sizing-Stufe vergleichen. Ein Connected-Status ist kein Kapazitätsnachweis.

Eine einzelne künstliche Detection ist für den Deployment-Smoke-Test nicht erforderlich. Entscheidend sind ein stabiler Managementpfad und nachgewiesener bidirektionaler Traffic am richtigen SPAN-Interface. Der Testflow enthält keine Malware und keine echten Kundendaten in einem Packet Capture.

Dieser Smoke-Test belegt nur die konkret getesteten Pfade. Die vollständige Abnahme aller vorgesehenen Quellen, VLANs, Richtungen und Traffic-Klassen gehört in das separate Runbook Traffic Mirroring für Sophos NDR planen und validieren; aus Connected oder einem erfolgreichen Einzelflow wird hier keine umfassende Mirror-Abdeckung abgeleitet.

Fehler nach Symptom eingrenzen

Der Status bleibt auf Waiting for deployment

1. Prüfen, ob das richtige, neu aus dieser Konfiguration geladene Image bereitgestellt wurde.
2. VM-Konsole und Power-State prüfen und den ersten Start mindestens zehn Minuten ohne Unterbruch abwarten.
3. MGMT-vNIC, Portgruppe beziehungsweise vSwitch und DHCP-Reservation oder statische Felder vergleichen.
4. DNS, Gateway, NTP sowie TCP 443, TCP 22 und UDP 123 gemäss Allowlist vom Managementnetz prüfen.
5. Erst nach diesen Checks neu bereitstellen. Auf ESXi ist dafür ein neu erzeugtes OVA nötig; das bereits verwendete OVA wird nicht erneut importiert.

Connected, aber kein NDR-Traffic

Auf ESXi zuerst SPAN1/SPAN2-Zuordnung, VLAN ID 4095, Promiscuous mode: Accept, physischen Uplink und Mirror-Destination-Port prüfen. Bei vMotion kontrollieren, ob die VM noch auf dem Host mit der angeschlossenen SPAN-NIC läuft.

Auf Hyper-V kontrolliert das Plattformteam SPAN Virtual Interface, NDIS Capture Extension, Source-/Destination-Modus und den vSwitch, der im Sophos-Script ausgewählt wurde. Es werden keine Firewall-Regeln oder erfundenen Mirroring-Befehle auf Verdacht ergänzt.

Auf beiden Plattformen den Testfilter nicht sofort enger machen: zuerst Adapterzähler und einen klar identifizierbaren bidirektionalen Flow prüfen. MGMT-Traffic auf dem MGMT-Adapter ist kein Beweis für funktionierendes SPAN.

Nur eine Richtung oder nur ein Netz ist sichtbar

• Mirror-Quelle muss Senden und Empfangen umfassen.
• Bei asymmetrischem Routing kann der Rückweg über einen anderen Uplink laufen.
• Virtueller interner und physischer externer Traffic können getrennte SPAN-Pfade benötigen.
• Ist SPAN2 konfiguriert, müssen der zweite vSwitch beziehungsweise die zweite Portgruppe korrekt zugeordnet und mindestens 8 vCPUs vorhanden sein.

Nach jeder Korrektur wird exakt derselbe Testflow wiederholt. So bleibt erkennbar, welche Änderung wirkte.

Dragonfly bleibt Pending

Ist Central bereits Connected, NDR arbeitet aber nicht, wird in der Sophos VA Console der Dienststatus Dragonfly geprüft. Vor diesem Schritt muss der lokale Konsolenzugriff nach dem separaten Runbook Sophos NDR Integration Appliance und Sensor betreiben bereitgestellt sein. Hypervisor- oder Central-Zugangsdaten werden dafür nicht ungeprüft übernommen; dieses Deployment-Runbook erzeugt und nennt keine lokalen Appliance-Zugangsdaten.

Bei Pending in einem ESXi-EVC-Cluster zuerst EVC-Modus und sichtbare CPU-Fähigkeiten kontrollieren. Sandy Bridge wird für diesen Einsatz nicht unterstützt; erforderlich ist Skylake oder neuer sowie pdpe1gb und avx2.

Auf Hyper-V zusätzlich Processor Compatibility Mode, CPU-/RAM-Grenzen und die Topologie mit höchstens einem NUMA-Node und einem CPU-Socket prüfen. Die VM wird nicht durch weitere CPUs oder RAM über die unterstützten Grenzen «repariert».

Unter Last fehlen Pakete oder Ergebnisse

Aktuellen Durchsatz, Pakete und Flows mit den Sizing-Grenzen vergleichen. Ist eine SPAN-Destination langsamer als die Summe ihrer Quellen, kann die Kopie Pakete verlieren, während der produktive Traffic störungsfrei weiterläuft. Dann Quellen enger wählen, SPAN-Pfade aufteilen oder mehrere Appliances einsetzen. Breite Protokollausnahmen sind kein Ersatz für korrektes Sizing.

Lokal begrenzte Rücknahme dieses Deployments

Die folgenden Schritte sind eine konservative lokale Change-back-Empfehlung für die hier beschriebene passive Bereitstellung. Sie sind kein von Sophos dokumentiertes vollständiges Decommissioning- oder Offboarding-Verfahren. Der Rückweg bleibt bewusst auf die im Change neu angelegten Sensor- und Mirror-Objekte beschränkt:

1. Test und letzte bekannte Zustände sichern: Central-Status, VM-Ressourcen, Interface-Zuordnung, Mirror-Quellen und -Richtungen.
2. Zuerst die SPAN- beziehungsweise Mirroring-Session am Switch oder Hypervisor deaktivieren. Produktive Source-Ports, VLANs und vSwitches werden dabei nicht gelöscht oder neu verkabelt.
3. Prüfen, dass der Originaltraffic weiterhin funktioniert und keine Kopien mehr am NDR-Destination-Pfad eintreffen.
4. Danach die NDR-VM geordnet ausschalten.
5. Dedizierte Portgruppen, vSwitches, Uplinks oder VM-Dateien erst entfernen, wenn ihre alleinige Nutzung durch diese Appliance bestätigt ist. Gemeinsam verwendete Management- oder Produktionsobjekte bleiben bestehen.
6. Statische DHCP-Reservation, Firewall-Allowlist und DNS-Einträge als separate, referenzgeprüfte Änderungen zurücknehmen.

Die Central-Integration oder Appliance wird im Rahmen dieser lokalen Rücknahme nicht gelöscht. Eine solche Löschung liegt ausserhalb dieses Deployment-Rollbacks und benötigt einen separat validierten und freigegebenen Offboarding-Prozess. Ebenso wird ein bestehendes OVA nicht als Rollback-Image behandelt: Für einen erneuten ESXi-Aufbau erzeugt man ein neues Image in Central.

Nach einem fehlgeschlagenen Erststart lautet die lokal begrenzte Rücknahme daher: Mirroring stoppen, VM ausschalten, ausschliesslich die diesem Change eindeutig zugeordneten Netzwerkobjekte zurücknehmen und die Ursache vor einer neuen Bereitstellung klären. Ein passiver NDR-Test wird nicht spontan in ein anderes Netzdesign oder einen Inline-Pfad umgebaut.