Konfigurera sFlow-övervakning på Sophos Firewall

Med sFlow-övervakning kan en Sophos Firewall skicka trafikprover till en extern Collector. Detta gör det möjligt att bättre se volymtoppar, anmärkningsvärda flöden, ovanliga mål eller lastfördelning över gränssnitt än bara med enskilda live-loggar. Sophos lade till sFlow som en övervakningsfunktion med Sophos Firewall v22.

Funktionen är särskilt intressant för felsökning, kapacitetsplanering och säkerhetsövervakning. sFlow ersätter dock varken Log viewer eller Packet Capture eller en ordentlig loggförvaring via Central Firewall Reporting eller Syslog. sFlow svarar på andra frågor: inte “vilken regel trädde exakt i kraft?”, utan “vilka trafikflöden går över detta gränssnitt och hur fördelar de sig?”. För hårdvarutillstånd, temperatur, fläktar, nätaggregat och PoE passar däremot SNMP Hardware Monitoring.

När sFlow är meningsfullt

sFlow är meningsfullt när en extern Collector eller ett övervakningssystem finns och trafikmönster över tid ska bli synliga.

Typiska användningsfall:

• Upptäcka oväntade bandbreddstoppar på WAN-, LAN- eller Core-gränssnitt.
• Bättre kategorisera trafik mellan VLAN eller platser.
• Stödja kapacitetsplanering för brandvägg, uplink eller core-switching.
• Hitta misstänkta flöden som utgångspunkt för vidare analys.
• Jämföra övervakningsdata med brandväggsloggar, Central Reporting eller SIEM-data.

Om endast en enskild anslutning ska kontrolleras är sFlow ofta inte rätt verktyg. För riktade prestandatester passar iPerf bättre. För konkreta anslutningsproblem är Log Viewer, Policy Test och Packet Capture oftast snabbare.

Förutsättningar

För sFlow behöver man:

• Sophos Firewall med SFOS 22.0 eller nyare.
• Administrativ åtkomst till Device Console.
• En tillgänglig sFlow Collector, till exempel ett NMS, SIEM eller flödesanalysverktyg.
• Ett säkert nätverk mellan brandvägg och Collector.
• Ett tydligt beslut om vilka hårdvarugränssnitt som ska övervakas.

Konfigurationen sker inte i den vanliga WebAdmin-gränssnittet, utan via Device Console med system sflow. Advanced Shell är inte rätt plats för detta. Skillnaden mellan Device Console och Advanced Shell förklaras i artikeln Sophos Firewall Troubleshooting: Services och Logs.

Viktiga begränsningar före aktivering

sFlow verkar harmlöst, men kan påverka drift och säkerhet.

sFlow är inte krypterat

sFlow-trafiken från brandväggen till Collector är inte krypterad. Därför bör Collector vara tillgänglig via ett betrott hanteringsnätverk, ett internt övervakningsnätverk eller en annars skyddad väg.

⚠️ sFlow bör inte skickas oskyddat över osäkra nätverk. Flödesdata kan göra interna IP-adresser, kommunikationsrelationer och målsystem synliga.

FastPath inaktiveras på det övervakade gränssnittet

När sFlow är aktivt på ett gränssnitt inaktiveras Fast Path på detta gränssnitt. Detta är särskilt viktigt vid högbelastade WAN-, LAN- eller Core-gränssnitt.

Innan aktivering bör man kontrollera:

• Hur belastat är gränssnittet?
• Går produktiv höggenomströmningstrafik över det?
• Finns det ett underhållsfönster för det första testet?
• Kan man jämföra prestanda före och efter aktivering?

För grundläggande förståelse av brandväggsprestanda passar artikeln Förstå Sophos Firewall prestandamått korrekt.

HA-kluster: sFlow körs endast på Primary

I ett HA-kluster körs sFlow-agenten på Primary. Detta måste beaktas vid utvärderingar och failover-tester. Efter en rollbyte bör man kontrollera om Collector fortfarande tar emot data och om agentens IP förblir som förväntat.

För planering av HA-drift och övervakning passar Ställa in Sophos Firewall High Availability.

Planera gränssnitt och Collector

sFlow konfigureras på hårdvarugränssnitt. Även beroende gränssnitt som alias och VLAN för det valda hårdvarugränssnittet kan bli synliga i proverna. Valet av gränssnitt bör därför alltid passa den faktiska trafikvägen, inte bara namnet på VLAN eller den önskade utvärderingen i Collector.

Detta är praktiskt, men kan leda till feltolkningar:

• Om Port1 övervakas kan även tillhörande VLAN- eller alias-gränssnitt bli synliga i sampling.
• Om endast ett visst VLAN är av intresse måste det filtreras korrekt i Collector.
• Om flera Core- eller WAN-portar finns bör man inte omedelbart aktivera alla gränssnitt.
• Vid LAG-, Bridge- eller VLAN-design bör det vara klart var den relevanta trafiken verkligen flyter.

Den rena grunden för detta är en förståelig gränssnitts- och zonplanering. Artikeln Konfigurera Sophos Firewall zoner och gränssnitt hjälper till med att kategorisera fysiska gränssnitt, VLAN, broar, LAGs och RED.

Planera pilot, dataskydd och återgång

Innan den första aktiveringen bör sFlow behandlas som en produktiv övervakningsändring. Funktionen genererar ytterligare data, förändrar FastPath på det övervakade gränssnittet och skickar flödesinformation till ett annat system. Därför räcker det inte att bara ange Collector-IP och samplingsfrekvens.

Innan piloten bör dessa punkter fastställas:

• Vilket konkret problem ska sFlow lösa: kapacitetsplanering, bandbreddstoppar, säkerhetsövervakning eller felsökning?
• Vem driver Collector och vem får se flödesdata?
• Hur länge lagras flödesdata?
• Vilken nätväg når sFlow-paketen Collector?
• Vilket gränssnitt testas först?
• Vilka mätvärden gäller som baslinje före aktivering?
• När ska sFlow inaktiveras eller flyttas till ett annat gränssnitt?

Flödesdata kan göra interna IP-adresser, kommunikationsrelationer, målsystem, portar och trafikvolym synliga. Dessa data är därmed mindre detaljerade än en fullständig Packet Capture, men ändå drift- och säkerhetsrelevanta. Om Collector är ansluten till ett SIEM eller en central övervakningsplattform bör ansvaret vara lika tydligt fastställt som vid Skicka Sophos Firewall Syslog till SIEM.

För det första testet är en begränsad pilot meningsfull:

1. Dokumentera utgångsläget: gränssnittsbelastning, CPU-belastning, berörda tjänster, befintliga övervakningsdata.
2. Välj ett enskilt, inte maximalt belastat gränssnitt.
3. Sätt samplingsfrekvensen konservativt.
4. Kontrollera Collector-mottagning och datamängd.
5. Observera prestanda, latens och genomströmning efter aktivering.
6. Testa återgång: system sflow off eller ta bort övervakningsgränssnittet.

Återgången bör vara klar före aktivering. Om prestandan på ett produktivt gränssnitt försämras bör man inte samtidigt ändra samplingsfrekvens, Collector, routing och brandväggsregler. Först inaktivera sFlow eller ta bort det berörda gränssnittet med system sflow monitor delete interface-name ... från övervakningen, sedan mäta igen.

Lägg till sFlow Collector

Först definieras Collector. Standardporten för sFlow är ofta 6343; i produktiva miljöer måste porten passa den använda Collector.

Exempel:

system sflow collector add ip-address 192.0.2.10 port 6343

Sophos stöder upp till fem Collector. Varje Collector läggs till separat.

Den aktuella statusen kan sedan kontrolleras:

system sflow show

Om en Collector ska tas bort:

system sflow collector delete ip-address 192.0.2.10 port 6343

Konfigurera gränssnitt och samplingsfrekvens

Därefter fastställs vilket gränssnitt som ska övervakas och med vilken samplingsfrekvens paket väljs ut.

Exempel:

system sflow monitor add interface-name Port1 sampling-rate 1000

Samplingsfrekvensen avgör hur ofta paket väljs ut som prover. Ett lägre tal genererar fler prover och därmed mer detaljer, men också mer belastning och mer data hos Collector. Ett högre tal minskar datamängden, men kan göra korta eller mindre flöden mindre synliga.

De relevanta gränsvärdena är:

För start är ett konservativt värde meningsfullt, till exempel 1000 eller högre. Därefter bör man i Collector kontrollera om datamängden, detaljnivån och prestandan passar målet.

Ett övervakningsgränssnitt kan tas bort igen:

system sflow monitor delete interface-name Port1

Ställ in Polling Interval

Förutom Packet Sampling kan sFlow också fråga efter statistik och gränssnittsräknare i ett intervall. Sophos tillåter ett Polling Interval mellan 30 och 300 sekunder. Med 0 inaktiveras Polling.

Exempel:

system sflow polling-interval 80

Inaktivera Polling:

system sflow polling-interval 0

För de flesta miljöer är ett medelintervall meningsfullt. För korta intervall genererar mer data och är inte automatiskt mer hjälpsamma.

Aktivera sFlow

När Collector, gränssnitt och Polling är planerade aktiveras sFlow:

system sflow on

Kontrollera status:

system sflow show

Inaktivera sFlow:

system sflow off

Efter aktivering bör man inte bara kontrollera brandväggen, utan även Collector. Där måste data från brandväggens agent-IP komma fram och lösas upp på ett meningsfullt sätt.

Validering efter aktivering

Efter att ha slagit på bör man kontrollera dessa punkter:

1. system sflow show visar Collector, gränssnitt, samplingsfrekvens och status korrekt.
2. Collector tar emot sFlow-data från den förväntade brandväggs-IP:n.
3. Tiden på brandvägg och Collector stämmer.
4. Gränssnittens namn och flödesriktning är spårbara i Collector.
5. Belastningen på brandvägg och Collector förblir okritisk.
6. Datamängden passar den planerade lagringen och bearbetningen.
7. Den definierade återgången har testats en gång eller åtminstone dokumenterats som ett konkret kommando.
8. Vid HA-kluster kontrolleras efter ett failover om data fortfarande kommer fram.

Om brandväggsregler, NAT, VPN eller TLS Inspection analyseras parallellt bör sFlow inte betraktas isolerat. För konkreta anslutningsbeslut förblir Log Viewer och Packet Capture avgörande. För långsiktig utvärdering bör man kontrollera om ytterligare Syslog eller Central Reporting behövs.

Felsökning

Ingen trafik i Collector

Kontrollera först system sflow show. Kontrollera sedan om Collector-IP, port, routing och brandväggsregler till Collector stämmer. Dessutom bör man på Collector kontrollera om UDP-porten är tillgänglig och om inkommande sFlow-paket avvisas.

Endast en del av trafiken är synlig

sFlow arbetar med sampling. Det är normalt att inte varje enskilt paket är synligt. Om viktiga flöden saknas kan samplingsfrekvensen justeras eller ett annat gränssnitt väljas. Vid VLAN och alias bör man kontrollera om rätt hårdvarugränssnitt övervakas.

Prestanda förändras efter aktivering

Om ett starkt använt gränssnitt övervakas kan inaktiveringen av FastPath vara relevant. I detta fall bör sFlow testvis inaktiveras och prestandan jämföras. Vid produktiva Core- eller WAN-gränssnitt är ett planerat test bättre än en spontan aktivering.

HA-data verkar ofullständiga

I HA-miljöer körs sFlow-agenten på Primary. Efter ett failover bör man kontrollera vilken brandvägg som för närvarande är Primary, vilken IP som används som agent-IP och om Collector fortfarande korrekt tilldelar data.

Driftchecklista

• Placera Collector i ett säkert nätverk.
• Dokumentera ägare, syfte, åtkomst och lagring av flödesdata.
• Kontrollera UDP-port och routing till Collector.
• Börja med ett eller få gränssnitt.
• Samla före-efter-baslinje för gränssnittsbelastning, CPU, latens och genomströmning.
• Välj samplingsfrekvens konservativt och justera därefter.
• Beakta FastPath-effekt på kritiska gränssnitt.
• Dokumentera återgång: system sflow off eller ta bort övervakningsgränssnitt.
• Testa HA-failover om sFlow används i kluster.
• Jämför flödesdata med Log Viewer, Packet Capture och rapportering.
• Kontrollera regelbundet om data fortfarande utvärderas eller bara samlas in oanvänd.

FAQ