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.

Welche Security-Funktionen tatsächlich sichtbar sind

SFOS 22 trennt Erkennung und Kontrolle im Discover Mode deutlich. Current activity, Reports und User Identity sind verfügbar. Mit der jeweils nötigen Subscription sind auch IPS detection, Sophos X-Ops Threat Feeds, Security Heartbeat, Synchronized Application Control, URL-basierte Web Categorization sowie signaturbasierte Application Classification verfügbar. MDR Threat Feeds und NDR Essentials gehören ebenfalls zu den von Sophos als verfügbar aufgeführten Funktionen.

Die SFOS-23-Tabelle führt dieselben Funktionen und Grenzen auf. Die Subscription-Zuordnung in beiden Versionen hilft, die Voraussetzungen für den Pilot zu prüfen:

Base Subscription: Current activity, Reports, User identity und Active-Passive HA. Auch DoS protection ist als verfügbar markiert; daraus darf keine Blockierung des produktiven Originaltraffics durch den passiven TAP-Port abgeleitet werden.
Network Protection: IPS detection, Sophos X-Ops Threat Feeds, Security Heartbeat und Synchronized Application Control.
Web Protection: URL-basierte Web Categorization über IPS und signaturbasierte Application Classification.
Xstream Protection Bundle: MDR Threat Feeds und NDR Essentials.

Eine verfügbare Subscription hebt die TAP-Grenzen nicht auf. Vor dem Pilot werden die benötigten Subscriptions auf der konkreten Firewall geprüft; die Tabelle ist kein Nachweis, dass jede Funktion auf der eigenen Appliance aktiv ist.

Die zugehörigen Kontrollen sind dagegen nicht verfügbar: keine Firewall- oder benutzerbasierte Policy, kein IPS Control, Web Filtering oder Application Filtering. Auch HTTPS Micro Apps, Antivirus, Mail- und WAF-Schutz gehören nicht zum TAP-Pfad. Gleiches gilt für IPv6, Netzwerkdienste wie ARP, Routing, DNS und DHCP, Spoofing Protection, VPN, Wireless, Traffic ACL, QoS und RED-Verwaltung. Die Feature-Tabelle in der SFOS-22-Hilfe ist damit die Grenze für die Auswertung: Ein sichtbarer Heartbeat, Benutzer oder Anwendungsname ist Telemetrie und keine durchgesetzte Regel.

Für den TAP-Port wird deshalb keine Firewall-Regel erstellt. Network zone: None ist die Voraussetzung zum Freigeben eines zuvor gebundenen Ports; nach der Aktivierung erscheint er als Discover, physical (TAP). Zonen- und Regelobjekte werden nur für die getrennten Inline-Interfaces eines gemischten Aufbaus konfiguriert.

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.

Als externe Authentifizierungsquellen nennt die Discover-Anleitung für SFOS 22 und 23 Microsoft Entra ID, RADIUS, LDAP und Apple Directory. Nur die SFOS-22-Liste nennt zusätzlich Novell eDirectory; dieser Altpfad wird nicht als SFOS-23-Voraussetzung übernommen. Für eine vorhandene eDirectory-Umgebung hilft eDirectory vor SFOS 23 migrieren. Die Integration allein ersetzt nicht die separate Prüfung der Benutzerzuordnung im SAR.

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.

Port Affinity lässt sich nur für bereits konfigurierte Interfaces setzen. PortD und CPU 2 sind austauschbare Beispiele; vor der Änderung werden reale Port-ID, vorhandene CPU-Kerne, Ausgangslast und ein Rückweg dokumentiert:

set port-affinity add port PortD bind-with cpu 2
set port-affinity del port PortD
set port-affinity defsetup

del entfernt die Zuordnung des gewählten Ports. defsetup wendet die Standardkonfiguration an und wird deshalb nicht als beiläufiger Rollback für nur einen Port behandelt. Die ebenfalls dokumentierte Variante start-with erhält ohne plattformbezogene Vorgabe keinen geratenen CPU-Wert. fwonlysetup ist laut Sophos das Legacy-Default und verarbeitet nur einfachen Firewalltraffic, nicht Proxy- oder IPS-Traffic; es ist kein Performance-Tuning für ein modernes System.

Bei virtuellen Appliances mit Legacy-Netzwerkadaptern wird Port Affinity nicht unterstützt; Sophos nennt als Beispiel eine Hyper-V-Bereitstellung mit solchen Adaptern. Nach einer tatsächlich notwendigen Zuordnung werden CPU-Verteilung, Paketverlust, TAP-Packet-Capture und Reportdaten mit demselben Testflow verglichen. Bringt die Änderung keinen reproduzierbaren Vorteil, wird die Portzuordnung mit del entfernt.

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.

TAP- und LAN-/Managementport dürfen am selben Switch angeschlossen sein: TAP am SPAN-Port, LAN/Management an einem anderen normalen Switch-Port.

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.

Variante: Ersteinrichtung mit dem Assistenten (SFOS 22 und 23)

Bei einer neuen Firewall kann TAP bereits im Einrichtungsassistenten aktiviert werden. Auf einem bestehenden System wird stattdessen der unten beschriebene CLI-Weg verwendet; für TAP ist kein Factory Reset nötig.

Port A für die getrennte Administration mit einem normalen Switch-Port verbinden und den freien TAP-Port, hier PortD, mit dem Mirror-Port.
Nur bei unveränderter Werksadresse den Managementrechner auf 172.16.16.2 mit Maske 255.255.255.0 setzen und https://172.16.16.16:4444 öffnen. Die dokumentierten Werkszugangsdaten sind Benutzer admin und Kennwort admin; sie gelten nicht für bereits geänderte Zugangsdaten. In einer bereits angepassten Umgebung gelten die vorhandene Managementadresse und die eigenen Zugangsdaten. Den Erstzugang isoliert durchführen und das Standardkennwort im Einrichtungsablauf ersetzen.
Click to begin wählen und dem Assistenten folgen.
Auf Network configuration (LAN) die Option Enable TAP/discover mode wählen.
Einen oder mehrere tatsächlich ungebundene Ports auswählen; im Beispiel nur PortD. Die dokumentierte Ausgangskonfiguration bindet A, B und C an LAN, DMZ und WAN. Massgeblich ist aber die reale Portbelegung, nicht der Buchstabe.
Apply, danach Continue wählen und die Ersteinrichtung abschliessen.
Den Interface-Typ und anschliessend den unten beschriebenen Paketnachweis prüfen. Auch der Assistent konfiguriert kein Port Mirroring auf dem Switch.

Variante: Aktivierung über die Device Console

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;
signaturbasierte Application Classification und URL-basierte Web Categorization erscheinen nur, wenn SFOS den Testflow tatsächlich zuordnen kann;
IPS-Erkennung ist Beobachtung, keine Blockierung;
Benutzer erscheinen nur mit funktionierender Identitätsquelle und passender Zuordnung;
Security Heartbeat und Synchronized Application Control liefern Sichtbarkeit, aber keine TAP-Policy;
HTTPS-Inhalte und HTTPS Micro Apps 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 und mit Save gespeichert. 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.