Traffic Mirroring voor Sophos NDR plannen en valideren

Traffic Mirroring levert Sophos NDR een kopie van het netwerkverkeer. Voor lokale of gevirtualiseerde netwerken gebeurt dit meestal via SPAN. Verkeer van externe bronnen wordt via ERSPAN over GRE of VXLAN ingekapseld en in AWS gebeurt de configuratie via VPC > Traffic mirror sessions. Het doel is niet om zonder controle zo veel mogelijk poorten te spiegelen. NDR heeft de juiste verkeersrelaties nodig, zonder lussen, onnodige duplicaten of een overbelast doelpad.

De veilige werkwijze is:

de te bewaken verkeersrelaties en grenzen vaststellen,
voor elke relatie precies één geschikt observatiepunt kiezen,
de capaciteit van de bron tot de NDR-sensor controleren,
eerst een kleine pilotbron spiegelen,
de keten van bron tot verwerking stapsgewijs valideren,
bronnen alleen gecontroleerd uitbreiden en na elke wijziging opnieuw meten.

Voor activering moeten bron, richting, filter, doel, onderhoudsvenster, toegestane gegevensomvang en verantwoordelijkheid voor de rollback zijn goedgekeurd en gedocumenteerd. Spiegelgegevens kunnen payloads en andere gevoelige informatie bevatten. Daarom mogen onbedoelde gebruikers-, beheer-, identiteits- of andere gevoelige segmenten niet uit voorzorg of ‘voor de zekerheid’ breed worden gespiegeld. De pilotbron wordt beperkt tot de goedgekeurde functionele en privacyrechtelijke scope.

Bronnen en observatiepunten selecteren

Voor de configuratie is een beknopte dekkingsmatrix nuttig. Deze bevat niet simpelweg alle switchpoorten, maar de relevante communicatiepaden, bijvoorbeeld:

clients naar internet en externe diensten,
clients naar interne servers,
verkeer tussen servers, vooral over segment- of beveiligingszonegrenzen,
datacenter naar filialen of cloudnetwerken,
oost-westverkeer tussen virtuele machines dat geen fysieke uplink passeert.

Voor elk pad wordt een punt gekozen waar beide richtingen zichtbaar zijn. Meestal is dit een trunk, een VLAN of een poort nabij een segmentgrens. Een internetuplink biedt goed zicht op noord-zuidverkeer, maar ziet geen lokaal verkeer binnen hetzelfde VLAN. Een fysieke switch ziet op zijn beurt geen verkeer dat binnen dezelfde vSwitch blijft. Zulke hiaten zijn niet af te leiden uit een groene sensorstatus; ze moeten blijken uit de topologie en testmatrix.

Bron en richting

Een SPAN-bron kan, afhankelijk van het platform, een poort, poortgroep of VLAN zijn. Selecteer waar mogelijk both, oftewel inkomend en uitgaand verkeer. Als slechts één richting wordt gespiegeld, kunnen antwoorden, fouten en delen van een sessie buiten beeld blijven.

Een trunk of volledig VLAN vereenvoudigt de dekking, maar vergroot het gegevensvolume en de kans op duplicaten. Afzonderlijke accesspoorten zijn gerichter, maar worden bij verhuizingen of dynamische workloads gemakkelijker vergeten. De keuze is daarom gebaseerd op de verkeersrelatie en niet op het aantal beschikbare bronnen.

Doel

Het spiegeldoel is uitsluitend het capturepad van de NDR-sensor:

bij een VM de poortgroep of vSwitch waarop SPAN1 of SPAN2 is aangesloten,
bij een fysieke verbinding de speciale switchpoort naar de SPAN-interface,
bij ERSPAN het geconfigureerde GRE- of VXLAN-doeladres van de sensor,
in AWS het door de CloudFormation-stack aangemaakte NDR SPAN Target.

De beheerinterface hoort niet als SPAN-doel in deze keten. De doelpoort wordt bovendien niet als normale bron gebruikt en mag geen productieverkeer terug het netwerk in sturen.

Lussen en dubbele pakketten voorkomen

Port Mirroring kopieert pakketten; de kopieën mogen niet in het productieve doorstuurpad worden teruggevoerd. Een lus ontstaat bijvoorbeeld wanneer het SPAN-doel zelf opnieuw wordt gespiegeld of als normale uplink wordt gebruikt. Dubbele gegevens komen vaker voor: hetzelfde pakket wordt vastgelegd bij de accesspoort en de uplink, aan beide kanten van een segmentgrens of tegelijkertijd via lokale SPAN en ERSPAN.

Controleer daarom vóór activering het volgende:

De doelinterface is uitsluitend een doel en nooit een bron van dezelfde of een overlappende sessie.
Een end-to-endverkeerspad wordt waar mogelijk op precies één betekenisvolle grens gespiegeld.
Twee SPAN-poorten ontvangen geen overlappende bronnen, tenzij die overlap is gedocumenteerd en bedoeld is voor een tijdelijke test.
Broadcasts en multicasts worden niet op meerdere punten binnen hetzelfde Layer 2-domein verzameld.
Bij een cluster of vMotion is duidelijk op welke host en uplink het fysiek gespiegelde verkeer binnenkomt. Een NDR-VM met standaard-SPAN vanaf een fysieke switch moet op de ESXi-host blijven die dit verkeer ontvangt.
In AWS bestaat per ENI en beoogde verkeersomvang alleen de noodzakelijke sessie. Ook worden de sessievolgorde en filters gecontroleerd.

Duplicaten verbruiken capture-, tunnel- en CPU-capaciteit zonder de functionele dekking te verbeteren. Een pakket- of bytesnelheid die bijna verdubbelt nadat een bron is toegevoegd, is verdacht als het productieverkeer gelijk is gebleven. Schakel in dat geval de laatst toegevoegde bron weer uit en controleer de topologie op overlap.

SPAN lokaal of in de hypervisor configureren

De precieze syntaxis verschilt per switch en hypervisor. Ongeacht het platform blijft het model hetzelfde: selecteer bron en richting, stel een specifiek doel in en zorg dat de virtuele capturepoortgroep ontvangst in promiscuous mode toestaat.

Bij een Sophos Switch-sessie kan een kleine pilotconfiguratie bijvoorbeeld poort 1 tot en met 4 in beide richtingen naar poort 8 spiegelen:

configure terminal
monitor session 1 destination interface gigabitethernet 0/8 allow-ingress
monitor session 1 source interface gigabitethernet 0/1 both
monitor session 1 source interface gigabitethernet 0/2 both
monitor session 1 source interface gigabitethernet 0/3 both
monitor session 1 source interface gigabitethernet 0/4 both
save
end
show monitor session 1

De interfacenummers zijn voorbeelden en moeten overeenkomen met de eigen bekabeling. Controleer vóór het opslaan of 0/8 daadwerkelijk alleen naar het NDR-capturepad leidt. Gebruik bij andere fabrikanten hun gedocumenteerde SPAN-opdrachten; vergelijkbare namen hebben niet automatisch dezelfde semantiek.

Stel voor een ESXi Standard vSwitch de capturepoortgroep in op VLAN ID 4095 en kies onder Security bij Promiscuous mode de waarde Accept. Fysiek gespiegeld verkeer vereist daarnaast een specifieke uplink van de switch naar de juiste vSwitch. Intern VM-verkeer kan een afzonderlijke virtuele spiegelbron vereisen. Bij Hyper-V moet de NDR-capture-interface als doel van de poortspiegeling met de juiste vSwitch zijn verbonden; controleer de platformconfiguratie daar afzonderlijk van de NDR-sensorinstelling.

Sophos NDR schakelt SPAN Port 1 standaard in; SPAN Port 2 is standaard uitgeschakeld. Een tweede SPAN-poort is alleen zinvol als deze een afzonderlijke bron zonder onnodige overlap ontvangt. Voor SPAN Port 2 heeft de VM ten minste 8 vCPU’s nodig.

ERSPAN met GRE of VXLAN gebruiken

ERSPAN transporteert kopieën van externe bronnen via een IP-netwerk naar de sensor. Daardoor wordt het transportpad onderdeel van de capaciteits- en foutanalyse: MTU, routering, ACL’s en mogelijke fragmentatie kunnen de vastlegging beïnvloeden, ook als de bronsessie correct is.

Configureer in Sophos Appliance Manager de juiste capture-interface onder Settings:

VXLAN

Schakel naast de beoogde SPAN-poort Enable ERSPAN in.
Selecteer onder Tunnel Protocol de waarde vxlan.
Voer onder IP Address het adres van de VTEP-interface in.
Stel VXLAN ID en VXLAN Port exact zo in als bij de inkapselende bron.
Selecteer Save.

GRE

Schakel naast de beoogde SPAN-poort Enable ERSPAN in.
Selecteer onder Tunnel Protocol de waarde gre.
Voer onder IP Address het adres van de GRE-doelinterface in.
Voer bij GRE Port de waarde in die overeenkomt met de bronconfiguratie.
Selecteer Save.

Wijzigingen in de SPAN-instellingen worden pas van kracht nadat de VM opnieuw is opgestart. Controleer vóór de herstart of dezelfde appliance andere integraties verwerkt; ook hun gegevensverzameling wordt daarbij onderbroken. Valideer daarna de tunnelparameters en verwerking opnieuw.

SPAN samen met VXLAN op dezelfde appliance is een gebruikelijk ontwerp. Gebruik VXLAN en GRE alleen gelijktijdig op dezelfde appliance als bronnen, capaciteit en foutdomeinen duidelijk van elkaar zijn gescheiden en zijn gedocumenteerd.

AWS Traffic Mirroring beoordelen

In AWS blijft het architectuurmodel hetzelfde: de Mirror Source is de ENI van de goedgekeurde workload en niet de beheer-ENI van de NDR-sensor; Mirror Target en filter moeten deel uitmaken van het geïmplementeerde NDR-ontwerp. Beperk het filter tot de beoogde gegevensomvang. De daadwerkelijke AWS-implementatie en het aanmaken van de Traffic Mirror Session worden beschreven in ‘Sophos NDR op AWS implementeren’ en worden hier niet herhaald.

Gebruik vervolgens voor de acceptatie de hieronder beschreven bewijsketen. Alleen het bestaan van een AWS-sessie bewijst noch de pakketstroom naar het doel, noch verwerking, upload of detectie.

Capaciteit vóór acceptatie beperken

SPAN Port 2 is geen capaciteitsuitbreiding: de VM heeft voor activering ten minste 8 vCPU’s nodig, maar de tweede invoer voegt verkeer en daarmee verwerkingsbehoefte toe. Gebruik deze poort alleen voor een afzonderlijke, niet-overlappende bron. Als de verkeerssnelheid of het pakketverlies na activering toeneemt, controleer dan of SPAN2 extra of dubbele belasting heeft toegevoegd.

In ‘Sophos NDR-health en -capaciteit bewaken’ leest u hoe u status-, unicast- en dropsignalen beoordeelt en de capaciteit evalueert. Zie ‘NDR Integration Appliance en sensor diagnosticeren’ voor symptoomgerichte stappen voor probleemoplossing. Afhankelijk van het platform kunnen extra vCPU’s of een niet-overlappende verdeling over een andere appliance als capaciteitsmaatregel dienen; andere CPU-intensieve integraties moeten afzonderlijk worden ingepland. Alleen SPAN2 toevoegen vergroot de verwerkingscapaciteit niet.

Validatie: van bron tot detectie

Voer de controle uit met een bekende pilothost en een vastgesteld tijdvenster. Zo kan een fout aan één fase worden toegewezen, in plaats van tegelijkertijd wijzigingen aan switch, tunnel, sensor en Sophos Fusion aan te brengen.

1. Configuratie en topologie

Vergelijk bron, richting en doel met de dekkingsmatrix.
Controleer de door de fabrikant aangegeven status van de SPAN- of AWS-sessie.
Zorg dat het doel niet als bron is opgenomen.
Controleer bij ERSPAN het doeladres, de GRE- of VXLAN-parameters en het netwerkpad.
Controleer bij virtuele platforms de toewijzing van de capture-NIC, poortgroep of vSwitch.

2. Pakketten op het doel

Gebruik gecontroleerd unicast-testverkeer vanaf de pilothost om te controleren of pakketten op het beoogde capturedoel aankomen. Leg als bewijs het tijdvenster, de doelinterface, de verwachte bron- en doeladressen en, waar van toepassing, beide richtingen vast. Deze fase bewijst dat de geteste pakketten op het beoogde doel aankomen, maar nog niet dat ze worden verwerkt of geüpload. Alleen broadcastverkeer is geen betrouwbare test. Als pakketten ontbreken, beperkt u het onderzoek in eerste instantie tot bron, filter, richting, transport en virtuele poortgroep.

3. Capture en flow op de beoogde SPAN-poort

Leg onder Sophos Appliance Manager > NDR voor precies de beoogde SPAN-poort het weergegeven capturepercentage vast en registreer gedurende het venster van 30 seconden de activiteit in de Total Flow-grafiek. Beide moeten in tijd overeenkomen met het pilotverkeer. Dit toont activiteit op de geselecteerde invoer aan; de weergaven bewijzen noch volledige pakketvastlegging, noch de juiste gegevensomvang, beide richtingen of een geslaagde upload.

Volgens de huidige Sophos-classificatie is een SPAN-poort gezond wanneer ten minste 2 procent van de netwerkpakketten unicast is. Deze waarde is uitsluitend het minimale criterium voor de healthclassificatie: de waarde sluit in de onderzochte steekproef alleen een unicastaandeel van nul uit. Ook een onjuiste, gedeeltelijke, dubbele, verouderde of voor het doel ongeschikte invoer kan aan de drempel van 2 procent voldoen. De waarde bewijst daarom noch de verwachte bron en richting, bruikbaar verkeer, dekking, het weergegeven capturepercentage, upload of detectie. Oudere verwijzingen naar 100 procent unicast gelden niet als actuele vereiste.

4. Verwerking en upload

Leg onder Sophos Appliance Manager > NDR voor hetzelfde tijdvenster het weergegeven uploadpercentage vast en vergelijk het tijdstip ervan met de capture- en flowactiviteit. Dit documenteert uploadactiviteit, maar bewijst niet dat elk gespiegeld pakket is geüpload of dat er later een detectie ontstaat. Connected bevestigt hoofdzakelijk de verbinding van de appliance en vervangt dit bewijs niet. Als health-, capture-, upload- en dropsignalen van elkaar afwijken, volgt u de systematische diagnose van appliance en sensor.

5. Functionele dekking

Genereer voor elke rij van de dekkingsmatrix gericht en toegestaan testverkeer en registreer tijd, testapparaat, verwacht segment, bron, doel en richting. Koppel het bewijs uit fase 2 tot en met 4 aan deze test. Alleen deze steekproeven tonen aan dat de geteste paden in beginsel worden vastgelegd; ze vormen geen bewijs voor niet-geteste segmenten of tijdvensters.

6. Onschadelijke end-to-enddetectie

Voer pas na een geslaagde acceptatie van de spiegelconfiguratie de afzonderlijke, goedgekeurde procedure ‘Een veilige Sophos NDR-testdetectie genereren en controleren’ uit. Het genereren van die test valt buiten deze procedure. Controleer het resultaat voor het verwachte testapparaat en tijdvenster onder Threat Analysis Center > Detections en koppel het aan de eerdere bewijsketen. Een daar waargenomen testdetectie bewijst het geteste end-to-endpad; deze garandeert noch detectie van elke aanvalstechniek, noch dekking van andere paden.

Afwijkingen stapsgewijs afbakenen

Onderzoek bij een mislukte acceptatie alleen de eerste fase zonder het verwachte bewijs: het daadwerkelijke bronpad, de richting en het filter; daarna de doelbekabeling of virtuele capturetoewijzing; bij ERSPAN vervolgens het transport en de overeenkomende tunnelwaarden; daarna capture/flow op de beoogde poort; en ten slotte upload en detectie. Een groene status of ten minste 2 procent unicast slaat geen van deze fasen over. Breng telkens slechts één wijziging aan en meet opnieuw met dezelfde pilot en hetzelfde tijdvenster.

Als alleen een richting of segment ontbreekt, vergelijkt u de dekkingsmatrix met het daadwerkelijke fysieke of virtuele pad, zonder uit voorzorg extra gevoelige segmenten of alle poorten toe te voegen. Bij een opvallend hoge verkeerssnelheid controleert u de gedocumenteerde overlappingen afzonderlijk aan de hand van tellers en de zichtbaarheid van het pilotverkeer. Deze werkwijze eindigt met de acceptatie van de spiegelconfiguratie en de lokalisatie van de fout; ga bij sensor-, upload- of platformfouten verder met de diagnose van appliance en sensor.

Wijzigingen van deze procedure veilig terugdraaien

Leg vóór elke uitbreiding de sessie-ID, bronnen, richtingen, filters, het doel, de tunnelparameters en de uitgangsmetingen vast. De volgende rollback omvat alleen spiegelwijzigingen die tijdens deze procedure nieuw zijn aangebracht; het is geen instructie voor het verwijderen van een appliance, cloudstack of andere infrastructuur.

Draai bij problemen de wijzigingen in omgekeerde volgorde terug:

verwijder de laatst toegevoegde lokale bron; verwijder een AWS Traffic Mirror Session die nieuw voor deze procedure is aangemaakt,
herstel een als laatste uitgebreid filter naar de gedocumenteerde pilotomvang,
schakel pas geactiveerde ERSPAN uit of herstel de eerdere tunnelwaarden,
schakel SPAN Port 2 uit als deze de nieuwe belasting of overlap heeft veroorzaakt,
herstel de eerdere switchsessie als de fysieke spiegelconfiguratie is gewijzigd,
controleer pakketstroom, droprate, integratiestatus en pilotverkeer opnieuw.

Voor het terugdraaien van de Sophos SPAN-instellingen zijn opnieuw Save en een VM-herstart nodig voordat de wijziging van kracht wordt. Houd ook hierbij rekening met de gevolgen voor andere integraties op dezelfde appliance. De rollback is pas voltooid wanneer niet alleen de status weer groen is, maar de eerder gedocumenteerde pilotpaden zichtbaar zijn zonder nieuwe duplicaten en zonder problematisch pakketverlies.