Sophos NDR implementeren op VMware ESXi of Hyper-V

Sophos NDR draait op ESXi of Hyper-V als virtuele Integration Appliance. De VM heeft twee duidelijk gescheiden paden nodig: MGMT krijgt een normaal IP-adres en maakt verbinding met Sophos Fusion (voorheen Sophos Central) of de Sophos Data Lake; SPAN1 en optioneel SPAN2 ontvangen uitsluitend gespiegelde kopieën van het te inspecteren verkeer. Een groene VM of de Central-status Connected bevestigt daarom nog niet dat NDR pakketten ziet.

Kort overzicht: controleer de vereisten en capaciteit, maak de NDR-configuratie in Sophos Fusion, bereid de mirroring voor het betreffende platform voor, implementeer de gegenereerde image precies één keer, wacht tot de eerste start en automatische herstart zijn voltooid en valideer daarna het beheer- en SPAN-pad afzonderlijk.

Belangrijke grens: het SPAN-pad is niet inline en mag niet als beheernetwerk worden gebruikt. Mirroring wordt op de switch en hypervisor geconfigureerd; de NDR-appliance wijzigt het oorspronkelijke productieverkeer niet. Voor Hyper-V worden hier bewust geen externe PowerShell-opdrachten voor mirroring gegeven. Implementeer het ontwerp in Hyper-V volgens de goedgekeurde richtlijnen van Microsoft en Sophos en controleer het met echt testverkeer.

Vereisten verplicht controleren

Voor beide platforms gelden in eerste instantie de volgende minimumvereisten:

• een actieve licentie voor het Sophos Network Detection and Response integration license pack in de gebruikte tenant;
• 4 vCPU’s, 16 GB RAM en 160 GB opslagruimte;
• de CPU-flags pdpe1gb voor Packet Capture en avx2 voor de machinelearning-functies;
• een afzonderlijk beheernetwerk met DHCP of een statisch adres, DNS, een standaardgateway en uitgaande internettoegang;
• voorbereide SPAN-paden voor bidirectionele kopieën van alle goedgekeurde verkeersklassen: virtueel intern verkeer en fysiek extern verkeer, als beide binnen de afgesproken bewakingsscope vallen;
• gedocumenteerde verantwoordelijkheden voor Central, de hypervisor, fysieke switches en de allowlist van de firewall.

Als de goedgekeurde scope daadwerkelijk slechts een van deze verkeersklassen bevat, documenteer deze grens dan expliciet. Eén SPAN-pad mag dan niet worden beschouwd als dekking van de andere klasse.

Installeer geen extra Sophos Agent of andere antimalware-agent op de appliance. Sophos beheert updates van het besturingssysteem, de beveiliging en de appliance. Eigen vereisten voor patches of hardening mogen deze beheerde toestand niet zonder voorafgaande validatie wijzigen.

Platformlimieten

VMware ESXi vereist:

• ESXi 6.7 Update 3 of nieuwer;
• VM hardware version 11 of nieuwer;
• bij gebruik van Enhanced vMotion Compatibility een EVC-modus van Skylake of nieuwer;
• geen implementatie in VMware Cloud, omdat dit niet wordt ondersteund.

De CPU-flags moeten via de gekozen EVC-modus ook zichtbaar blijven in de VM. Alleen een recente fysieke processor is niet voldoende als EVC vereiste mogelijkheden verbergt.

Microsoft Hyper-V vereist:

• Hyper-V 6.0.6001.18016, overeenkomend met Windows Server 2016, of nieuwer;
• uitgeschakelde Processor Compatibility Mode;
• maximaal 8 CPU-cores en 32 GB RAM per NDR-VM;
• maximaal één NUMA-node en één CPU-socket.

De Hyper-V-limieten zijn geen aanbeveling om altijd de maximale resources aan de VM toe te wijzen. Ze voorkomen een niet-ondersteunde NUMA-topologie.

De VM dimensioneren op basis van het verkeer

De standaardgrootte met 4 vCPU’s is bedoeld voor een uitsluitend voor NDR gebruikte appliance tot de volgende richtwaarden:

• 500 Mbit/s,
• 70'000 pakketten per seconde,
• 1'200 flows per seconde.

Gebruik voor een hoge belasting tot 1 Gbit/s, 300'000 pakketten per seconde of 4'500 flows per seconde 8 vCPU’s. SPAN2 vereist eveneens minimaal 8 vCPU’s. Als de belasting deze waarden overschrijdt, verdeel die dan over meerdere NDR-appliances op geschikte netwerkpunten; schaal één VM niet verder op dan de gedocumenteerde limieten.

Als op dezelfde appliance ook logcollectorintegraties draaien, moet hun belasting afzonderlijk worden gepland. NDR reserveert met hoge prioriteit twee CPU’s bij 4 vCPU’s en drie bij 8 vCPU’s. Andere integraties kunnen deze CPU’s desondanks belasten. Bij 16 GB RAM mogen logcollectorintegraties samen maximaal 2 GB gebruiken. Ongeacht het aantal integraties accepteert een appliance maximaal 8'000 loggebeurtenissen per seconde. Per appliance is slechts één NDR-integratie mogelijk.

Uitgaande verbindingen toestaan

Als de firewall wildcards ondersteunt, heeft de appliance toegang tot de volgende bestemmingen nodig:

yum.oracle.com is optioneel, omdat de appliance de Sophos JFrog-mirror gebruikt als deze bestemming niet bereikbaar is. Breid wildcards niet klakkeloos uit naar andere zones. Als de firewall geen wildcards toestaat, moet vóór de wijziging de volledige actuele, regiospecifieke lijst met Sophos-hostnamen aan de allowlist worden toegevoegd en vanuit de MGMT-zone met DNS- en verbindingstests worden gecontroleerd. Een ingekorte lijst of een lijst die uit een andere regio is gekopieerd, is geen veilig alternatief.

Integratie en image maken in Sophos Fusion

1. Open in Sophos Fusion Threat Analysis Center > Integrations > Marketplace.
2. Selecteer Sophos Network Detection and Response (NDR).
3. Klik onder Data Ingest (Security Alerts) op Add Configuration.
4. Voer in Step 1 een unieke naam en een beschrijving voor de integratie in.
5. Selecteer in Step 2 een bestaande appliance of klik op Create new appliance. Een bestaande appliance mag nog geen andere NDR-integratie hebben.
6. Kies voor een nieuwe appliance een unieke Appliance name, een beschrijving en het juiste platform, VMware ESXi of Microsoft Hyper-V.
7. Configureer onder Internet-facing network port settings DHCP of Manual. Een via DHCP toegewezen adres moet worden gereserveerd.
8. Voer in Step 3 een Exclusion list name in. Deze naam is ook vereist als de lijst aanvankelijk leeg blijft.
9. Rond af door op Save te klikken.

Vul bij Manual de velden IP address, Subnet mask, Gateway address, DNS 1 en optioneel DNS 2 in. Een intern voorbeeld is:

• 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

Vervang deze waarden door beschikbare adressen en bereikbare DNS-servers uit het eigen beheernetwerk. Toets het statische adres vooraf aan de DHCP-pool, IPAM en bestaande hosts.

Onder Domain exclusions kunt u een domeinnaam invoeren. Protocol exclusions heeft één veld voor het hoofdprotocol, bijvoorbeeld TCP of UDP, en één veld voor het subprotocol, bijvoorbeeld facebook; als beide zijn opgegeven, voegt Central ze samen met één punt. Sluit niet een volledig hoofdprotocol uit alleen om het datavolume te verminderen. Voor elke uitzondering is een bevestigde false positive of een gemotiveerde capaciteitsbeslissing, een eigenaar en een controledatum vereist.

Selecteer na het opslaan in de kolom Actions de platformspecifieke download: Download OVA file voor ESXi of het ZIP-pakket voor Hyper-V. De status links van de integratie verandert in Waiting for deployment. De image bevat de specifieke applianceconfiguratie en mag niet opnieuw worden gebruikt voor andere tenants of appliances.

Implementeren op VMware ESXi

1. SPAN-poortgroepen voorbereiden

Maak voor virtueel intern verkeer een afzonderlijke poortgroep op de betreffende standaard-vSwitch:

1. Open Networking > Virtual switches en selecteer de beoogde vSwitch.
2. Klik onder Port groups op Add port group.
3. Geef de poortgroep een unieke naam.
4. Stel VLAN ID in op 4095.
5. Stel onder Security Promiscuous mode in op Accept.
6. Sla de poortgroep op.

Gebruik voor gespiegeld verkeer van een fysieke switch een aparte vSwitch met een eigen SPAN-poortgroep volgens hetzelfde patroon. Wijs onder vSwitch topology met Add uplink een beschikbare fysieke NIC toe. Verbind de speciaal toegewezen mirrorbestemmingspoort van de fysieke switch rechtstreeks met deze NIC van de ESXi-host.

Selecteer op de fysieke switch alleen de goedgekeurde poorten of VLAN’s als mirrorbronnen en selecteer beide richtingen. De bestemmingspoort transporteert de kopieën naar de ESXi-NIC en mag niet tegelijkertijd als normale access-, trunk- of beheerpoort worden gebruikt. De exacte switchsyntaxis is leverancierspecifiek en mag niet worden overgenomen uit een voorbeeld voor een ander model.

Als fysieke SPAN en vMotion samen worden gebruikt, moet de NDR-VM op de ESXi-host blijven waarvan de fysieke NIC het mirrorverkeer ontvangt. Een onbedoelde migratie naar een andere host kan het SPAN-pad geruisloos verwijderen, terwijl MGMT blijft werken.

2. De OVA importeren en interfaces toewijzen

De gedownloade OVA is aan deze Central-configuratie gekoppeld en kan slechts één keer worden gebruikt. Genereer in Central een nieuwe OVA voor vervanging of een nieuwe implementatie.

1. Open op de ESXi-host Virtual Machines > Create/Register VM.
2. Selecteer Deploy a virtual machine from an OVF or OVA file.
3. Voer een VM-naam in en selecteer ndr-sensor.ova.
4. Selecteer Standard als opslagtype en kies daarna de beoogde datastore.
5. Wijs onder Deployment options de netwerken zorgvuldig toe:
   • SPAN1: de eerste voorbereide SPAN-poortgroep;
   • SPAN2: de tweede SPAN-poortgroep, als deze werkelijk nodig is;
   • SYSLOG: selecteer voor een uitsluitend voor NDR gebruikte appliance een tijdelijke poortgroep en ontkoppel de adapter na de import;
   • MGMT: de beheerpoortgroep met DHCP of de statische netwerkparameters die in Central zijn ingevoerd.
6. Stel Disk Provisioning in op Thin.
7. Schakel Power on automatically in.
8. Sla Additional settings ongewijzigd over en klik op Finish om te importeren.

Documenteer vóór de eerste inschakeling van de VM opnieuw de toewijzing, linkstatus en MAC-adressen van alle vNIC’s. MGMT mag niet op een SPAN-poortgroep staan. Als SPAN2 wordt gebruikt, moet de VM minimaal 8 vCPU’s hebben.

Implementeren op Microsoft Hyper-V

1. Het mirroringontwerp voorbereiden

Bepaal vóór het uitvoeren van het script welk doel elke vSwitch dient:

• een normale vSwitch voor MGMT met DHCP of het geplande statische netwerkpad;
• een bestemmingspad voor SPAN1;
• optioneel een tweede bestemmingspad voor SPAN2, in dat geval met minimaal 8 vCPU’s;
• geen actief SYSLOG-pad, tenzij dezelfde appliance ook goedgekeurde integraties van derden verwerkt.

Voor Hyper-V bestaat de mirroringconfiguratie conceptueel uit vier onderdelen: een poort voor traffic mirroring, een met de vSwitch verbonden SPAN Virtual Interface, de ingeschakelde Microsoft NDIS Capture Extension en correct ingestelde Source- en Destination-mirroringmodi. De implementatie hangt af van de Windows-/Hyper-V-versie, het type vSwitch en de bron van het te spiegelen verkeer. Neem daarom geen onbevestigde PowerShell-opdrachten uit andere omgevingen over.

Voordat NDR wordt gestart, controleert het platformteam het beoogde pad als deployment-smoketest met een bekende bidirectionele testflow. De kopie moet op het beoogde bestemmingspad aankomen zonder het oorspronkelijke productieverkeer te beïnvloeden. Pas daarna wordt deze vSwitch in het Sophos-script als SPAN-bestemming geselecteerd. Deze ene test bevestigt niet dat de mirroring volledig dekkend is.

2. Het ZIP-bestand uitpakken en het Sophos-script uitvoeren

1. Pak het vanuit Central gedownloade ZIP-bestand uit in een lokale, beveiligde map op de Hyper-V-host. Het bevat virtuele schijven, seed.iso en ndr-sensor.ps1.
2. Start ndr-sensor.ps1 vanuit die map met Run with PowerShell.
3. Controleer bij Security Warning het lokale bestand dat rechtstreeks vanuit Central is gedownload en sta het toe met Open.
4. Voer een unieke VM-naam in.
5. Controleer de weergegeven nieuwe VM-map in het standaardpad voor virtuele schijven en voer C in om deze te laten maken.
6. Geef 4 CPU’s op voor de standaardgrootte of 8 CPU’s voor hoge belasting of SPAN2.
7. Geef 16 GB RAM op als standaardwaarde; overschrijd de Hyper-V-limiet van 32 GB niet.
8. Selecteer in de genummerde vSwitch-lijst eerst de MGMT-vSwitch.
9. Selecteer voor SYSLOG op een uitsluitend voor NDR gebruikte appliance een tijdelijke vSwitch en ontkoppel deze adapter na het maken.
10. Selecteer de voorbereide vSwitch voor SPAN1 en, indien gepland, die voor SPAN2.
11. Wacht op Installation Completed Successfully en druk daarna op een willekeurige toets om het script af te sluiten.
12. Open de nieuwe VM in Hyper-V Manager en controleer vóór het starten de CPU, het RAM-geheugen, de netwerkadapters, de verbonden vSwitches en de ontkoppelde SYSLOG-adapter.

De door Sophos gegenereerde virtuele schijven en seed.iso horen bij elkaar. Vervang afzonderlijke bestanden niet door gelijknamige bestanden uit een oudere download.

Eerste start en deployment-smoketest

Tijdens de eerste start controleert de appliance de toegewezen netwerken en internettoegang en wordt daarna automatisch opnieuw gestart. Dit proces kan tot tien minuten duren.

Onderbreek de eerste start en automatische herstart niet. Als de VM in deze periode handmatig wordt uitgeschakeld, kan deze in een onvolledige toestand achterblijven; dit is geen stap voor probleemoplossing.

Voer de technische deployment-smoketest in deze volgorde uit:

1. VM-console: het opstartproces wordt voltooid zonder aanhoudende fouten of herstartlussen.
2. Beheerpad: het geconfigureerde of gereserveerde MGMT-adres, DNS, NTP en de vereiste uitgaande bestemmingen zijn bereikbaar.
3. Central-controlepad: onder Threat Analysis Center > Integrations > Configured > Integration Appliances of op de NDR-integratiepagina verandert de appliance van Waiting for deployment in Connected.
4. SPAN-pad: genereer voor elk geïmplementeerd SPAN-pad in beide richtingen een aangekondigde, onschadelijke testflow tussen twee bekende testsystemen. Source, Direction en Destination op de switch of hypervisor moeten overeenkomen met de wijziging; op de appliance moet de toegewezen SPAN-adapter verkeer ontvangen.
5. Plausibiliteit: vergelijk het tijdvenster, de bron- en bestemmingsadressen en de richting van de waargenomen testflow. Het betreffende geïmplementeerde pad is voor deze smoketest pas bevestigd als deze waarden overeenkomen.
6. Belasting: vergelijk tijdens een eerste geschikt belastingsvenster de doorvoer, pakketten en flows met het geselecteerde capaciteitsniveau. De status Connected is geen bewijs van voldoende capaciteit.

Voor de deployment-smoketest is geen afzonderlijke kunstmatige detectie vereist. Van belang zijn een stabiel beheerpad en aangetoond bidirectioneel verkeer op de juiste SPAN-interface. De testflow bevat geen malware en geen echte klantgegevens in een Packet Capture.

Deze smoketest bewijst alleen de specifiek geteste paden. De volledige acceptatie van alle beoogde bronnen, VLAN’s, richtingen en verkeersklassen hoort in het afzonderlijke runbook Traffic mirroring voor Sophos NDR plannen en valideren; noch Connected, noch één geslaagde flow geldt hier als bewijs van volledige mirrordekking.

Problemen per symptoom oplossen

De status blijft Waiting for deployment

1. Controleer of de juiste, nieuw vanuit deze configuratie gedownloade image is geïmplementeerd.
2. Controleer de VM-console en energiestatus en laat de eerste start minimaal tien minuten ononderbroken doorgaan.
3. Controleer of de MGMT-vNIC en de poortgroep of vSwitch overeenkomen met de DHCP-reservering of statische velden.
4. Controleer DNS, gateway, NTP, TCP 443, TCP 22 en UDP 123 vanaf het beheernetwerk volgens de allowlist.
5. Implementeer pas na deze controles opnieuw. Op ESXi is hiervoor een nieuw gegenereerde OVA vereist; importeer de al gebruikte OVA niet opnieuw.

Connected, maar geen NDR-verkeer

Op ESXi controleert u eerst de SPAN1-/SPAN2-toewijzing, VLAN ID 4095, Promiscuous mode: Accept, de fysieke uplink en de mirrorbestemmingspoort. Controleer bij gebruik van vMotion of de VM nog steeds draait op de host met de aangesloten SPAN-NIC.

Op Hyper-V controleert het platformteam de SPAN Virtual Interface, NDIS Capture Extension, Source-/Destination-modus en de vSwitch die in het Sophos-script is geselecteerd. Voeg niet op basis van aannames firewallregels of verzonnen mirroringopdrachten toe.

Maak op beide platforms het testfilter niet meteen strenger: controleer eerst de adaptertellers en een duidelijk herkenbare bidirectionele flow. MGMT-verkeer op de MGMT-adapter is geen bewijs dat SPAN werkt.

Slechts één richting of één netwerk is zichtbaar

• De mirrorbron moet zowel de verzend- als de ontvangstrichting omvatten.
• Bij asymmetrische routering kan het retourpad een andere uplink gebruiken.
• Virtueel intern en fysiek extern verkeer kunnen afzonderlijke SPAN-paden vereisen.
• Als SPAN2 is geconfigureerd, moet de tweede vSwitch of poortgroep correct zijn toegewezen en moeten minimaal 8 vCPU’s beschikbaar zijn.

Herhaal na elke correctie exact dezelfde testflow. Zo blijft duidelijk welke wijziging effect had.

Dragonfly blijft Pending

Als Central al Connected is, maar NDR niet werkt, controleert u de status van de service Dragonfly in de Sophos VA Console. Voor deze stap moet lokale consoletoegang zijn ingericht volgens het afzonderlijke runbook De Sophos NDR Integration Appliance en sensor beheren. Gebruik hiervoor niet zonder validatie de aanmeldgegevens van de hypervisor of Central; dit implementatierunbook maakt of vermeldt geen lokale aanmeldgegevens voor de appliance.

Controleer bij Pending in een ESXi-EVC-cluster eerst de EVC-modus en de zichtbare CPU-mogelijkheden. Sandy Bridge wordt voor dit gebruik niet ondersteund; Skylake of nieuwer en pdpe1gb en avx2 zijn vereist.

Controleer op Hyper-V ook Processor Compatibility Mode, de CPU- en RAM-limieten en de topologie met maximaal één NUMA-node en één CPU-socket. Probeer de VM niet te ‘repareren’ door CPU’s of RAM toe te voegen tot boven de ondersteunde limieten.

Onder belasting ontbreken pakketten of resultaten

Vergelijk de huidige doorvoer, pakketten en flows met de capaciteitslimieten. Als een SPAN-bestemming langzamer is dan de gecombineerde bronnen, kan de kopie pakketten verliezen terwijl het productieverkeer ongestoord doorgaat. Beperk in dat geval de bronselectie, verdeel de SPAN-paden of gebruik meerdere appliances. Brede protocoluitzonderingen zijn geen vervanging voor een juiste dimensionering.

Deze implementatie lokaal en beperkt terugdraaien

De volgende stappen zijn een conservatief advies voor het lokaal terugdraaien van de hier beschreven passieve implementatie. Ze vormen geen volledige, door Sophos gedocumenteerde procedure voor buitengebruikstelling of offboarding. Het terugdraaien is bewust beperkt tot de sensor- en mirrorobjecten die als onderdeel van de wijziging nieuw zijn gemaakt:

1. Bewaar het testbewijs en de laatst bekende statusgegevens: Central-status, VM-resources, interfacetoewijzing, mirrorbronnen en -richtingen.
2. Schakel eerst de SPAN- of mirroringsessie op de switch of hypervisor uit. Verwijder daarbij geen productiebronpoorten, VLAN’s of vSwitches en wijzig de productiebekabeling niet.
3. Controleer of het oorspronkelijke verkeer blijft werken en er geen kopieën meer op het NDR-bestemmingspad aankomen.
4. Schakel daarna de NDR-VM gecontroleerd uit.
5. Verwijder afzonderlijke poortgroepen, vSwitches, uplinks of VM-bestanden pas nadat is bevestigd dat ze uitsluitend door deze appliance worden gebruikt. Gedeelde beheer- of productieobjecten blijven bestaan.
6. Draai de statische DHCP-reservering, firewall-allowlist en DNS-records als afzonderlijke wijzigingen terug nadat de verwijzingen zijn gecontroleerd.

De Central-integratie of -appliance wordt als onderdeel van dit lokale terugdraaien niet verwijderd. Een dergelijke verwijdering valt buiten de rollback van deze implementatie en vereist een afzonderlijk gevalideerd en goedgekeurd offboardingproces. Ook geldt een bestaande OVA niet als rollback-image: genereer in Central een nieuwe image voor een nieuwe ESXi-implementatie.

Na een mislukte eerste start is de lokaal beperkte rollback daarom: stop de mirroring, schakel de VM uit, draai uitsluitend de netwerkobjecten terug die duidelijk aan deze wijziging zijn gekoppeld en stel de oorzaak vast vóór een nieuwe implementatie. Zet een passieve NDR-test niet spontaan om naar een ander netwerkontwerp of een inline pad.