Driftsätt Sophos NDR på VMware ESXi eller Hyper-V

Sophos NDR körs på ESXi eller Hyper-V som en virtuell Integration Appliance. Den virtuella datorn behöver två tydligt separerade vägar: MGMT får en vanlig IP-adress och når Sophos Fusion (tidigare Sophos Central) och Sophos Data Lake. SPAN1 och, om det används, SPAN2 tar endast emot speglade kopior av den trafik som ska undersökas. En grön virtuell dator eller Central-statusen Connected bekräftar därför ännu inte att NDR ser paket.

Kort arbetsflöde: Kontrollera krav och kapacitet, skapa NDR-konfigurationen i Sophos Fusion, förbered speglingen för den aktuella plattformen, driftsätt den genererade avbildningen exakt en gång, vänta tills den första starten och den automatiska omstarten är klara och validera sedan hanterings- och SPAN-vägen separat.

Viktig avgränsning: SPAN-vägen är inte inline och får inte användas som hanteringsnätverk. Speglingen konfigureras på switchen och hypervisorn. NDR-appliancen ändrar inte den ursprungliga produktionstrafiken. För Hyper-V anges här medvetet inga externa PowerShell-kommandon för spegling. Implementera designen i Hyper-V enligt godkända anvisningar från Microsoft och Sophos och verifiera den med verklig testtrafik.

Kontrollera de obligatoriska kraven

Till att börja med gäller följande minimikrav för båda plattformarna:

en aktiv behörighet för Sophos Network Detection and Response integration license pack i den tenant som används;
4 vCPU:er, 16 GB RAM och 160 GB lagringsutrymme;
CPU-flaggorna pdpe1gb för Packet Capture och avx2 för maskininlärningsfunktionerna;
ett separat hanteringsnätverk med DHCP eller statisk adress, DNS, standardgateway och utgående internetåtkomst;
förberedda SPAN-vägar för dubbelriktade kopior av alla godkända trafikklasser: virtuell intern trafik och fysisk extern trafik, om båda ingår i den överenskomna övervakningsomfattningen;
dokumenterat ansvar för Central, hypervisorn, fysiska switchar och brandväggens tillåtelselista.

Om det godkända omfånget faktiskt bara innehåller en av dessa trafikklasser ska denna avgränsning dokumenteras uttryckligen. En enskild SPAN-väg får då inte anses täcka den andra klassen.

Installera inte någon ytterligare Sophos Agent eller annan agent mot skadlig kod på appliancen. Sophos hanterar uppdateringar av operativsystem, säkerhet och appliance. Egna krav på patchning eller härdning får inte ändra detta hanterade tillstånd utan föregående validering.

Plattformsgränser

VMware ESXi kräver:

ESXi 6.7 Update 3 eller senare;
VM hardware version 11 eller senare;
EVC-läget Skylake eller senare när Enhanced vMotion Compatibility används;
ingen driftsättning i VMware Cloud eftersom detta inte stöds.

CPU-flaggorna måste förbli synliga i den virtuella datorn även med det valda EVC-läget. En modern fysisk processor är inte tillräcklig om EVC döljer nödvändiga funktioner.

Microsoft Hyper-V kräver:

Hyper-V 6.0.6001.18016, motsvarande Windows Server 2016, eller senare;
inaktiverat Processor Compatibility Mode;
högst 8 CPU-kärnor och 32 GB RAM per virtuell NDR-dator;
högst en NUMA-nod och en CPU-sockel.

Gränserna för Hyper-V är inte en rekommendation att alltid tilldela den virtuella datorn maximala resurser. De förhindrar en NUMA-topologi som inte stöds.

Dimensionera den virtuella datorn efter trafiken

Standardstorleken med 4 vCPU:er är avsedd för en ren NDR-appliance upp till följande riktvärden:

500 Mbit/s,
70'000 paket per sekund,
1'200 flöden per sekund.

För hög belastning upp till 1 Gbit/s, 300'000 paket per sekund eller 4'500 flöden per sekund används 8 vCPU:er. SPAN2 kräver också minst 8 vCPU:er. Om belastningen överstiger dessa värden ska den fördelas på flera NDR-appliances vid lämpliga nätverkspunkter. Utöka inte en enskild virtuell dator utöver de dokumenterade gränserna.

Om ytterligare logginsamlarintegrationer körs på samma appliance måste belastningen från dem planeras separat. NDR reserverar två CPU:er med hög prioritet vid 4 vCPU:er och tre vid 8 vCPU:er. Andra integrationer kan ändå belasta dessa CPU:er. Med 16 GB RAM får logginsamlarintegrationerna tillsammans använda högst 2 GB. Oavsett antalet integrationer tar en appliance emot högst 8'000 logghändelser per sekund. Endast en NDR-integration är möjlig per appliance.

Tillåt utgående anslutningar

Om brandväggen stöder jokertecken behöver appliancen åtkomst till följande mål:

Mål	Port och protokoll
`*.sophos.com`	TCP 443 och TCP 22
`*.amazonaws.com`	TCP 443
`*.ntp.org`	UDP 123
`sophossecops.jfrog.io`	TCP 443
`yum.oracle.com`	TCP 443, valfritt

yum.oracle.com är valfritt eftersom appliancen använder Sophos JFrog-spegel om målet inte kan nås. Utöka inte blint jokertecken till andra zoner. Om brandväggen inte tillåter jokertecken måste den fullständiga aktuella, regionspecifika listan över Sophos-värdnamn läggas till i tillåtelselistan före ändringen och verifieras från MGMT-zonen med DNS- och anslutningstester. En förkortad lista eller en lista som kopierats från en annan region är inte ett säkert alternativ.

Skapa integrationen och avbildningen i Sophos Fusion

Öppna Threat Analysis Center > Integrations > Marketplace i Sophos Fusion.
Välj Sophos Network Detection and Response (NDR).
Klicka på Add Configuration under Data Ingest (Security Alerts).
Ange ett unikt namn och en beskrivning för integrationen i Step 1.
Välj en befintlig appliance eller klicka på Create new appliance i Step 2. En befintlig appliance får inte redan ha en annan NDR-integration.
För en ny appliance anger du ett unikt Appliance name och en beskrivning samt väljer rätt plattform, VMware ESXi eller Microsoft Hyper-V.
Konfigurera antingen DHCP eller Manual under Internet-facing network port settings. En adress som tilldelas via DHCP måste reserveras.
Ange ett Exclusion list name i Step 3. Namnet krävs även om listan till en början är tom.
Slutför genom att klicka på Save.

För Manual fyller du i fälten IP address, Subnet mask, Gateway address, DNS 1 och det valfria fältet DNS 2. Ett internt exempel är:

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

Ersätt dessa värden med lediga adresser och nåbara DNS-servrar i det egna hanteringsnätverket. Kontrollera i förväg den statiska adressen mot DHCP-poolen, IPAM och befintliga värdar.

Under Domain exclusions går det att ange ett domännamn. Protocol exclusions har ett fält för huvudprotokollet, till exempel TCP eller UDP, och ett fält för underprotokollet, till exempel facebook. När båda anges sammanfogar Central dem med en enda punkt. Uteslut inte ett helt huvudprotokoll enbart för att minska datamängden. Varje undantag kräver en bekräftad falsk positiv identifiering eller ett motiverat kapacitetsbeslut samt en ägare och ett granskningsdatum.

Efter att du har sparat väljer du den plattformsspecifika nedladdningen i kolumnen Actions: Download OVA file för ESXi eller ZIP-paketet för Hyper-V. Statusen till vänster om integrationen ändras till Waiting for deployment. Avbildningen innehåller den specifika appliance-konfigurationen och får inte återanvändas mellan olika tenants eller appliances.

Driftsätt på VMware ESXi

1. Förbered SPAN-portgrupper

Skapa en dedikerad portgrupp på den berörda standard-vSwitchen för virtuell intern trafik:

Öppna Networking > Virtual switches och välj avsedd vSwitch.
Klicka på Add port group under Port groups.
Ge portgruppen ett unikt namn.
Ställ in VLAN ID på 4095.
Ställ in Promiscuous mode på Accept under Security.
Spara portgruppen.

För speglad trafik från en fysisk switch används en separat vSwitch med en egen SPAN-portgrupp enligt samma mönster. Tilldela ett ledigt fysiskt nätverkskort med Add uplink under vSwitch topology. Anslut den fysiska switchens dedikerade målsport för spegling direkt till detta nätverkskort på ESXi-värden.

På den fysiska switchen väljer du endast de godkända portarna eller VLAN:en som speglingskällor och väljer båda riktningarna. Målporten överför kopiorna till ESXi-nätverkskortet och får inte samtidigt användas som en vanlig access-, trunk- eller hanteringsport. Den exakta switchsyntaxen är leverantörsspecifik och får inte kopieras från ett exempel för en annan modell.

Om fysisk SPAN och vMotion används tillsammans måste den virtuella NDR-datorn ligga kvar på den ESXi-värd vars fysiska nätverkskort tar emot speglingstrafiken. En oavsiktlig migrering till en annan värd kan obemärkt ta bort SPAN-vägen trots att MGMT fortsätter fungera.

2. Importera OVA-filen och mappa gränssnitten

Den nedladdade OVA-filen är bunden till denna Central-konfiguration och kan endast användas en gång. Generera en ny OVA i Central för en ersättnings- eller nyinstallation.

Öppna Virtual Machines > Create/Register VM på ESXi-värden.
Välj Deploy a virtual machine from an OVF or OVA file.
Ange ett VM-namn och välj ndr-sensor.ova.
Välj Standard som lagringstyp och välj sedan avsett datalager.
Mappa nätverken noggrant under Deployment options:
- SPAN1: den första förberedda SPAN-portgruppen;
- SPAN2: den andra SPAN-portgruppen, om den verkligen behövs;
- SYSLOG: välj en platshållarportgrupp för en ren NDR-appliance och koppla från adaptern efter importen;
- MGMT: hanteringsportgruppen med DHCP eller de statiska nätverksparametrar som angavs i Central.
Ställ in Disk Provisioning på Thin.
Aktivera Power on automatically.
Hoppa över Additional settings utan ändringar och importera genom att klicka på Finish.

Dokumentera återigen mappning, länkstatus och MAC-adresser för alla vNIC:ar innan den virtuella datorn startas för första gången. MGMT får inte ligga i en SPAN-portgrupp. Om SPAN2 används måste den virtuella datorn ha minst 8 vCPU:er.

Driftsätt på Microsoft Hyper-V

1. Förbered speglingsdesignen

Innan skriptet körs måste det vara fastställt vilket syfte varje vSwitch har:

en vanlig vSwitch för MGMT med DHCP eller den planerade statiska nätverksvägen;
en målväg för SPAN1;
valfritt en andra målväg för SPAN2, då med minst 8 vCPU:er;
ingen aktiv SYSLOG-väg, såvida inte samma appliance även bearbetar godkända tredjepartsintegrationer.

För Hyper-V består speglingskonfigurationen konceptuellt av fyra delar: en port för trafikspegling, ett SPAN Virtual Interface anslutet till vSwitchen, den aktiverade Microsoft NDIS Capture Extension samt korrekt inställda speglingslägen för Source och Destination. Implementeringen beror på Windows-/Hyper-V-versionen, typen av vSwitch och källan till trafiken som ska speglas. Därför ska inga obekräftade PowerShell-kommandon från andra miljöer användas.

Innan NDR startas kontrollerar plattformsteamet den avsedda vägen som ett driftsättnings-smoketest med ett känt dubbelriktat testflöde. Kopian måste nå den avsedda målvägen utan att den ursprungliga produktionstrafiken förändras. Först därefter väljs denna vSwitch som SPAN-mål i Sophos-skriptet. Detta enskilda test bekräftar inte fullständig speglingstäckning.

2. Packa upp ZIP-filen och kör Sophos-skriptet

Packa upp ZIP-filen som hämtats från Central i en lokal, skyddad mapp på Hyper-V-värden. Den innehåller virtuella diskar, seed.iso och ndr-sensor.ps1.
Starta ndr-sensor.ps1 i mappen med Run with PowerShell.
Vid Security Warning kontrollerar du den lokala filen som hämtades direkt från Central och godkänner den med Open.
Ange ett unikt VM-namn.
Kontrollera den nya VM-katalog som visas i standardsökvägen för virtuella diskar och låt den skapas med C.
Ange 4 CPU:er för standardstorleken eller 8 CPU:er för hög belastning eller SPAN2.
Ange 16 GB RAM som standardvärde. Överskrid inte Hyper-V-gränsen på 32 GB.
Välj först MGMT-vSwitchen i den numrerade vSwitch-listan.
För SYSLOG på en ren NDR-appliance väljer du en platshållar-vSwitch och kopplar från adaptern efter att den har skapats.
Välj den förberedda vSwitchen för SPAN1 och, om det är planerat, den för SPAN2.
Vänta på Installation Completed Successfully och avsluta sedan skriptet med valfri tangent.
Öppna den nya virtuella datorn i Hyper-V Manager och kontrollera CPU, RAM, nätverkskort, anslutna vSwitchar och det frånkopplade SYSLOG-kortet innan den startas.

De virtuella diskarna och filen seed.iso som Sophos har genererat hör ihop. Ersätt inte enskilda filer med filer med samma namn från en äldre nedladdning.

Första start och driftsättnings-smoketest

Vid den första starten kontrollerar appliancen de tilldelade nätverken och internetåtkomsten och startar sedan om automatiskt. Processen kan ta upp till tio minuter.

Avbryt inte den första starten och den automatiska omstarten. Om den virtuella datorn stängs av manuellt under detta tidsintervall kan den hamna i ett ofullständigt tillstånd. Detta är inte ett felsökningssteg.

Det tekniska smoketestet för driftsättningen utförs i följande ordning:

VM-konsol: Startprocessen slutförs utan en ihållande fel- eller omstartsloop.
Hanteringsväg: Den konfigurerade eller reserverade MGMT-adressen, DNS, NTP och de nödvändiga utgående målen kan nås.
Central-kontrollväg: Under Threat Analysis Center > Integrations > Configured > Integration Appliances respektive på sidan för NDR-integrationen ändras appliancen från Waiting for deployment till Connected.
SPAN-väg: Skapa för varje driftsatt SPAN-väg ett aviserat, ofarligt testflöde i båda riktningarna mellan två kända testsystem. Source, Direction och Destination på switchen respektive hypervisorn måste motsvara ändringen. På appliancen måste den mappade SPAN-adaptern ta emot trafik.
Rimlighet: Jämför tidsfönstret, käll- och måladresserna samt riktningen för det observerade testflödet. Först när dessa värden stämmer är den aktuella driftsatta vägen bekräftad för detta smoketest.
Belastning: Jämför under ett första lämpligt belastningsfönster genomströmning, paket och flöden med den valda dimensioneringsnivån. Statusen Connected är inget kapacitetsbevis.

En enskild artificiell detektering krävs inte för smoketestet av driftsättningen. Det viktiga är en stabil hanteringsväg och verifierad dubbelriktad trafik på rätt SPAN-gränssnitt. Testflödet innehåller ingen skadlig kod och inga verkliga kunddata i en Packet Capture.

Detta smoketest bevisar endast de vägar som faktiskt testades. Fullständig acceptans av alla avsedda källor, VLAN, riktningar och trafikklasser hör hemma i den separata runbooken Planera och validera trafikspegling för Sophos NDR. Varken Connected eller ett enskilt lyckat flöde tolkas här som fullständig speglingstäckning.

Felsök efter symptom

Statusen står kvar på Waiting for deployment

Kontrollera att den korrekta avbildningen, som nyligen hämtades från denna konfiguration, har driftsatts.
Kontrollera VM-konsolen och strömstatusen och låt den första starten pågå i minst tio minuter utan avbrott.
Jämför MGMT-vNIC, portgrupp respektive vSwitch samt DHCP-reservationen eller de statiska fälten.
Kontrollera DNS, gateway, NTP samt TCP 443, TCP 22 och UDP 123 från hanteringsnätverket enligt tillåtelselistan.
Driftsätt på nytt först efter dessa kontroller. På ESXi krävs en nygenererad OVA. Importera inte den redan använda OVA-filen igen.

Connected, men ingen NDR-trafik

På ESXi kontrollerar du först mappningen av SPAN1/SPAN2, VLAN ID 4095, Promiscuous mode: Accept, den fysiska upplänken och målporten för spegling. Om vMotion används ska du kontrollera att den virtuella datorn fortfarande körs på värden med det anslutna SPAN-nätverkskortet.

På Hyper-V kontrollerar plattformsteamet SPAN Virtual Interface, NDIS Capture Extension, Source-/Destination-läget och den vSwitch som valdes i Sophos-skriptet. Lägg inte till brandväggsregler eller påhittade speglingskommandon baserat på antaganden.

Begränsa inte omedelbart testfiltret ytterligare på någon av plattformarna. Kontrollera först adapterräknare och ett tydligt identifierbart dubbelriktat flöde. MGMT-trafik på MGMT-adaptern är inget bevis på att SPAN fungerar.

Endast en riktning eller ett nätverk syns

Speglingskällan måste omfatta både sändning och mottagning.
Vid asymmetrisk routning kan returvägen gå via en annan upplänk.
Virtuell intern och fysisk extern trafik kan kräva separata SPAN-vägar.
Om SPAN2 är konfigurerat måste den andra vSwitchen respektive den andra portgruppen vara korrekt mappad och minst 8 vCPU:er finnas.

Upprepa exakt samma testflöde efter varje korrigering. På så sätt förblir det tydligt vilken ändring som gav effekt.

Dragonfly står kvar på Pending

Om Central redan är Connected men NDR inte fungerar kontrolleras tjänststatusen Dragonfly i Sophos VA Console. Före detta steg måste lokal konsolåtkomst ha upprättats enligt den separata runbooken Hantera Sophos NDR Integration Appliance och sensor. Inloggningsuppgifter för hypervisorn eller Central ska inte återanvändas okontrollerat för detta. Denna runbook för driftsättning skapar eller anger inga lokala inloggningsuppgifter för appliancen.

Vid Pending i ett ESXi EVC-kluster ska du först kontrollera EVC-läget och de synliga CPU-funktionerna. Sandy Bridge stöds inte för denna användning. Skylake eller senare samt pdpe1gb och avx2 krävs.

På Hyper-V kontrollerar du även Processor Compatibility Mode, CPU- och RAM-gränserna samt topologin med högst en NUMA-nod och en CPU-sockel. Försök inte ”reparera” den virtuella datorn genom att lägga till CPU:er eller RAM utöver de gränser som stöds.

Paket eller resultat saknas under belastning

Jämför aktuell genomströmning samt aktuella paket och flöden med dimensioneringsgränserna. Om ett SPAN-mål är långsammare än de sammanlagda källorna kan kopian förlora paket samtidigt som produktionstrafiken fortsätter utan störningar. Begränsa då urvalet av källor, dela upp SPAN-vägarna eller använd flera appliances. Omfattande protokollundantag ersätter inte korrekt dimensionering.

Lokalt avgränsad återställning av denna driftsättning

Följande steg är en konservativ lokal rekommendation för att återställa den passiva driftsättning som beskrivs här. De är inte en fullständig procedur för avveckling eller offboarding som dokumenterats av Sophos. Återställningen begränsas avsiktligt till de sensor- och speglingsobjekt som skapades i samband med ändringen:

Spara testbevis och senast kända tillstånd: Central-status, VM-resurser, gränssnittsmappning, speglingskällor och riktningar.
Inaktivera först SPAN- respektive speglingssessionen på switchen eller hypervisorn. Ta inte bort och koppla inte om produktionskällportar, VLAN eller vSwitchar i samband med detta.
Kontrollera att den ursprungliga trafiken fortfarande fungerar och att inga fler kopior når NDR-målvägen.
Stäng därefter av den virtuella NDR-datorn kontrollerat.
Ta endast bort dedikerade portgrupper, vSwitchar, upplänkar eller VM-filer efter att du har bekräftat att de endast används av denna appliance. Delade hanterings- eller produktionsobjekt lämnas kvar.
Återställ ändringarna av statiska DHCP-reservationer, brandväggens tillåtelselista och DNS-poster separat efter att deras referenser har kontrollerats.

Central-integrationen eller appliancen tas inte bort inom ramen för denna lokala återställning. En sådan borttagning ligger utanför återställningen av driftsättningen och kräver en separat validerad och godkänd offboarding-process. En befintlig OVA behandlas inte heller som en återställningsavbildning. För en ny ESXi-installation genereras en ny avbildning i Central.

Efter en misslyckad första start är den lokalt avgränsade återställningen därför: stoppa speglingen, stäng av den virtuella datorn, återställ endast ändringarna av de nätverksobjekt som entydigt hör till denna ändring och fastställ orsaken före en ny driftsättning. Ett passivt NDR-test ska inte spontant byggas om till en annan nätverksdesign eller en inline-väg.