Sophos NDR-status en -capaciteit bewaken

Een groene Sophos NDR-status is een belangrijke tussentijdse controle, maar vormt nog geen bewijs van volledige mirrordekking of een werkende detectieketen. Voor een betrouwbare beoordeling moeten zes signaalgroepen afzonderlijk worden bekeken: Sophos Fusion, Appliance Manager, SPAN-invoer, upload, rekenkracht en opslag en, indien aanwezig, de zelfstandige Investigation Console.

Snelle controle: Bekijk eerst de NDR-status in Sophos Fusion. Controleer daarna in Appliance Manager onder NDR de waarden voor elke verwachte SPAN-poort, Uploaded en het verloop van de flows. Controleer onder Status CPU, Memory, Root Disk en Data Disk. Een gele melding spanX: packets being dropped betekent dat meer dan 10% van de bij NDR binnenkomende netwerkpakketten tijdens de verwerking wordt gedropt. Een groene SPAN-poort voldoet op dat moment aan het classificatiecriterium van het product: ten minste 2% unicast-pakketten. Geen van deze uitspraken bewijst op zichzelf dat alle bedoelde netwerken worden gemirrord of dat een detectie de keten van begin tot eind doorloopt.

De indicatoren aan hun doel koppelen

Open Appliance Manager in Sophos Fusion via Threat Analysis Center > Integrations > Configured > Integration Appliances. Selecteer in de rij van de appliance de drie puntjes en vervolgens Open Appliance Manager. In het kopgedeelte staan onder andere Version, K3S Helm Chart version, Uptime en System ID. Neem deze gegevens op in elke incidentregistratie, omdat twee appliances met ogenschijnlijk vergelijkbare symptomen verschillende softwareversies of uptimes kunnen hebben.

De Fusion-status als uitgangspunt gebruiken

Sophos Fusion onderscheidt drie statussen:

• Rood: De NDR-integratie werkt niet. NDR containers not ready, <specific container names> wijst op applicaties die nog niet gereed zijn. Upload to s3 failed ... heeft betrekking op de cloud-upload. spanX: unhealthy span heeft betrekking op de verkeersinvoer van het netwerkapparaat dat het verkeer mirrort.
• Geel: De integratie werkt, maar met fouten. spanX: packets being dropped wordt weergegeven wanneer meer dan 10% van de netwerkpakketten wordt gedropt.
• Groen: De integratie ontvangt SPAN-verkeer en verwerkt pakketgegevens zonder gemelde fout. Een SPAN-poort wordt momenteel als gezond geclassificeerd als ten minste 2% van de waargenomen pakketten unicast-pakketten zijn.

De twee percentages hebben verschillende noemers en mogen niet tegen elkaar worden weggestreept. De drempel van 2% classificeert de samenstelling van het verkeer dat bij de sensor aankomt. Dit betekent niet dat 2% van al het bedrijfsverkeer voldoende is, en evenmin dat NDR 98% mag verliezen. “Ten minste 2%” omvat exact 2%. De dropmelding beschrijft daarentegen het aandeel van de pakketten die al bij NDR aankomen, maar door onvoldoende verwerkingscapaciteit niet kunnen worden verwerkt. Sophos documenteert de waarschuwing voor meer dan 10%, niet voor “10% of meer”.

Belangrijk: De drempel van meer dan 10% is een productstatus, geen streefwaarde of aanvaardbaar verliesbudget. Ook een waarde onder de meldingsdrempel kan een verslechtering ten opzichte van de eigen baseline betekenen. Een groene poort kan eveneens onjuist of onvolledig gemirrord verkeer aanleveren, zolang de waargenomen mix aan de unicast-classificatie voldoet.

SPAN-invoer en upload afzonderlijk controleren

In Appliance Manager toont het tabblad NDR voor elke geconfigureerde SPAN-poort een vastleggingspercentage. SPAN Port 2 verschijnt alleen als een tweede poort is geconfigureerd. De grafiek met de totale Network Flows wordt weergegeven in intervallen van 30 seconden.

Deze indicatoren beantwoorden drie afzonderlijke vragen:

1. Komt er verkeer binnen op elke verwachte SPAN-poort? Een ontbrekende of plotseling sterk afwijkende waarde leidt het onderzoek eerst naar de bronswitch, de mirror- of SPAN-sessie, de toewijzing van de virtuele netwerkinterface en recent gewijzigde VLAN’s of poortgroepen.
2. Is de verkeersmix aannemelijk? Groen bevestigt alleen de huidige unicast-classificatie. Het verloop van de flows moet ook passen bij de gebruikelijke tijdstippen, locaties en verwachte verkeerspieken.
3. Kan NDR de pakketten verwerken? De gele dropmelding wijst op een knelpunt in de verwerking. Dit is niet hetzelfde als een overbelaste mirrorpoort of pakketverlies in het productiepad.

Het uploadpercentage, dat eveneens zichtbaar is op het tabblad NDR, vertegenwoordigt een later stadium. Een gezonde SPAN-invoer met een dalend uploadpercentage duidt niet op dezelfde foutcategorie als een SPAN-poort waarop geen verkeer binnenkomt. Controleer bij Upload to s3 failed. Request was received but an error code was returned de uitgaande internettoegang van de appliance en de firewall- en webproxyregels. NDR uploadt de gegevens via een vooraf ondertekende URL naar een S3-bucket. Neem contact op met Sophos Support als de fout na correctie van de netwerk- of proxyconfiguratie aanhoudt.

Voor logcollectorintegraties van derden tonen de kaarten onder Integrations de tellers Received, Filtered, Accepted en Uploaded. Deze syslogtellers zijn noch het NDR-uploadpercentage, noch het SPAN-vastleggingspercentage. Ze zijn toch belangrijk, omdat een zwaarbelaste logcollectorintegratie die op dezelfde appliance draait, CPU en Memory van die appliance gebruikt.

CPU, Memory en opslag beoordelen

Onder Status toont Appliance Manager het gebruik van CPU, Memory, Root Disk en Data Disk. Dat afzonderlijke CPU-cores continu volledig worden belast, is bij NDR te verwachten: de Data Plane Development Kit (DPDK) werkt in poll-modus op gereserveerde cores. Daar vraagt DPDK voortdurend pakketten op, in plaats van tijdens inactiviteit op interrupts te wachten.

Sophos geeft hiervoor twee concrete voorbeelden:

• Op een VM met 4 CPU-cores blijft één core op 100%.
• Op een VM met 8 CPU-cores blijven twee cores op 100%.

Dit type belasting per core is op zichzelf dus geen bewijs van overbelasting en verdwijnt niet noodzakelijkerwijs bij weinig verkeer. Omgekeerd mag “DPDK is normaal” niet worden gebruikt om elke hoge CPU-belasting te verklaren. De situatie wordt kritiek wanneer toenemend verkeer samengaat met meer volledig belaste cores, de melding packets being dropped, een dalend uploadpercentage of een ten opzichte van de baseline gewijzigd flowverloop.

Voor virtuele appliances gelden de volgende capaciteitsrichtlijnen:

Alle drie de meetwaarden moeten samen worden beoordeeld. Een omgeving kan onder de bandbreedtelimiet blijven en door zeer kleine pakketten toch veel pakketten per seconde genereren. Als de waarden het High-profiel overschrijden, adviseert Sophos om meerdere virtuele appliances in het netwerk te implementeren.

Deze waarden gelden voor een VM waarop alleen NDR draait. Bij hoge belasting vereist elke extra logcollectorintegratie die op de appliance wordt gehost ongeveer 400 MB RAM en kan deze extra CPU-capaciteit gebruiken. Controleer daarom ook de kaarten onder Integrations voordat u opschaalt. Bij een aanhoudende gemengde belasting kan het beter zijn de belasting over meerdere appliances te verdelen dan steeds middelen aan dezelfde VM toe te voegen.

De voor dit artikel gebruikte productdocumentatie specificeert geen algemene waarschuwingsdrempel voor Memory, Root Disk of Data Disk. Het zou daarom misleidend zijn om een willekeurig percentage als Sophos-limiet te behandelen. De relevante factoren zijn de trend, de beschikbare speelruimte en gelijktijdige symptomen. Verwijder bij een voortdurend toenemend schijfgebruik niet handmatig bestanden of containers. Documenteer eerst de status en de periode, en stel bij een onduidelijke oorzaak de logs voor Sophos Support veilig.

Een bruikbare baseline opstellen

Een momentopname kan een normaal dagpatroon niet onderscheiden van beginnende overbelasting. Leg daarom na de implementatie en na elke relevante wijziging vergelijkbare meetpunten vast:

• datum, tijd en tijdzone, en de verwachte belastingsperiode,
• Fusion-kleur en exacte meldingstekst,
• vastleggingspercentage voor elke geconfigureerde SPAN-poort,
• uploadpercentage en de vorm van het flowverloop,
• CPU per core en totaalbeeld, Memory, Root Disk en Data Disk,
• aan de VM toegewezen vCPU’s en RAM,
• geschatte Mbit/s, pakketten/s en flows/s, of waarden die op het bronsysteem zijn gemeten,
• gelijktijdig actieve integraties van derden en hun activiteit,
• wijzigingen aan de switch, hypervisor, proxy, firewall of appliance.

Metingen tijdens een rustige periode, normale bedrijfsbelasting en een bekende piek zijn nuttig. Het doel is geen universele streefwaarde, maar een vergelijking van dezelfde appliance onder vergelijkbare omstandigheden. Zo wordt een plotselinge afname op een SPAN-poort zichtbaar, ook als Fusion nog groen aangeeft. Stel na een capaciteitswijziging pas een nieuwe baseline op wanneer de status stabiel is.

Problemen in een veilige volgorde oplossen

1. Leg de omvang vast: Documenteer de getroffen appliance, SPAN-poort, begintijd, exacte Fusion-tekst en meest recente wijziging. Bewaar vóór een herstart schermafbeeldingen of meetwaarden.
2. Controleer de invoer: Controleer bij unhealthy span, ontbrekende flows of een afwijking van de poortbaseline eerst de mirrorbron, de doelpoort of virtuele netwerkinterface en de verwachte netwerken. Extra CPU herstelt geen onjuist geconfigureerde SPAN-bron.
3. Controleer de upload: Controleer bij een S3-uploadfout de uitgaande internettoegang, de firewall en de webproxy. Omgekeerd herstelt een geslaagde upload geen ontbrekende mirrordekking.
4. Controleer de capaciteit: Wanneer de drops meer dan 10% bedragen, vergelijkt u het verkeersprofiel, andere volledig belaste cores, de vCPU-toewijzing en integraties die op dezelfde appliance draaien. Wijs bij een VM extra vCPU’s toe; voor het gedocumenteerde High-profiel zijn 8 vCPU’s voorzien. Bij gecertificeerde hardware kan een extra appliance worden ingezet en kan het SPAN-verkeer worden verdeeld. Voordat het verkeer wordt verdeeld, is een goedgekeurd dekkingsplan verplicht: dit plan moet elk bedoeld netwerk, VLAN en elke mirrorbron duidelijk aan de doel-appliance toewijzen en zowel hiaten als onbedoelde dubbele invoer voorkomen. Bij gemengde workloads kunnen NDR en logcollectors over afzonderlijke appliances worden verdeeld.
5. Baken de herstart af: Als NDR na het wegnemen van de oorzaak nog steeds niet correct werkt, kan volgens de toepasselijke beheer- of probleemoplossingsinstructies een gerichte herstart van NDR worden overwogen. Tijdens de herstart vindt geen normale NDR-verwerking plaats; een herstart vervangt geen capaciteitscorrectie. Het herstarten of afsluiten van de volledige VM heeft een grotere impact en hoort niet thuis in de eerste stap van de probleemoplossing.

Als vCPU’s of de verkeersverdeling worden gewijzigd, doe dit dan binnen een goedgekeurd onderhoudsvenster en volgens de voorschriften van het gebruikte virtualisatieplatform. Voer één wijziging tegelijk uit, zodat het effect meetbaar blijft. Controleer na het verdelen van het verkeer het dekkingsplan voor elke resulterende SPAN-poort en valideer daarnaast het goedgekeurde end-to-end-testpad.

Verwar de Investigation Console niet met de NDR-appliance

De Investigation Console is een afzonderlijk onderdeel. De status ervan is geen bewijs voor de status van de NDR-integratie, de volledigheid van de SPAN-bronnen of een geslaagde gegevenslevering. Dit artikel beperkt zich daarom tot het verduidelijken van deze grens: SPAN, NDR-upload, DPDK en packet drops worden gecontroleerd bij de NDR-integratie en in Appliance Manager; controle en probleemoplossing van de Investigation Console horen thuis in de toepasselijke beheerdocumentatie voor de console.

Na elke maatregel valideren

Herhaal de controles onder een belasting die vergelijkbaar is met die van de oorspronkelijke meting. Een correctie geldt pas als effectief wanneer:

• Fusion de verwachte status zonder de eerdere rode of gele melding weergeeft,
• elke verwachte SPAN-poort zichtbaar is en weer overeenkomt met het eigen baselineverloop,
• de unicast-classificatie niet ten onrechte als bewijs van dekking is gebruikt,
• de melding voor meer dan 10% packet drops niet opnieuw verschijnt,
• upload en Network Flows gedurende een betekenisvolle observatieperiode stabiel blijven,
• CPU buiten de verwachte DPDK-cores, Memory, Root Disk en Data Disk voldoende speelruimte vertonen,
• integraties van derden die op dezelfde appliance draaien de verwachte gegevens blijven verwerken,
• na het verdelen van het verkeer elk bedoeld netwerk, VLAN en elke mirrorbron volgens het goedgekeurde dekkingsplan naar exact de bedoelde appliance wordt gevoerd en het goedgekeurde end-to-end-testpad werkt.

Deze controles valideren de operationele status, maar nog geen volledige detectieketen. Voor end-to-end-bewijs is daarnaast een goedgekeurde NDR-test met controle van de resulterende detectie vereist.

Wanneer Sophos Support inschakelen

Schakel Sophos Support in als containers niet gereed worden, een S3-uploadfout ondanks een bevestigde internet- en proxyroute aanhoudt, een SPAN-poort ondanks een gecorrigeerde bronconfiguratie unhealthy blijft, packet drops na een passende capaciteitsverhoging terugkeren of resource-indicatoren en statusmeldingen elkaar tegenspreken.

Bereid voor de escalatie ten minste de volgende gegevens voor:

• appliancenaam, System ID, Version, K3S Helm Chart version en Uptime,
• exacte status- en fouttekst, inclusief begintijd en tijdzone,
• getroffen SPAN-poort, vastleggings- en uploadpercentages en flowverloop,
• CPU per core, Memory, Root Disk en Data Disk vóór en na de maatregel,
• VM-toewijzing, waargenomen verkeersprofiel en integraties die op dezelfde appliance draaien,
• recente wijzigingen aan switch, hypervisor, firewall of proxy,
• uitgevoerde maatregelen en de meetbare resultaten ervan,
• bij problemen met een afzonderlijke Investigation Console: het bewijsmateriaal dat volgens de toepasselijke beheerdocumentatie vereist is.

Wachtwoorden, privésleutels en andere aanmeldgegevens horen niet in het ticket. Voer niet op basis van een vermoeden low-level Kubernetes-opdrachten uit en wijzig containers niet handmatig; verzamel bij NDR containers not ready de beschikbare waarnemingen en stem af met Sophos Support.