Hoppa till innehållet
Avanet

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

Sophos Firewall

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-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

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

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

  1. Klicka på Add under Administration > SNMP > SNMPv3 users and traps.
  2. Ange ett beständigt användarnamn, till exempel monitoring. Det kan inte ändras senare.
  3. Aktivera Accept queries.
  4. Aktivera endast Send traps om brandväggen även ska skicka meddelanden till managern.
  5. 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.
  6. Spara.

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 skapas en community-post under Administration > SNMP > SNMPv1/v2c. 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.

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

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.

Hårdvarumätvärden och modellbegränsningar

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

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

Sophos dokumenterar dessa sensorer för XGS-hårdvara. För virtuella, molnbaserade eller programvarubaserade enheter bör man inte förvänta sig fysiska värdsensorer i SFOS-MIB. Även på XGS 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 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 budgeten.
  • 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 är båda enheterna relevanta. En fråga mot enbart klusteradressen visar inte nödvändigtvis fläkten, nätaggregatet eller porten på den passiva enheten. Om nätverksdesignen och plattformen tillåter separata hanteringsanslutningar bör Primary och Auxiliary identifieras var för sig. Den faktiska SNMP-nåbarheten och tilldelningen måste kontrolleras efter HA-konfigurationen och efter en failover. 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 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.