Diagnostisera Sophos NDR Integration Appliance och sensorn

Den här runbook-artikeln avgränsar fel i NDR Integration Appliance och NDR-sensorn. Den börjar med exakt status i Sophos Fusion, tolkar synliga status- och mätvärden och visar när loggar måste samlas in för Sophos Support.

Statusen Connected eller grön är endast en delkontroll. Den bevisar varken fullständig speglingstäckning, lyckad uppladdning av varje datapost eller fungerande end-to-end-detektering.

Snabbt arbetsflöde

1. Dokumentera appliance-namn, System ID, felets starttid med tidszon och exakt meddelandetext.
2. Kontrollera färg och appliance-status i Sophos Fusion, men starta inte om något ännu.
3. Läs Status, NDR, Integrations och Advanced i Appliance Manager och skapa skärmbilder med tidsstämpel.
4. Hänför symptomet till en felklass: plattform/CPU, egress/uppladdning, SPAN, registrering eller delade resurser.
5. Genomför endast en reversibel korrigering inom den felklassen.
6. Kontrollera samma mätpunkter igen under jämförbar belastning.
7. Samla in loggar och eskalera vid motstridiga signaler, containrar som inte är redo eller utebliven effekt.

Symptom, kontroll och nästa steg

Tolka rött, gult och grönt korrekt

Rött: integrationen fungerar inte

Vid rött är det konkreta meddelandet viktigare än färgen:

• NDR containers not ready, <specific container names>. betyder att minst en nödvändig applikation inte är redo. Om dragonfly nämns eller har avvikande synlig status börjar kontrollen med CPU-kompatibilitet och plattformskrav.
• Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error> betyder att appliance försökte ladda upp via en försignerad URL till en S3-bucket och fick en felkod. Detta är främst en egress-/proxyfelklass.
• spanX: unhealthy span hänför störningen till ingången på den angivna SPAN-porten. Kontrollera först den sändande nätverkskomponenten eller den virtuella speglingsvägen.

Gult: integrationen fungerar med fel

spanX: packets being dropped visas när mer än 10 % av nätverkspaketen tappas. Paketinsamling och bearbetning är CPU-intensiva. En VM kan behöva fler vCPU:er. På certifierad maskinvara kan belastningen fördelas till ytterligare en appliance enligt godkänd täckningsplan. Log Collectors som körs gemensamt kan belasta samma resurser ytterligare.

En kapacitetsändring åtgärdar dock inte överlappande speglingskällor, en övertecknad målväg eller felaktig SPAN-konfiguration. Jämför därför trafikprofil och topologi före skalning.

Grönt: inget integrationsfel rapporteras för närvarande

Grönt betyder att NDR tar emot SPAN-trafik och bearbetar paketdata utan rapporterat problem. Den aktuella klassificeraren för en felfri SPAN-port kräver minst 2 % unicast-paket. Det bevisar inte att alla önskade VLAN, platser, riktningar eller tidsfönster samlas in. Det äldre påståendet att en port måste visa 100 % unicast används inte.

Detaljerad tolkning av hälso- och kapacitetssignaler finns i ”Övervaka hälsa och kapacitet för Sophos NDR”.

Om förväntade Detections fortfarande saknas trots grönt genomför du först den säkra NDR-testdetekteringen. Om även detta bevis saknas och ett VLAN-problem misstänks sparar du tidsfönster, SPAN-port, valt VLAN och synlig appliance-status för Sophos Support. VLAN Strip får endast ändras när analysen bekräftar att både valt VLAN och VLAN0 når sensorn. Annars ska inställningen förbli oförändrad.

Avgränsa lokala händelser med NDR Query

När Capture och Upload behöver kontrolleras separat kan NDR Query i Appliance Manager visa den lokala händelsenivån. Frågan körs mot NDR-händelsedatabasen på denna appliance-VM, inte mot Sophos Data Lake. Den måste tydligt skiljas från den separat distribuerade Investigation Console, som tillhandahåller data från en tilldelad NDR Appliance för Threat Hunting i det lokala nätverket.

1. Dokumentera berörd appliance och felets tidsfönster.
2. Öppna NDR Query och välj Example queries under Query.
3. Kopiera en lämplig fördefinierad fråga med Copy, klistra in den i textfältet och kör den med Go.
4. Spara resultatet under Query Results med tidsstämpel. Ordna kolumnerna med dra och släpp vid behov.
5. Jämför resultatet med aktiviteten under NDR och Fusion-statusen för samma tidsfönster.

Appliance Manager stöder för närvarande endast fördefinierade frågor här. Använd ingen egen SQL-fråga och ingen fråga från Investigation Console. Ett lokalt resultat när data saknas i Fusion leder den fortsatta kontrollen till Upload och Egress. Ett tomt lokalt resultat leder den först till SPAN-ingång, tidsfönster och val av fördefinierad fråga. Resultatet är inte ensamt ett bevis på fel.

Bedöm oväntade Nmap-Detections

Om nya Nmap-baserade OS-skanningar uppträder i andra säkerhetsprodukter kontrollerar du status för OS Detection under Global NDR Settings. Alternativet är avstängt som standard och skannar efter aktivering varannan timme varje intern IP-adress som NDR har sett. Detta kan utlösa Detections i andra säkerhetsprodukter.

Jämför aktiveringstidpunkt, berörd appliance, mål-IP-adresser och tidsstämplar för Detections. Om aktiveringen inte är godkänd, målen är otillåtna eller driftpåverkan uppstår stänger du av OS Detection igen och dokumenterar tidpunkten. Övervaka sedan att inga nya skanningshändelser som har utlösts av funktionen tillkommer. Hantera redan befintliga meddelanden enligt processen för respektive verktyg. Upprepa inga Nmap-kommandon manuellt och skapa inga undantag i andra säkerhetsprodukter enbart för att dölja symptomet. Om funktionen ska förbli aktiverad krävs ett dokumenterat godkännande från nätverks- och säkerhetsansvariga samt validering under minst ett fullständigt tvåtimmarsintervall.

Avgränsa container- och Dragonfly-symptom utan CLI

Dragonfly bearbetar NDR-data. Två synliga mönster är relevanta för diagnostiken:

• Ett rött meddelande om containrar som inte är redo kan visas när dragonfly fastnar i en omstartsloop på grund av att nödvändiga CPU-instruktioner saknas.
• Om appliance är Connected i Fusion men data inte når Data Lake och Dragonfly står på Pending under Advanced, måste EVC-läget kontrolleras i ett VMware EVC-kluster. Sophos kräver Skylake generation or later; Sandy Bridge stöds inte.

För virtuella NDR-enheter på VMware ESXi eller Hyper-V måste CPU-flaggorna pdpe1gb och avx2 vara tillgängliga. pdpe1gb krävs för paketinsamling och avx2 för maskininlärningsfunktioner. Fler vCPU:er kompenserar inte för flaggor som saknas. Processor Compatibility Mode stöds inte på Hyper-V. För ESXi gäller dessutom VM Hardware Version 11 eller senare samt de dokumenterade plattformskraven.

Säker kontroll:

1. Dokumentera status och synligt namn på berörd container under Advanced.
2. Dokumentera CPU-belastning, Memory, Root Disk och Data Disk under Status.
3. Jämför hypervisor, CPU-modell, EVC- eller Compatibility-inställning och flaggorna som VM:n får med godkänd plattformsdokumentation.
4. Korrigera en felaktig hypervisor-/CPU-inställning endast i ett planerat underhållsfönster. Dokumentera först utgångsvärde och återgångsväg.
5. Validera därefter VM- och appliance-status via de ordinarie driftgränssnitten.
6. Skapa loggpaket och eskalera om dragonfly förblir Pending, en container inte blir redo eller en omstartsloop är synlig.

Plattformsvärden och CPU-krav sammanfattas i ”Sophos NDR: välj plattform och dimensionera sensorn korrekt”.

Kontrollera S3-uppladdning och utgående anslutning

Ett S3-uppladdningsfel betyder inte att ingen SPAN-trafik kommer fram. Capture och Upload är två separata steg. Spara därför Capture-/Flow-aktivitet och Uploaded för samma tidsfönster under NDR i Appliance Manager.

Kontrollera egressvägen i denna ordning:

1. Stämmer MGMT-IP-konfigurationen – DHCP eller manuell – med hanteringsnätverket?
2. Fungerar DNS-upplösning och NTP via avsedda tjänster?
3. Går Default Route via avsedd internet- eller central egressväg?
4. Tillåter Network ACL, Security Group eller lokal brandvägg utgående HTTPS-trafik?
5. Tillåter Web Proxy appliance och nödvändiga mål utan att ändra eller blockera den försignerade S3-begäran?
6. Stämmer reglerna med Sophos aktuella port- och domänundantag?

Listan över regionsberoende domäner utan jokertecken ska inte kopieras från gamla ärenden. Jämför den vid kontrolltillfället med aktuella Appliance requirements. En tillfällig bred internetregel är inget säkert test. Gör ändringarna var för sig och validera efter varje steg med samma feltidsfönster.

Återställning: En proxy-, ACL- eller brandväggsregel som ändrats för test ska återställas till utgångsvärdet efter kontrollen om den inte krävs permanent. Vid återställningen måste andra integrationers tidigare fungerande hanterings- och uppladdningsvägar förbli intakta.

SPAN unhealthy, Packet Drops eller saknade Flows

spanX: unhealthy span

Kontrollera för exakt den angivna porten:

• förväntad speglingskälla och riktning,
• dedikerat målgränssnitt och fysisk kabeldragning,
• tilldelning av insamlings-NIC, portgrupp eller vSwitch,
• mål-IP, routing, MTU samt GRE- eller VXLAN-värden vid ERSPAN,
• senaste ändringar av VLAN, trunk, portgrupp, värdplacering eller speglingssession,
• om målet av misstag åter speglas som källa.

Skapa känd, ofarlig unicast-trafik med en pilotvärd och observera avsedd SPAN-port och flödesförlopp i samma tidsfönster. Om aktivitet saknas ska diagnostiken stanna vid källa, riktning, filter, transport eller insamlingstilldelning. Bedöm bearbetning och uppladdning först när ingången är bevisad.

spanX: packets being dropped

Vid mer än 10 % paketförlust dokumenteras dessutom:

• tilldelade vCPU:er och CPU per kärna,
• bandbredd, paket/s och flöden/s,
• nyligen tillagda eller överlappande speglingskällor,
• Memory samt trend för Root Disk och Data Disk,
• samtliga Log Collectors på samma appliance med Received, Filtered, Accepted och Uploaded.

För en delad appliance börjar dimensioneringen med NDR. Därefter beaktas collectorbelastningen. Ytterligare gränssignaler är högst 8'000 collector-händelser per sekund för hela appliance och, vid 16 GB RAM, högst 2 GB för Log Collectors. Även CPU-kärnor som NDR gör anspråk på kan delas med andra integrationer och därmed påverka NDR-kapaciteten. Om collectorbelastning måste fördelas fastställer du först ansvar och mål-appliance och använder den generiska integrationsguiden. Den här runbook-artikeln ändrar inga tillverkarspecifika Syslog-källor.

Med 4 vCPU ligger typiskt en kärna på 100 % på grund av DPDK; med 8 vCPU ligger två kärnor på 100 %. Det är i sig normalt. Ett kapacitetsfel styrks av kombinationen med paketförlust, ytterligare belastade kärnor, sjunkande uppladdning eller förändrat flödesförlopp.

Speglingskedjan, pilotvalideringen och en avgränsad återgång beskrivs i ”Planera och validera trafikspegling för Sophos NDR”.

Diagnostisera registrering och Connected

En ny appliance visas först som Waiting for deployment. Efter lyckad bootstrap och hanteringsväg ändras statusen under Threat Analysis Center > Integrations > Configured > Integration Appliances till Connected.

Om detta inte sker:

1. identifiera rätt appliance med namn, plattform och genererad avbildning eller seed,
2. kontrollera VM-start efter bestående fel- eller omstartsloopar,
3. kontrollera MGMT-IP, VLAN, DHCP eller manuella värden, gateway och DNS,
4. kontrollera NTP och nödvändig egress mot aktuella appliance-krav,
5. använd på ESXi OVA-filen från Fusion endast för ett driftsättningsförsök. Följ aktuellt driftsättningsförlopp för andra plattformar.
6. dokumentera tidpunkt, synlig status och senaste bootstrap-utdata utan hemligheter.

Ta varken bort eller installera om appliance. Den här runbook-artikeln innehåller medvetet inget förfarande för nedmontering eller ersättning. Connected bekräftar central anslutning och tilldelning, inte SPAN-täckning, uppladdning eller detektering.

Om appliance tidigare var Connected och förlorar statusen kontrolleras först hanteringsväg, egress och appliance-tillgänglighet. Speglingsinställningar är inte första åtgärd eftersom SPAN och hantering är separata vägar.

Kontrollera åtkomst till Appliance Manager i stället för sensorfel

Om Open Appliance Manager öppnas men inloggning med zadmin misslyckas är detta först ett inloggningsproblem, inte bevis på SPAN-, uppladdnings- eller Dragonfly-fel. Använd länken reset it i bekräftelsedialogen för Open Appliance Manager om lösenordet är glömt och ange ett nytt lösenord. Lägg det nya lösenordet direkt i lösenordssystemet. Varken det gamla eller det nya lösenordet hör hemma i en skärmbild, driftlogg eller ett Support Case.

Om kontot har låsts på grund av för många felaktiga lösenordsförsök är den dokumenterade alternativa vägen webbkonsolen för den hypervisor som är värd för appliancen. Välj där Unlock Account i Weblink interface. Denna reservväg förutsätter redan behörig åtkomst till hypervisorns webbkonsol. Den här runbook-artikeln lägger inte till shell-, SSH- eller konsolkommandon och härleder ingen annan åtkomstväg från detta. Prova därefter inloggningen en gång med det säkert lagrade lösenordet. Om kontot fortfarande är låst ska du inte prova fler lösenord. Dokumentera i stället tidpunkt och synligt meddelande och kontakta Sophos Support.

Offline-konfiguration av Management som sista lokala återställningssteg

Actions > Settings > Management i Appliance Manager får endast ändras lokalt när VM:n saknar nätverksanslutning. Om anslutningen fungerar ska ändringen göras i Sophos Fusion. Att VM:n är offline skapar inte i sig en ny åtkomstväg. Den lokala korrigeringen förutsätter ett redan befintligt och godkänt återställningsförfarande. Utan sådan åtkomst sparar du aktuell MGMT-IP, senast kända Fusion-status och plattformsdata och eskalerar ärendet.

Jämför före Save gamla och nya värden för IP Assignment, IPv4/Netmask, Gateway IP, DNS, DNS 2 samt vid behov Enable Web Proxy, Web Proxy Type, Proxy URL och Port Number. Proxyautentiseringsuppgifter ska stanna i lösenordssystemet. Ändra endast det värde som bevisligen är felaktigt. Om gränssnittet kräver en bekräftelse för omstart är detta en omstart av appliancen: NDR och alla Log Collectors avbryts. Dokumentera därför först gemensamma arbetslaster, underhållsfönster, förväntad ny IP-adress och återgångsväg.

När ändringen har trätt i kraft kontrollerar du åtkomst på den nya IP-adressen, Fusion-status, NDR Capture och Upload samt alla Log Collectors. Om den godkända återställningsåtkomsten fortfarande finns och kontrollen misslyckas återställer du exakt den senaste ändringen till de registrerade utgångsvärdena. Om gränssnittet inte längre kan nås ska du inte gissa adresser eller proxyvärden. Eskalera med baslinje, tidpunkt och påverkan. Fullständig för- och efterkontroll finns i ”Säker drift av Sophos NDR-appliance och sensor”.

Skydda andra integrationer på en delad appliance

Fäll ut pilen vid appliance-namnet i Fusion och dokumentera alla integrationer på samma appliance före Restart eller resursändring. Under Integrations i Appliance Manager visas deras status, senaste omstart och Syslog-räknare.

• En enskild Log Collector kan startas om separat med Restart; NDR och andra integrationer fortsätter.
• Restart All påverkar alla Log Collectors men inte NDR.
• Restart NDR påverkar NDR-sensorn men inte Log Collectors.
• Actions > Restart påverkar hela VM:n och avbryter NDR och alla Log Collectors.
• Actions > Shutdown stoppar hela VM:n och alla integrationer; en separat verifierad startväg krävs.

En bred VM-omstart är inte det första diagnostiksteget. Dokumentera först status och mätvärden och avgör den minsta berörda komponenten. Påverkan och säker driftordning beskrivs i ”Hantera Sophos NDR Appliance och sensor säkert”.

Samla in diagnostikdata och loggar

Baspaket

Dokumentera före en ändring:

• appliance-namn, System ID, Version, K3S Helm Chart version och Uptime,
• Fusion-status och exakt feltext,
• start, reproduktionstidpunkt och tidszon,
• CPU per kärna, Memory, Root Disk och Data Disk under Status,
• Capture per konfigurerad SPAN-port, Uploaded och flödesförlopp under NDR,
• alla Log Collectors på samma appliance med status och räknare under Integrations,
• synlig containerstatus och senaste synliga omstartstid under Advanced,
• plattform, VM-resurser, trafikprofil och senaste ändringar,
• förväntat och faktiskt resultat samt verksamhetspåverkan.

När Appliance Manager inte kan nås

1. Öppna Threat Analysis Center > Integrations > Configured > Integration Appliances i Fusion.
2. Välj Collect logs i trepunktsmenyn för berörd appliance.
3. Öppna informationsmeddelandet i kolumnen Log requested och anteckna filnamnet som visas.
4. Överlämna filnamnet tillsammans med appliance, tidsfönster och feltext till Sophos Support.

När Appliance Manager kan nås

1. Välj Open Appliance Manager i trepunktsmenyn och sedan Open.
2. Välj Actions > Download Log File i Appliance Manager.
3. Överför loggarkivet till befintligt Case endast genom överenskommen supportkanal.

Loggarkiv kan innehålla IP-adresser, värdnamn och andra känsliga driftdata. zadmin-lösenord, tokens, privata nycklar, proxyautentiseringsuppgifter och andra hemligheter får aldrig finnas i ärende, skärmbild eller bilaga.

Ge Remote Assistance kontrollerat

Aktivera Remote Assistance endast för ett konkret supportärende. Appliance måste vara online.

1. Öppna Threat Analysis Center > Integrations > Configured > Integration Appliances i Fusion.
2. Välj Remote Assistance i trepunktsmenyn.
3. Aktivera Enable i dialogrutan.
4. Markera bekräftelsen för Sophos Group Privacy Notice och välj Save.
5. Vänta tills Access ID visas.
6. Skicka endast detta Access ID till Sophos Support genom överenskommen kanal.

Åtkomsten upphör automatiskt senast efter sju dagar. Om analysen avslutas tidigare inaktiverar du Enable i samma dialogruta och dokumenterar sluttiden. Remote Assistance ersätter varken ett Support Case eller diagnostikpaketet.

Validera och återställ korrigeringen säkert

Ändra endast en hypotes per genomgång. Dokumentera utgångsvärde, ansvarig person, underhållsfönster och återgångsväg i förväg. Kontrollera därefter under jämförbar belastning att:

• föregående röda eller gula meddelande inte återkommer,
• förväntad appliance-status och hanteringsväg är stabila,
• varje avsedd SPAN-port visar aktivitet som motsvarar pilottrafiken,
• flödesförlopp och uppladdning förblir stabila under ett representativt tidsfönster,
• inget meddelande om mer än 10 % paketförlust återkommer,
• CPU utanför förväntade DPDK-kärnor, Memory och Storage har tillräcklig marginal,
• alla Log Collectors på samma appliance fortsätter att bearbeta data,
• en plattformsändring tillhandahåller nödvändiga CPU-flaggor och ett läge som stöds.

Om efterkontrollen misslyckas eller nya effekter uppstår återställer du exakt den senaste ändringen. Om utgångsläget inte kan återställas ska inga fler ändringar göras. Samla in diagnostikdata och öppna ett ärende hos Sophos Support.

En grön integration efter den tekniska korrigeringen är fortfarande inget bevis på detektering. Använd först efter en stabil speglings- och uppladdningskedja ”Skapa och verifiera en säker Sophos NDR-testdetektering”.

Eskalera till Sophos Support

Öppna ett ärende hos Sophos Support när:

• NDR containers not ready kvarstår eller dragonfly synligt förblir Pending eller i en omstartsloop,
• nödvändiga CPU-flaggor inte är tillgängliga trots korrekt plattform,
• ett S3-uppladdningsfel kvarstår trots bekräftad DNS-, proxy-, brandväggs- och egressväg,
• spanX: unhealthy span kvarstår trots verifierad källa, riktning och måltilldelning,
• Packet Drops återkommer efter lämplig kapacitets- eller belastningsfördelning,
• Connected, lokal uppladdning och mottagning i Data Lake motsäger varandra,
• bootstrap inte når registrering eller appliance oväntat växlar mellan statusar,
• en säker korrigering skulle kräva lågnivåingrepp i containrar, Kubernetes eller Dragonfly.

Skicka baspaketet, loggfilnamnet eller loggarkivet, exakta steg och mätbara resultat i ärendet. Ange tydligt vilka hypoteser som redan har avfärdats. Sophos Support hanterar produktproblem inom installation, administration och drift; ärendet är inte ett uppdrag att undersöka en Detection.

En XDR-baserad Self-managed Detection förblir kundens ansvar. Endast ett MDR Case som hanteras av Sophos undersöks och besvaras av Sophos MDR. Se ”Öppna Sophos-supportärende med Support Assistant” för hur ärendet skapas och eskaleras.