Konfigurera SNMP-övervakning av Sophos Firewall-hårdvara

För SNMP-baserad hårdvaruövervakning aktiveras agenten under Administration > SNMP, helst med en SNMPv3-användare. Åtkomsten begränsas under Administration > Device access till övervakningsvärden och aktuell MIB hämtas. Därefter kan anslutningen testas från övervakningssystemet med snmpget och hårdvaruträdet hämtas med snmpwalk.

Sedan Sophos Firewall v22 ger MIB-filen, beroende på XGS Appliance-modell, även tillgång till CPU- och NPU-temperatur, fläkthastigheter, nätaggregatstatus och PoE-värden. SNMP svarar därmed främst på frågor om enhetens tillstånd. För enskilda säkerhetshändelser passar Central Firewall Reporting eller Syslog bättre, och för trafikmönster passar sFlow.

När det inte handlar om permanent övervakning utan om en akut kontroll direkt på appliance-enheten visar Kontrollera temperatur och fläkt i Sophos Firewall via SSH hur man läser sensors och xgs-healthmond.log och tolkar skenbara råsensorlarm korrekt.

⚠️ SNMP bör endast vara tillgängligt från ett betrott hanterings- eller övervakningsnät. Bred åtkomst från klient-, gäst-, IoT- eller WAN-zoner exponerar i onödan information om modell, gränssnitt och drifttillstånd.

Konfigurera SNMP säkert

Begränsa åtkomsten till övervakningsvärden

Om en dedikerad övervakningszon ska få åtkomst aktiveras SNMP under Administration > Device access endast för den zonen. Om exakt en server med fast IP-adress skickar förfrågningar förblir SNMP avstängt för zonen. I stället tillåter en Local service ACL exception rule specifikt källan, brandväggsmålet och tjänsten SNMP. Hela konfigurationen beskrivs i Säkra Device Access på Sophos Firewall.

SNMP är en lokal tjänst på brandväggen. En vanlig LAN-to-WAN-regel ersätter inte Device Access. SNMP bör inte exponeras direkt från WAN; ett hanterings-VPN är den säkrare anslutningen för extern övervakning.

Aktivera agenten

Öppna Administration > SNMP.
Aktivera Enable SNMP agent.
Ange namn, plats och kontakt, till exempel xgs-zrh-01, ZRH-DC1 / Rack 3 och noc@example.net.
Spara med Apply.
Hämta den MIB som hör till brandväggsversionen via Download MIB och importera den i övervakningssystemet.

Utöver det Sophos-specifika maskinvaruträdet tillhandahåller SFOS standard-MIB:erna SNMPv2-MIB, IF-MIB med Counter32 och Counter64, SNMPv2-SMI, IP-MIB, IP-FORWARD-MIB, TCP-MIB och UDP-MIB. Med dem kan bland annat uptime, gränssnittsräknare, IP- och routingvärden samt TCP/UDP-statistik övervakas. Den aktuella Sophos-MIB:en är ändå viktig eftersom den innehåller leverantörsspecifika OID:er och deras betydelse för den installerade SFOS-versionen.

Förfrågningar går till agenten via UDP 161. Traps går till managern via UDP 162. Routing och lokala värdbrandväggar mellan systemen måste också tillåta dessa riktningar.

Konfigurera SNMPv3

Klicka på Add under Administration > SNMP > SNMPv3 users and traps.
Ange ett beständigt användarnamn, till exempel monitoring. Använd bokstäver utan mellanslag och konfigurera samma användarnamn på managern. Det kan inte ändras senare.
Aktivera Accept queries.
Aktivera endast Send traps om brandväggen även ska skicka meddelanden till managern.
Om Send traps är aktiverat anger du de faktiska IPv4- eller IPv6-adresserna för de avsedda trap-mottagarna under Authorized hosts innan SNMPv3-användaren sparas. Här ska mottagaradresserna i den egna miljön anges, inte automatiskt polling-värdarnas IP-adresser.
Välj om möjligt AES och SHA256 eller SHA512 för nya konfigurationer. Båda lösenfraserna måste vara minst tolv tecken långa.
Spara.

SFOS erbjuder även DES eller None för kryptering och MD5 för autentisering. Dessa alternativ bör inte användas i nya konfigurationer. Om en collector endast stöder dessa metoder ska den först uppdateras eller SNMP-anslutningen begränsas till en tekniskt motiverad, isolerad hanteringsväg; en tyst nedgradering är inte ett lyckat kompatibilitetstest.

Enligt Sophos gäller Authorized hosts endast för trap-destinationer. Listan begränsar inte SNMPv3-förfrågningar. Där avgör korrekta autentiseringsuppgifter, Accept queries och Device Access åtkomsten.

Använd SNMPv1 eller SNMPv2c endast vid behov

Om övervakningssystemet inte stöder SNMPv3 korrekt klickar du på Add under Administration > SNMP > SNMPv1/v2c och skapar en community-post. Namn, Community String, IPv4 eller IPv6, managerns IP-adress och Accept queries krävs. Send traps förblir avstängt om traps inte används. Spara sedan posten med Save.

Community String fungerar som ett lösenord men överförs okrypterat med v1/v2c. Det hör inte hemma i skärmbilder eller ärenden och bör endast användas i ett strikt begränsat hanteringsnät.

Efter en uppgradering till SFOS 22 bör befintliga v1/v2c-poster kontrolleras: brandväggen använder det tidigare namnet som Community String och skapar ett migrerat objektnamn med prefixet snmp. Samtidigt kan onödiga IPv4-/IPv6-varianter och övervakningskällor som inte längre används tas bort.

Aktivera traps selektivt

SFOS 23 – säkerhetsuppdateringar via hotfix: SNMP-aviseringar är inte tillgängliga för dessa uppdateringar. Konfigurera i stället e-post för Firmware > Security updates med den globala e-postomkopplaren och fungerande SMTP, och kontrollera tillämpade uppdateringar. Undantaget gäller inte generellt för alla hotfixar eller firmwarehändelser.

SNMP-användaren eller community-posten räcker inte för traps. Under System services > Notification list måste SNMP traps och de alert-typer som faktiskt behövs aktiveras.

Mottagningen bör testas med en vald händelse som verkligen inträffar. SNMPv3-informs bekräftas; om brandväggen inte får någon bekräftelse gör den enligt Sophos inget nytt leveransförsök. Traps och informs ersätter därför inte övervakning genom polling.

Spara eller överför SNMP-konfigurationen

SFOS 22 kan exportera och importera konfigurationen för SNMP-agenten, communities och SNMPv3-användare som en TAR-fil under Backup and firmware > Import export. Det är användbart vid ett kontrollerat hårdvarubyte eller före större ändringar. Arkivet innehåller säkerhetsrelevant övervakningskonfiguration och ska därför förvaras skyddat. Det allmänna arbetsflödet beskrivs i Exportera och importera konfigurationen för Sophos Firewall.

En lyckad import bevisar inte att övervakningen fungerar. Kontrollera därefter agentstatus, Device Access eller ACL exception, credentials, query och trapdestination igen med ett verkligt polling- och händelsetest. Övervakningssystemet måste också ha den aktuella MIB som motsvarar målversionen.

Återställ en testkonfiguration

Anteckna före en pilot om agenten och SNMP för den berörda zonen redan var aktiverade, vilka användare, communities och ACL exceptions som finns och vilka SNMP-alternativ som är aktiverade under System services > Notification list. Då kan endast pilotens ändringar återställas utan att koppla bort ett annat övervakningssystem.

Vid återställning avaktiveras först pilotens pollingjobb och all pilotspecifik traphantering i övervakningssystemet, men en gemensam trapmottagare ska inte stoppas. Ta därefter bort den nya SNMPv3-användaren eller community-posten och den Local Service ACL exception som skapades för den. Avaktivera Enable SNMP agent och bekräfta med Apply endast om agenten var avstängd före piloten och ingen annan manager använder den. Om SNMP aktiverades för en hel zon återställs även den tidigare inställningen under Administration > Device access. Återställ dessutom det antecknade tillståndet för trap- och larmalternativ som aktiverades enbart för piloten under System services > Notification list. Slutligen ska frågan från pilotvärden ge timeout, medan befintliga managers fortfarande ska få svar och förväntade traps.

Hårdvarumätvärden och modellbegränsningar

SFOS 22 tillhandahåller de nya hårdvaruvärdena för XGS Appliances:

CPU temperature: alla XGS Appliance-modeller.
NPU temperature: alla XGS Appliance-modeller utom 88/88w, 108/108w, 118/118w och 128/128w.
Fan speed: alla XGS Appliance-modeller utom 88/88w och 108/108w.
Power supply status: XGS 2100 och högre.
PoE measurements: XGS Appliance-modeller med PoE utom XGS 116/116w.

Sophos dokumenterar dessa sensorer för XGS Appliances. För virtuella, molnbaserade eller programvarubaserade enheter bör man inte förvänta sig fysiska värdsensorer i SFOS-MIB. Även på en XGS Appliance innebär ett saknat mätvärde inte automatiskt ett fel; kontrollera först modellbegränsningen.

OID:er och enheter i SFOS-22-MIB

Hårdvaruträdet börjar vid .1.3.6.1.4.1.2604.5.1.9. De viktigaste områdena är:

NPU-temperatur: .1.3.6.1.4.1.2604.5.1.9.1.0
CPU-temperatur: .1.3.6.1.4.1.2604.5.1.9.2.0
Fläkthastighet: .1.3.6.1.4.1.2604.5.1.9.3.1.2
Nätaggregatstatus: .1.3.6.1.4.1.2604.5.1.9.4.1.2
PoE-tabell: .1.3.6.1.4.1.2604.5.1.9.5

Temperaturer levereras i tiondels grader Celsius: 420 motsvarar 42,0 °C. Fläktvärden anges i RPM. PoE-effekt anges i milliwatt, spänning i millivolt och ström i milliampere. För nätaggregatet betyder up(1) driftklart och down(2) ur funktion.

För varje port ger PoE-tabellen även etikett, status, konfigurerad effektgräns och aktuell förbrukning. enabled(1) betyder att PoE-matningen är aktiv, medan disabled(2) betyder att den är avstängd. disabled(2) är därför inte i sig ett hårdvarufel. För larm jämförs förbrukningen med gränsen för samma port, och etikett samt index identifieras på nytt i stället för att tabellrader blint kopplas till en gammal övervakningsmall. Tabellen anger inte enhetens totala PoE-budget. Ett larm för den sammanlagda förbrukningen kräver därför också en separat verifierad, modellspecifik PoE-budget.

För numerisk bearbetning av hårdvaruvärden bör minst SFOS 22.0 GA Build 411 köras. Denna build åtgärdar bland annat NC-169564, där sensorvärden levererades som strängar i stället för heltal, samt andra MIB- och OID-problem.

Efter en firmwareuppgradering bör aktuell MIB hämtas på nytt, importeras i övervakningssystemet och Discovery kontrolleras. Övervakningsmallar får inte enbart bygga på visningsnamn.

Testa anslutning och hårdvaruvärden

Följande Bash-kommandon körs på en övervakningsvärd med Linux eller macOS och Net-SNMP, inte på Sophos Firewall. På macOS startas först bash, eftersom read -p har en annan betydelse i standardskalet zsh. Exemplen har kontrollerats mot den dokumenterade Net-SNMP-syntaxen och den officiella SFOS-22-MIB, men inte körts mot en kundbrandvägg.

SHA-256 och SHA-512 kräver normalt Net-SNMP 5.8 eller senare. Med snmpwalk -h går det att kontrollera vilka algoritmer den installerade klienten accepterar. Äldre macOS-versioner stöder ibland endast MD5 och SHA.

⚠️ Net-SNMP överför Community String och lösenfraser som processargument. Inmatning via read håller dem borta från skalhistoriken men förhindrar inte att de syns kortvarigt i processlistan. Sådana tester ska endast köras på en betrodd övervakningsvärd.

Testa SNMPv3 med AuthPriv

Anpassa IP-adress och användare, ange lösenfraserna och fråga först efter det ofarliga standard-OID:t sysUpTime.0:

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "Lösenord för SNMPv3-autentisering: " SNMP_AUTH
printf '\n'
read -r -s -p "Lösenord för SNMPv3-kryptering: " SNMP_PRIV
printf '\n'

snmpget -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_AUTH SNMP_PRIV

En lyckad första fråga returnerar sysUpTime.0 som Timeticks. Den efterföljande hämtningen visar endast de sensorer som den aktuella modellen stöder.

SNMPv2c som kompatibilitetstest

För en medvetet konfigurerad v2c-manager:

FIREWALL_IP="192.0.2.1"

read -r -s -p "SNMP-community: " SNMP_COMMUNITY
printf '\n'

snmpget -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_COMMUNITY

Ett lyckat uptime-test bekräftar nåbarhet och korrekta autentiseringsuppgifter, men ännu inte att alla sensorvärden är rimliga. Kontrollera därefter värdnamn, modell, firmware, MIB-version och värden mot WebAdmin, enheten och normal drift. Samla först in en baslinje under flera dagar innan temperatur- och PoE-larm aktiveras.

Larm och HA

Användbara larm rapporterar inte bara ett enskilt mätvärde utan en driftsmässig avvikelse:

SNMP-nåbarheten eller ett förväntat gränssnitt försvinner.
CPU- eller NPU-temperaturen ligger varaktigt över den egna baslinjen.
En befintlig fläkt rapporterar 0 RPM eller inget värde.
Ett redundant nätaggregat växlar till down(2).
PoE-förbrukningen närmar sig den konfigurerade effektgränsen för en port.
Gränssnittsfel eller drops ökar märkbart.

Fasta universella temperaturgränser vore missvisande. Modell, rack, omgivningstemperatur och belastning avgör normalområdet. En runbook för larm bör först kontrollera mätvärde, förlopp och modellbegränsning och därefter bedöma kylning, strömförsörjning, kablage, switchport eller PoE-enheter.

Larm bör skilja på minst Varning och Kritisk. För varje nivå ska ansvar, första kontrollsteg och eskaleringsväg anges i runbooken.

Vid bekräftad misstanke om hårdvarufel dokumenteras modell, serienummer, firmware, tidpunkt och förlopp. Processen för garanti och utbyte beskrivs i Sophos-hårdvarufel: förbered RMA och utbyte. För lagringsenheter passar Kontrollera SSD-hälsa med SMART bättre än SNMP.

I ett HA-kluster har varje enhet egna sensorer. Sophos dokumenterar en peer-administrationsadress för WebAdmin-åtkomst till Auxiliary-enheten, men inte att dess SNMP-hårdvaruvärden kan hämtas separat via den adressen. En fråga mot klusteradressen får därför inte betraktas som bevis för båda enheternas hårdvarustatus. Kontrollera efter HA-konfigurationen och efter en failover om managern entydigt kan koppla mätvärdena till en viss enhet. Använd annars en annan dokumenterad metod för att kontrollera Auxiliary-enheten. Grunderna för HA beskrivs i Konfigurera High Availability på Sophos Firewall.

SNMP-värden bör inte användas som enda bevis på prestanda. Hur genomströmning och belastning ska tolkas beskrivs i Tolka prestandavärden för Sophos Firewall korrekt.

Felsökning

Timeout eller inget svar

Kontrollera först övervakningssystemets IP-adress, routing, Device Access, Local Service ACL, Accept queries, SNMP-version och autentiseringsuppgifter. I WebAdmin under Diagnostics > Packet capture kan filtret host 192.0.2.50 and port 161 användas; hanteringen beskrivs i Packet Capture i WebAdmin.

Alternativt går det att kontrollera i alternativ 4, Device Console, om förfrågan når brandväggen:

tcpdump 'host 192.0.2.50 and port 161'

Avsluta testet med Ctrl+C. Om inget paket kommer fram ligger orsaken före SNMP-agenten. Om förfrågan kommer fram men inget svar går tillbaka är Device Access, managerns IP-adress, autentiseringsuppgifter och agentkonfiguration de följande kontrollpunkterna.

Autentisering eller algoritm misslyckas

Användarnamn, Security Level authPriv samt autentiserings- och krypteringsalgoritm måste exakt motsvara brandväggens inställningar. Om klienten inte accepterar SHA-256 eller SHA-512, kontrollera de metoder som stöds med snmpwalk -h och uppdatera Net-SNMP. Växla inte automatiskt tillbaka till MD5 eller okrypterat SNMP.

Vid ett fel på en förfrågan ska fokus inte ligga på Authorized hosts: i SNMPv3 gäller listan endast för trap-destinationer.

Hårdvaruvärden saknas eller verkar felaktiga

Kontrollera modellbegränsning, firmware och MIB-version. I SFOS 22.0 GA Build 365 kan hårdvaruvärden visas som strängar i stället för heltal på grund av NC-169564; Build 411 åtgärdar felet. Uppdatera MIB och övervakningssystemets Discovery efter uppgraderingen.

De senaste meddelandena kan läsas i Device Console:

show logs snmpd.log lines 100
show logs xgs-healthmond.log lines 100

snmpd.log hör till SNMP-agenten. xgs-healthmond.log hjälper vid CPU-temperatur och fläktstatus. Fler tilldelningar finns i Sophos Firewall-tjänsteloggar.

Traps kommer inte fram

Kontrollera först händelsetypen: för säkerhetsuppdateringar via hotfix i SFOS 23 är en utebliven trap förväntad. Den bevisar inte ett fel i routning, UDP 162 eller bekräftelsen av SNMPv3-informs och säger inget om uppdateringen lyckats. Använd för denna händelse vägen för e-post och uppdateringsverifiering ovan i stället för att ändra SNMP-transporten. Följande kontroller gäller händelser som stöder traps.

Kontrollera Send traps, Authorized hosts, UDP 162 och de valda händelserna under System services > Notification list. I Device Console visar en riktad paketfångst om brandväggen skickar till managern:

tcpdump 'host 192.0.2.50 and port 162'

Om paket lämnar brandväggen men inte kommer fram kontrolleras routing, mellanliggande brandväggar och trap-mottagaren. För SNMPv3-informs ska även managerns bekräftelse kontrolleras.