Konfigurera SNMP-hårdvaruövervakning på Sophos Firewall
Med SNMP-hårdvaruövervakning kan du bättre integrera statusen för en Sophos Firewall i ett befintligt övervakningssystem. Förutom klassiska tillgänglighets- och gränssnittsvärden finns sedan Sophos Firewall v22 ytterligare hårdvarumetriker tillgängliga via MIB. Dessa inkluderar beroende på modell CPU-temperatur, NPU-temperatur, fläktar, strömförsörjningsstatus och PoE-värden.
Detta är särskilt intressant för produktiva XGS-installationer. En brandvägg kan fortfarande vara tillgänglig i WebAdmin men ändå visa tecken på termiska problem, defekta fläktar, ett strömförsörjningsfel eller oväntad PoE-belastning. Sådana tillstånd bör inte upptäckas först vid nästa manuella inloggning.
När SNMP på brandväggen är meningsfullt
SNMP är meningsfullt när ett övervakningssystem redan används och brandväggen ska övervakas där som en infrastrukturkomponent.
Typiska användningsfall:
- Övervaka hårdvarustatus för XGS-enheter.
- Observera CPU- och NPU-temperatur över tid.
- Inkludera fläkt- och strömförsörjningsstatus i ett NOC eller MSP-övervakning.
- Kontrollera PoE-belastning på XGS-modeller med PoE-portar.
- Jämföra gränssnittsvärden med switch-, router- och leverantörsövervakning.
- Korrelatera larm från brandvägg, switch, UPS och omgivningstemperatur.
SNMP ersätter inte logganalys. För trafik- och säkerhetsfrågor är Log viewer, Central Firewall Reporting, Syslog eller ett SIEM viktigare. För trafikmönster på gränssnitt passar sFlow-övervakning på Sophos Firewall bättre. SNMP svarar främst på statusfrågor: Är enheten tillgänglig, fungerar gränssnitten, är hårdvaruvärdena normala och förändras värden över tid?
Förutsättningar
Innan du konfigurerar bör du klargöra dessa punkter:
- Ett övervakningssystem med SNMP-stöd finns tillgängligt.
- Brandväggen är tillgänglig via ett hanterings- eller övervakningsnätverk.
- SNMP-åtkomst är under Device Access endast tillåten för övervakningssystemet.
- Den lämpliga Sophos Firewall MIB är importerad i övervakningssystemet.
- Det är klart vilka brandväggsmodeller som ska övervakas och vilka hårdvaruvärden dessa modeller levererar.
- Larmregler är planerade så att de rapporterar verkliga driftproblem och inte bara skapar brus.
⚠️ SNMP bör inte vara brett tillgängligt från klient-, gäst-, IoT- eller WAN-zoner. Övervakningsdata kan göra modell, gränssnitt, statusvärden och driftstatus synliga. Åtkomst bör vara i ett betrott hanterings- eller övervakningsnätverk.
Separera SNMP, sFlow och rapportering tydligt
SNMP, sFlow och rapportering ger olika svar.
| Verktyg | Bra fråga | Inte idealiskt för |
|---|---|---|
| SNMP | Är brandväggen tillgänglig, hur ser hårdvaru- och gränssnittsvärden ut? | Enskild brandväggsregel, URL-blockering eller VPN-fel |
| sFlow | Vilka trafikflöden går över ett gränssnitt? | Exakt paket- eller regelanalys |
| Log Viewer / Syslog / Central Reporting | Vilken regel, vilket modul eller vilken användare var inblandad? | Hårdvarustatus och långsiktiga gränssnittspollingvärden |
| Packet Capture | Vad syns faktiskt på gränssnittet? | Permanent övervakning |
I praktiken kombinerar man dessa verktyg. SNMP rapporterar till exempel hög temperatur eller gränssnittsfel. Därefter kontrollerar man Log Viewer, Packet Capture, switch-port, omgivningstemperatur eller det berörda nätsegmentet.
Vilka hårdvaruvärden SFOS 22 levererar
Sophos har i SFOS 22 Release Notes beskrivit ytterligare SNMP-hårdvarumetriker. Tillgängligheten beror på brandväggsmodellen.
| Metrik | Enligt Sophos tillgänglig för |
|---|---|
| CPU temperature | alla XGS-modeller |
| NPU temperature | XGS-modeller utom XGS 88/88w, 108/108w, 118/118w, 128/128w |
| Fan speed | XGS-modeller utom XGS 88/88w och 108/108w |
| Power supply status | XGS 2100 och högre |
| PoE measurements | XGS-modeller med PoE, utom XGS 116/116w |
Denna tabell är viktig för förväntningarna. Om en liten desktop-modell inte levererar fläktvärde eller NPU-temperatur är det inte automatiskt ett övervakningsfel. Först måste man kontrollera om modellen överhuvudtaget stöder den aktuella metriken.
Säkra SNMP-åtkomst
Den första säkerhetskontrollen sker inte i övervakningssystemet, utan på själva brandväggen.
Under Administration > Device access bör SNMP endast vara tillgängligt från det nätverk där övervakningsservern finns. Om övervakningssystemet har en enda fast IP-adress är en Local service ACL exception rule oftast bättre än en bred zonfrisläppning.
Sinnfulla grundregler:
- Tillåt inte SNMP från
WAN. - Tillåt inte SNMP för hela klient- eller serverzoner om endast en övervakningsvärd pollar.
- Definiera övervakningsservern som ett eget värdobjekt eller hanteringsnät.
- Kontrollera åtkomst efter ändringar med Packet Capture eller övervakningstest.
- Ta bort oanvända SNMP-regler och gamla övervakningskällor.
Device Access styr trafik till själva brandväggen. En vanlig brandväggsregel för LAN-till-WAN-trafik ersätter inte denna inställning.
Välj SNMP-version medvetet
Om möjligt bör SNMPv3 användas eftersom det möjliggör autentisering och, med lämplig AuthPriv-konfiguration, även kryptering. SNMPv1 och SNMPv2c arbetar med Community Strings. Dessa Community Strings är inga användarkonton utan delade hemligheter och bör skyddas därefter.
För SNMPv1/v2c nämner Sophos i SFOS 22 en ändring: Man kan lägga till Community String och välja om konfigurationen gäller för IPv4 eller IPv6. Vid uppgradering behåller brandväggen befintliga namn som Community String och skapar migrerade objektbeteckningar med prefixet snmp.
Efter en uppgradering bör man därför kontrollera:
- Finns det gamla SNMPv1/v2c Community Strings?
- Är de automatiskt migrerade
snmp-objekten tydligt namngivna? - Behövs verkligen IPv4, IPv6 eller båda?
- Kan gamla övervakningskällor tas bort?
- Är SNMPv3 möjligt eller förblir v2c nödvändigt av kompatibilitetsskäl?
⚠️ Community Strings bör inte behandlas som ofarliga etiketter. Sådana strängar hör hemma i ett lösenords- eller hemlighetskoncept, bör inte kopieras i ärenden och får inte synas i skärmdumpar.
Importera MIB och kontrollera OIDs
För att ett övervakningssystem ska kunna känna igen Sophos-värden på ett meningsfullt sätt behöver det rätt MIB-fil. MIB beskriver vilka OIDs som är tillgängliga för brandväggs-, gränssnitts- och hårdvaruvärden.
Praktiskt tillvägagångssätt:
- Hämta aktuell MIB-fil från Sophos Firewall eller lämplig Sophos-dokumentation.
- Importera MIB i övervakningssystemet.
- Lägg till brandväggen med SNMPv3 eller en medvetet vald v1/v2c-konfiguration.
- Låt modell, firmwareversion och tillgängliga OIDs identifieras.
- Kontrollera hårdvarumetriker mot den specifika modellen.
- Utför en manuell poll och verifiera värden.
- Aktivera larmregler först därefter.
Efter firmwareuppgraderingar bör MIB-sidan kontrolleras igen. Nya SFOS-versioner kan lägga till OIDs eller ändra befintliga områden. Om ett övervakningssystem efter en uppdatering inte längre löser värden korrekt, bör man inte först misstänka brandväggen, utan kontrollera MIB-version, upptäckt och OID-tilldelning.
Meningsfull larmhantering
SNMP-övervakning är endast användbar om larm är meningsfullt inställda. För snäva tröskelvärden skapar brus, för breda tröskelvärden rapporterar problem för sent.
Typiska larmområden:
| Område | Meningsfull kontroll |
|---|---|
| Tillgänglighet | Brandväggen svarar inte längre via SNMP eller Ping |
| CPU temperature | Temperaturen stiger varaktigt över det normala området |
| NPU temperature | Temperaturtrend är anmärkningsvärd eller varaktigt högre än jämförelsevärden |
| Fan speed | Fläktvärde saknas, är noll eller betydligt utanför normalområdet |
| Power supply | Redundant strömförsörjning saknas eller rapporterar fel |
| PoE | PoE-belastning närmar sig den tillgängliga budgeten |
| Interfaces | Port nere, felräknare, ovanlig bandbredd |
För temperaturvärden är en baslinje viktig. En liten desktop-brandvägg i ett varmt teknikskåp beter sig annorlunda än en rack-enhet i ett luftkonditionerat rum. Därför bör man först observera några dagars normal drift och först därefter fastställa produktiva tröskelvärden.
Fastställ larm-runbook och ansvar
Ett SNMP-larm är endast användbart om det därefter är klart vem som reagerar och vilken procedur som gäller. Hårdvaruvärden är ofta tidiga indikatorer: En stigande temperatur, ett saknat fläktvärde eller ett strömförsörjningslarm betyder inte automatiskt att enheten omedelbart måste bytas ut. Det betyder dock att tillståndet bör bedömas och dokumenteras.
För produktiva brandväggar bör en kort runbook-post finnas:
| Larm | Första kontroll |
|---|---|
| Brandvägg inte tillgänglig via SNMP | Kontrollera hanteringsnät, Device Access, routing, övervakningsserver och enhetens tillgänglighet |
| Temperatur stiger varaktigt | Jämför omgivningstemperatur, ventilation, rack-position, damm, belastning och trend |
| Fläktvärde saknas eller är anmärkningsvärt | Kontrollera modellgräns, sensorvärde, ljud, temperaturtrend och supportrelevans |
| Strömförsörjning rapporterar fel | Kontrollera strömförsörjning, UPS, kablar, redundant strömförsörjning och HA-risk |
| PoE-belastning är hög | Kontrollera anslutna enheter, PoE-budget och planerade reserver |
| Gränssnittsfel ökar | Kontrollera kablar, switch-port, duplex/hastighet, SFP-modul och leverantörsövergång |
Viktigt är ordningen: först kontrollera synlighet och rimlighet, sedan bedöma risk, därefter förbereda support- eller utbytesprocess. Vid möjliga hårdvarufel bör dessutom serienummer, modell, firmwareversion, tidpunkt, berörd metrik, trend och skärmdump eller övervakningsutdrag dokumenteras. Garanti- och RMA-frågor beror i slutändan inte bara på larmet, utan på den specifika enheten, supportstatus och felbild.
För SSD-frågor är SNMP inte den rätta huvudvägen. Om lagringsenhetens tillstånd eller skrivbelastning är i fokus passar Kontrollera Sophos Firewall SSD-hälsa med SMART bättre.
HA-kluster och flera brandväggar
I HA-miljöer bör man tydligt fastställa hur båda enheterna övervakas. Det räcker inte alltid att bara observera klusteradressen. För hårdvaruvärden är ofta båda enheterna relevanta, eftersom en fläkt, strömförsörjning eller port på den passiva enheten också kan fallera.
Viktiga frågor:
- Känns Primary och Auxiliary igen separat?
- Har båda enheterna egna hanterings-IP-adresser för övervakning?
- Visas serienummer, värdnamn eller modell tydligt i övervakningen?
- Förblir larm förståeliga efter ett failover?
- Rapporteras ett strömförsörjningsfel på den passiva enheten också?
För själva HA-driften passar Konfigurera Sophos Firewall High Availability. SNMP bör inte planeras isolerat där, utan tillsammans med firmwareuppdateringar, failover-tester, backup-koncept och driftdokumentation.
Validering efter konfiguration
Efter SNMP-konfigurationen bör man inte bara kontrollera om övervakningen är grön. Viktigt är om rätt data kommer från rätt källa.
Checklista:
- SNMP-åtkomst är endast möjlig från övervakningsnätet.
- Brandväggen känns igen med korrekt värdnamn, modell och firmwareversion.
- Sophos MIB är importerad och hårdvaruvärden namnges korrekt.
- Icke stödda metriker dokumenteras som modellgräns, inte som fel.
- Temperatur-, fläkt-, strömförsörjnings- och PoE-värden är rimliga.
- Ett testlarm utlöses och når rätt mottagare.
- Vid HA-kluster kontrolleras båda enheterna eller den önskade klusterlogiken.
- Efter en firmwareuppgradering testas upptäckten igen.
För prestanda- och genomströmningsfrågor bör man inte övertolka SNMP-värden. Tolkningen av Sophos-prestandadata beskrivs i artikeln Förstå Sophos Firewall prestandametriker korrekt.
Felsökning
Brandväggen svarar inte på SNMP
Kontrollera först om övervakningssystemet kommer från den förväntade zonen och om SNMP är tillåtet under Administration > Device access. Kontrollera sedan IP-adress, routing, lokala ACL-regler, SNMP-version, Community String eller SNMPv3-åtkomstdata.
Om det är oklart om paket når brandväggen, hjälper Packet Capture på det berörda gränssnittet. En vanlig brandväggsregel löser inte detta problem om trafiken går till själva brandväggen.
MIB importeras, men värden saknas
Kontrollera först om den saknade metriken är tillgänglig för den använda modellen. Små XGS-modeller levererar inte alla hårdvaruvärden. Jämför sedan MIB-version, OID-tilldelning och firmwareversion.
Efter uppgradering är SNMP-objekt annorlunda namngivna
Vid SNMPv1/v2c kan SFOS 22 skapa migrerade objekt med prefixet snmp. Efter en uppgradering bör man därför kontrollera Community Strings, objektbeteckningar och övervakningsupptäckt. Om övervakningen arbetar med namn istället för stabila OIDs kan mallar behöva anpassas.
Övervakning rapporterar för många temperaturlarm
Då är tröskelvärden troligen för snäva eller satta utan baslinje. Först samla normalvärden över flera dagar. Sätt sedan tröskelvärden efter modell, plats och omgivningstemperatur. Enskilda korta toppar bör bedömas annorlunda än en varaktigt stigande temperaturtrend.
HA-kluster visar endast en enhet
Då måste man kontrollera om övervakningen endast frågar klusteradressen eller om båda enheterna är separat tillgängliga. För hårdvarustatus är den passiva enheten också relevant. Vid produktiva kluster bör man dokumentera vilken IP-adress som representerar vilken enhet och roll.
Driftchecklista
- Tillåt endast SNMP från hanterings- eller övervakningsnät.
- Föredra SNMPv3 om övervakningssystemet stöder det korrekt.
- Behandla SNMPv1/v2c Community Strings som hemligheter.
- Importera Sophos MIB och kontrollera efter firmwareuppgraderingar.
- Dokumentera modellgränser för hårdvaruvärden.
- Sätt temperatur- och PoE-tröskelvärden baserat på verkliga baslinjer.
- Namnge och bedöm HA-enheter tydligt och separat.
- Dokumentera larm-runbook med första kontroll, eskalation och ansvar.
- Vid hårdvarumisstanke, säkra modell, serienummer, firmwareversion och trend.
- Testa larm regelbundet och klargör ansvar.
- Kombinera SNMP-data med loggar, sFlow, Packet Capture och Central Reporting.