Konfiguracja monitorowania sprzętu przez SNMP na Sophos Firewall

Aby skonfigurować monitorowanie sprzętu przez SNMP, należy włączyć agenta w Administration > SNMP, utworzyć najlepiej użytkownika SNMPv3, ograniczyć dostęp w Administration > Device access do hosta monitorującego i pobrać aktualną MIB. Następnie można sprawdzić połączenie z systemu monitorowania za pomocą snmpget i odpytać drzewo sprzętowe poleceniem snmpwalk.

Od wersji Sophos Firewall v22 MIB udostępnia, zależnie od modelu XGS, także temperaturę CPU i NPU, prędkości wentylatorów, stan zasilaczy oraz wartości PoE. SNMP odpowiada więc przede wszystkim na pytania o stan urządzenia. Do pojedynczych zdarzeń bezpieczeństwa lepiej nadają się Central Firewall Reporting lub Syslog, a do analizy wzorców ruchu sFlow.

Jeżeli zamiast stałego monitorowania potrzebna jest doraźna kontrola bezpośrednio na urządzeniu, artykuł Sprawdzanie temperatury i wentylatora Sophos Firewall przez SSH pokazuje, jak odczytać sensors i xgs-healthmond.log oraz prawidłowo interpretować pozorne alarmy surowych czujników.

⚠️ SNMP powinno być dostępne wyłącznie z zaufanej sieci zarządzającej lub monitorującej. Szerokie udostępnienie usługi ze stref klienta, gościa, IoT lub WAN niepotrzebnie ujawnia informacje o modelu, interfejsach i stanie urządzenia.

Bezpieczna konfiguracja SNMP

Ograniczenie dostępu do hosta monitorującego

Jeśli dostęp ma mieć dedykowana strefa monitorująca, SNMP włącza się w Administration > Device access tylko dla tej strefy. Jeśli zapytania wysyła dokładnie jeden serwer ze stałym adresem IP, SNMP pozostaje wyłączone dla całej strefy. Zamiast tego Local service ACL exception rule zezwala konkretnie na źródło, cel na zaporze i usługę SNMP. Pełną konfigurację opisuje artykuł Zabezpieczenie Device Access na Sophos Firewall.

SNMP jest lokalną usługą zapory. Zwykła reguła LAN-to-WAN nie zastępuje Device Access. Nie należy bezpośrednio udostępniać SNMP z WAN; bezpieczniejszym rozwiązaniem dla zewnętrznego monitorowania jest VPN do zarządzania.

Włączenie agenta

Otworzyć Administration > SNMP.
Włączyć Enable SNMP agent.
Wpisać nazwę, lokalizację i kontakt, na przykład xgs-zrh-01, ZRH-DC1 / Rack 3 oraz noc@example.net.
Zapisać przyciskiem Apply.
Za pomocą Download MIB pobrać MIB odpowiadającą wersji zapory i zaimportować ją do systemu monitorowania.

Zapytania trafiają do agenta przez UDP 161. Trapy są wysyłane do managera przez UDP 162. Routing i lokalne zapory hostów między oboma systemami również muszą zezwalać na ruch w tych kierunkach.

Konfiguracja SNMPv3

W Administration > SNMP > SNMPv3 users and traps kliknąć Add.
Ustawić trwałą nazwę użytkownika, na przykład monitoring. Nie można jej później zmienić.
Włączyć Accept queries.
Send traps włączyć tylko wtedy, gdy zapora ma również wysyłać komunikaty do managera.
W nowych konfiguracjach wybierać w miarę możliwości AES oraz SHA256 lub SHA512. Obie frazy hasłowe muszą mieć co najmniej dwanaście znaków.
Zapisać.

Według Sophos lista Authorized hosts dotyczy wyłącznie celów trapów. Nie ogranicza zapytań SNMPv3. Za dostęp do zapytań odpowiadają prawidłowe dane uwierzytelniające, Accept queries i Device Access.

SNMPv1 lub SNMPv2c tylko w razie potrzeby

Jeśli system monitorowania nie obsługuje prawidłowo SNMPv3, w Administration > SNMP > SNMPv1/v2c tworzy się wpis community. Potrzebne są nazwa, Community String, IPv4 lub IPv6, adres IP managera i Accept queries. Send traps pozostaje wyłączone, jeśli trapy nie są używane.

Community String działa jak hasło, ale w SNMPv1/v2c jest przesyłany bez szyfrowania. Nie powinien pojawiać się na zrzutach ekranu ani w zgłoszeniach i należy go używać wyłącznie w ściśle ograniczonej sieci zarządzającej.

Po aktualizacji do SFOS 22 należy sprawdzić istniejące wpisy v1/v2c: zapora przejmuje dotychczasową nazwę jako Community String i tworzy nazwę migrowanego obiektu z prefiksem snmp. Przy tej okazji można usunąć zbędne warianty IPv4/IPv6 i nieużywane już źródła monitorowania.

Selektywne włączenie trapów

Sam użytkownik SNMP lub wpis community nie wystarcza do konfiguracji trapów. W System services > Notification list trzeba włączyć SNMP traps oraz rzeczywiście potrzebne typy alertów.

Odbiór należy sprawdzić przy rzeczywiście występującym, wybranym zdarzeniu. Informs SNMPv3 są potwierdzane; jeśli zapora nie otrzyma potwierdzenia, według Sophos nie ponawia wysyłki. Powiadomienia typu trap i inform nie zastępują więc monitorowania przez cykliczne zapytania.

Metryki sprzętowe i ograniczenia modeli

SFOS 22 udostępnia nowe wartości sprzętowe dla urządzeń XGS:

CPU temperature: wszystkie modele XGS.
NPU temperature: wszystkie modele XGS z wyjątkiem 88/88w, 108/108w, 118/118w oraz 128/128w.
Fan speed: wszystkie modele XGS z wyjątkiem 88/88w i 108/108w.
Power supply status: XGS 2100 i wyższe.
PoE measurements: modele XGS z PoE z wyjątkiem XGS 116/116w.

Sophos dokumentuje te czujniki dla sprzętu XGS. W przypadku urządzeń wirtualnych, chmurowych lub instalacji programowych nie należy oczekiwać fizycznych czujników hosta w SFOS-MIB. Także na XGS brak metryki nie oznacza automatycznie błędu; najpierw trzeba sprawdzić ograniczenia konkretnego modelu.

OID i jednostki z SFOS-22-MIB

Drzewo sprzętowe zaczyna się od .1.3.6.1.4.1.2604.5.1.9. Najważniejsze obszary to:

Temperatura NPU: .1.3.6.1.4.1.2604.5.1.9.1.0
Temperatura CPU: .1.3.6.1.4.1.2604.5.1.9.2.0
Prędkość wentylatora: .1.3.6.1.4.1.2604.5.1.9.3.1.2
Stan zasilacza: .1.3.6.1.4.1.2604.5.1.9.4.1.2
Tabela PoE: .1.3.6.1.4.1.2604.5.1.9.5

Temperatury są podawane w dziesiątych częściach stopnia Celsjusza: 420 oznacza 42,0 °C. Prędkość wentylatora jest podawana w RPM. Moc PoE jest wyrażana w miliwatach, napięcie w miliwoltach, a natężenie w miliamperach. Dla zasilacza up(1) oznacza gotowość do pracy, a down(2) awarię.

Do liczbowego przetwarzania wartości sprzętowych powinna działać co najmniej wersja SFOS 22.0 GA Build 411. Ten build naprawia między innymi błąd NC-169564, przez który wartości czujników były zwracane jako ciągi znaków zamiast liczb całkowitych, a także inne problemy z MIB i OID.

Po aktualizacji firmware należy ponownie pobrać aktualną MIB, zaimportować ją do systemu monitorowania i sprawdzić Discovery. Szablony monitorowania nie powinny opierać się wyłącznie na nazwach wyświetlanych.

Testowanie połączenia i wartości sprzętowych

Poniższe polecenia Bash wykonuje się na hoście monitorującym z systemem Linux lub macOS i zainstalowanym Net-SNMP, a nie na Sophos Firewall. W macOS należy najpierw uruchomić bash, ponieważ read -p ma inne znaczenie w domyślnej powłoce zsh. Przykłady sprawdzono pod kątem udokumentowanej składni Net-SNMP i oficjalnej SFOS-22-MIB, ale nie wykonano ich na zaporze klienta.

SHA-256 i SHA-512 wymagają zazwyczaj Net-SNMP 5.8 lub nowszego. Polecenie snmpwalk -h pozwala sprawdzić, które algorytmy obsługuje zainstalowany klient. Niektóre starsze wersje macOS obsługują tylko MD5 i SHA.

⚠️ Net-SNMP przekazuje Community String i frazy hasłowe jako argumenty procesu. Wprowadzanie ich przez read chroni przed zapisaniem w historii powłoki, ale nie zapobiega krótkotrwałej widoczności na liście procesów. Takie testy należy wykonywać wyłącznie na zaufanym hoście monitorującym.

Test SNMPv3 z AuthPriv

Dostosować adres IP i użytkownika, wprowadzić frazy hasłowe i najpierw odpytać bezpieczny standardowy OID sysUpTime.0:

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "Hasło uwierzytelniania SNMPv3: " SNMP_AUTH
printf '\n'
read -r -s -p "Hasło szyfrowania SNMPv3: " 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

Pierwsze zapytanie zakończone powodzeniem zwraca sysUpTime.0 jako Timeticks. Kolejne odpytanie pokazuje tylko czujniki obsługiwane przez konkretny model.

SNMPv2c jako test zgodności

Dla świadomie skonfigurowanego managera v2c:

FIREWALL_IP="192.0.2.1"

read -r -s -p "Community SNMP: " 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

Prawidłowy test czasu pracy potwierdza dostępność i poprawność danych uwierzytelniających, ale jeszcze nie wiarygodność wszystkich wartości czujników. Następnie należy porównać nazwę hosta, model, firmware, wersję MIB i wartości z WebAdmin, urządzeniem oraz normalnym stanem pracy. Przed ustawieniem alarmów temperatury i PoE należy przez kilka dni zebrać wartości bazowe.

Alarmy i HA

Przydatne alarmy zgłaszają nie tylko pojedynczą wartość pomiarową, lecz odchylenie istotne dla działania:

Brak dostępności SNMP lub oczekiwanego interfejsu.
Temperatura CPU lub NPU utrzymuje się powyżej własnej wartości bazowej.
Istniejący wentylator zgłasza 0 RPM lub nie zwraca wartości.
Nadmiarowy zasilacz zmienia stan na down(2).
Zużycie PoE zbliża się do dostępnego budżetu.
Liczba błędów lub dropów na interfejsie wyraźnie rośnie.

Stałe, uniwersalne progi temperatury byłyby mylące. Normalny zakres zależy od modelu, szafy rack, temperatury otoczenia i obciążenia. Runbook alarmowy powinien najpierw obejmować sprawdzenie wartości, przebiegu i ograniczeń modelu, a następnie ocenę chłodzenia, zasilania, okablowania, portu przełącznika lub urządzeń PoE.

Alarmy powinny rozróżniać co najmniej poziomy Ostrzeżenie i Krytyczny; dla każdego poziomu należy określić w runbooku odpowiedzialność, pierwszy krok kontrolny i ścieżkę eskalacji.

Przy potwierdzonym podejrzeniu usterki sprzętu należy udokumentować model, numer seryjny, firmware, czas i przebieg. Proces gwarancyjny i wymianę opisuje artykuł Usterka sprzętu Sophos: przygotowanie RMA i wymiany. W przypadku nośników danych lepiej użyć procedury Sprawdzanie stanu SSD za pomocą SMART niż SNMP.

W klastrze HA istotne są oba urządzenia. Odpytanie samego adresu klastra nie musi pokazywać wentylatora, zasilacza ani portu urządzenia pasywnego. Jeśli architektura sieci i platforma pozwalają na oddzielny dostęp administracyjny, Primary i Auxiliary powinny być rozpoznawane osobno. Rzeczywistą dostępność SNMP i przypisanie należy sprawdzić po zestawieniu HA oraz po failoverze. Podstawy HA opisuje artykuł Konfiguracja High Availability na Sophos Firewall.

Wartości SNMP nie powinny być jedynym dowodem wydajności. Interpretację przepustowości i obciążenia opisuje artykuł Prawidłowa interpretacja parametrów wydajności Sophos Firewall.

Rozwiązywanie problemów

Timeout lub brak odpowiedzi

Najpierw sprawdzić adres IP systemu monitorowania, routing, Device Access, Local Service ACL, Accept queries, wersję SNMP i dane uwierzytelniające. W WebAdmin w Diagnostics > Packet capture można użyć filtra host 192.0.2.50 and port 161; obsługę opisuje artykuł Packet Capture w WebAdmin.

Alternatywnie w opcji 4 Device Console można sprawdzić, czy zapytanie dociera do zapory:

tcpdump 'host 192.0.2.50 and port 161'

Po teście zakończyć przechwytywanie klawiszami Ctrl+C. Jeśli pakiet nie dociera, przyczyna znajduje się przed agentem SNMP. Jeśli zapytanie dociera, ale odpowiedź nie wraca, w następnej kolejności należy sprawdzić Device Access, adres IP managera, dane uwierzytelniające i konfigurację agenta.

Błąd uwierzytelniania lub algorytmu

Nazwa użytkownika, Security Level authPriv oraz algorytmy uwierzytelniania i szyfrowania muszą dokładnie odpowiadać konfiguracji zapory. Jeśli klient nie akceptuje SHA-256 lub SHA-512, należy sprawdzić obsługiwane metody poleceniem snmpwalk -h i zaktualizować Net-SNMP. Nie należy po cichu przechodzić na MD5 lub nieszyfrowane SNMP.

Przy błędzie zapytania nie należy skupiać się na Authorized hosts: w SNMPv3 lista ta dotyczy wyłącznie celów trapów.

Brakujące lub nieprawidłowe wartości sprzętowe

Sprawdzić ograniczenia modelu, firmware i wersję MIB. W SFOS 22.0 GA Build 365 wartości sprzętowe mogą być zwracane jako ciągi znaków zamiast liczb całkowitych z powodu NC-169564; Build 411 naprawia ten błąd. Po aktualizacji odświeżyć MIB i Discovery systemu monitorowania.

Ostatnie komunikaty można odczytać w Device Console:

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

snmpd.log należy do agenta SNMP. xgs-healthmond.log pomaga przy temperaturze CPU i stanie wentylatorów. Dalsze przypisania zawiera artykuł Logi usług Sophos Firewall.

Trapy nie docierają

Sprawdzić Send traps, Authorized hosts, UDP 162 oraz wybrane zdarzenia w System services > Notification list. W Device Console precyzyjnie filtrowane przechwytywanie pakietów pokazuje, czy zapora wysyła dane do managera:

tcpdump 'host 192.0.2.50 and port 162'

Jeśli pakiety opuszczają zaporę, ale nie docierają do celu, należy sprawdzić routing, zapory pośrednie i odbiornik trapów. W przypadku informs SNMPv3 należy dodatkowo sprawdzić potwierdzenie managera.