Konfiguracja monitorowania sprzętu Sophos Firewall za pomocą SNMP
Dzięki SNMP Hardware Monitoring można lepiej zintegrować stan Sophos Firewall z istniejącym systemem monitorowania. Oprócz klasycznych wartości dostępności i interfejsów, od Sophos Firewall v22 dostępne są dodatkowe metryki sprzętowe za pośrednictwem MIB. W zależności od modelu obejmują one temperaturę CPU, temperaturę NPU, wentylatory, status zasilacza i wartości PoE.
Jest to szczególnie interesujące dla produkcyjnych instalacji XGS. Firewall może być nadal dostępny w WebAdmin, ale jednocześnie wykazywać oznaki problemów termicznych, uszkodzonych wentylatorów, awarii zasilacza lub nieoczekiwanego obciążenia PoE. Takie stany nie powinny być zauważane dopiero przy następnym ręcznym logowaniu.
Kiedy SNMP na firewallu ma sens
SNMP ma sens, gdy już działa system monitorowania i firewall ma być monitorowany jako komponent infrastruktury.
Typowe przypadki użycia:
- Monitorowanie stanu sprzętu urządzeń XGS.
- Obserwowanie temperatury CPU i NPU w czasie.
- Włączenie statusu wentylatorów i zasilaczy do monitorowania NOC lub MSP.
- Kontrola obciążenia PoE w modelach XGS z portami PoE.
- Porównywanie wartości interfejsów z monitorowaniem switchów, routerów i dostawców.
- Korelowanie alarmów z firewalla, switcha, UPS i temperatury otoczenia.
SNMP nie zastępuje analizy logów. W przypadku pytań dotyczących ruchu i bezpieczeństwa ważniejsze są Log viewer, Central Firewall Reporting, Syslog lub SIEM. Dla wzorców ruchu na interfejsach lepiej pasuje sFlow Monitoring na Sophos Firewall. SNMP odpowiada głównie na pytania dotyczące stanu: Czy urządzenie jest dostępne, czy interfejsy działają, czy wartości sprzętowe są normalne i czy zmieniają się w czasie?
Wymagania
Przed konfiguracją należy wyjaśnić następujące kwestie:
- Istnieje system monitorowania z obsługą SNMP.
- Firewall jest dostępny przez sieć zarządzania lub monitorowania.
- Dostęp SNMP jest dozwolony tylko dla systemu monitorowania w Device Access.
- Odpowiednia MIB Sophos Firewall została zaimportowana do systemu monitorowania.
- Wiadomo, które modele firewalli będą monitorowane i jakie wartości sprzętowe te modele dostarczają.
- Zasady alarmowania są zaplanowane tak, aby zgłaszały rzeczywiste problemy operacyjne, a nie tylko generowały szum.
⚠️ SNMP nie powinno być szeroko dostępne z sieci klienckich, gościnnych, IoT ani WAN. Dane monitorowania mogą ujawniać model, interfejsy, wartości statusu i stany operacyjne. Dostęp powinien być ograniczony do zaufanej sieci zarządzania lub monitorowania.
Oddzielne traktowanie SNMP, sFlow i raportowania
SNMP, sFlow i raportowanie dostarczają różnych odpowiedzi.
| Narzędzie | Dobre pytanie | Nieidealne dla |
|---|---|---|
| SNMP | Czy firewall jest dostępny, jakie są wartości sprzętowe i interfejsów? | Pojedyncza reguła firewalla, blokada URL lub błąd VPN |
| sFlow | Jakie przepływy ruchu przechodzą przez interfejs? | Dokładna analiza pakietów lub reguł |
| Log Viewer / Syslog / Central Reporting | Która reguła, który moduł lub który użytkownik był zaangażowany? | Stan sprzętu i długoterminowe wartości sondowania interfejsów |
| Packet Capture | Co faktycznie widać na interfejsie? | Stałe monitorowanie |
W praktyce te narzędzia są łączone. SNMP zgłasza na przykład wysoką temperaturę lub błędy interfejsu. Następnie sprawdza się Log Viewer, Packet Capture, port switcha, temperaturę otoczenia lub dotknięty segment sieci.
Jakie wartości sprzętowe dostarcza SFOS 22
Sophos opisał dodatkowe metryki sprzętowe SNMP w notatkach wydania SFOS 22. Dostępność zależy od modelu firewalla.
| Metryka | Według Sophos dostępna dla |
|---|---|
| Temperatura CPU | wszystkie modele XGS |
| Temperatura NPU | modele XGS z wyjątkiem XGS 88/88w, 108/108w, 118/118w, 128/128w |
| Prędkość wentylatora | modele XGS z wyjątkiem XGS 88/88w i 108/108w |
| Status zasilacza | XGS 2100 i wyższe |
| Pomiary PoE | modele XGS z PoE, z wyjątkiem XGS 116/116w |
Ta tabela jest ważna dla oczekiwań. Jeśli mały model desktopowy nie dostarcza wartości wentylatora lub temperatury NPU, nie jest to automatycznie błąd monitorowania. Najpierw należy sprawdzić, czy model w ogóle obsługuje daną metrykę.
Zabezpieczenie dostępu SNMP
Pierwsza kontrola bezpieczeństwa nie odbywa się w systemie monitorowania, ale na samym firewallu.
W Administration > Device access SNMP powinno być dostępne tylko z sieci, w której znajduje się serwer monitorowania. Jeśli system monitorowania ma pojedynczy stały adres IP, reguła Local service ACL exception jest zazwyczaj lepsza niż szerokie udostępnienie stref.
Sensowne zasady podstawowe:
- Nie zezwalaj na SNMP z
WAN. - Nie udostępniaj SNMP dla całych stref klienckich lub serwerowych, jeśli tylko jeden host monitorujący wykonuje sondowanie.
- Zdefiniuj serwer monitorowania jako osobny obiekt hosta lub sieć zarządzania.
- Sprawdź dostęp po zmianach za pomocą Packet Capture lub testu monitorowania.
- Usuń nieużywane reguły SNMP i stare źródła monitorowania.
Device Access kontroluje ruch do samego firewalla. Zwykła reguła firewalla dla ruchu LAN-do-WAN nie zastępuje tego ustawienia.
Świadomy wybór wersji SNMP
Jeśli to możliwe, należy używać SNMPv3, ponieważ umożliwia ono uwierzytelnianie, a przy odpowiedniej konfiguracji AuthPriv także szyfrowanie. SNMPv1 i SNMPv2c działają z ciągami wspólnotowymi. Te ciągi wspólnotowe nie są kontami użytkowników, lecz wspólnymi tajemnicami i powinny być odpowiednio chronione.
Dla SNMPv1/v2c Sophos w SFOS 22 wprowadza zmianę: można dodać ciąg wspólnotowy i wybrać, czy konfiguracja dotyczy IPv4 czy IPv6. Po aktualizacji firewall przejmuje istniejące nazwy jako ciąg wspólnotowy i generuje zmigrowane nazwy obiektów z prefiksem snmp.
Po aktualizacji należy sprawdzić:
- Czy istnieją stare ciągi wspólnotowe SNMPv1/v2c?
- Czy automatycznie zmigrowane obiekty
snmpsą zrozumiale nazwane? - Czy naprawdę potrzebne jest IPv4, IPv6 czy oba?
- Czy można usunąć stare źródła monitorowania?
- Czy możliwe jest użycie SNMPv3, czy z powodów kompatybilności konieczne jest pozostanie przy v2c?
⚠️ Ciągi wspólnotowe nie powinny być traktowane jak nieszkodliwe etykiety. Takie ciągi należą do koncepcji haseł lub tajemnic, nie powinny być kopiowane do zgłoszeń i nie mogą być widoczne na zrzutach ekranu.
Import MIB i sprawdzanie OID
Aby system monitorowania mógł sensownie rozpoznać wartości Sophos, potrzebuje odpowiedniego pliku MIB. MIB opisuje, które OID są dostępne dla wartości firewalla, interfejsów i sprzętu.
Praktyczne podejście:
- Pobierz aktualny plik MIB z Sophos Firewall lub odpowiedniej dokumentacji Sophos.
- Zaimportuj MIB do systemu monitorowania.
- Dodaj firewall z SNMPv3 lub świadomie wybraną konfiguracją v1/v2c.
- Rozpoznaj model, wersję oprogramowania i dostępne OID.
- Sprawdź metryki sprzętowe w odniesieniu do konkretnego modelu.
- Przeprowadź ręczne sondowanie i sprawdź wiarygodność wartości.
- Dopiero potem aktywuj zasady alarmowania.
Po aktualizacjach oprogramowania należy ponownie sprawdzić stronę MIB. Nowe wersje SFOS mogą dodawać OID lub zmieniać istniejące obszary. Jeśli system monitorowania po aktualizacji nie rozwiązuje wartości poprawnie, nie należy najpierw podejrzewać firewalla, lecz sprawdzić wersję MIB, odkrywanie i przypisanie OID.
Sensowne alarmowanie
Monitorowanie SNMP jest pomocne tylko wtedy, gdy alarmy są sensownie ustawione. Zbyt wąskie progi generują szum, zbyt szerokie progi zgłaszają problemy z opóźnieniem.
Typowe obszary alarmowe:
| Obszar | Sensowne sprawdzenie |
|---|---|
| Dostępność | Firewall nie odpowiada już przez SNMP lub Ping |
| Temperatura CPU | Temperatura stale wzrasta powyżej normalnego zakresu |
| Temperatura NPU | Trend temperatury jest podejrzany lub stale wyższy niż wartości porównawcze |
| Prędkość wentylatora | Wartość wentylatora jest brakująca, wynosi zero lub jest znacznie poza normalnym zakresem |
| Zasilacz | Brakuje redundantnego zasilacza lub zgłasza błąd |
| PoE | Obciążenie PoE zbliża się do dostępnego budżetu |
| Interfejsy | Port down, licznik błędów, nietypowa przepustowość |
Dla wartości temperatury ważna jest linia bazowa. Mały firewall desktopowy w ciepłej szafie technicznej zachowuje się inaczej niż urządzenie rackowe w klimatyzowanym pomieszczeniu. Dlatego najpierw należy obserwować kilka dni normalnej pracy, a dopiero potem ustalić produktywne progi.
Ustalenie runbooka alarmowego i odpowiedzialności
Alarm SNMP jest pomocny tylko wtedy, gdy wiadomo, kto reaguje i jaki jest przebieg działań. Wartości sprzętowe są często wczesnymi wskaźnikami: wzrastająca temperatura, brakująca wartość wentylatora lub alarm zasilacza nie oznaczają automatycznie, że urządzenie musi zostać natychmiast wymienione. Oznacza to jednak, że stan powinien być oceniony i udokumentowany.
Dla produkcyjnych firewalli powinien istnieć krótki wpis w runbooku:
| Alarm | Pierwsze sprawdzenie |
|---|---|
| Firewall nie jest dostępny przez SNMP | Sprawdź sieć zarządzania, Device Access, routing, serwer monitorowania i dostępność urządzenia |
| Temperatura stale wzrasta | Porównaj temperaturę otoczenia, wentylację, pozycję w racku, kurz, obciążenie i przebieg |
| Wartość wentylatora jest brakująca lub podejrzana | Sprawdź granicę modelu, wartość sensora, hałas, trend temperatury i znaczenie dla wsparcia |
| Zasilacz zgłasza błąd | Sprawdź zasilanie, UPS, kable, redundantny zasilacz i ryzyko HA |
| Obciążenie PoE jest wysokie | Sprawdź podłączone urządzenia, budżet PoE i planowane rezerwy |
| Błędy interfejsu rosną | Sprawdź kable, port switcha, duplex/szybkość, moduł SFP i przekazanie dostawcy |
Ważna jest kolejność: najpierw sprawdź widoczność i wiarygodność, potem oceń ryzyko, następnie przygotuj proces wsparcia lub wymiany. W przypadku podejrzenia uszkodzenia sprzętu należy dodatkowo udokumentować numer seryjny, model, wersję oprogramowania, czas, dotkniętą metrykę, przebieg oraz zrzut ekranu lub wyciąg z monitorowania. Pytania dotyczące gwarancji i RMA zależą na końcu nie tylko od alarmu, ale od konkretnego urządzenia, statusu wsparcia i obrazu błędu.
Dla tematów związanych z SSD SNMP nie jest właściwą główną drogą. Jeśli stan nośnika danych lub obciążenie zapisem są w centrum uwagi, lepiej pasuje Sprawdzanie zdrowia SSD Sophos Firewall za pomocą SMART.
HA-Cluster i wiele firewalli
W środowiskach HA należy jasno określić, jak oba urządzenia będą monitorowane. Nie zawsze wystarczy obserwować tylko adres klastra. Dla wartości sprzętowych często oba urządzenia są istotne, ponieważ wentylator, zasilacz lub port na pasywnym urządzeniu również mogą ulec awarii.
Ważne pytania:
- Czy Primary i Auxiliary są rozpoznawane oddzielnie?
- Czy oba urządzenia mają własne adresy IP do monitorowania?
- Czy numer seryjny, nazwa hosta lub model są jednoznacznie wyświetlane w monitorowaniu?
- Czy alarmy pozostają zrozumiałe po przełączeniu awaryjnym?
- Czy błąd zasilacza na pasywnym urządzeniu również jest zgłaszany?
Dla samego działania HA lepiej pasuje Konfiguracja wysokiej dostępności Sophos Firewall. SNMP nie powinno być tam planowane w izolacji, lecz razem z aktualizacjami oprogramowania, testami przełączenia awaryjnego, koncepcją kopii zapasowych i dokumentacją operacyjną.
Walidacja po konfiguracji
Po konfiguracji SNMP nie należy tylko sprawdzać, czy monitorowanie jest zielone. Ważne jest, czy dane pochodzą z właściwego źródła.
Lista kontrolna:
- Dostęp SNMP jest możliwy tylko z sieci monitorowania.
- Firewall jest rozpoznawany z poprawną nazwą hosta, modelem i wersją oprogramowania.
- MIB Sophos jest zaimportowana i wartości sprzętowe są poprawnie nazwane.
- Nieobsługiwane metryki są dokumentowane jako granica modelu, a nie jako błąd.
- Wartości temperatury, wentylatora, zasilacza i PoE są wiarygodne.
- Testowy alarm jest wywoływany i trafia do właściwego odbiorcy.
- W przypadku klastrów HA oba urządzenia lub pożądana logika klastra są sprawdzane.
- Po aktualizacji oprogramowania ponownie testuje się odkrywanie.
Dla pytań dotyczących wydajności i przepustowości nie należy nadinterpretować wartości SNMP. Interpretacja danych wydajnościowych Sophos jest opisana w artykule Zrozumienie danych wydajnościowych Sophos Firewall.
Rozwiązywanie problemów
Firewall nie odpowiada na SNMP
Najpierw sprawdź, czy system monitorowania pochodzi z oczekiwanej strefy i czy SNMP jest dozwolone w Administration > Device access. Następnie sprawdź adres IP, routing, lokalne reguły ACL, wersję SNMP, ciąg wspólnotowy lub dane dostępowe SNMPv3.
Jeśli nie jest jasne, czy pakiety docierają do firewalla, pomocne jest Packet Capture na dotkniętym interfejsie. Zwykła reguła firewalla nie rozwiązuje tego problemu, jeśli ruch kieruje się do samego firewalla.
MIB jest importowana, ale brakuje wartości
Najpierw sprawdź, czy brakująca metryka jest dostępna dla używanego modelu. Małe modele XGS nie dostarczają wszystkich wartości sprzętowych. Następnie porównaj wersję MIB, przypisanie OID i wersję oprogramowania.
Po aktualizacji obiekty SNMP są inaczej nazwane
W przypadku SNMPv1/v2c SFOS 22 może generować zmigrowane obiekty z prefiksem snmp. Po aktualizacji należy zatem sprawdzić ciągi wspólnotowe, nazwy obiektów i odkrywanie monitorowania. Jeśli monitorowanie działa z nazwami zamiast stabilnych OID, mogą być konieczne dostosowania szablonów.
Monitorowanie zgłasza zbyt wiele alarmów temperaturowych
Wtedy prawdopodobnie progi są zbyt wąskie lub ustawione bez linii bazowej. Najpierw zbierz normalne wartości przez kilka dni. Następnie ustal progi według modelu, lokalizacji i temperatury otoczenia. Pojedyncze krótkie szczyty są oceniane inaczej niż stale rosnący trend temperatury.
HA-Cluster pokazuje tylko jedno urządzenie
Wtedy należy sprawdzić, czy monitorowanie pyta tylko o adres klastra, czy oba urządzenia są dostępne oddzielnie. Dla stanu sprzętu pasywne urządzenie również jest istotne. W przypadku produkcyjnych klastrów należy udokumentować, który adres IP reprezentuje które urządzenie i jaką rolę.
Lista kontrolna operacyjna
- Zezwalaj na SNMP tylko z sieci zarządzania lub monitorowania.
- Preferuj SNMPv3, jeśli system monitorowania go poprawnie obsługuje.
- Traktuj ciągi wspólnotowe SNMPv1/v2c jak tajemnice.
- Importuj MIB Sophos i sprawdzaj po aktualizacjach oprogramowania.
- Dokumentuj granice modelu dla wartości sprzętowych.
- Ustalaj progi temperatury i PoE na podstawie rzeczywistych linii bazowych.
- Nazwij i oceniaj urządzenia HA jednoznacznie i oddzielnie.
- Dokumentuj runbook alarmowy z pierwszym sprawdzeniem, eskalacją i odpowiedzialnością.
- W przypadku podejrzenia uszkodzenia sprzętu zabezpiecz model, numer seryjny, wersję oprogramowania i przebieg.
- Regularnie testuj alarmy i ustalaj odpowiedzialność.
- Łącz dane SNMP z logami, sFlow, Packet Capture i Central Reporting.