sFlow Monitoring configureren op Sophos Firewall

Met sFlow Monitoring kan een Sophos Firewall verkeerssamples naar een externe collector sturen. Hierdoor worden volumepieken, opvallende flows, ongebruikelijke doelen of belastingverdeling over interfaces beter zichtbaar dan alleen met individuele live-logs. Sophos heeft sFlow toegevoegd als monitoringfunctie met Sophos Firewall v22.

De functie is vooral interessant voor troubleshooting, capaciteitsplanning en security monitoring. sFlow vervangt echter niet de Log viewer noch Packet Capture of een goede logopslag via Central Firewall Reporting of Syslog. sFlow beantwoordt andere vragen: niet “welke regel werd exact toegepast?”, maar “welke verkeersstromen lopen over dit interface en hoe worden ze verdeeld?”. Voor hardwarestatus, temperatuur, ventilatoren, voedingen en PoE is SNMP Hardware Monitoring meer geschikt.

Wanneer sFlow zinvol is

sFlow is zinvol wanneer er een externe collector of een monitoringsysteem aanwezig is en verkeerspatronen over tijd zichtbaar moeten worden.

Typische toepassingsgevallen:

• Onverwachte bandbreedtepieken op WAN-, LAN- of core-interfaces herkennen.
• Verkeer tussen VLAN’s of locaties beter indelen.
• Capaciteitsplanning voor firewall, uplink of core-switching ondersteunen.
• Verdachte flows als uitgangspunt voor verdere analyse vinden.
• Monitoringgegevens vergelijken met firewall logs, Central Reporting of SIEM-gegevens.

Als slechts één enkele verbinding moet worden gecontroleerd, is sFlow vaak niet het juiste hulpmiddel. Voor gerichte prestatietests is iPerf meer geschikt. Voor specifieke verbindingsproblemen zijn Log Viewer, Policy Test en Packet Capture meestal sneller.

Vereisten

Voor sFlow heeft men nodig:

• Sophos Firewall met SFOS 22.0 of nieuwer.
• Administratieve toegang tot de Device Console.
• Een bereikbare sFlow Collector, bijvoorbeeld een NMS, SIEM of flow-analysetool.
• Een veilig netwerk tussen firewall en collector.
• Een duidelijke beslissing over welke hardware-interfaces moeten worden bewaakt.

De configuratie gebeurt niet in de normale WebAdmin-interface, maar via de Device Console met system sflow. De Advanced Shell is hiervoor niet de juiste plek. Het onderscheid tussen Device Console en Advanced Shell wordt uitgelegd in het artikel Sophos Firewall Troubleshooting: Services en Logs.

Belangrijke grenzen vóór de activering

sFlow lijkt onschuldig, maar kan gevolgen hebben voor de werking en veiligheid.

sFlow is niet versleuteld

De sFlow-verkeer van de firewall naar de collector is niet versleuteld. Daarom moet de collector bereikbaar zijn via een betrouwbaar beheernetwerk, een intern monitoringsnetwerk of een anderszins beveiligd pad.

⚠️ sFlow mag niet onbeschermd over onveilige netwerken worden verzonden. Flow-gegevens kunnen interne IP-adressen, communicatieverbanden en doelsystemen zichtbaar maken.

FastPath wordt op het bewaakte interface gedeactiveerd

Wanneer sFlow op een interface actief is, wordt Fast Path op dat interface gedeactiveerd. Dit is vooral belangrijk bij zwaar belaste WAN-, LAN- of core-interfaces.

Voor de activering moet men controleren:

• Hoe zwaar is het interface belast?
• Loopt er productief high-throughput-verkeer over?
• Is er een onderhoudsvenster voor de eerste test?
• Kan men prestaties voor en na de activering vergelijken?

Voor de basisindeling van firewallprestaties is het artikel Leistungsdaten der Sophos Firewall richtig verstehen geschikt.

HA-cluster: sFlow draait alleen op de Primary

In een HA-cluster draait de sFlow-agent op de Primary. Dit moet men in overweging nemen bij evaluaties en failover-tests. Na een rolwisseling moet worden gecontroleerd of de collector nog steeds gegevens ontvangt en of het agent-IP zoals verwacht blijft.

Voor de planning van HA-bedrijf en monitoring is Sophos Firewall High Availability einrichten geschikt.

Interface en Collector plannen

sFlow wordt geconfigureerd op hardware-interfaces. Daarbij kunnen ook afhankelijke interfaces zoals aliassen en VLAN’s van het gekozen hardware-interface in de samples zichtbaar worden. De interfacekeuze moet daarom altijd overeenkomen met het werkelijke verkeerspad, niet alleen met de naam van het VLAN of de gewenste evaluatie in de collector.

Dit is praktisch, maar kan tot misinterpretaties leiden:

• Wanneer Port1 wordt bewaakt, kunnen ook bijbehorende VLAN- of alias-interfaces in de sampling zichtbaar worden.
• Als alleen een specifiek VLAN van belang is, moet in de collector goed gefilterd worden.
• Als er meerdere core- of WAN-poorten zijn, moet men niet meteen alle interfaces activeren.
• Bij LAG-, bridge- of VLAN-ontwerpen moet vooraf duidelijk zijn waar het relevante verkeer werkelijk stroomt.

De solide basis hiervoor is een begrijpelijke interface- en zoneplanning. Het artikel Sophos Firewall Zonen en Interfaces configureren helpt bij de indeling van fysieke interfaces, VLAN’s, bridges, LAG’s en RED.

Pilot, gegevensbescherming en terugweg plannen

Voor de eerste activering moet sFlow als een productieve monitoringwijziging worden behandeld. De functie genereert extra gegevens, verandert FastPath op het bewaakte interface en stuurt flow-informatie naar een ander systeem. Daarom is het niet voldoende om alleen collector-IP en sampling rate in te voeren.

Voor de pilot moeten deze punten vaststaan:

• Welk specifiek probleem moet sFlow oplossen: capaciteitsplanning, bandbreedtepieken, security monitoring of foutopsporing?
• Wie beheert de collector en wie mag de flow-gegevens zien?
• Hoe lang worden flow-gegevens opgeslagen?
• Via welk netwerkpad bereiken de sFlow-pakketten de collector?
• Welk interface wordt als eerste getest?
• Welke meetwaarden gelden voor de activering als baseline?
• Wanneer wordt sFlow weer gedeactiveerd of naar een ander interface verplaatst?

Flow-gegevens kunnen interne IP-adressen, communicatieverbanden, doelsystemen, poorten en verkeersvolume zichtbaar maken. Deze gegevens zijn daarmee minder gedetailleerd dan een volledige Packet Capture, maar toch bedrijfs- en veiligheidsrelevant. Als de collector is aangesloten op een SIEM of een centraal monitoringsplatform, moet de verantwoordelijkheid net zo duidelijk zijn als bij Sophos Firewall Syslog an SIEM senden.

Voor de eerste test is een beperkte pilot zinvol:

1. Beginstatus documenteren: interfacebelasting, CPU-belasting, betrokken diensten, bestaande monitoringgegevens.
2. Een enkel, niet maximaal belast interface selecteren.
3. Sampling rate conservatief instellen.
4. Collectorontvangst en gegevenshoeveelheid controleren.
5. Prestaties, latentie en doorvoer na de activering observeren.
6. Terugweg testen: system sflow off of het monitoringinterface weer verwijderen.

De terugweg moet voor de activering duidelijk zijn. Als de prestaties op een productief interface slechter worden, moet men niet tegelijkertijd sampling rate, collector, routing en firewallregels wijzigen. Eerst sFlow deactiveren of het betreffende interface met system sflow monitor delete interface-name ... uit de monitoring halen, daarna opnieuw meten.

sFlow Collector toevoegen

Eerst wordt de collector gedefinieerd. De standaardpoort voor sFlow is vaak 6343; in productieve omgevingen moet de poort overeenkomen met de gebruikte collector.

Voorbeeld:

system sflow collector add ip-address 192.0.2.10 port 6343

Sophos ondersteunt tot vijf collectors. Elke collector wordt afzonderlijk toegevoegd.

De huidige status kan daarna worden gecontroleerd:

system sflow show

Als een collector weer verwijderd moet worden:

system sflow collector delete ip-address 192.0.2.10 port 6343

Interface en Sampling Rate configureren

Daarna wordt bepaald welk interface wordt bewaakt en met welke sampling rate pakketten worden geselecteerd.

Voorbeeld:

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

De sampling rate bepaalt hoe vaak pakketten als sample worden geselecteerd. Een lagere waarde genereert meer samples en daarmee meer details, maar ook meer belasting en meer gegevens bij de collector. Een hogere waarde vermindert de gegevenshoeveelheid, maar kan korte of kleinere flows minder zichtbaar maken.

De relevante grenswaarden zijn:

Voor de start is een conservatieve waarde zinvol, bijvoorbeeld 1000 of hoger. Daarna moet men in de collector controleren of de gegevenshoeveelheid, detailniveau en prestaties aan het doel voldoen.

Een monitoringinterface kan weer worden verwijderd:

system sflow monitor delete interface-name Port1

Polling Interval instellen

Naast Packet Sampling kan sFlow ook statistieken en interfacecounters in een interval opvragen. Sophos staat een polling interval toe tussen 30 en 300 seconden. Met 0 wordt polling gedeactiveerd.

Voorbeeld:

system sflow polling-interval 80

Polling deactiveren:

system sflow polling-interval 0

Voor de meeste omgevingen is een gemiddeld interval zinvol. Te korte intervallen genereren meer gegevens en zijn niet automatisch nuttiger.

sFlow activeren

Wanneer collector, interface en polling gepland zijn, wordt sFlow geactiveerd:

system sflow on

De status controleren:

system sflow show

sFlow deactiveren:

system sflow off

Na de activering moet men niet alleen de firewall controleren, maar ook de collector. Daar moeten gegevens van het firewall-agent-IP aankomen en zinvol worden opgelost.

Validatie na de activering

Na het inschakelen moet men deze punten controleren:

1. system sflow show toont collector, interface, sampling rate en status correct aan.
2. De collector ontvangt sFlow-gegevens van het verwachte firewall-IP.
3. De tijd op firewall en collector komt overeen.
4. Interfacenamen en flowrichting zijn in de collector te volgen.
5. De belasting op firewall en collector blijft onkritisch.
6. De gegevenshoeveelheid past bij de geplande opslag en verwerking.
7. De gedefinieerde terugweg is eenmaal getest of ten minste als concrete opdracht gedocumenteerd.
8. Bij HA-clusters wordt na een failover gecontroleerd of er nog steeds gegevens binnenkomen.

Als parallel firewallregels, NAT, VPN of TLS Inspection worden geanalyseerd, moet sFlow niet geïsoleerd worden bekeken. Voor specifieke verbindingsbeslissingen blijven Log Viewer en Packet Capture essentieel. Voor langdurige evaluatie moet men controleren of daarnaast Syslog of Central Reporting nodig is.

Problemen oplossen

Geen verkeer in de collector

Eerst system sflow show controleren. Daarna controleren of collector-IP, poort, routing en firewallregels naar de collector passen. Daarnaast moet men op de collector controleren of de UDP-poort bereikbaar is en of binnenkomende sFlow-pakketten worden verworpen.

Slechts een deel van het verkeer is zichtbaar

sFlow werkt met sampling. Het is normaal dat niet elk afzonderlijk pakket zichtbaar is. Als belangrijke flows ontbreken, kan de sampling rate worden aangepast of een ander interface worden gekozen. Bij VLAN’s en aliassen moet men controleren of het juiste hardware-interface wordt bewaakt.

Prestaties veranderen na activering

Als een zwaar gebruikt interface wordt bewaakt, kan de deactivering van FastPath relevant zijn. In dit geval moet sFlow testmatig worden gedeactiveerd en de prestaties worden vergeleken. Bij productieve core- of WAN-interfaces is een geplande test beter dan een spontane activering.

HA-gegevens lijken onvolledig

In HA-omgevingen draait de sFlow-agent op de Primary. Na een failover moet worden gecontroleerd welke firewall momenteel Primary is, welk IP als agent-IP wordt gebruikt en of de collector de gegevens nog steeds correct toewijst.

Operationele checklist

• Plaats de collector in een veilig netwerk.
• Documenteer eigenaar, doel, toegang en opslag van de flow-gegevens.
• Controleer UDP-poort en routing naar de collector.
• Begin met één of enkele interfaces.
• Verzamel voor-en-na-baseline voor interfacebelasting, CPU, latentie en doorvoer.
• Kies een conservatieve sampling rate en pas deze daarna aan.
• Houd rekening met de impact van FastPath bij kritische interfaces.
• Documenteer de terugweg: system sflow off of monitoringinterface verwijderen.
• Test HA-failover als sFlow in de cluster wordt gebruikt.
• Vergelijk flow-gegevens met Log Viewer, Packet Capture en Reporting.
• Controleer regelmatig of de gegevens nog worden geëvalueerd of alleen ongebruikt worden verzameld.

FAQ