Övervaka hälsa och kapacitet för Sophos NDR

En grön Sophos NDR-status är en viktig delkontroll, men den bevisar inte att speglingstäckningen är fullständig eller att detekteringskedjan fungerar. För en tillförlitlig bedömning måste sex signalgrupper granskas separat: Sophos Fusion, Appliance Manager, SPAN-indata, uppladdning, beräkningskapacitet och lagring samt – om den finns – den fristående Investigation Console.

Snabbkontroll: Läs först NDR-statusen i Sophos Fusion. Kontrollera sedan värdena för varje förväntad SPAN-port, Uploaded och flödeshistoriken under NDR i Appliance Manager. Under Status kontrollerar du CPU, Memory, Root Disk och Data Disk. Ett gult meddelande, spanX: packets being dropped, innebär att mer än 10 % av de nätverkspaket som NDR bearbetar tappas. En grön SPAN-port uppfyller för närvarande produktklassificeringens gräns på minst 2 % unicast-paket. Inget av dessa påståenden bevisar i sig att alla avsedda nätverk speglas eller att en detektering når hela vägen genom kedjan.

Koppla indikatorerna till rätt funktion

Öppna Appliance Manager i Sophos Fusion via Threat Analysis Center > Integrations > Configured > Integration Appliances. Klicka på de tre punkterna på apparatens rad och välj Open Appliance Manager. I sidhuvudet visas bland annat Version, K3S Helm Chart version, Uptime och System ID. Ta med dessa uppgifter i all incidentdokumentation, eftersom två apparater med till synes liknande symtom kan ha olika programvaruversioner eller drifttider.

Använd Fusion-statusen som utgångspunkt

Sophos Fusion skiljer mellan tre tillstånd:

• Röd: NDR-integrationen fungerar inte. NDR containers not ready, <specific container names> anger program som inte är klara. Upload to s3 failed ... gäller molnuppladdningen. spanX: unhealthy span gäller trafikindata från nätverksenheten som utför speglingen.
• Gul: Integrationen fungerar, men med fel. spanX: packets being dropped visas när mer än 10 % av nätverkspaketen tappas.
• Grön: Integrationen tar emot SPAN-trafik och bearbetar paketdata utan rapporterade fel. En SPAN-port klassificeras för närvarande som hälsosam om minst 2 % av de observerade paketen är unicast-paket.

De två procenttalen har olika nämnare och får inte räknas av mot varandra. Gränsen på 2 % klassificerar sammansättningen av den trafik som når sensorn. Den innebär varken att 2 % av all företagstrafik räcker eller att NDR får förlora 98 %. ”Minst 2 %” omfattar exakt 2 %. Meddelandet om tappade paket beskriver däremot den andel paket som redan når NDR men som bearbetningen inte klarar av på grund av otillräckliga resurser. Sophos dokumenterar varningen för mer än 10 %, inte för ”10 % eller mer”.

Viktigt: Gränsen på mer än 10 % är en produktstatus, inte ett målvärde eller en acceptabel förlustbudget. Även ett värde under rapporteringsgränsen kan vara en försämring jämfört med den egna baslinjen. På samma sätt kan en grön port leverera felaktigt eller ofullständigt speglad trafik så länge den observerade blandningen uppfyller unicast-klassificeringen.

Kontrollera SPAN-indata och uppladdning separat

På fliken NDR i Appliance Manager visas ett insamlingsvärde för varje konfigurerad SPAN-port. SPAN Port 2 visas endast om en andra port har konfigurerats. Diagrammet över samtliga Network Flows visas i 30-sekundersintervall.

Indikatorerna besvarar tre separata frågor:

1. Kommer trafik in på varje förväntad SPAN-port? Om ett värde saknas eller plötsligt avviker kraftigt bör felsökningen först inriktas på källswitchen, speglings- eller SPAN-sessionen, tilldelningen av det virtuella nätverkskortet samt nyligen ändrade VLAN eller portgrupper.
2. Är trafiksammansättningen rimlig? Grönt bekräftar endast den aktuella unicast-klassificeringen. Flödeshistoriken måste dessutom stämma överens med normala tider på dygnet, platser och förväntade trafiktoppar.
3. Kan NDR bearbeta paketen? Det gula meddelandet om tappade paket visar att det finns en bearbetningsflaskhals. Det är inte samma sak som en överbelastad speglingsport eller paketförlust i produktionsvägen.

Uppladdningsandelen, som också visas på fliken NDR, representerar ett senare steg. Hälsosamma SPAN-indata i kombination med sjunkande uppladdning tyder inte på samma felklass som en tom SPAN-port. Vid Upload to s3 failed. Request was received but an error code was returned kontrollerar du apparatens utgående internetåtkomst samt regler för brandvägg och webbproxy. NDR laddar upp data till en S3-bucket via en försignerad URL. Kontakta Sophos Support om felet kvarstår efter att nätverks- eller proxykonfigurationen har korrigerats.

För tredjepartsintegrationer av typen logginsamling räknar korten under Integrations värdena Received, Filtered, Accepted och Uploaded. Dessa syslog-räknare är varken NDR:s uppladdningsvärde eller SPAN:s insamlingsvärde. De är ändå viktiga, eftersom en hårt belastad logginsamlingsintegration som körs på samma apparat använder dess CPU och Memory.

Bedöm CPU, Memory och lagring

Under Status visar Appliance Manager användningen av CPU, Memory, Root Disk och Data Disk. Att enskilda CPU-kärnor är kontinuerligt fullt belastade är förväntat med NDR: Data Plane Development Kit (DPDK) körs på reserverade kärnor i pollningsläge. Det söker kontinuerligt efter paket i stället för att vänta på avbrott vid inaktivitet.

Sophos anger två konkreta exempel:

• På en virtuell dator med 4 CPU-kärnor ligger en kärna kvar på 100 %.
• På en virtuell dator med 8 CPU-kärnor ligger två kärnor kvar på 100 %.

Denna typ av belastning per kärna är därför inte i sig ett tecken på överbelastning och försvinner inte nödvändigtvis vid låg trafik. Omvänt får ”DPDK är normalt” inte användas för att förklara all hög CPU-belastning. Det kritiska är kombinationen av ökande trafik, ytterligare fullt belastade kärnor, meddelandet packets being dropped, sjunkande uppladdning eller en flödeshistorik som avviker från baslinjen.

För virtuella apparater gäller följande riktvärden för kapacitet:

Alla tre måtten måste bedömas tillsammans. En miljö kan ligga under bandbreddsgränsen men ändå generera många paket per sekund på grund av mycket små paket. Om värdena överskrider High-profilen rekommenderar Sophos att flera virtuella apparater distribueras i nätverket.

Värdena gäller för en virtuell dator där endast NDR körs. Vid hög belastning behöver varje ytterligare logginsamlingsintegration på apparaten cirka 400 MB RAM och kan använda ytterligare CPU-kapacitet. Kontrollera därför även korten under Integrations före en kapacitetsutökning. Vid långvarig blandad belastning kan det vara lämpligare att fördela arbetsbelastningen på flera apparater än att upprepade gånger tillföra resurser till samma virtuella dator.

Produktdokumentationen som används för den här artikeln anger ingen allmän varningsgräns för Memory, Root Disk eller Data Disk. Det vore därför missvisande att betrakta ett godtyckligt procenttal som en Sophos-gräns. Det viktiga är trenden, tillgänglig marginal och samtidiga symtom. Ta inte bort filer eller containrar manuellt om diskanvändningen ökar kontinuerligt. Dokumentera först status och tidsperiod och spara loggar för Sophos Support om orsaken är oklar.

Skapa en användbar baslinje

En ögonblicksbild kan inte skilja ett normalt dygnsmönster från en begynnande överbelastning. Registrera därför jämförbara mätpunkter efter driftsättningen och efter varje relevant ändring:

• datum, tid och tidszon samt förväntad belastningsperiod,
• färg i Fusion och exakt meddelandetext,
• insamlingsvärde för varje konfigurerad SPAN-port,
• uppladdningsandel och flödeshistorikens form,
• CPU per kärna och totalt, Memory, Root Disk och Data Disk,
• den virtuella datorns tilldelade vCPU och RAM,
• uppskattade Mbit/s, paket/s och flöden/s eller värden uppmätta i källsystemet,
• tredjepartsintegrationer som körs samtidigt och deras aktivitet,
• ändringar av switch, hypervisor, proxy, brandvägg eller apparat.

Mätningar under en lugn period, vid normal verksamhetsbelastning och under en känd topp är användbara. Målet är inte ett universellt börvärde, utan att jämföra samma apparat under liknande förhållanden. På så sätt blir en plötslig minskning på en SPAN-port synlig även om Fusion fortfarande visar grönt. Efter en kapacitetsändring skapar du en ny baslinje först när tillståndet är stabilt.

Åtgärda störningar i säker ordning

1. Dokumentera omfattningen: Dokumentera berörd apparat, SPAN-port, starttid, exakt Fusion-text och senaste ändring. Spara skärmbilder eller mätvärden före en omstart.
2. Kontrollera indata: Vid unhealthy span, uteblivna flöden eller en avvikelse från portens baslinje kontrollerar du först speglingskällan, målporten eller det virtuella nätverkskortet samt de förväntade nätverken. Ytterligare CPU åtgärdar inte en felkonfigurerad SPAN-källa.
3. Kontrollera uppladdningen: Vid ett S3-uppladdningsfel kontrollerar du utgående internetåtkomst, brandväggen och webbproxyn. Omvänt åtgärdar en lyckad uppladdning inte bristande speglingstäckning.
4. Kontrollera kapaciteten: När mer än 10 % av paketen tappas jämför du trafikprofilen, andra fullt belastade kärnor, vCPU-tilldelningen och integrationer som körs på samma apparat. Tilldela ytterligare vCPU till en virtuell dator; den dokumenterade High-profilen anger 8 vCPU. För certifierad maskinvara kan ytterligare en apparat driftsättas och SPAN-trafiken delas upp. Innan trafiken delas upp krävs en godkänd täckningsplan: den ska entydigt tilldela varje avsett nätverk, VLAN och varje speglingskälla till målapparaten och förhindra både luckor och oavsiktliga dubbla flöden. Vid blandade arbetsbelastningar kan NDR och logginsamlare fördelas på separata apparater.
5. Avgränsa omstarten: Om NDR fortfarande inte fungerar korrekt efter att orsaken har åtgärdats kan en riktad omstart av NDR övervägas enligt tillämpliga drift- eller felsökningsanvisningar. Normal NDR-bearbetning sker inte under omstarten; en omstart ersätter inte en kapacitetskorrigering. En omstart eller avstängning av hela den virtuella datorn har större påverkan och hör inte hemma i det första felsökningssteget.

Om antalet vCPU eller trafikfördelningen ändras ska det göras under ett godkänt underhållsfönster och enligt kraven för den virtualiseringsplattform som används. Gör en ändring i taget så att effekten förblir mätbar. När trafiken har delats upp kontrollerar du täckningsplanen mot varje resulterande SPAN-port och validerar dessutom den godkända testvägen från början till slut.

Förväxla inte Investigation Console med NDR-apparaten

Investigation Console är en separat komponent. Dess status visar varken hur NDR-integrationen mår, om SPAN-källorna är fullständiga eller om data har levererats. Den här artikeln begränsas därför till att tydliggöra avgränsningen: SPAN, NDR-uppladdning, DPDK och tappade paket kontrolleras i NDR-integrationen och Appliance Manager. Kontroll och felsökning av Investigation Console hör hemma i den tillämpliga driftdokumentationen för konsolen.

Validera efter varje åtgärd

Upprepa kontrollerna under en belastning som är jämförbar med den ursprungliga mätningen. En korrigering betraktas som effektiv först när:

• Fusion visar det förväntade tillståndet utan det tidigare röda eller gula meddelandet,
• varje förväntad SPAN-port är synlig och åter följer sin egen baslinjehistorik,
• unicast-klassificeringen inte felaktigt har använts som bevis på täckning,
• meddelandet om mer än 10 % tappade paket inte återkommer,
• uppladdning och Network Flows förblir stabila under en meningsfull observationsperiod,
• CPU utanför de förväntade DPDK-kärnorna, Memory, Root Disk och Data Disk visar tillräcklig marginal,
• tredjepartsintegrationer som körs på samma apparat fortsätter att bearbeta förväntade data,
• varje avsett nätverk, VLAN och varje speglingskälla efter en trafikuppdelning matas till exakt den avsedda apparaten enligt den godkända täckningsplanen och den godkända testvägen från början till slut fungerar.

Dessa kontroller validerar drifttillståndet, men ännu inte en fullständig detekteringskedja. Ett bevis från början till slut kräver dessutom ett godkänt NDR-test och kontroll av den detektering som testet resulterar i.

När Sophos Support bör kopplas in

Koppla in Sophos Support om containrar inte blir klara, om ett S3-uppladdningsfel kvarstår trots bekräftad internet- och proxyväg, om en SPAN-port fortfarande är unhealthy trots korrigerad källkonfiguration, om paket återigen tappas efter en lämplig kapacitetsökning eller om resursindikatorer och statusmeddelanden motsäger varandra.

Förbered minst följande uppgifter inför eskaleringen:

• apparatens namn, System ID, Version, K3S Helm Chart version och Uptime,
• exakt status- och feltext, inklusive starttid och tidszon,
• berörd SPAN-port, insamlings- och uppladdningsvärden samt flödeshistorik,
• CPU per kärna, Memory, Root Disk och Data Disk före och efter åtgärden,
• den virtuella datorns resurstilldelning, observerad trafikprofil och integrationer som körs på samma apparat,
• de senaste ändringarna av switch, hypervisor, brandvägg eller proxy,
• utförda åtgärder och deras mätbara resultat,
• vid problem med en separat Investigation Console, de underlag som krävs enligt dess tillämpliga driftdokumentation.

Lösenord, privata nycklar och andra inloggningsuppgifter ska inte finnas i ärendet. Kör inte Kubernetes-kommandon på låg nivå och ändra inte containrar manuellt enbart på grund av misstankar. Vid NDR containers not ready samlar du in tillgängliga observationer och samordnar åtgärderna med Sophos Support.