Konfigurera Sophos Firewall Discover Mode med TAP och SPAN

I Discover Mode tar Sophos Firewall emot en kopia av nätverkstrafiken via ett TAP-interface. Switchen speglar valda portar eller VLAN till en SPAN- eller mirror-port som är ansluten till en obunden brandväggsport. Brandväggen står inte inline och ändrar inte paketens produktionsväg.

Snabbprocedur: Säkerställ en separat administrationsåtkomst, konfigurera en dubbelriktad SPAN-port på switchen, välj en obunden brandväggsport, kör system discover-mode tap add PortD i Device Console och verifiera först den inkommande trafiken med Packet Capture. Granska därefter Current Activity, rapporter och vid behov en Security audit report.

⚠️ Discover Mode är ett observationsläge. Security Policies kan inte tillämpas på trafik vid TAP-interfacet och brandväggen kan varken blockera eller kassera den. HTTPS stöds inte i detta läge. En rapport utan fynd bevisar därför varken fullständig insyn eller ett effektivt skydd.

PortD är ett exempel i den här guiden. Använd den fysiska port som faktiskt är ledig på appliance-enheten.

Discover Mode i åtta steg

1. Verifiera en oberoende administrationsport på brandväggen och en säker återställningsväg till administrationen.
2. Fastställ på switchen vilka portar eller VLAN som ska speglas i båda riktningarna.
3. Anslut en dedikerad mirror-port till en obunden fysisk brandväggsport.
4. Spara utgångsläget i Device Console med system discover-mode tap show.
5. Aktivera exempelporten som TAP med system discover-mode tap add PortD.
6. Kontrollera typen Discover, physical (TAP) under Network > Interfaces.
7. Skapa ett känt testflöde och bekräfta dess paket på TAP-interfacet.
8. Först därefter utvärderas rapporter, användartilldelning och en Security Audit Report.

Switchen och brandväggen konfigureras separat. Ett synligt TAP-interface bevisar ännu inte att switchen speglar rätt ramar.

När TAP passar och när det inte gör det

Discover Mode passar för en passiv inventering, en proof of concept eller en föranalys inför en senare inline-implementering. Typiska mål är att:

• synliggöra trafikrelationer och aktiva applikationer;
• klassificera webb- och applikationskategorier inom de tekniska gränserna;
• observera IPS-detekteringar utan att ändra datavägen;
• samla rapporter för senare planering av policyer och segmentering;
• utvärdera en ny brandvägg parallellt med den befintliga infrastrukturen.

TAP är inte rätt val om trafiken redan måste blockeras aktivt, dekrypteras, ändras med NAT eller styras med användarbaserade regler. Då krävs gateway-, bridge- eller ett annat inline-läge med lämpliga brandväggsregler.

Discover Mode kan kombineras med gateway-, mixed- och bridge-läge. Säkerhetsreglerna gäller då för de normala inline-interfacen, inte för TAP-interfacet. Planera zoner och interface på Sophos Firewall förklarar hur fysiska portar, zoner, bryggor och andra interfacetyper hänger ihop.

Vilka säkerhetsfunktioner som faktiskt ger insyn

SFOS 22 skiljer tydligt mellan detektering och kontroll i Discover Mode. Current activity, rapporter och User Identity är tillgängliga. Med den prenumeration som krävs är även IPS detection, Sophos X-Ops Threat Feeds, Security Heartbeat, Synchronized Application Control, URL-baserad Web Categorization och signaturbaserad Application Classification tillgängliga. Sophos anger också MDR Threat Feeds och NDR Essentials som tillgängliga.

Tabellen för SFOS 23 anger samma funktioner och gränser. Prenumerationstilldelningen i båda versionerna hjälper till att kontrollera förutsättningarna för piloten:

• Base Subscription: Current activity, Reports, User identity och active-passive HA. Även DoS protection är markerat som tillgängligt; det betyder inte att den passiva TAP-porten kan blockera den ursprungliga produktionstrafiken.
• Network Protection: IPS detection, Sophos X-Ops Threat Feeds, Security Heartbeat och Synchronized Application Control.
• Web Protection: URL-baserad Web Categorization via IPS och signaturbaserad Application Classification.
• Xstream Protection Bundle: MDR Threat Feeds och NDR Essentials.

En tillgänglig prenumeration upphäver inte TAP-gränserna. Kontrollera de prenumerationer som krävs på den aktuella brandväggen före piloten; tabellen bevisar inte att varje funktion är aktiv på appliance-enheten.

Motsvarande kontrollfunktioner är däremot inte tillgängliga: ingen firewall- eller användarbaserad policy, IPS Control, Web Filtering eller Application Filtering. HTTPS Micro Apps, antivirus, e-postskydd och WAF ingår inte heller i TAP-vägen. Detsamma gäller IPv6, nätverkstjänster som ARP, routing, DNS och DHCP, Spoofing Protection, VPN, Wireless, Traffic ACL, QoS och RED-hantering. Funktionstabellen för SFOS 22 sätter därmed gränsen för utvärderingen: ett synligt heartbeat, en användare eller ett applikationsnamn är telemetri, inte en tillämpad regel.

Skapa därför ingen brandväggsregel för TAP-porten. Network zone: None är förutsättningen för att frigöra en tidigare bunden port; efter aktiveringen visas den som Discover, physical (TAP). Zon- och regelobjekt konfigureras endast för de separata inline-interfacen i en blandad driftsättning.

Dessa gränser gäller TAP-vägen, inte den separata administrationsåtkomsten eller andra inline-interface. Ett speglat DNS-paket i inspelningen betyder exempelvis inte att TAP-porten fungerar som DNS-server. Båda versionerna anger också Mail usage och Anti-spam som otillgängliga: en allmän trafikrapport är inte en rapport om e-postanvändning. Att skicka en SAR via e-post är en separat administrationsfunktion, inte ett bevis på e-postanalys på TAP-porten.

Exempeltopologi och utbytbara värden

Exemplet använder följande komponenter:

• Core-switch: SW-Core-01
• Uplink som ska speglas: Switch-Port 1, mottagning och sändning
• SPAN-destination: Switch-Port 24
• Brandväggens TAP: PortD, obunden och utan IP-konfiguration
• Brandväggshantering: PortA - 10.10.10.16/24
• Testklient: 10.20.30.40

Namnen och adresserna är exempel. Funktionen är avgörande: TAP-porten tar bara emot de speglade ramarna. Hantering, uppdateringar, DNS och rapportutskick går via ett annat, normalt konfigurerat interface.

Mirror-porten måste vara minst lika snabb som den trafik som observeras. Om flera hårt belastade källportar speglas till en långsammare destinationsport kan switchen kassera paket ur kopian. Produktionsanslutningen kan fortsätta att fungera medan rapporten blir ofullständig. Detta är dock ingen garanti för en överbelastad switch. TAP är därför inte en förlustfri forensisk inspelning, och en händelse som saknas är inget bevis för att den inte inträffade.

Dimensioneringen måste räkna med summan av de speglade riktningarna: en uplink på 1 Gbit/s som tar emot 700 Mbit/s och skickar 600 Mbit/s kan med dubbelriktad SPAN leverera upp till 1300 Mbit/s kopior till en destination på 1 Gbit/s. Även en enda källport kan alltså överbelasta destinationen. Siffrorna är ett räkneexempel, inte en prestandagräns för SFOS. Jämför switchens belastning och räknare för kasserade paket före och under piloten enligt tillverkarens anvisningar. Minska speglingens omfattning vid förluster i stället för att dra slutsatser om säkerheten från ofullständiga rapporter.

Förutsättningar och säkerhetsgränser

Följande punkter måste vara klarlagda före aktiveringen:

• En hanterad switch stöder SPAN eller port mirroring.
• En fysisk brandväggsport är obunden och används inte i produktion.
• Administrationen förblir nåbar via ett separat interface.
• Brandväggen har internetåtkomst för molnklassificering, IPS-uppdateringar och generering av Security Audit Report.
• Om rapporten ska visa användare i stället för enbart IP-adresser finns en lämplig extern autentiseringskälla integrerad.
• Syfte, lagringstid och mottagare för de speglade uppgifterna uppfyller integritetskraven.

De speglade ramarna kan exponera interna adresser, DNS-förfrågningar, okrypterade protokoll och kommunikationsrelationer. Spara därför Packet Captures och rapporter endast så länge som behövs och överför dem skyddat.

Discover-guiden för SFOS 22 och 23 anger Microsoft Entra ID, RADIUS, LDAP och Apple Directory som externa autentiseringskällor. Endast listan för SFOS 22 anger även Novell eDirectory; denna äldre väg används inte som en förutsättning för SFOS 23. För en befintlig eDirectory-miljö hjälper Migrera eDirectory före SFOS 23. Integrationen ensam ersätter inte den separata kontrollen av användartilldelning i SAR.

Bedöm Port Affinity korrekt

För vissa plattformar rekommenderar Sophos-guiden att TAP-interfacet binds till en CPU med bind-with före aktiveringen. XGS Appliances behöver ingen manuell Port Affinity eftersom bearbetningen automatiskt fördelas över CPU-kärnorna.

På andra appliances och virtuella plattformar beror en lämplig CPU-tilldelning på hårdvara, adapter och belastning. Kopiera därför inte ett CPU-värde från ett främmande exempel. Om plattformen kräver manuell tilldelning planeras den före TAP-utrullningen med rätt enhets- eller supportvägledning. Ett generellt set port-affinity hör inte hemma i den normala snabbproceduren.

Port Affinity kan endast tilldelas interface som redan är konfigurerade. PortD och CPU 2 är utbytbara exempel; dokumentera först verkligt Port ID, tillgängliga CPU-kärnor, startbelastning och rollback:

⚠️ Följande kommandon är syntaxreferenser för Device Console, inte en konfigurationssekvens som ska köras i ordning. Discover-guiden rekommenderar CPU-bindning före TAP, medan CLI-hjälpen kräver ett redan konfigurerat interface. På andra plattformar än XGS ska denna kombination klarläggas med support för den aktuella enheten innan affinity ändras; bind inte en produktionsport till en zon som genväg. add ändrar tilldelningen och del tar bort den, men återställer inte en tidigare anpassad tilldelning. En befintlig tilldelning kräver därför en dokumenterad, godkänd återställningsväg. XGS behöver inte denna manuella ändring.

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

del tar bort tilldelningen för den valda porten. defsetup tillämpar standardkonfigurationen och behandlas därför inte som en tillfällig rollback för endast en port. Den dokumenterade varianten start-with får inget gissat CPU-värde utan plattformsspecifik vägledning. Enligt Sophos är fwonlysetup Legacy-standard och hanterar endast vanlig firewalltrafik, inte Proxy- eller IPS-trafik; det är ingen prestandajustering för ett modernt system.

Port Affinity stöds inte på virtuella appliances med Legacy-nätverksadaptrar; Sophos anger en Hyper-V-distribution med sådana adaptrar som exempel. Efter en verkligt nödvändig tilldelning jämförs CPU-fördelning, paketförlust, TAP Packet Capture och reportdata med samma testflöde. Om ändringen inte ger någon reproducerbar fördel återställs det dokumenterade utgångsläget exakt via den återställningsväg som har godkänts i förväg och bekräftats för den aktuella plattformen. del används endast om det inte fanns någon tilldelning för denna port före ändringen, endast den tilldelning som infördes i denna procedur tas bort och plattformens anvisningar bekräftar att detta återställer det dokumenterade utgångsläget. En tidigare anpassad tilldelning återställs exakt via den bekräftade återställningsvägen; del återställer den inte. Därefter verifieras det återställda tillståndet med den kontrollmetod som har bekräftats för plattformen eller av support; CPU-fördelning, paketförlust, TAP Packet Capture och rapportdata kontrolleras på nytt med samma testflöde. Om utgångsläget eller återställningsvägen inte har bekräftats ändras inte tilldelningen; defsetup ersätter inte ett okänt utgångsläge.

För en virtuell brandvägg måste det dessutom säkerställas att hypervisor, vSwitch och virtuell nätverksadapter faktiskt levererar de speglade ramarna till den virtuella maskinen. Den virtuella nätverksadapterns status bekräftar inte detta ensam; paketbeviset i SFOS är avgörande.

Förbered SPAN eller port mirroring på switchen

Den exakta konfigurationen är tillverkarspecifik. Minst följande värden anges på switchen:

1. Source: den fysiska port som ska observeras eller de planerade VLAN:en.
2. Direction: mottagning och sändning, så att båda riktningarna blir synliga.
3. Destination: den dedikerade port som är ansluten till brandväggens PortD.
4. Session status: aktiverad.

Destinationsporten används inte samtidigt som en normal access- eller trunk-port för endpoints. Brandväggens administrationsport ansluts inte heller till mirror-porten. Annars blandas administrations- och observationsvägarna eller så skapar switchen en oväntad Layer 2-topologi.

TAP- och LAN/administrationsportarna får anslutas till samma switch: TAP till SPAN-porten, LAN/administration till en annan normal switchport.

Dokumentera före brandväggskonfigurationen vilka VLAN och riktningar switchen verkligen speglar. På stora uplinks bör piloten börja med ett enda test-VLAN eller en tydligt avgränsad port i stället för omedelbart med all core-trafik.

Aktivera TAP-interfacet på Sophos Firewall

Under Network > Interfaces måste den valda porten ha zonen None och får inte ha någon IP-konfiguration eller produktionsberoenden. Frigör inte en port som redan används bara för att genomföra testet: det kan avbryta interface hosts, DHCP, routing, regler eller andra tjänster.

Variant: första konfigurering med assistenten (SFOS 22 och 23)

På en ny brandvägg kan TAP aktiveras redan i konfigurationsassistenten. Använd i stället CLI-proceduren nedan på ett befintligt system; TAP kräver ingen Factory Reset.

1. Anslut port A till en normal switchport för separat administration och den lediga TAP-porten, här PortD, till mirror-porten.
2. Ställ endast vid oförändrad fabriksadress in administrationsdatorn på 172.16.16.2 med masken 255.255.255.0 och öppna https://172.16.16.16:4444. De dokumenterade fabriksuppgifterna är användarnamn admin och lösenord admin; de gäller inte efter att inloggningsuppgifterna har ändrats. I en redan anpassad miljö gäller den befintliga administrationsadressen och de egna inloggningsuppgifterna. Utför den första åtkomsten isolerat och byt standardlösenordet under konfigureringen.
3. Välj Click to begin och följ assistenten.
4. Välj Enable TAP/discover mode på Network configuration (LAN).
5. Välj en eller flera faktiskt obundna portar; i exemplet endast PortD. Den dokumenterade startkonfigurationen binder A, B och C till LAN, DMZ och WAN. Den verkliga porttilldelningen är avgörande, inte bokstaven.
6. Välj Apply, sedan Continue, och slutför den första konfigureringen.
7. Kontrollera interfacetypen och utför därefter paketkontrollen som beskrivs nedan. Assistenten konfigurerar inte heller port mirroring på switchen.

Variant: aktivering via Device Console

Efter SSH-inloggning på Sophos Firewall öppnas Option 4: Device Console. Läs först det aktuella tillståndet:

system discover-mode tap show

Aktivera därefter den planerade exempelporten och kontrollera igen:

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

Sophos dokumenterar meddelandet Discover Interface added successfully vid en lyckad aktivering. Porten visas därefter under Network > Interfaces som Discover, physical (TAP).

Kommandot konfigurerar inte SPAN på switchen. Om porten visar rätt SFOS-status men ingen trafik ska switchidan kontrolleras först, i stället för att en brandväggsregel skapas på misstanke.

Verifiera trafik och rapporter

1. Genomför en kontrollerad paketkontroll

Skapa ett tydligt DNS-test eller okrypterat HTTP-test på testklienten 10.20.30.40. Under Diagnostics > Packet capture används ett smalt BPF-filter:

host 10.20.30.40

I inspelningen måste paket med In interface PortD vara synliga. Vid dubbelriktad spegling visas begäran och svar. En Firewall Rule ID eller statusen Forwarded är inget framgångskriterium på den passiva TAP-vägen, eftersom SFOS inte vidarebefordrar trafiken och inte tillämpar någon Security Policy på den.

För ett meningsfullt test måste flödet faktiskt passera den speglade källporten eller valt VLAN. Använd ett godkänt DNS-test eller en intern HTTP-testsida utan inloggningsuppgifter eller känsligt innehåll; stäng inte av TLS-säkerheten i produktion för testet. Anteckna testtid, klient, destination, protokoll och förväntad riktning och jämför dem med inspelningen och rapportperioden. Om klienten får ett resultat men inget paket passerar speglingskällan är det inte ett SFOS-fel. Om synligheten fortfarande saknas, lämna dessa uppgifter till support tillsammans med SFOS-version, porttilldelning och SPAN-konfiguration, utan att skicka onödigt paketinnehåll.

Packet Capture i Sophos Firewall WebAdmin förklarar hantering, filter och exportgränser. Stoppa inspelningen efter testet och behåll endast den tidsperiod som behövs.

2. Kontrollera synligheten i sitt sammanhang

Modellbegränsning: XGS 87, 87w, 88 och 88w stöder inte lokala rapporter. På dessa modeller bevisar därför en saknad lokal rapport inte att TAP-konfigurationen är felaktig; paketverifiering krävs fortfarande.

Efter paketbeviset granskas Current activities och lämpliga lokala rapporter. Förväntningarna måste motsvara protokollet:

• synliga käll- och destinationsadresser stämmer med testet;
• signaturbaserad Application Classification och URL-baserad Web Categorization visas endast när SFOS kan koppla testflödet;
• en IPS-detektering är en observation, inte en blockering;
• användare visas endast med en fungerande identitetskälla och korrekt tilldelning;
• Security Heartbeat och Synchronized Application Control ger insyn, men ingen TAP-policy;
• HTTPS-innehåll och HTTPS Micro Apps stöds inte i Discover Mode.

Den externa användarkällan testas separat. För Active Directory hjälper Anslut Active Directory till Sophos Firewall. Ett saknat användarnamn betyder annars inte automatiskt att TAP-trafiken saknas.

3. Generera en Security Audit Report

Under Reports > Show report settings > Report scheduling > Add väljs typen Security audit report. Mottagare och organisation anges medvetet och sparas med Save. Därefter kontrolleras e-posttransport och rapportinnehåll separat.

Schemalägg Sophos Firewall-rapporter och skicka dem via e-post förklarar gränserna för Send test mail, Generate now, integritet, språk och HA-beteende. Ett lyckat testmeddelande bevisar bara e-postvägen. Först en genererad rapport med rimliga data bekräftar hela vägen.

HA och blandade driftlägen

Discover Mode stöder endast active-passive HA. Active-active HA är inte möjligt när någon av brandväggarna arbetar i Discover Mode.

Ett active-passive-kluster kan inte skapas medan TAP-interfacet är aktivt. För att konfigurera HA avaktiveras TAP-porten på båda appliances, HA skapas och därefter aktiveras TAP-interfacet igen individuellt på båda enheterna. Sophos påpekar också att TAP-interfacet förblir aktivt på den passiva enheten.

Därför kontrolleras kablage, switchspegling och datamottagning igen efter ett planerat rollbyte. Det antas inte att en befintlig rapportperiod eller TAP-observation fortsätter utan avbrott på den andra noden. Konfigurera HA på Sophos Firewall beskriver roller, synkronisering och nodlokalt beteende.

Även i en blandad gateway- eller bridge-design är gränsen tydlig: normala interface kan vidarebefordra och skydda trafik. TAP-interfacet tar bara emot den speglade kopian.

Felsök efter symptom

TAP-interfacet visar inga paket

1. Kontrollera den konfigurerade porten med system discover-mode tap show.
2. Kontrollera typen Discover, physical (TAP) och den fysiska länken under Network > Interfaces.
3. Jämför switch-destination, källportar eller VLAN och speglingsriktningen.
4. Upprepa ett känt testflöde utan ett alltför snävt inspelningsfilter.
5. Kontrollera på en VM om den virtuella nätverksvägen levererar speglade främmande ramar till brandväggen.

En brandväggsregel är inte lösningen, eftersom TAP-trafiken inte vidarebefordras genom den normala Rule Engine.

Endast en riktning är synlig

Mirror-källan på switchen är ofta inställd på endast RX eller TX. Ändra sessionen till both, alltså båda riktningarna, och upprepa samma test. Vid asymmetrisk routing kan returvägen dessutom gå via en annan fysisk uplink som inte speglas.

Paket är synliga, men rapporterna är tomma eller ofullständiga

Kontrollera först tidsintervall, rapporttyp, internetåtkomst, patternstatus och de protokoll som faktiskt speglas. HTTPS stöds inte i Discover Mode. En överbelastad SPAN-destination kan dessutom tappa kopior utan att påverka produktionstrafiken.

Om användare saknas fortsätter felsökningen med autentiseringskällan. Om endast e-postutskicket misslyckas kontrolleras först e-postaviseringar. Starta inte om rapporttjänster på misstanke och radera inte lokala rapportdata som första åtgärd.

En rapport visar risker, men inget blockeras

Det är det förväntade beteendet. Discover Mode utvärderar en kopia. Ett fynd blir först efter en teknisk bedömning en senare inline-policy, segmentering eller annan skyddsåtgärd. TAP-brandväggen kan inte stoppa det observerade originalflödet i efterhand.

Återställ Discover Mode på ett säkert sätt

Spara nödvändiga rapporter, tidsintervall och fynd före återställningen. Därefter:

1. Avaktivera SPAN-sessionen på switchen så att inga fler kopior anländer.
2. Ta bort exempelporten i Device Console:

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

3. Kontrollera under Network > Interfaces att porten inte längre visas som Discover, physical (TAP).
4. Ta kontrollerat bort Security Audit-scheman som inte längre behövs.
5. Återanvänd switchens destinationsport normalt först efter en dokumenterad kontroll.
6. Om brandväggsporten ska användas i produktion planeras och testas zon, IP, beroenden och regler som en separat ändring.

Blanda inte en TAP-återställning med en improviserad inline-migrering. Gateway- eller bridge-läge ändrar routing, regler och avbrottsrisk och kräver en separat migreringsplan.

Checklista

• Separat administrationsåtkomst fungerar.
• TAP-porten är fysisk, obunden och används inte på annat håll.
• SPAN-source, direction och destination är dokumenterade.
• Mirror-destinationen är inte överbelastad.
• system discover-mode tap show visar den förväntade porten.
• Packet Capture ser ett känt testflöde i båda riktningarna.
• Rapporter bedöms endast inom den synlighet som stöds.
• HTTPS och avsaknaden av enforcement är dokumenterade.
• Användartilldelning har vid behov testats separat.
• Rapportmottagare och lagringstid är godkända.
• HA- eller VM-gränser har testats i den verkliga miljön.
• Återställning och senare inline-migrering är separata ändringar.

Vanliga frågor