Traffic Mirroring für Sophos NDR planen und validieren

Traffic Mirroring liefert Sophos NDR eine Kopie des Netzwerkverkehrs. Für lokale oder virtualisierte Netze geschieht das meist per SPAN, für entfernte Quellen gekapselt per ERSPAN über GRE oder VXLAN und in AWS über VPC > Traffic mirror sessions. Entscheidend ist nicht, möglichst viele Ports ungeprüft zu spiegeln. NDR braucht die richtigen Verkehrsbeziehungen, ohne Schleifen, unnötige Duplikate oder eine überlastete Zielstrecke.

Der sichere Ablauf ist:

zu beobachtende Verkehrsbeziehungen und Grenzen festlegen,
pro Beziehung genau einen geeigneten Beobachtungspunkt wählen,
Kapazität von Quelle bis NDR-Sensor prüfen,
zuerst eine kleine Pilotquelle spiegeln,
die Kette von der Quelle bis zur Verarbeitung stufenweise validieren,
Quellen nur kontrolliert erweitern und nach jeder Änderung erneut messen.

Vor der Aktivierung müssen Quelle, Richtung, Filter, Ziel, Wartungsfenster, zulässiger Datenumfang und Rollback-Verantwortung freigegeben und dokumentiert sein. Mirror-Daten können Nutzdaten und andere sensible Informationen enthalten. Deshalb dürfen unbeabsichtigte Benutzer-, Administrations-, Identitäts- oder andere sensible Segmente weder vorsorglich noch «zur Sicherheit» breit gespiegelt werden. Die Pilotquelle wird auf den genehmigten fachlichen und datenschutzrechtlichen Umfang begrenzt.

Quellen und Beobachtungspunkte auswählen

Vor der Konfiguration hilft eine kurze Abdeckungsmatrix. Darin stehen nicht einfach alle Switchports, sondern die relevanten Kommunikationswege, beispielsweise:

Clients zu Internet und externen Diensten,
Clients zu internen Servern,
Server untereinander, besonders über Segment- oder Sicherheitszonengrenzen,
Rechenzentrum zu Zweigstellen oder Cloud-Netzen,
Ost-West-Verkehr zwischen virtuellen Maschinen, der keinen physischen Uplink passiert.

Für jeden Weg wird ein Punkt gewählt, an dem beide Richtungen sichtbar sind. In der Regel ist das ein Trunk, ein VLAN oder ein Port nahe an einer Segmentgrenze. Ein Internet-Uplink zeigt Nord-Süd-Verkehr gut, sieht aber lokalen Verkehr im selben VLAN nicht. Ein physischer Switch sieht wiederum keinen Verkehr, der innerhalb desselben vSwitch bleibt. Solche Lücken lassen sich nicht aus einem grünen Sensorstatus ableiten; sie müssen aus Topologie und Testmatrix hervorgehen.

Quelle und Richtung

Eine SPAN-Quelle kann je nach Plattform ein Port, eine Portgruppe oder ein VLAN sein. Wenn möglich, wird both beziehungsweise eingehender und ausgehender Verkehr gespiegelt. Nur eine Richtung kann Antworten, Fehler und Teile einer Sitzung ausblenden.

Ein Trunk oder ganzes VLAN vereinfacht die Abdeckung, erhöht aber das Datenvolumen und die Wahrscheinlichkeit von Duplikaten. Einzelne Access-Ports sind gezielter, werden bei Umzügen oder dynamischen Workloads jedoch leichter vergessen. Die Wahl richtet sich deshalb nach der Verkehrsbeziehung und nicht nach der Anzahl verfügbarer Quellen.

Ziel

Das Spiegelziel ist ausschliesslich der Capture-Pfad des NDR-Sensors:

bei einer VM die Portgruppe oder der vSwitch, an dem SPAN1 beziehungsweise SPAN2 angeschlossen ist,
bei einer physischen Verbindung der dedizierte Switchport zum SPAN-Interface,
bei ERSPAN die konfigurierte GRE- oder VXLAN-Zieladresse des Sensors,
in AWS das vom CloudFormation-Stack erstellte NDR SPAN Target.

Die Management-Schnittstelle gehört nicht als SPAN-Ziel in diese Kette. Der Zielport wird zudem nicht als normale Quelle verwendet und soll keinen produktiven Datenverkehr zurück ins Netz senden.

Schleifen und doppelte Pakete vermeiden

Port Mirroring kopiert Pakete, es darf sie nicht in den produktiven Weiterleitungspfad zurückführen. Eine Schleife entsteht beispielsweise, wenn das SPAN-Ziel zugleich wieder gespiegelt oder als normaler Uplink genutzt wird. Doppelte Daten entstehen häufiger: Dasselbe Paket wird am Access-Port und am Uplink, auf beiden Seiten einer Segmentgrenze oder gleichzeitig per lokalem SPAN und ERSPAN erfasst.

Vor dem Aktivieren wird deshalb geprüft:

Das Zielinterface ist nur Ziel und nie Quelle derselben oder einer überlappenden Session.
Ein End-to-End-Verkehrspfad wird möglichst an genau einer aussagekräftigen Grenze gespiegelt.
Zwei SPAN-Ports erhalten keine überlappenden Quellen, ausser diese Überschneidung ist dokumentiert und für einen zeitlich begrenzten Test beabsichtigt.
Broadcasts und Multicasts werden nicht an mehreren Stellen desselben Layer-2-Bereichs gesammelt.
Bei einem Cluster oder vMotion ist klar, auf welchem Host und Uplink der physische Mirror ankommt. Eine NDR-VM mit Standard-SPAN von einem physischen Switch muss auf dem ESXi-Host bleiben, der diesen Verkehr empfängt.
In AWS existiert pro ENI und beabsichtigtem Verkehrsbereich nur die notwendige Session. Session-Reihenfolge und Filter werden mitgeprüft.

Duplikate verbrauchen Capture-, Tunnel- und CPU-Kapazität, ohne die fachliche Abdeckung zu verbessern. Verdächtig sind nahezu doppelte Paket- oder Byte-Raten nach dem Hinzufügen einer Quelle, obwohl der produktive Verkehr gleich blieb. Dann wird die zuletzt hinzugefügte Quelle wieder deaktiviert und die Topologie auf Überschneidungen geprüft.

SPAN lokal oder im Hypervisor konfigurieren

Die konkrete Syntax unterscheidet sich je nach Switch und Hypervisor. Unabhängig von der Plattform bleibt das Modell gleich: Quelle und Richtung auswählen, ein dediziertes Ziel festlegen und sicherstellen, dass die virtuelle Capture-Portgruppe Promiscuous-Empfang zulässt.

Bei einer Sophos-Switch-Session kann eine kleine Pilotkonfiguration beispielsweise die Ports 1 bis 4 in beiden Richtungen auf Port 8 spiegeln:

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

Die Interface-Nummern sind Beispiele und müssen zur eigenen Verkabelung passen. Vor dem Speichern ist zu kontrollieren, dass 0/8 tatsächlich nur zum NDR-Capture-Pfad führt. Bei anderen Herstellern werden deren dokumentierte SPAN-Befehle verwendet; ähnliche Namen bedeuten nicht automatisch identische Semantik.

Für einen ESXi Standard vSwitch setzt man die Capture-Portgruppe auf VLAN ID 4095 und unter Security den Wert Promiscuous mode auf Accept. Physisch gespiegelter Verkehr benötigt zusätzlich einen dedizierten Uplink vom Switch zum passenden vSwitch. Interner VM-Verkehr kann eine separate virtuelle Mirror-Quelle benötigen. Bei Hyper-V muss die NDR-Capture-Schnittstelle als Ziel der Portspiegelung am richtigen vSwitch hängen; die Plattformkonfiguration wird dort getrennt von der NDR-Sensoreinstellung geprüft.

Sophos NDR aktiviert SPAN Port 1 standardmässig, SPAN Port 2 ist standardmässig deaktiviert. Ein zweiter SPAN-Port ist nur sinnvoll, wenn er eine getrennte Quelle ohne unnötige Überschneidung aufnimmt. Für SPAN Port 2 benötigt die VM mindestens 8 vCPUs.

ERSPAN mit GRE oder VXLAN einsetzen

ERSPAN transportiert die Kopien entfernter Quellen über ein IP-Netz zum Sensor. Damit wird der Transportpfad Teil der Kapazitäts- und Fehleranalyse: MTU, Routing, ACLs und mögliche Fragmentierung können die Erfassung beeinflussen, obwohl die Quell-Session korrekt ist.

Im Sophos Appliance Manager wird die passende Capture-Schnittstelle unter Settings konfiguriert:

VXLAN

Neben dem vorgesehenen SPAN-Port Enable ERSPAN aktivieren.
Unter Tunnel Protocol den Wert vxlan wählen.
Unter IP Address die Adresse des VTEP-Interfaces eintragen.
VXLAN ID und VXLAN Port exakt wie an der kapselnden Quelle setzen.
Save wählen.

GRE

Neben dem vorgesehenen SPAN-Port Enable ERSPAN aktivieren.
Unter Tunnel Protocol den Wert gre wählen.
Unter IP Address die Adresse des GRE-Zielinterfaces eintragen.
GRE Port passend zur Quellkonfiguration eintragen.
Save wählen.

Änderungen an den SPAN-Einstellungen werden erst nach einem Neustart der VM wirksam. Vor dem Neustart wird geprüft, ob dieselbe Appliance weitere Integrationen verarbeitet; deren Datenerfassung wird dabei ebenfalls unterbrochen. Danach müssen Tunnelparameter und Verarbeitung erneut validiert werden.

SPAN zusammen mit VXLAN auf derselben Appliance ist ein übliches Design. VXLAN und GRE gleichzeitig auf derselben Appliance sollte man nur einsetzen, wenn Quellen, Kapazität und Fehlerdomänen klar getrennt und dokumentiert sind.

AWS Traffic Mirroring einordnen

In AWS bleibt das Architekturmodell gleich: Mirror Source ist die ENI des genehmigten Workloads und nicht die Management-ENI des NDR-Sensors; Mirror Target und Filter müssen zum bereitgestellten NDR-Design gehören. Der Filter wird auf den beabsichtigten Datenumfang begrenzt. Die eigentliche AWS-Bereitstellung und das Erstellen der Traffic Mirror Session sind in «Sophos NDR auf AWS bereitstellen» beschrieben und werden hier nicht dupliziert.

Für die Abnahme wird danach die unten beschriebene Evidenzkette verwendet. Die blosse Existenz einer AWS-Session belegt weder Paketfluss zum Ziel noch Verarbeitung, Upload oder Erkennung.

Kapazität vor der Abnahme begrenzen

SPAN Port 2 ist keine Kapazitätserweiterung: Die VM benötigt für seine Aktivierung mindestens 8 vCPUs, der zweite Eingang fügt aber Verkehr und damit Verarbeitungsbedarf hinzu. Er wird nur für eine getrennte, nicht überlappende Quelle verwendet. Steigen Rate oder Paketverluste nach seiner Aktivierung, wird geprüft, ob SPAN2 zusätzliche oder doppelte Last eingebracht hat.

Wie Sie Status-, Unicast- und Drop-Signale auswerten und die Kapazität beurteilen, beschreibt «Sophos NDR Health und Kapazität überwachen». Schritte zur symptombezogenen Fehlerbehebung finden Sie unter «NDR Integration Appliance und Sensor diagnostizieren». Als Kapazitätsmassnahme kommen je nach Plattform zusätzliche VM-CPU oder eine nicht überlappende Verteilung auf eine weitere Appliance infrage; CPU-intensive weitere Integrationen müssen getrennt eingeplant werden. Das Hinzufügen von SPAN2 allein erhöht die Verarbeitungskapazität nicht.

Validierung: von der Quelle bis zur Erkennung

Die Prüfung wird mit einem bekannten Pilot-Host und einem festgelegten Zeitfenster durchgeführt. So lässt sich ein Fehler einer Stufe zuordnen, statt gleichzeitig Switch, Tunnel, Sensor und Sophos Fusion zu verändern.

1. Konfiguration und Topologie

Quelle, Richtung und Ziel mit der Abdeckungsmatrix vergleichen.
Herstellerstatus der SPAN- oder AWS-Session prüfen.
Sicherstellen, dass das Ziel nicht als Quelle enthalten ist.
Bei ERSPAN Zieladresse, GRE- oder VXLAN-Parameter und Netzpfad abgleichen.
Bei virtuellen Plattformen Zuordnung von Capture-NIC, Portgruppe oder vSwitch prüfen.

2. Pakete am Ziel

Mit einem kontrollierten Unicast-Testverkehr vom Pilot-Host prüfen, ob Pakete am vorgesehenen Capture-Ziel ankommen. Als Evidenz werden Zeitfenster, Zielinterface, erwartete Quell- und Zieladressen sowie – sofern vorgesehen – beide Richtungen festgehalten. Diese Stufe belegt die Ankunft der geprüften Pakete am vorgesehenen Ziel, aber noch nicht deren Verarbeitung oder Upload. Broadcast allein ist kein belastbarer Test. Wenn Pakete fehlen, bleibt die Eingrenzung vorerst bei Quelle, Filter, Richtung, Transport und virtueller Portgruppe.

3. Capture und Flow am vorgesehenen SPAN-Port

Unter Sophos Appliance Manager > NDR für genau den vorgesehenen SPAN-Port den angezeigten Capture-Wert in Prozent und im 30-Sekunden-Fenster die Aktivität im Total-Flow-Graphen protokollieren. Beides muss zeitlich zum Pilotverkehr passen. Damit ist Aktivität am gewählten Eingang belegt; die Anzeigen beweisen weder vollständige Paketübernahme noch den richtigen Datenumfang, beide Richtungen oder einen erfolgreichen Upload.

Die aktuelle Sophos-Klassifikation bezeichnet einen SPAN-Port bei mindestens 2 Prozent Unicast-Netzwerkpaketen als gesund. Dieser Wert ist ausschliesslich der minimale Health-Klassifikator: Er schliesst in der betrachteten Stichprobe lediglich einen Unicast-Anteil von null aus. Auch eine falsche, partielle, doppelte, veraltete oder für den Zweck ungeeignete Einspeisung kann die 2-Prozent-Grenze erfüllen. Der Wert belegt daher weder erwartete Quelle und Richtung, nützlichen Verkehr, Abdeckung, den angezeigten Capture-Wert, Upload noch Erkennung. Ältere Hinweise auf 100 Prozent Unicast werden nicht als aktuelle Vorgabe verwendet.

4. Verarbeitung und Upload

Unter Sophos Appliance Manager > NDR den angezeigten Upload-Wert in Prozent für dasselbe Zeitfenster erfassen und zeitlich mit Capture- und Flow-Aktivität vergleichen. Das dokumentiert Upload-Aktivität, beweist aber nicht, dass jedes gespiegelte Paket hochgeladen wurde oder später eine Detection entsteht. Connected belegt primär die Verbindung der Appliance und ersetzt diese Evidenz nicht. Weichen Health-, Capture-, Upload- und Drop-Signale voneinander ab, folgen Sie der systematischen Diagnose von Appliance und Sensor.

5. Fachliche Abdeckung

Für jede Zeile der Abdeckungsmatrix gezielten, zulässigen Testverkehr erzeugen und Zeit, Testgerät, erwartetes Segment, Quelle, Ziel und Richtung protokollieren. Die Evidenz aus den Stufen 2 bis 4 wird diesem Test zugeordnet. Erst diese Stichproben zeigen, dass die geprüften Pfade grundsätzlich erfasst werden; sie sind kein Nachweis für unbeprobte Segmente oder Zeitfenster.

6. Harmlose End-to-End-Erkennung

Erst nach erfolgreicher Mirror-Abnahme führen Sie den separaten, genehmigten Ablauf «Sichere Sophos NDR Test-Detection erzeugen und prüfen» aus. Die Testgenerierung wird hier nicht vorweggenommen. Das Resultat wird für das erwartete Testgerät und Zeitfenster unter Threat Analysis Center > Detections verifiziert und mit der bisherigen Evidenzkette verknüpft. Eine dort beobachtete Test-Detection belegt den getesteten End-to-End-Pfad; sie garantiert weder die Erkennung jeder Angriffstechnik noch die Abdeckung anderer Pfade.

Abweichungen stufenweise eingrenzen

Bei einer fehlgeschlagenen Abnahme wird nur die erste Stufe ohne erwartete Evidenz untersucht: tatsächlicher Quellpfad, Richtung und Filter; danach Zielverkabelung oder virtuelle Capture-Zuordnung; bei ERSPAN anschliessend Transport und passende Tunnelwerte; danach Capture/Flow am vorgesehenen Port; schliesslich Upload und Detection. Ein grüner Status oder mindestens 2 Prozent Unicast überspringt keine dieser Stufen. Es wird jeweils nur eine Änderung vorgenommen und mit demselben Pilot sowie Zeitfenster erneut gemessen.

Fehlen nur Richtung oder Segment, wird die Abdeckungsmatrix gegen den tatsächlichen physischen oder virtuellen Pfad geprüft, ohne vorsorglich weitere sensible Segmente oder alle Ports aufzunehmen. Bei auffällig hoher Rate werden die dokumentierten Überlappungen einzeln gegen Zähler und die Sichtbarkeit des Pilotverkehrs geprüft. Dieser Ablauf endet mit der Mirror-Abnahme und Fehlerlokalisierung; bei Sensor-, Upload- oder Plattformfehlern führen Sie mit der Diagnose von Appliance und Sensor fort.

Änderungen dieses Ablaufs sicher zurückrollen

Vor jeder Erweiterung werden Session-ID, Quellen, Richtungen, Filter, Ziel, Tunnelparameter und Ausgangsraten festgehalten. Der folgende Rückweg umfasst nur die in diesem Ablauf neu vorgenommenen Mirror-Änderungen; er ist keine Anleitung zum Abbau einer Appliance, eines Cloud-Stacks oder weiterer Infrastruktur.

Bei Störungen wird in umgekehrter Reihenfolge zurückgerollt:

die zuletzt hinzugefügte lokale Quelle entfernen; eine für diesen Ablauf neu erstellte AWS Traffic Mirror Session löschen,
einen zuletzt erweiterten Filter auf den dokumentierten Pilotumfang zurücksetzen,
neu aktiviertes ERSPAN deaktivieren oder die vorherigen Tunnelwerte wiederherstellen,
SPAN Port 2 deaktivieren, wenn er die neue Last oder Überschneidung eingebracht hat,
bei einem geänderten physischen Mirror die vorherige Switch-Session wiederherstellen,
Paketfluss, Drop-Rate, Integrationsstatus und Pilotverkehr erneut prüfen.

Ein Rollback der Sophos-SPAN-Einstellungen erfordert wieder Save und einen VM-Neustart, bevor die Änderung wirksam ist. Auch dabei werden die Auswirkungen auf weitere Integrationen derselben Appliance berücksichtigt. Der Rollback ist erst abgeschlossen, wenn nicht nur der Status wieder grün ist, sondern die zuvor dokumentierten Pilotpfade ohne neue Duplikate und ohne problematische Paketverluste sichtbar sind.