Sophos Firewall SNMP Hardware Monitoring instellen
Met SNMP Hardware Monitoring kan de status van een Sophos Firewall beter worden geïntegreerd in een bestaand monitoringsysteem. Naast klassieke bereikbaarheid- en interfacewaarden zijn sinds Sophos Firewall v22 extra hardwaremetriek via de MIB beschikbaar. Afhankelijk van het model omvatten deze CPU-temperatuur, NPU-temperatuur, ventilatoren, voedingsstatus en PoE-waarden.
Dit is vooral interessant voor productieve XGS-installaties. Een firewall kan nog steeds bereikbaar zijn in WebAdmin, maar toch tekenen van thermische problemen, defecte ventilatoren, een uitgevallen voeding of onverwachte PoE-belasting vertonen. Dergelijke toestanden zouden niet pas bij de volgende handmatige login moeten opvallen.
Wanneer SNMP op de firewall zinvol is
SNMP is zinvol wanneer er al een monitoringsysteem wordt gebruikt en de firewall daar als infrastructuurcomponent moet worden bewaakt.
Typische toepassingsgevallen:
- Hardwarestatus van XGS-appliances bewaken.
- CPU- en NPU-temperatuur over tijd observeren.
- Ventilator- en voedingsstatus opnemen in een NOC of MSP-monitoring.
- PoE-belasting controleren bij XGS-modellen met PoE-poorten.
- Interfacewaarden vergelijken met switch-, router- en provider-monitoring.
- Alarmen van firewall, switch, UPS en omgevingstemperatuur correleren.
SNMP vervangt geen loganalyse. Voor vragen over verkeer en beveiliging blijven Log viewer, Central Firewall Reporting, Syslog of een SIEM belangrijker. Voor verkeerspatronen op interfaces past sFlow Monitoring op Sophos Firewall beter. SNMP beantwoordt vooral statusvragen: Is het apparaat bereikbaar, werken interfaces, zijn hardwarewaarden normaal en veranderen waarden over tijd?
Vereisten
Voor de installatie moet men deze punten verduidelijken:
- Er is een monitoringsysteem met SNMP-ondersteuning aanwezig.
- De firewall is bereikbaar via een beheer- of monitoringsnetwerk.
- SNMP-toegang is onder Device Access alleen toegestaan voor het monitoringsysteem.
- De juiste Sophos Firewall MIB is in het monitoringsysteem geïmporteerd.
- Het is duidelijk welke firewallmodellen worden bewaakt en welke hardwarewaarden deze modellen leveren.
- Alarmregels zijn zo gepland dat ze echte operationele problemen melden en niet alleen ruis veroorzaken.
⚠️ SNMP zou niet breed toegankelijk moeten zijn vanuit client-, gast-, IoT- of WAN-zones. Monitoringgegevens kunnen model, interfaces, statuswaarden en operationele toestanden zichtbaar maken. De toegang behoort tot een vertrouwd beheer- of monitoringsnetwerk.
SNMP, sFlow en Reporting duidelijk scheiden
SNMP, sFlow en Reporting geven verschillende antwoorden.
| Hulpmiddel | Goede vraag | Niet ideaal voor |
|---|---|---|
| SNMP | Is de firewall bereikbaar, hoe zien hardware- en interfacewaarden eruit? | Individuele firewallregel, URL-blokkering of VPN-fout |
| sFlow | Welke verkeersstromen lopen over een interface? | Exacte pakket- of regelanalyse |
| Log Viewer / Syslog / Central Reporting | Welke regel, welk module of welke gebruiker was betrokken? | Hardwarestatus en langdurige interface-pollingwaarden |
| Packet Capture | Wat is daadwerkelijk op de interface te zien? | Permanent monitoring |
In de praktijk combineert men deze hulpmiddelen. SNMP meldt bijvoorbeeld hoge temperatuur of interfacefouten. Daarna controleert men Log Viewer, Packet Capture, switch-poort, omgevingstemperatuur of het getroffen netwerksegment.
Welke hardwarewaarden SFOS 22 levert
Sophos heeft in de SFOS 22 Release Notes extra SNMP-hardwaremetriek beschreven. De beschikbaarheid hangt af van het firewallmodel.
| Metriek | Volgens Sophos beschikbaar voor |
|---|---|
| CPU temperature | alle XGS-modellen |
| NPU temperature | XGS-modellen behalve XGS 88/88w, 108/108w, 118/118w, 128/128w |
| Fan speed | XGS-modellen behalve XGS 88/88w en 108/108w |
| Power supply status | XGS 2100 en hoger |
| PoE measurements | XGS-modellen met PoE, behalve XGS 116/116w |
Deze tabel is belangrijk voor de verwachtingen. Als een klein desktopmodel geen ventilatorwaarde of NPU-temperatuur levert, is dat niet automatisch een monitoringfout. Eerst moet worden gecontroleerd of het model de betreffende metriek überhaupt ondersteunt.
SNMP-toegang beveiligen
De eerste veiligheidscontrole vindt niet plaats in het monitoringsysteem, maar op de firewall zelf.
Onder Administration > Device access zou SNMP alleen bereikbaar moeten zijn vanuit het netwerk waarin de monitoringserver zich bevindt. Als het monitoringsysteem een enkele vaste IP-adres heeft, is een Local service ACL exception rule meestal beter dan een brede zonevrijgave.
Zinvolle basisregels:
- SNMP niet toestaan vanuit
WAN. - SNMP niet vrijgeven voor complete client- of serverzones als slechts één monitoringhost polt.
- Monitoringserver definiëren als eigen hostobject of beheernetwerk.
- Toegang na wijzigingen controleren met Packet Capture of monitoringtest.
- Niet-gebruikte SNMP-regels en oude monitoringsbronnen verwijderen.
Device Access regelt verkeer naar de firewall zelf. Een normale firewallregel voor LAN-naar-WAN-verkeer vervangt deze instelling niet.
SNMP-versie bewust kiezen
Indien mogelijk, zou SNMPv3 moeten worden gebruikt, omdat het authenticatie en bij passende AuthPriv-configuratie ook encryptie mogelijk maakt. SNMPv1 en SNMPv2c werken met Community Strings. Deze Community Strings zijn geen gebruikersaccounts, maar gedeelde geheimen en moeten dienovereenkomstig worden beschermd.
Voor SNMPv1/v2c noemt Sophos in SFOS 22 een wijziging: Men kan de Community String toevoegen en kiezen of de configuratie voor IPv4 of IPv6 geldt. Bij de upgrade neemt de firewall bestaande namen over als Community String en genereert gemigreerde objectnamen met het voorvoegsel snmp.
Na een upgrade moet men daarom controleren:
- Zijn er oude SNMPv1/v2c Community Strings?
- Zijn de automatisch gemigreerde
snmp-objecten begrijpelijk benoemd? - Wordt IPv4, IPv6 of beide echt nodig?
- Kunnen oude monitoringsbronnen worden verwijderd?
- Is SNMPv3 mogelijk of blijft v2c om compatibiliteitsredenen nodig?
⚠️ Community Strings zouden niet als onschuldige labels moeten worden behandeld. Dergelijke strings behoren tot een wachtwoord- of geheimenconcept, mogen niet in tickets worden gekopieerd en mogen niet zichtbaar zijn in screenshots.
MIB importeren en OIDs controleren
Zodat een monitoringsysteem de Sophos-waarden zinvol herkent, heeft het de juiste MIB-bestand nodig. De MIB beschrijft welke OIDs voor firewall-, interface- en hardwarewaarden beschikbaar zijn.
Praktische aanpak:
- Actueel MIB-bestand verkrijgen van de Sophos Firewall of de passende Sophos-documentatie.
- MIB importeren in het monitoringsysteem.
- Firewall toevoegen met SNMPv3 of een bewust gekozen v1/v2c-configuratie.
- Model, firmwareversie en bereikbare OIDs laten herkennen.
- Hardwaremetriek controleren tegen het specifieke model.
- Een handmatige poll uitvoeren en waarden plausibiliseren.
- Pas daarna alarmregels activeren.
Na firmware-upgrades moet de MIB-pagina opnieuw worden gecontroleerd. Nieuwe SFOS-versies kunnen OIDs aanvullen of bestaande gebieden wijzigen. Als een monitoringsysteem na een update waarden niet meer correct oplost, moet men niet eerst de firewall verdenken, maar MIB-versie, discovery en OID-toewijzing controleren.
Zinvolle alarmering
SNMP-monitoring is alleen nuttig als alarmen zinvol zijn ingesteld. Te nauwe drempelwaarden veroorzaken ruis, te brede drempelwaarden melden problemen te laat.
Typische alarmgebieden:
| Gebied | Zinvolle controle |
|---|---|
| Bereikbaarheid | Firewall reageert niet meer via SNMP of Ping |
| CPU temperature | Temperatuur stijgt blijvend boven het normale bereik |
| NPU temperature | Temperatuurtrend opvallend of blijvend hoger dan vergelijkingswaarden |
| Fan speed | Ventilatorwaarde ontbreekt, is nul of duidelijk buiten het normale bereik |
| Power supply | Redundante voeding ontbreekt of meldt een fout |
| PoE | PoE-belasting nadert het beschikbare budget |
| Interfaces | Poort down, foutenteller, ongebruikelijke bandbreedte |
Voor temperatuurwaarden is een baseline belangrijk. Een kleine desktop-firewall in een warme technische kast gedraagt zich anders dan een rack-appliance in een geklimatiseerde ruimte. Daarom moet men eerst enkele dagen normaal bedrijf observeren en pas daarna productieve drempelwaarden instellen.
Alarm-Runbook en verantwoordelijkheid vaststellen
Een SNMP-alarm is alleen nuttig als daarna duidelijk is wie reageert en welke procedure geldt. Hardwarewaarden zijn vaak vroege indicatoren: Een stijgende temperatuur, een ontbrekende ventilatorwaarde of een voedingalarm betekent niet automatisch dat de appliance onmiddellijk moet worden vervangen. Het betekent echter wel dat de toestand moet worden ingeschat en gedocumenteerd.
Voor productieve firewalls zou een korte Runbook-vermelding moeten bestaan:
| Alarm | Eerste controle |
|---|---|
| Firewall niet bereikbaar via SNMP | Beheernetwerk, Device Access, routing, monitoringsserver en appliance-bereikbaarheid controleren |
| Temperatuur stijgt blijvend | Omgevingstemperatuur, ventilatie, rackpositie, stof, belasting en verloop vergelijken |
| Ventilatorwaarde ontbreekt of is opvallend | Modelgrens, sensorwaarde, geluid, temperatuurtrend en supportrelevantie controleren |
| Voeding meldt fout | Stroomvoorziening, UPS, kabel, redundante voeding en HA-risico controleren |
| PoE-belasting is hoog | Aangesloten apparaten, PoE-budget en geplande reserves controleren |
| Interfacefouten stijgen | Kabel, switch-poort, duplex/snelheid, SFP-module en provideroverdracht controleren |
Belangrijk is de volgorde: eerst zichtbaarheid en plausibiliteit controleren, dan risico beoordelen, daarna support- of vervangingsproces voorbereiden. Bij mogelijke hardwaredefecten moet bovendien serienummer, model, firmwareversie, tijdstip, getroffen metriek, verloop en screenshot of monitoring-uittreksel worden gedocumenteerd. Garantie- en RMA-vragen hangen uiteindelijk niet alleen van het alarm af, maar van het specifieke apparaat, supportstatus en foutbeeld.
Voor SSD-thema’s is SNMP niet de juiste hoofdweg. Als de toestand van de schijf of schrijflast centraal staat, past Sophos Firewall SSD-Gezondheid controleren met SMART beter.
HA-cluster en meerdere firewalls
In HA-omgevingen moet men duidelijk vaststellen hoe beide apparaten worden bewaakt. Het is niet altijd voldoende om alleen het clusteradres te observeren. Voor hardwarewaarden zijn vaak beide appliances relevant, omdat een ventilator, voeding of poort op de passieve appliance ook kan uitvallen.
Belangrijke vragen:
- Worden Primary en Auxiliary apart herkend?
- Hebben beide apparaten eigen beheer-IP-adressen voor monitoring?
- Worden serienummer, hostnaam of model in de monitoring duidelijk weergegeven?
- Blijven alarmen na een failover begrijpelijk?
- Wordt een voedingfout op de passieve appliance ook gemeld?
Voor de HA-bediening zelf past Sophos Firewall High Availability instellen. SNMP moet daar niet geïsoleerd worden gepland, maar samen met firmware-updates, failover-tests, back-upconcept en operationele documentatie.
Validatie na de installatie
Na de SNMP-installatie moet men niet alleen controleren of de monitoring groen is. Belangrijk is of de juiste gegevens uit de juiste bron komen.
Checklist:
- SNMP-toegang is alleen mogelijk vanuit het monitoringsnetwerk.
- De firewall wordt herkend met correcte hostnaam, model en firmwareversie.
- De Sophos MIB is geïmporteerd en hardwarewaarden worden correct benoemd.
- Niet-ondersteunde metriek worden als modelgrens gedocumenteerd, niet als fout.
- Temperatuur-, ventilator-, voeding- en PoE-waarden zijn plausibel.
- Een testalarm wordt geactiveerd en komt bij de juiste ontvanger terecht.
- Bij HA-clusters worden beide apparaten of de gewenste clusterlogica gecontroleerd.
- Na een firmware-upgrade wordt de discovery opnieuw getest.
Voor prestatie- en doorvoerkwesties moet men SNMP-waarden niet overinterpreteren. De interpretatie van Sophos-prestatiegegevens is beschreven in het artikel Prestatiegegevens van de Sophos Firewall correct begrijpen.
Problemen oplossen
Firewall reageert niet op SNMP
Eerst controleren of het monitoringsysteem uit de verwachte zone komt en of SNMP onder Administration > Device access is toegestaan. Daarna IP-adres, routing, lokale ACL-regels, SNMP-versie, Community String of SNMPv3-inloggegevens controleren.
Als het onduidelijk is of pakketten de firewall bereiken, helpt Packet Capture op de getroffen interface. Een normale firewallregel lost dit probleem niet op als het verkeer naar de firewall zelf gaat.
MIB wordt geïmporteerd, maar waarden ontbreken
Eerst controleren of de ontbrekende metriek voor het gebruikte model beschikbaar is. Kleine XGS-modellen leveren niet alle hardwarewaarden. Daarna MIB-versie, OID-toewijzing en firmwareversie vergelijken.
Na de upgrade zijn SNMP-objecten anders benoemd
Bij SNMPv1/v2c kan SFOS 22 gemigreerde objecten met het voorvoegsel snmp genereren. Na een upgrade moet men daarom Community Strings, objectbenamingen en monitoring-discovery controleren. Als de monitoring met namen in plaats van stabiele OIDs werkt, kunnen sjablonen moeten worden aangepast.
Monitoring meldt te veel temperatuuralarm
Dan zijn drempelwaarden waarschijnlijk te nauw of zonder baseline ingesteld. Eerst normale waarden over meerdere dagen vastleggen. Daarna drempelwaarden instellen op basis van model, locatie en omgevingstemperatuur. Individuele korte pieken moeten anders worden beoordeeld dan een blijvend stijgende temperatuurtrend.
HA-cluster toont slechts één apparaat
Dan moet worden gecontroleerd of de monitoring alleen het clusteradres opvraagt of dat beide appliances afzonderlijk bereikbaar zijn. Voor hardwarestatus is de passieve appliance ook relevant. Bij productieve clusters moet men documenteren welk IP-adres welk apparaat en welke rol vertegenwoordigt.
Operationele checklist
- SNMP alleen toestaan vanuit beheer- of monitoringsnetwerken.
- SNMPv3 verkiezen als het monitoringsysteem het correct ondersteunt.
- SNMPv1/v2c Community Strings behandelen als geheimen.
- Sophos MIB importeren en na firmware-upgrades controleren.
- Modelgrenzen voor hardwarewaarden documenteren.
- Temperatuur- en PoE-drempelwaarden instellen op basis van reële baselines.
- HA-apparaten duidelijk benoemen en afzonderlijk beoordelen.
- Alarm-Runbook met eerste controle, escalatie en verantwoordelijkheid documenteren.
- Bij hardwarevermoeden model, serienummer, firmwareversie en verloop vastleggen.
- Alarmen regelmatig testen en verantwoordelijkheid verduidelijken.
- SNMP-gegevens combineren met logs, sFlow, Packet Capture en Central Reporting.