Sophos Firewall Discover Mode mit TAP und SPAN einrichten

Im Discover Mode empfängt die Sophos Firewall eine Kopie des Netzwerktraffics über ein TAP-Interface. Der Switch spiegelt dazu ausgewählte Ports oder VLANs auf einen SPAN- beziehungsweise Mirror-Port, der mit einem ungebundenen Firewall-Port verbunden wird. Die Firewall steht nicht inline und verändert den produktiven Paketpfad nicht.

Kurzablauf: Einen separaten Managementzugang sicherstellen, auf dem Switch einen bidirektionalen SPAN-Port einrichten, einen ungebundenen Firewall-Port wählen, in der Device Console system discover-mode tap add PortD ausführen und den Eingang zuerst mit Packet Capture prüfen. Danach werden Current Activity, Reports und bei Bedarf ein Security audit report ausgewertet.

⚠️ Discover Mode ist ein Beobachtungsmodus. Auf Traffic am TAP-Interface lassen sich keine Security Policies anwenden, und die Firewall kann ihn weder blockieren noch verwerfen. HTTPS wird in diesem Modus nicht unterstützt. Ein unauffälliger Report beweist deshalb weder vollständige Sichtbarkeit noch wirksamen Schutz.

PortD ist in dieser Anleitung ein Beispiel. Verwendet wird der tatsächlich freie physische Port der eigenen Appliance.

Discover Mode in acht Schritten

Einen unabhängigen Managementport der Firewall und einen sicheren Rückweg zur Administration prüfen.
Auf dem Switch festlegen, welche Ports oder VLANs in beiden Richtungen gespiegelt werden sollen.
Einen dedizierten Mirror-Port mit einem ungebundenen physischen Firewall-Port verbinden.
In der Device Console mit system discover-mode tap show den Ausgangszustand sichern.
Den Beispielport mit system discover-mode tap add PortD als TAP aktivieren.
Unter Network > Interfaces den Typ Discover, physical (TAP) kontrollieren.
Einen bekannten Testflow erzeugen und dessen Pakete auf dem TAP-Interface nachweisen.
Erst danach Reports, Benutzerzuordnung und einen Security Audit Report bewerten.

Der Switch und die Firewall werden getrennt konfiguriert. Ein sichtbares TAP-Interface beweist noch nicht, dass der Switch die richtigen Frames spiegelt.

Wann TAP passt und wann nicht

Discover Mode passt für eine passive Bestandsaufnahme, einen Proof of Concept oder eine Voranalyse vor einer späteren Inline-Einführung. Typische Ziele sind:

Traffic-Beziehungen und aktive Anwendungen sichtbar machen;
Web- und Anwendungskategorien in den technisch unterstützten Grenzen einordnen;
IPS-Erkennungen beobachten, ohne den Datenpfad zu verändern;
Berichte für eine spätere Policy- und Segmentierungsplanung sammeln;
eine neue Firewall parallel zur bestehenden Infrastruktur bewerten.

TAP ist nicht die richtige Wahl, wenn Traffic bereits aktiv blockiert, entschlüsselt, per NAT verändert oder durch benutzerbasierte Regeln gesteuert werden muss. Dafür braucht es Gateway-, Bridge- oder einen anderen Inline-Betrieb mit passenden Firewall-Regeln.

Discover Mode lässt sich mit Gateway-, Mixed- und Bridge-Betrieb kombinieren. Die Sicherheitsregeln wirken dann auf den normalen Inline-Interfaces, nicht auf dem TAP-Interface. Wie physische Ports, Zonen, Bridge und andere Interface-Typen zusammenhängen, erklärt Sophos Firewall Zonen und Interfaces planen.

Beispieltopologie und austauschbare Werte

Das Beispiel verwendet diese Komponenten:

Core-Switch: SW-Core-01
zu spiegelnder Uplink: Switch-Port 1, Empfang und Senden
SPAN-Destination: Switch-Port 24
Firewall-TAP: PortD, ungebunden und ohne IP-Konfiguration
Firewall-Management: PortA - 10.10.10.16/24
Testclient: 10.20.30.40

Die Namen und Adressen sind Muster. Entscheidend ist die Funktion: Der TAP-Port erhält nur die gespiegelten Frames. Management, Updates, DNS und Reportversand laufen über ein anderes, normal konfiguriertes Interface.

Der Mirror-Port muss mindestens so schnell sein wie der zu beobachtende Datenstrom. Werden mehrere stark ausgelastete Quellports auf einen langsameren Zielport gespiegelt, kann der Switch Pakete aus der Kopie verwerfen. Die produktive Verbindung läuft trotzdem weiter, der Report bleibt jedoch unvollständig. TAP ist deshalb kein verlustfreier forensischer Mitschnitt und ein fehlendes Ereignis kein Beweis dafür, dass es nicht stattgefunden hat.

Voraussetzungen und Sicherheitsgrenzen

Vor der Aktivierung müssen diese Punkte geklärt sein:

Ein verwalteter Switch unterstützt SPAN oder Port Mirroring.
Ein physischer Firewall-Port ist ungebunden und wird nicht produktiv verwendet.
Die Administration bleibt über ein separates Interface erreichbar.
Die Firewall erreicht das Internet für On-Cloud-Klassifizierung, IPS-Updates und die Erzeugung des Security Audit Report.
Falls der Report Benutzer statt nur IP-Adressen zeigen soll, ist eine passende externe Authentifizierungsquelle integriert.
Zweck, Aufbewahrung und Empfängerkreis der gespiegelten Daten sind datenschutzrechtlich geklärt.

Die gespiegelten Frames können interne Adressen, DNS-Anfragen, unverschlüsselte Protokolle und Kommunikationsbeziehungen offenlegen. Packet Captures und Reports werden deshalb nur so lange wie nötig aufbewahrt und geschützt übertragen.

Port Affinity richtig einordnen

Die Sophos-Anleitung empfiehlt für bestimmte Plattformen, das TAP-Interface vor der Aktivierung mit bind-with an eine CPU zu binden. Für XGS-Appliances ist keine manuelle Port Affinity nötig, weil die Verarbeitung automatisch über die CPU-Kerne verteilt wird.

Auf anderen Appliances und virtuellen Plattformen hängt eine sinnvolle CPU-Zuordnung von Hardware, Adapter und Last ab. Deshalb keinen CPU-Wert aus einem fremden Beispiel übernehmen. Wenn die Plattform eine manuelle Zuordnung benötigt, wird sie vor dem TAP-Rollout mit der passenden Geräte- oder Supportvorgabe geplant. Ein pauschales set port-affinity gehört nicht in den normalen Kurzablauf.

Bei einer virtuellen Firewall muss zusätzlich sichergestellt sein, dass Hypervisor, vSwitch und virtuelle Netzwerkkarte die gespiegelten Frames tatsächlich an die VM liefern. Der Status der virtuellen Netzwerkkarte allein bestätigt das nicht; entscheidend ist der Paketnachweis in SFOS.

SPAN oder Port Mirroring am Switch vorbereiten

Die genaue Konfiguration ist herstellerspezifisch. Auf dem Switch werden mindestens diese Werte festgelegt:

Source: der zu beobachtende physische Port oder die vorgesehenen VLANs.
Direction: Empfang und Senden, damit Hin- und Rückweg sichtbar sind.
Destination: der dedizierte Port, der mit PortD der Firewall verbunden wird.
Session status: aktiviert.

Der Destination-Port wird nicht gleichzeitig als normaler Access- oder Trunk-Port für Endgeräte verwendet. Auch der Managementport der Firewall wird nicht an den Mirror-Port angeschlossen. Sonst vermischen sich Management- und Beobachtungspfad oder der Switch erzeugt einen unerwarteten Layer-2-Aufbau.

Vor der Firewall-Konfiguration sollte dokumentiert werden, welche VLANs und Richtungen der Switch wirklich spiegelt. Bei grossen Uplinks beginnt der Pilot besser mit einem einzelnen Test-VLAN oder einem klar begrenzten Port statt sofort mit dem gesamten Core-Traffic.

TAP-Interface auf Sophos Firewall aktivieren

Unter Network > Interfaces muss der gewählte Port die Zone None besitzen und darf keine IP-Konfiguration oder produktive Abhängigkeit haben. Einen bereits genutzten Port nicht nur für den Test unbinden: Das kann Interface Hosts, DHCP, Routing, Regeln oder andere Dienste unterbrechen.

Nach dem SSH-Login auf Sophos Firewall wird Option 4: Device Console geöffnet. Zuerst den bestehenden Zustand lesen:

system discover-mode tap show

Danach den vorgesehenen Beispielport aktivieren und erneut prüfen:

system discover-mode tap add PortD
system discover-mode tap show

Sophos dokumentiert für eine erfolgreiche Aktivierung die Meldung Discover Interface added successfully. Im WebAdmin erscheint der Port anschliessend unter Network > Interfaces als Discover, physical (TAP).

Der Befehl richtet kein SPAN auf dem Switch ein. Bleibt der Port trotz richtiger SFOS-Anzeige ohne Traffic, wird zuerst die Switch-Seite geprüft und nicht auf Verdacht eine Firewall-Regel erstellt.

Traffic nachweisen und Reports abnehmen

1. Einen kontrollierten Paketnachweis durchführen

Auf dem Testclient 10.20.30.40 wird ein klarer DNS- oder unverschlüsselter HTTP-Test erzeugt. Unter Diagnostics > Packet capture wird ein enger BPF-Filter verwendet:

host 10.20.30.40

Im Capture müssen Pakete mit In interface PortD sichtbar sein. Bei bidirektionalem Mirroring erscheinen Anfrage und Antwort. Eine Firewall Rule ID oder ein Forwarded-Status ist auf dem passiven TAP-Pfad kein Erfolgskriterium, weil SFOS diesen Traffic nicht weiterleitet und keine Security Policy darauf anwendet.

Die Bedienung, Filter und Exportgrenzen erklärt Packet Capture im Sophos Firewall WebAdmin. Der Mitschnitt wird nach dem Test wieder beendet und enthält nur den notwendigen Zeitraum.

2. Sichtbarkeit fachlich prüfen

Nach dem Paketnachweis werden Current activities und die passenden lokalen Reports geprüft. Die Erwartung muss zum Protokoll passen:

sichtbare Quell- und Zieladressen stimmen mit dem Test überein;
Anwendungs- oder Webkategorie ist nur dort zu erwarten, wo SFOS den Traffic klassifizieren kann;
IPS-Erkennung ist Beobachtung, keine Blockierung;
Benutzer erscheinen nur mit funktionierender Identitätsquelle und passender Zuordnung;
HTTPS-Inhalte werden im Discover Mode nicht unterstützt.

Die externe Benutzerquelle wird separat getestet. Für Active Directory hilft Active Directory mit Sophos Firewall verbinden. Ein fehlender Benutzername bedeutet sonst nicht automatisch, dass der TAP-Traffic fehlt.

3. Security Audit Report erzeugen

Unter Reports > Show report settings > Report scheduling > Add wird als Typ Security audit report gewählt. Empfänger und Organisation werden bewusst eingetragen, danach werden Mailtransport und Reportinhalt getrennt geprüft.

Wie Send test mail, Generate now, Datenschutz, Sprache und HA-Verhalten abgegrenzt werden, erklärt Sophos Firewall Reports planen und per E-Mail versenden. Eine erfolgreiche Testmail beweist nur den Mailweg. Erst ein erzeugter Report mit plausiblen Daten bestätigt den Gesamtpfad.

HA und gemischte Betriebsarten

Discover Mode unterstützt nur Active-Passive HA. Active-Active HA ist nicht möglich, sobald eine der Firewalls im Discover Mode arbeitet.

Ein Active-Passive-Cluster kann nicht aufgebaut werden, während das TAP-Interface aktiv ist. Für die HA-Einrichtung wird der TAP-Port auf beiden Appliances deaktiviert, danach wird HA eingerichtet und das TAP-Interface auf beiden Geräten einzeln wieder aktiviert. Sophos weist ausserdem darauf hin, dass das TAP-Interface auch auf der passiven Appliance aktiv bleibt.

Darum werden Verkabelung, Switch-Mirroring und Datenempfang nach einem geplanten Rollenwechsel erneut geprüft. Es gibt keine Annahme, dass ein bestehender Reportzeitraum oder eine TAP-Beobachtung ohne Unterbruch auf dem anderen Node weiterläuft. Die Rollen-, Sync- und Node-Logik beschreibt Sophos Firewall HA einrichten.

In einem gemischten Gateway- oder Bridge-Design bleibt die Grenze ebenfalls klar: Normale Interfaces können Traffic weiterleiten und schützen. Das TAP-Interface empfängt nur die Spiegelkopie.

Probleme nach Symptom eingrenzen

Das TAP-Interface zeigt gar keine Pakete

Mit system discover-mode tap show den konfigurierten Port prüfen.
Unter Network > Interfaces den Typ Discover, physical (TAP) und den physischen Link kontrollieren.
Switch-Destination, Source-Ports oder VLANs und die Mirror-Richtung vergleichen.
Einen bekannten Testflow ohne zu engen Capture-Filter wiederholen.
Bei einer VM prüfen, ob die virtuelle Netzwerkkette gespiegelte Fremdframes an die Firewall liefert.

Eine Firewall-Regel ist nicht die Lösung, weil der TAP-Traffic nicht durch die normale Rule Engine weitergeleitet wird.

Nur eine Richtung ist sichtbar

Auf dem Switch ist häufig nur RX oder nur TX als Mirror-Quelle gewählt. Die Session auf both beziehungsweise beide Richtungen umstellen und denselben Test wiederholen. Bei asymmetrischem Routing kann der Rückweg zusätzlich über einen anderen physischen Uplink laufen, der nicht gespiegelt wird.

Pakete sind sichtbar, Reports bleiben leer oder unvollständig

Zuerst Zeitfenster, Reporttyp, Internetzugang, Patternstand und tatsächlich gespiegelte Protokolle prüfen. HTTPS wird im Discover Mode nicht unterstützt. Eine überlastete SPAN-Destination kann ausserdem Kopien verlieren, ohne den Produktivtraffic zu beeinträchtigen.

Wenn Benutzer fehlen, folgt die Authentifizierungsquelle. Wenn nur der Mailversand scheitert, wird zuerst die E-Mail-Benachrichtigung geprüft. Reporting-Dienste werden nicht auf Verdacht neu gestartet und lokale Reportdaten nicht als ersten Schritt gelöscht.

Ein Report zeigt Risiken, aber nichts wird blockiert

Das ist das erwartete Verhalten. Discover Mode bewertet eine Kopie. Aus einem Finding entsteht erst nach fachlicher Prüfung eine spätere Inline-Policy, Segmentierung oder andere Schutzmassnahme. Die TAP-Firewall kann den beobachteten Originalflow nicht nachträglich stoppen.

Discover Mode sicher zurückbauen

Vor dem Rückbau werden benötigte Reports, Zeiträume und Befunde gesichert. Danach:

Die SPAN-Session am Switch deaktivieren, damit keine weiteren Kopien eintreffen.
In der Device Console den Beispielport entfernen:

system discover-mode tap delete PortD
system discover-mode tap show

Unter Network > Interfaces prüfen, dass der Port nicht mehr als Discover, physical (TAP) erscheint.
Nicht mehr benötigte Security-Audit-Zeitpläne kontrolliert entfernen.
Den Switch-Destination-Port erst nach dokumentierter Prüfung wieder normal verwenden.
Soll der Firewall-Port künftig produktiv eingesetzt werden, Zone, IP, Abhängigkeiten und Regeln als eigene Änderung planen und testen.

Ein TAP-Rückbau darf nicht mit einer spontanen Inline-Migration vermischt werden. Gateway- oder Bridge-Betrieb verändert Routing, Regeln und Ausfallrisiko und braucht einen separaten Migrationsplan.

Checkliste

Separater Managementzugang funktioniert.
TAP-Port ist physisch, ungebunden und nicht anderweitig verwendet.
SPAN-Source, Direction und Destination sind dokumentiert.
Mirror-Destination ist nicht überbucht.
system discover-mode tap show zeigt den erwarteten Port.
Packet Capture sieht einen bekannten Testflow in beiden Richtungen.
Reports werden nur innerhalb der unterstützten Sichtbarkeit bewertet.
HTTPS und fehlende Enforcement-Wirkung sind dokumentiert.
Benutzerzuordnung wurde bei Bedarf separat geprüft.
Reportempfänger und Aufbewahrung sind freigegeben.
HA oder VM-Grenzen wurden im realen Aufbau getestet.
Rückbau und spätere Inline-Migration sind getrennte Changes.

FAQ

Kann Discover Mode Angriffe oder unerwünschte Anwendungen blockieren?

Nein. Die Firewall analysiert am TAP-Interface nur die gespiegelte Kopie. Security Policies lassen sich auf diesen Traffic nicht anwenden; Blockierung benötigt einen Inline-Pfad.

Kann Sophos Firewall im Discover Mode HTTPS entschlüsseln?

Nein. Sophos dokumentiert, dass HTTPS im Discover Mode nicht unterstützt wird. Der Modus ersetzt deshalb weder TLS Inspection noch einen Inline-Test von Web Policies.

Kann Discover Mode parallel zu einer normalen Firewall-Konfiguration laufen?

Ja. Discover Mode lässt sich mit Gateway-, Mixed- oder Bridge-Betrieb kombinieren. Der TAP-Port bleibt passiv; Regeln und Security Policies wirken nur auf den normalen Inline-Interfaces.