Planera och validera trafikspegling för Sophos NDR

Trafikspegling förser Sophos NDR med en kopia av nätverkstrafiken. I lokala eller virtualiserade nätverk sker det oftast via SPAN. Trafik från fjärrkällor kapslas in via ERSPAN över GRE eller VXLAN, och i AWS används VPC > Traffic mirror sessions. Målet är inte att spegla så många portar som möjligt utan urskiljning. NDR behöver rätt trafikflöden, utan loopar, onödiga dubbletter eller en överbelastad målväg.

Ett säkert tillvägagångssätt är att:

fastställa vilka trafikflöden och gränser som ska övervakas,
välja exakt en lämplig observationspunkt för varje flöde,
kontrollera kapaciteten hela vägen från källan till NDR-sensorn,
först spegla en liten pilotkälla,
validera kedjan stegvis från källan till bearbetningen,
endast utöka källorna kontrollerat och mäta på nytt efter varje ändring.

Innan aktiveringen måste källa, riktning, filter, mål, underhållsfönster, tillåten dataomfattning och ansvar för återställning vara godkända och dokumenterade. Speglade data kan innehålla nyttolast och annan känslig information. Därför får oavsiktliga användar-, administrations-, identitets- eller andra känsliga segment inte speglas brett i förebyggande syfte eller ”för säkerhets skull”. Pilotkällan begränsas till den godkända omfattningen för verksamhet och dataskydd.

Välja källor och observationspunkter

Före konfigurationen är det bra att skapa en kort täckningsmatris. I den listas inte alla switchportar, utan de relevanta kommunikationsvägarna, till exempel:

klienter till internet och externa tjänster,
klienter till interna servrar,
servrar sinsemellan, särskilt över segment- eller säkerhetszonsgränser,
datacenter till filialer eller molnnätverk,
öst-västtrafik mellan virtuella maskiner som inte passerar någon fysisk upplänk.

För varje väg väljs en punkt där båda riktningarna är synliga. Det är vanligtvis en trunk, ett VLAN eller en port nära en segmentgräns. En internetupplänk visar nord-sydtrafik väl, men ser inte lokal trafik inom samma VLAN. En fysisk switch ser i sin tur inte trafik som stannar inom samma vSwitch. Sådana luckor går inte att härleda från grön sensorstatus, utan måste framgå av topologin och testmatrisen.

Källa och riktning

En SPAN-källa kan beroende på plattform vara en port, en portgrupp eller ett VLAN. Om möjligt speglas both, det vill säga både inkommande och utgående trafik. Med bara en riktning kan svar, fel och delar av en session döljas.

En trunk eller ett helt VLAN förenklar täckningen, men ökar datavolymen och risken för dubbletter. Enskilda accessportar är mer riktade, men glöms lättare bort vid flyttar eller dynamiska arbetslaster. Valet ska därför utgå från trafikflödet, inte från antalet tillgängliga källor.

Mål

Speglingsmålet är uteslutande NDR-sensorns insamlingsväg:

för en virtuell dator den portgrupp eller vSwitch som SPAN1 respektive SPAN2 är ansluten till,
för en fysisk anslutning den dedikerade switchporten till SPAN-gränssnittet,
för ERSPAN, sensorns konfigurerade GRE- eller VXLAN-måladress,
i AWS det NDR SPAN Target som CloudFormation-stacken skapade.

Hanteringsgränssnittet hör inte hemma som SPAN-mål i den här kedjan. Målporten ska inte heller användas som vanlig källa och ska inte skicka tillbaka produktiv datatrafik till nätverket.

Undvika loopar och dubblerade paket

Portspegling kopierar paket; funktionen får inte leda tillbaka dem till den produktiva vidarebefordringsvägen. En loop uppstår till exempel om SPAN-målet samtidigt speglas igen eller används som vanlig upplänk. Dubblerade data är vanligare: samma paket samlas in vid accessporten och upplänken, på båda sidor om en segmentgräns eller samtidigt via lokal SPAN och ERSPAN.

Kontrollera därför följande före aktivering:

Målgränssnittet är endast mål och aldrig källa för samma eller en överlappande session.
En end-to-end-trafikväg speglas om möjligt vid exakt en relevant gräns.
Två SPAN-portar får inte överlappande källor, såvida inte överlappningen är dokumenterad och avsedd för ett tidsbegränsat test.
Broadcast- och multicast-trafik samlas inte in på flera platser inom samma lager 2-domän.
I ett kluster eller vid vMotion är det tydligt på vilken värd och upplänk den fysiska speglingen anländer. En NDR-VM med standard-SPAN från en fysisk switch måste stanna på den ESXi-värd som tar emot trafiken.
I AWS finns endast den nödvändiga sessionen per ENI och avsett trafikområde. Även sessionsordning och filter kontrolleras.

Dubbletter förbrukar insamlings-, tunnel- och CPU-kapacitet utan att förbättra den faktiska täckningen. Nästan fördubblade paket- eller bytehastigheter efter att en källa lagts till är misstänkta om den produktiva trafiken är oförändrad. Inaktivera då den senast tillagda källan igen och kontrollera om topologin överlappar.

Konfigurera SPAN lokalt eller i hypervisorn

Den konkreta syntaxen skiljer sig mellan switchar och hypervisorer. Modellen är densamma oavsett plattform: välj källa och riktning, ange ett dedikerat mål och säkerställ att den virtuella insamlingsportgruppen tillåter mottagning i promiscuöst läge.

I en Sophos Switch-session kan en liten pilotkonfiguration till exempel spegla port 1 till 4 i båda riktningarna till port 8:

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

Gränssnittsnumren är exempel och måste stämma med den egna kabeldragningen. Kontrollera före lagring att 0/8 faktiskt endast leder till NDR:s insamlingsväg. För andra tillverkare används deras dokumenterade SPAN-kommandon; liknande namn innebär inte automatiskt identisk semantik.

För en ESXi Standard vSwitch ställer du in insamlingsportgruppen på VLAN ID 4095 och under Security sätter du Promiscuous mode till Accept. Fysiskt speglad trafik kräver dessutom en dedikerad upplänk från switchen till rätt vSwitch. Intern VM-trafik kan kräva en separat virtuell speglingskälla. I Hyper-V måste NDR:s insamlingsgränssnitt vara anslutet som mål för portspeglingen på rätt vSwitch. Där kontrolleras plattformskonfigurationen separat från NDR-sensorinställningen.

Sophos NDR aktiverar SPAN Port 1 som standard, medan SPAN Port 2 är inaktiverad som standard. En andra SPAN-port är endast meningsfull om den tar emot en separat källa utan onödig överlappning. För SPAN Port 2 behöver den virtuella datorn minst 8 vCPU.

Använda ERSPAN med GRE eller VXLAN

ERSPAN transporterar kopior från fjärrkällor över ett IP-nätverk till sensorn. Därmed blir transportvägen en del av kapacitets- och felanalysen: MTU, routing, ACL:er och eventuell fragmentering kan påverka insamlingen trots att källsessionen är korrekt.

I Sophos Appliance Manager konfigureras rätt insamlingsgränssnitt under Settings:

VXLAN

Aktivera Enable ERSPAN bredvid den avsedda SPAN-porten.
Välj vxlan under Tunnel Protocol.
Ange adressen till VTEP-gränssnittet under IP Address.
Ställ in VXLAN ID och VXLAN Port exakt som på den inkapslande källan.
Välj Save.

GRE

Aktivera Enable ERSPAN bredvid den avsedda SPAN-porten.
Välj gre under Tunnel Protocol.
Ange adressen till GRE-målgränssnittet under IP Address.
Ange GRE Port enligt källkonfigurationen.
Välj Save.

Ändringar av SPAN-inställningarna träder i kraft först efter att den virtuella datorn har startats om. Kontrollera före omstarten om samma appliance bearbetar ytterligare integrationer, eftersom även deras datainsamling avbryts. Därefter måste tunnelparametrarna och bearbetningen valideras på nytt.

SPAN tillsammans med VXLAN på samma appliance är en vanlig design. VXLAN och GRE bör endast användas samtidigt på samma appliance om källor, kapacitet och feldomäner är tydligt åtskilda och dokumenterade.

Förstå AWS Traffic Mirroring

I AWS är arkitekturmodellen densamma: Mirror Source är den godkända arbetslastens ENI och inte NDR-sensorns hanterings-ENI. Mirror Target och filter måste ingå i den etablerade NDR-designen. Filtret begränsas till den avsedda dataomfattningen. Själva AWS-driftsättningen och skapandet av en Traffic Mirror Session beskrivs i ”Driftsätta Sophos NDR på AWS” och upprepas inte här.

För godkännandet används sedan evidenskedjan nedan. Enbart förekomsten av en AWS-session bevisar varken paketflöde till målet eller bearbetning, uppladdning eller detektering.

Begränsa kapaciteten före godkännande

SPAN Port 2 är ingen kapacitetsutökning: den virtuella datorn behöver minst 8 vCPU för att porten ska kunna aktiveras, men den andra ingången tillför trafik och därmed bearbetningsbehov. Den används endast för en separat källa som inte överlappar. Om paket- eller bytehastigheten ökar eller om paketförlusterna tilltar efter aktiveringen kontrollerar du om SPAN2 har tillfört extra eller dubblerad belastning.

Hur du utvärderar status-, unicast- och paketförlustsignaler och bedömer kapaciteten beskrivs i ”Övervaka hälsa och kapacitet för Sophos NDR”. Symtombaserad felsökning finns i ”Diagnostisera NDR Integration Appliance och sensorn”. Beroende på plattform kan extra VM-processorkapacitet eller en fördelning av belastningen utan överlappning till ytterligare en appliance användas som kapacitetsåtgärd. Andra CPU-intensiva integrationer måste planeras separat. Att enbart lägga till SPAN2 ökar inte bearbetningskapaciteten.

Validering: från källa till detektering

Kontrollen genomförs med en känd pilotvärd och ett fastställt tidsfönster. Då kan ett fel hänföras till ett visst steg i stället för att switch, tunnel, sensor och Sophos Fusion ändras samtidigt.

1. Konfiguration och topologi

Jämför källa, riktning och mål med täckningsmatrisen.
Kontrollera tillverkarstatusen för SPAN- eller AWS-sessionen.
Säkerställ att målet inte ingår som källa.
Kontrollera måladress, GRE- eller VXLAN-parametrar och nätverksväg för ERSPAN.
Kontrollera tilldelningen av nätverkskort för insamling, portgrupp eller vSwitch på virtuella plattformar.

2. Paket vid målet

Använd kontrollerad unicast-testtrafik från pilotvärden för att kontrollera om paketen når det avsedda insamlingsmålet. Dokumentera tidsfönster, målgränssnitt, förväntade käll- och måladresser samt, i förekommande fall, båda riktningarna som evidens. Det här steget visar att de kontrollerade paketen når det avsedda målet, men inte att de bearbetas eller laddas upp. Enbart broadcast-trafik är inget tillförlitligt test. Om paket saknas ska felsökningen tills vidare begränsas till källa, filter, riktning, transport och virtuell portgrupp.

3. Insamling och flöde på den avsedda SPAN-porten

Under Sophos Appliance Manager > NDR dokumenterar du det visade insamlingsvärdet i procent för exakt den avsedda SPAN-porten och aktiviteten i Total Flow-diagrammet under 30-sekundersfönstret. Båda måste tidsmässigt stämma med pilottrafiken. Det styrker aktivitet på den valda ingången. Visningarna bevisar varken fullständig paketinsamling, rätt dataomfattning, båda riktningarna eller en lyckad uppladdning.

Sophos aktuella klassificering bedömer en SPAN-port som felfri vid minst 2 procent unicast-nätverkspaket. Värdet är enbart den lägsta tröskeln för hälsoklassificeringen: i det aktuella stickprovet utesluter det endast att andelen unicast är noll. Även en felaktig, ofullständig, dubblerad, inaktuell eller för ändamålet olämplig trafikström kan nå 2-procentsgränsen. Värdet styrker därför varken förväntad källa och riktning, användbar trafik, täckning, visat insamlingsvärde, uppladdning eller detektering. Äldre uppgifter om 100 procent unicast används inte som aktuellt krav.

4. Bearbetning och uppladdning

Under Sophos Appliance Manager > NDR registrerar du det visade uppladdningsvärdet i procent för samma tidsfönster och jämför det tidsmässigt med insamlings- och flödesaktiviteten. Det dokumenterar uppladdningsaktivitet, men bevisar inte att varje speglat paket har laddats upp eller att en detektering senare skapas. Connected styrker i första hand anslutningen till appliance-enheten och ersätter inte denna evidens. Om signalerna för hälsa, insamling, uppladdning och paketförlust avviker från varandra följer du den systematiska diagnostiken av appliance och sensor.

5. Verksamhetsmässig täckning

Skapa riktad och tillåten testtrafik för varje rad i täckningsmatrisen och dokumentera tid, testenhet, förväntat segment, källa, mål och riktning. Evidensen från steg 2 till 4 kopplas till respektive test. Först med dessa stickprov går det att visa att de kontrollerade vägarna i princip samlas in. De styrker inte oprövade segment eller tidsfönster.

6. Ofarlig end-to-end-detektering

Först efter godkänd spegling genomför du det separata, godkända förfarandet ”Skapa och verifiera en säker Sophos NDR-testdetektering”. Hur testet genereras beskrivs inte här. Resultatet verifieras för den förväntade testenheten och tidsperioden under Threat Analysis Center > Detections och kopplas till den tidigare evidenskedjan. En testdetektering som visas där styrker den testade end-to-end-vägen. Den garanterar varken detektering av alla angreppstekniker eller täckning av andra vägar.

Avgränsa avvikelser stegvis

Vid ett misslyckat godkännande undersöks endast det första steget utan förväntad evidens: faktisk källväg, riktning och filter; därefter målkablage eller tilldelning av det virtuella insamlingsgränssnittet; för ERSPAN sedan transport och matchande tunnelvärden; därefter insamling och flöde på den avsedda porten; och slutligen uppladdning och detektering. Grön status eller minst 2 procent unicast innebär inte att något av stegen kan hoppas över. Gör endast en ändring åt gången och mät på nytt med samma pilot och tidsfönster.

Om endast en riktning eller ett segment saknas jämförs täckningsmatrisen med den faktiska fysiska eller virtuella vägen, utan att fler känsliga segment eller alla portar läggs till för säkerhets skull. Vid ovanligt hög paket- eller bytehastighet kontrolleras de dokumenterade överlappningarna en i taget mot räknare och pilottrafikens synlighet. Förfarandet avslutas med godkännande av speglingen och lokalisering av fel. Vid sensor-, uppladdnings- eller plattformsfel fortsätter du med diagnostiken av appliance och sensor.

Återställa ändringar i det här förfarandet säkert

Före varje utökning dokumenteras sessions-ID, källor, riktningar, filter, mål, tunnelparametrar samt baslinjevärden för paket- och bytehastighet. Följande återställning omfattar endast de speglingsändringar som har gjorts i det här förfarandet. Den beskriver inte hur en appliance, en molnstack eller annan infrastruktur avvecklas.

Vid störningar återställer du i omvänd ordning:

ta bort den senast tillagda lokala källan; radera en AWS Traffic Mirror Session som skapades i det här förfarandet,
återställ ett nyligen utökat filter till den dokumenterade pilotomfattningen,
inaktivera nyligen aktiverad ERSPAN eller återställ de tidigare tunnelvärdena,
inaktivera SPAN Port 2 om den har tillfört den nya belastningen eller överlappningen,
återställ den tidigare switch-sessionen om en fysisk spegling ändrades,
kontrollera paketflöde, paketförlustfrekvens, integrationsstatus och pilottrafik igen.

En återställning av Sophos SPAN-inställningar kräver återigen Save och en omstart av den virtuella datorn innan ändringen träder i kraft. Även då måste påverkan på andra integrationer på samma appliance beaktas. Återställningen är slutförd först när statusen inte bara är grön igen, utan de tidigare dokumenterade pilotvägarna också är synliga utan nya dubbletter och utan problematiska paketförluster.