Migrera SVA-Log Collectors till Sophos XDR Data Collectors

Vid övergången till den utökade Sophos XDR-lösningen provisionerar Sophos en ny XDR Data Collector-konfiguration för lämpliga Log Collectors på Sophos Security Virtual Appliance (SVA). Detta installerar eller aktiverar inte den virtuella datorn automatiskt i den egna miljön. Ersättaren måste driftsättas, Syslog-vägen växlas och nya händelser verifieras. Om IP-adressen är densamma får den gamla collectorn inte vara igång när den nya startas.

XDR Data Collector är en virtuell Syslog-mottagare lokalt eller i AWS, Azure eller GCP. Den vidarebefordrar mottagna loggar till Sophos XDR. En direkt API-integrering behöver inte denna Syslog-mottagare. Integreringsrunbooken förklarar Data Ingest, Response Actions och dessa anslutningstyper.

Om Sophos Next-Gen SIEM redan används rekommenderar Sophos att tidigare SVA-Syslog-collectors ersätts med XDR Data Collectors för att kunna använda hela den datalagringsfunktion som SIEM-produkten stöder. Befintliga API-integreringar behöver inte konfigureras om för detta byte av Syslog-collector. Det innebär varken en viss lagringstid eller rätt till SIEM-datalagring för alla XDR-tenants; villkoren för den egna SIEM-produktens datalagring gäller fortfarande.

Kontrolläge 11 oktober 2026: migreringsguiden från 1 oktober 2026 kompletterar septemberutrullningen. Den tidigare EAP-dokumentationssökvägen anger versionsursprung, inte ett löfte om att alla tenants redan har funktionen. Kontrollera först det tenantspecifika uppgraderingsläget och den collector som faktiskt erbjuds under Security Operations > Integrations > Data Collectors. Runbooken beskriver Syslog-övergången och en konkret lokal driftsättning på vSphere; molnadresser förklaras, men skapandet av respektive molnresurser ingår inte i vSphere-stegen.

Inventera befintliga arbetslaster och inställningar som inte migreras

För varje gammal SVA-collector behövs plattform, namn, värdnamn, statiska nätverksvärden eller DHCP-lease, alla sändande källor samt deras Syslog-mål, port och protokoll. Anteckna även dataformat, val av Event Type, undantag för domäner och protokoll, Passthrough-inställningar och nödvändiga autentiseringsuppgifter. Dokumentera det senaste verifierade datamottagandet per källa; då går det efter övergången att skilja ett inaktivt dataflöde från ett fel.

Collector-namn, värdnamn eller dess härledda värde, statisk IP-adress, nätmask, gateway och DNS eller DHCP-inställningen samt Syslog-port- och protokollmappningar överförs automatiskt. Ursprungliga källportar behålls och mappas till standardportarna för Syslog: UDP/514 respektive TCP/601. Plattformstypen avgör om den nya collectorn är en molncollector eller en lokal collector.

Följande överförs inte automatiskt:

• NDR-integreringar: NDR använder inte Syslog-vidarebefordran. För en SVA med blandade arbetslaster migreras endast Syslog-delen; en ren NDR-SVA får ingen XDR Data Collector för detta ändamål.
• Event Type-filter och undantagslistor för domäner och protokoll.
• SVA-specifika inställningar för Syslog-format och Passthrough.
• Autentiseringsuppgifter för integreringar.
• Investigation Consoles, Nessus Scanner och andra VM-typer utanför SVA-Log Collectors.
• Fysiska hårdvaruappliances: dessa migreras inte automatiskt till virtuella collectors.

Kontrollera uttryckligen vilka filter och format som fortfarande behövs för den nya integreringen och vilken konfiguration anslutningen erbjuder för dem. Saknade filter kan leda till att mer data än avsett samlas in; fel format kan medföra att loggar bara bearbetas som generiska händelser. Kopiera inte autentiseringsuppgifter från ärenden eller gamla skärmbilder, utan tillhandahåll dem på nytt via avsedd hemlighetshantering.

Om NDR körs på samma SVA får Syslog-övergången inte oavsiktligt stänga av sensorn. Alternativet med samma IP kräver att den gamla SVA:n stängs av och avbryter därmed också dess NDR-arbetslast. Planera NDR-driften separat eller välj en annan IP för den nya Syslog-collectorn så att SVA:n kan fortsätta köra NDR. NDR-runbooken behandlar denna arbetslast; provisionering av en Syslog-ersättare är ingen NDR-migrering.

Bestäm adressalternativ före nedladdningen

Måladressen avgör om båda virtuella datorerna får köras samtidigt och om källorna måste ändras.

Vid statisk adress med samma IP måste en kort övergångsperiod planeras: stäng av gamla SVA:n och starta sedan den nya virtuella datorn. Källorna behåller sitt mål. Det garanterar inte en förlustfri övergång; om händelser bevaras under avbrottet beror även på källsystemets buffring och transport.

För ett stegvis byte anges den nya statiska IP-adressen före ISO-nedladdningen. Exempel: gamla collectorn använder 192.0.2.10, den nya 192.0.2.20. Dessa dokumentationsadresser ska inte användas i produktion. Välj i stället en ledig adress i rätt eget nät och kontrollera subnät, gateway, DNS och nåbarhet från källnäten. En ny IP underlättar återställningen och gör det möjligt att växla källor separat, men kräver anpassade mål- och brandväggsregler.

Vid DHCP med återanvändning av gamla IP:n, dokumentera den gamla och nya virtuella datorns MAC-adress, den tidigare IP-reservationen och aktuellt lease-läge före övergången. Ändra eller skapa sedan reservationen så att den nya virtuella datorns MAC-adress tilldelas gamla IP:n; följ det dokumenterade reservations- och lease-förfarandet för den DHCP-plattform som används. Stäng därefter av gamla SVA:n och starta först sedan den nya collectorn. Kontrollera dess faktiska lease och tilldelade IP före godkännande av dataflödet. En reservation hindrar inte en gammal virtuell dator som fortfarande körs från att använda samma adress.

För molncollectors ändras adressen alltid. Vid AWS med CloudFormation finns värdet CTPxCollectorDnsName under Outputs i stacken. Det är DNS-namnet för Network Load Balancer och bör användas för Syslog-källor i stället för en fast angiven IP. Kontrollera VM-nätverksgränssnittets adress i Azure-portalen för Azure, och den interna adressen under Compute Engine > VM instances för GCP. DHCP-adresser kan identifieras i lease-tabellen med den nya MAC-adressen eller via Data Collectors. Förväxla inte denna måladress för källorna med de regionala Sophos-adresserna för uplink.

Förbered nätverksväg och collector-resurser

Uppladdningen från collectorn till Sophos XDR använder mTLS med TLS 1.3 och utgående TCP/443. Det betyder inte att inga inkommande portar behövs: de egna Syslog-källorna måste kunna nå collectorn på konfigurerad port och med konfigurerat protokoll. Standardmålen är UDP/514 och TCP/601; migrerade portmappningar måste dessutom jämföras med tidigare konfiguration. Öppna inte Syslog-mottagaren generellt mot internet.

Tillåt regional uplink, DNS och tidssynkronisering

Följande uplink-mål för collectorn är en ögonblicksbild med kontrolläge 11 oktober 2026. Mappningen US1/US2/US3/EU1/EU2 kommer från XDR-collector-konfigurationen, inte från ett antaget samband med en AWS-Central-region. Använd endast den faktiskt tilldelade regionen. Den befintliga uppsättningen Sophos-IP-adresser för inkommande API-anrop hos tredjepartsleverantören är en annan allowlist.

Om den egna brandväggen kräver IP-baserade tillåtelseregler ingår följande måladresser i ögonblicksbilden. Slå inte ihop regioner:

• US1: 18.217.45.178/32, 3.16.4.173/32, 18.224.219.97/32, 13.59.146.90/32, 3.16.16.254/32, 18.223.74.238/32.
• US2: 52.14.113.127/32, 3.141.73.137/32, 3.136.78.106/32.
• US3: 44.229.101.49, 35.166.77.47, 34.214.135.78.
• EU1: 18.158.143.139/32, 35.159.14.37/32, 52.59.37.234/32.
• EU2: 54.217.251.111/32, 54.194.78.20/32, 52.50.215.147/32.

Jämför region och målvärden med aktuell tenant-konfiguration och den collector-safelist som driftansvarig underhåller före en produktionsändring. Avvikelser hör hemma i en granskad ändring, inte i en bredare tillåtelseregel i förebyggande syfte. Den tekniska endpoint-stavningen secureworks.com förblir oförändrad.

Collectorn behöver också UDP och TCP/53 till de DNS-servrar som angavs vid provisioneringen. För tidssynkronisering behövs UDP/123 till valda NTP-servrar. Utan egna NTP-inställningar använder collectors utanför AWS 0.pool.ntp.org till 3.pool.ntp.org; för AWS är standardmålet 169.254.169.123. Vid lokal NTP måste trafik mellan collector och tidsserver vara tillåten i båda riktningarna. För den lokala collectorn används dessa NTP-värden vid uppstarten; efter anslutningen tar XDR-backend-kanalen över tidssynkroniseringen. Enligt plattformsguiden är Windows-domänkontrollanter inte lämpliga NTP-mål för denna värd som inte är domänansluten.

En forward-webbproxy kan anges via Host Proxy. Collector-översikten utesluter fast konfigurerade autentiserade proxyservrar, medan anvisningen för lokal driftsättning även visar URL-syntax med användare och lösenord. Uppgifterna stämmer inte överens. Planera därför ingen autentiserad proxyväg i produktion utan klarlagt godkännande från Sophos; kringgå inte konflikten genom att bädda in autentiseringsuppgifter i ISO-filen. Vid TLS Inspection måste den konkreta mTLS-uplinken fungera utan MITM-ingrepp. Begränsa ett undantag till de collector-anslutningar som behövs.

Dimensionera inte den lokala virtuella datorn efter gamla SVA-värden

Den nya lokala virtuella datorn behöver 4 vCPU:er på minst 2 GHz, 8 GB RAM, en systemdisk på 20 GB och en datadisk på 200 GB. Plattformsguiden anger vSphere ESXi 6.7 eller senare, Hyper-V 8.0 på Windows Server 2016 eller senare samt Nutanix 6.8.x eller senare som rekommenderade miljöer. Den virtuella datorn måste kunna se x86-64-v2-CPU-funktioner; en olämplig CPU-kompatibilitetsmask kan hindra starten.

Angivelsen upp till 200 000 EPS är en övre gräns för lämpligt konfigurerade molncollectors och lokala collectors, ingen genomströmningsgaranti för dessa minimiresurser. Dimensionera efter händelsernas antal, storlek och toppbelastning och kontrollera det faktiska dataflödet. Inga tredjepartsverktyg eller ytterligare applikationer får installeras på collectorn. Uppdateringar sker automatiskt, vanligtvis var 24:e timme när anslutningen fungerar.

Driftsätt den förprovisionerade lokala collectorn på vSphere

Använd den tillhörande konfigurationen under Security Operations > Integrations > Data Collectors för en befintlig migrering. Jämför namn, nätverksvärden och Syslog-mappningar med gamla SVA:n. Ladda ner ISO med collector-konfigurationen och OVA för den virtuella datorn. De hör ihop; en annan collectors ISO skulle provisionera fel tillstånd. Förvara konfigurationsfiler med begränsad åtkomst.

Om konfigurationen saknas, kontrollera först undantag och nätverksfel i nästa avsnitt. För en avsiktligt manuellt skapad ersättare erbjuder gränssnittet Actions > Add Collector > On-Premises > Next. Ange namn och värdnamn samt vid behov beskrivning, Host Proxy och NTP, och antingen DHCP eller fullständiga statiska nätverksvärden, och skapa den med Create Collector. Detta är ingen anledning att skapa en okontrollerad dubbelcollector bredvid en redan befintlig migrering.

Driftsättningen på vSphere sker så här:

1. Öppna Virtual Machines > Create / Register VM i vSphere Web Console och välj Deploy a virtual machine from an OVF or OVA file.
2. Ange ett entydigt VM-namn, exempelvis sophos-xdr-collector, och välj den nedladdade OVA-filen. Namnet kan väljas fritt; det ska skilja den virtuella datorn från gamla SVA:n i hypervisorn.
3. Välj en Datastore med minst 220 GB ledigt utrymme för de två diskarna. Kontrollera nätverkstilldelning och diskkonfiguration, granska sammanfattningen och slutför med Finish. Låt den virtuella datorn vara avstängd tills vidare.
4. Ladda upp rätt konfigurations-ISO under Storage > Datastore Browser.
5. Öppna Edit Settings för den virtuella datorn. Ändra CD-ROM från Client Device till Datastore ISO File, välj den uppladdade ISO-filen och spara. Kontrollera före första starten att ISO-filen faktiskt är ansluten och att den virtuella datorn når rätt källnät.
6. Om IP-adressen är densamma, stäng nu av gamla SVA:n. Starta först därefter den nya virtuella datorn. Vid ny IP får gamla SVA:n fortsätta köras; källorna växlas sedan separat.
7. Vänta under Security Operations > Integrations > Data Collectors tills den nya collectorn visar Ready. Först då får ISO-filen kopplas bort. Ready bekräftar inte ännu att varje källa tas emot korrekt.

För Hyper-V tillhandahåller Sophos ett VHD-paket i stället för OVA, och för Nutanix QCOW2-filer; den andra datadisken och ISO-filen som är ansluten vid första starten behövs fortfarande. vSphere-klickföljden ska inte överföras till dessa plattformar. Molncollectors ska på samma sätt driftsättas med respektive plattformsresurser, inte som OVA i vSphere.

Växla källor och godkänn dataflödet

Om måladressen har ändrats, ställ om alla berörda enheter och applikationer till den nya collector-IP:n eller det nya DNS-namnet. Ändra endast målet, inte port, protokoll eller loggformat utan granskning: dessa mappningar ska ha överförts från SVA:n. Om en källa tidigare skickade via UDP/514 behålls UDP/514 för denna migrering. En transportändring till TCP är en separat ändring med kontroll av källsystemet.

Vid olika IP-adresser, växla först en källa som är enkel att överblicka. Skapa där en ofarlig händelse som anslutningen registrerar och anteckna källa, händelsetyp och tidpunkt med tidszon. Sök efter den i XDR via den datavy eller frågeväg som erbjuds för integreringen. Underlaget måste visa rätt tenant, källa, tidsstämpel och händelseformat. Ta hänsyn till anslutningens förväntade fördröjningar; en testhändelse behöver inte skapa ett Case eller en Detection.

Växla övriga källor först efter denna kontroll. Jämför de sista händelserna före och de första efter övergången per källa. Samma tidsintervall eller händelsefrekvens kan inte förväntas för alla källor; det avgörande är deras faktiska aktivitet och att inga oförklarade tidsluckor finns. Undvik oplanerad samtidig sändning av samma dataflöde till båda collectors, eftersom detta kan skapa dubbletter.

Den tidigare SVA:n kan fortsätta arbeta under planeringen. Historiska SVA-data som redan har samlats in kan fortfarande frågas ut i XDR; ersättaren behöver inte skicka dem igen. Det innebär inget nytt löfte om obegränsad lagring. Den nya collectorns spool på 200 GB buffrar loggar vid långsam eller tillfälligt avbruten uplink. Den ersätter varken källkontroll eller en garanti för godtyckligt långa avbrott.

Driftgodkännande uppnås först när alla förväntade källor levererar aktuella, korrekt tilldelade data, filter och undantag har granskats medvetet, DNS, tidssynkronisering och uplink fungerar och eventuell NDR fortsätter fungera separat. Dokumentera övergångstidpunkt och observationsperiod. Behåll gamla SVA:n och dess konfiguration för en möjlig återställning fram till dess; besluta först därefter om dess kvarvarande arbetslaster och säker avveckling.

Avgränsa fel och återställ utan IP-konflikt

Ingen ny collector finns: en hårdvaruappliance, ren NDR-SVA eller VM som inte är en SVA migreras inte automatiskt. För en aktivt använd Syslog-SVA, kontrollera att port och protokoll är konfigurerade och att de statiska nätverksvärdena är fullständiga. Saknade gateway- eller DNS-värden kan hindra migreringen. Korrigera ogiltig nätverkskonfiguration i Fusion och klargör med supporten hur migreringen kan upprepas, eller skapa en uttryckligen planerad manuell collector. Använd inga platshållaradresser bara för att ett formulär ska accepteras.

Den nya virtuella datorn startar inte: kontrollera ISO-tilldelning, andra disk, RAM, vCPU:er och de x86-64-v2-funktioner som den virtuella datorn kan se. Installera ingen reparations- eller övervakningsprogramvara på collectorn.

Collectorn förblir offline: kontrollera först faktisk tilldelad IP eller lease, gateway, DNS och tidssynkronisering vid uppstarten. Kontrollera sedan brandväggs- och proxyloggar för regional TCP/443-uplink. En öppen utgående port bevisar inte i sig en fungerande mTLS-kanal. Vid samma IP, säkerställ dessutom att gamla SVA:n verkligen är avstängd.

Collectorn är Ready men en källa saknas: kontrollera källans måladress, route och inkommande Syslog-port. Jämför portmappning och format med den gamla integreringen. En föregående loggvidarebefordrare måste bevara det förväntade integreringsformatet; annars kan data komma in som generiska händelser i stället för i det förväntade schemat. Verifiera först datavägen, sök sedan efter en Detection.

Vid återställning måste statiska adresser och DHCP-reservationer behandlas separat:

• Statisk adress med samma IP: stäng av den nya virtuella datorn och starta först därefter gamla SVA:n med dess bevarade statiska konfiguration. Källorna behåller sitt tidigare mål. Kontrollera att gamla SVA:n faktiskt använder denna IP och tar emot och vidarebefordrar nya Syslog-händelser. Starta aldrig båda virtuella datorerna med denna adress.
• DHCP-reservation för samma IP: stäng först av den nya virtuella datorn. Koppla därefter reservationen för gamla IP:n tillbaka till den dokumenterade gamla SVA-MAC-adressen och hantera lease-läget enligt den egna DHCP-plattformens dokumenterade förfarande. Inget universellt kommando för att radera lease förutsätts här. Starta först därefter gamla SVA:n, kontrollera dess faktiska lease och IP och verifiera mottagning och vidarebefordran med en ny Syslog-händelse. Källorna behåller sitt tidigare mål; att enbart starta SVA:n bevisar därför inte en fungerande återställningsväg. Starta aldrig båda virtuella datorerna med denna adress.
• Annan IP eller annat DNS-mål: återställ de dokumenterade källmålen och vid behov tillhörande nätverksregler till gamla collectorn. Kontrollera med en ny händelse att gamla SVA:n tar emot och vidarebefordrar igen. Avveckla den nya collectorn först när alla tilldelningar har granskats.

Återställningen är godkänd först när gamla SVA:n bevisligen har den avsedda måladressen och nya Syslog-händelser åter tas emot och vidarebefordras.

Återställningsvägen fungerar bara så länge gamla SVA:n finns kvar och dess konfiguration har bevarats. Den återställer inte leverantörens produktuppgradering och garanterar inte återhämtning av händelser som inte levererats. Sophos aviserar ett senare slut på supporten för SVA-Log Collectors, men anger inget konkret datum i det migreringsläge som granskats här. Nya Log Collector-instanser ska efter migreringen skapas som XDR Data Collectors; gamla SVA:n är därför en begränsad återställningsväg för befintlig drift, ingen långsiktig nyinstallationsstrategi.

Om orsaken förblir oklar, samla collector- och tenant-identitet, plattform, nätverksvärden utan känsliga uppgifter, berörd källa, exakta tidsfönster, status och felmeddelande. För eskalering gäller Öppna ett Sophos-supportärende. Hemligheter, konfigurations-ISO och loggdata med känsliga uppgifter hör inte hemma i fritt tillgängliga ärenden eller skärmbilder.