Sophos Firewall w trybie Failsafe: diagnostyka przyczyny

Gdy Sophos Firewall uruchamia się w trybie Failsafe, SFOS wykrył błąd krytyczny i nie rozpoczął normalnej pracy. Przetwarzanie pakietów, interfejsy i dostęp administracyjny mogą przestać działać całkowicie lub częściowo, zależnie od przyczyny. Dlatego z nadal dostępnego portu administracyjnego nie wolno wnioskować, że zapora wciąż zapewnia niezawodną ochronę.

Najważniejszym pierwszym krokiem nie jest Factory Reset ani reimage, lecz zapisanie przyczyny wykrytej przez SFOS:

1. Połączyć się przez konsolę lokalną, szeregową lub konsolę hypervisora.
2. Otworzyć Device Console w menu Failsafe.
3. Wykonać następujące polecenie tylko do odczytu:

show failure-reason

Konsola może następnie wyglądać na przykład tak:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> jest tylko promptem i nie należy go wpisywać. Dokładny komunikat może być inny. Najważniejsze jest sfotografowanie lub skopiowanie niezmienionego wyniku i pierwszych widocznych wierszy konsoli. Jeśli SSH nadal działa w stanie błędu, Device Console jest dostępna również tą drogą; w przypadku awarii konsola lokalna, szeregowa lub hypervisora pozostaje bardziej niezawodnym dostępem.

⚠️ Zapisać przed ponownym uruchomieniem: Reboot może zmienić widoczny stan błędu lub tymczasowo go usunąć. Wcześniej należy udokumentować co najmniej komunikat o błędzie, wersję SFOS wraz z Buildem, rolę appliance i czas zdarzenia. Reset to Factory Defaults, Remove Firewall Rules oraz ręczne ingerencje w bazę danych lub system plików nie są diagnostyką i mogą zniszczyć ważną konfigurację lub materiał dowodowy.

Co oznacza tryb Failsafe

Failsafe jest stanem ochrony i odzyskiwania. SFOS uruchamia go, gdy komponent wymagany do bezpiecznego działania zapory nie uruchomi się prawidłowo. Znane komunikaty i rzeczywiste przypadki błędów dotyczą na przykład bazy danych konfiguracji, frameworka firewalla, zestawu reguł, usługi logowania lub sieciowej, bazy sygnatur albo, w odpowiednio wyposażonym modelu XGS, Network Processing Unit (NPU). Nie jest to kompletna macierz napraw; decydujący pozostaje konkretny wynik wyświetlony na konsoli.

Sam niedostępny WebAdmin nie dowodzi jeszcze stanu Failsafe. Jeśli ruch jest nadal przetwarzany, a zawiesił się tylko interfejs, najpierw należy przeprowadzić ukierunkowaną kontrolę lub restart WebAdmin GUI. Rzeczywisty tryb Failsafe rozpoznaje się na konsoli. To, czy dostęp administracyjny lub pojedyncze interfejsy nadal działają, zależy od przyczyny i nie potwierdza prawidłowego stanu zapory.

To rozróżnienie jest ważne: gdy awarii uległa jedna usługa, jej celowy restart może być właściwy. W trybie Failsafe brakuje natomiast krytycznego warunku uruchomienia. Restartowanie wielu usług na próbę raczej zaciemnia przyczynę, niż ją usuwa.

Diagnostyka przyczyny Failsafe za pomocą show failure-reason

Polecenie show failure-reason należy wykonać w Device Console, a nie w Advanced Shell. Nie zmienia ono konfiguracji. Pokazuje klasę błędu wykrytą przez SFOS podczas uruchamiania.

Wynik jest punktem wyjścia, a nie kompletną instrukcją naprawy. Poniższe grupy komunikatów pomagają w klasyfikacji:

• Configuration database: Zapora nie mogła prawidłowo uruchomić bazy danych konfiguracji. Przed ręcznymi naprawami należy zapisać komunikat o błędzie, Build, ostatnią zmianę i dostępny backup. Nie usuwać ani nie modyfikować plików bazy danych.
• Firewall framework lub firewall rules: SFOS nie mógł zastosować podstawy przetwarzania pakietów lub zestawu reguł. Istotne są ostatnie zmiany reguł, obiektów, restore lub firmware. Ogólne usunięcie wszystkich reguł firewall oznaczałoby utratę danych, a nie prawidłową pierwszą diagnostykę.
• Logging daemon: Krytyczna usługa logowania nie uruchomiła się. Oprócz komunikatu o błędzie należy sprawdzić stan pamięci masowej, Build i logi. Nie usuwać Reports ani logów bez uprzedniego zapisania potrzebnych danych.
• Network daemon: Komponenty sieciowe nie mogły się prawidłowo uruchomić. W przypadku wirtualnych appliances należy sprawdzić istniejące vNICs, kolejność adapterów i zmiany w hypervisorze.
• Signature database: Nie udało się wczytać wymaganej bazy sygnatur. Istotne są stan Pattern, pamięć masowa i związek czasowy z aktualizacjami; plików sygnatur nie usuwa się ręcznie.
• NPU: W przypadku modelu XGS wyposażonego w NPU już pierwszy wiersz konsoli może zawierać Network processing unit error. Nawet jeśli show failure-reason nie zwróci potem użytecznych danych, należy zapisać całą konsolę i przygotować zgłoszenie do wsparcia lub przypadek sprzętowy.

Dokładna pisownia komunikatu może się różnić zależnie od wersji SFOS. Dla wsparcia niezmieniony wynik jest zatem cenniejszy niż własne podsumowanie, takie jak Firewall nie uruchamia się.

Kontrola platformy i ostatniej zmiany

Kolejny krok zależy od tego, czy problem dotyczy sprzętu, wirtualnej lub programowej appliance, czy klastra HA. Ten sam komunikat o błędzie nie może automatycznie prowadzić do tego samego działania.

Wirtualna firewall i software appliance

Wirtualna firewall może przejść w tryb Failsafe już z powodu nieodpowiednich zasobów. Sophos podaje obecnie dla lokalnych appliances SFOS 22 działających pod VMware, Hyper-V, KVM i Citrix co najmniej:

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

Ponadto skonfigurowane vCPU i vRAM nie mogą przekraczać zakupionej licencji. Wartości minimalne są wyłącznie technicznymi progami uruchomienia, a nie sizingiem produkcyjnym dla IPS, TLS Inspection lub wysokiej przepustowości.

Auxiliary Disk z obrazów VM jest tą oddzielną Report Disk. Nie jest opcjonalna i nie zastępuje Primary Disk. W przypadku AWS i Azure obowiązują natomiast obsługiwane typy instancji chmurowych i rozmiary właściwe dla danej platformy.

W hypervisorze należy sprawdzić, czy oba dyski i wszystkie przewidziane vNICs nadal istnieją, są podłączone i przypisane w oczekiwanej kolejności. Późniejsza zmiana CPU, RAM, kontrolera dysku lub sieci wirtualnej również należy do osi czasu incydentu. Różnice między platformami i wymagania dotyczące zasobów opisano szerzej w osobnym artykule.

Dla software appliance SFOS 22 bezsporne są x86-64, Legacy BIOS, co najmniej 4 GB RAM i dwie karty sieciowe. Dwie aktualne strony Sophos podają jednak sprzeczne wartości dla dysku: ogólny przegląd platform wskazuje minimum 10 GB, a nowsza, szczegółowa strona software appliance minimum 32 GB i zaleca 64 GB. Nie istnieje zatem jednolity opublikowany limit Sophos. Dla nowych instalacji Avanet konserwatywnie zaleca co najmniej 32 GB, a w miarę możliwości 64 GB; odpowiada to bardziej szczegółowej stronie produktu i pozwala uniknąć systemu zbyt ciasnego już podczas uruchamiania.

Podczas niejasnej próby odzyskiwania nie należy wielokrotnie i dowolnie zmieniać zasobów. Najpierw dokumentuje się stan bieżący, a następnie wykonuje planowaną korektę ze zdefiniowanym testem uruchomienia.

Hardware appliance i NPU

W fizycznym urządzeniu XGS uwzględnia się dodatkowo zdarzenia zasilania, temperaturę, wentylatory, błędy SSD lub I/O oraz pierwsze komunikaty startowe. Błąd NPU w odpowiednio wyposażonym modelu XGS nie jest powodem do testowania nieudokumentowanych poleceń resetu lub service. Jeśli komunikat powraca albo sama diagnostyka się nie powiedzie, właściwym kolejnym krokiem jest zgłoszenie do wsparcia z możliwym przygotowaniem RMA.

Jeden udany restart nie dowodzi jeszcze, że problem sprzętowy został rozwiązany. Przy powtarzających się awariach pomagają również istniejące kontrole temperatury i wentylatorów oraz stanu SSD.

Failsafe w klastrze HA

W przypadku HA najpierw ustala się, którego Node dotyczy problem i czy peer stabilnie przetwarza ruch produkcyjny. Dokumentuje się Primary lub Auxiliary, stan klastra, ostatnią zmianę ról i ten sam punkt czasowy na obu appliances.

Nie uruchamiać ponownie obu Nodes jednocześnie ani nie wyłączać HA na próbę. Nieskoordynowana zmiana może zagrozić nadal działającej ścieżce, zmienić układ ról lub wymusić ponowną konfigurację. Artykuł Konfiguracja High Availability w Sophos Firewall wyjaśnia role, synchronizację i logi specyficzne dla Node; konkretną przyczynę Failsafe należy mimo to zapisać na Node, którego dotyczy problem.

Po aktualizacji firmware lub restore

Jeśli tryb Failsafe pojawia się bezpośrednio po upgrade, rollback lub restore, ważne są wersja wyjściowa, wersja docelowa i pełny numer Build. W SFOS 22 Sophos usunął w MR2 Build 546 kilka konkretnych przyczyn Failsafe, w tym błędy po upgrade do GA, nieuruchamiający się Logging Daemon, pełną partycję konfiguracji i niektóre wadliwe obiekty usług. Przegląd SFOS 22 MR2 wymienia rozwiązane Issue IDs.

Nie oznacza to, że każdą sytuację Failsafe rozwiązuje aktualizacja. Najpierw trzeba sprawdzić, czy komunikat o błędzie i używany Build w ogóle odpowiadają znanej poprawce. Zmiana firmware nadal wymaga backupu, okna serwisowego, planu HA i trasy powrotnej. Służą do tego przygotowanie aktualizacji firmware i kontrola przed upgrade do SFOS 22.

Failed to start Red server service

Jeżeli firewall w trybie Failsafe wyświetla dokładnie ten komunikat, objaw odpowiada NC-178906. Sophos usunął ten błąd Failsafe w SFOS 22.0 MR2 Build 546. W przypadku starszego Buildu po zabezpieczeniu materiału dowodowego sprawdza się kontrolowaną ścieżkę recovery i upgrade’u do Buildu 546 lub nowszego. Jeżeli komunikat występuje w Buildzie 546 lub nowszym, sam Issue ID nie potwierdza przyczyny; należy wtedy otworzyć Support Case z zabezpieczonymi logami.

Przed ponownym uruchomieniem lub zmianą firmware należy zabezpieczyć pełny Build, czas, odpowiedni Node HA oraz sysinit.log, red.log i syslog.log z czasu wystąpienia błędu. Nie należy na podstawie przypuszczeń usuwać interfejsów RED, RED Firmware Pattern ani konfiguracji RED, a także wielokrotnie restartować usługi RED. Jeśli firewall uruchamia się normalnie, a tylko tunel RED pozostaje offline, właściwa jest diagnostyka RED.

Zabezpieczenie materiału dowodowego przed odzyskiwaniem lub restartem

W miarę możliwości przed pierwszym działaniem zmieniającym stan należy zgromadzić:

• pełny wynik show failure-reason i widoczne pierwsze wiersze uruchamiania
• model, numer seryjny oraz platformę hardware, virtual lub software
• dokładną wersję SFOS wraz z MR i Buildem
• czas awarii i ostatni znany czas prawidłowego działania
• ostatnie zmiany firmware, restore, reguł, obiektów, interfejsów, zasobów VM lub pamięci masowej
• w przypadku HA: Node, którego dotyczy problem, rolę, stan peera i czas ostatniego failoveru
• dostępny aktualny backup i powiązany Secure Storage Master Key
• w przypadku VM: vCPU, vRAM, vNICs, Primary Disk, Report Disk i limit licencji
• powtarzające się objawy, takie jak Reboots oraz błędy I/O, NPU, temperatury lub pamięci masowej

Jeśli Advanced Shell jest nadal dostępna, można dodatkowo zapisać odpowiednie fragmenty logów. Poniższe przykłady odczytują tylko ostatnie 200 wierszy i nie zmieniają systemu:

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

sysinit.log jest centralnym logiem uruchamiania systemu, syslog.log zawiera zdarzenia kernela i systemu, a postgres.log pomaga przy bazie danych konfiguracji. Zależnie od wyniku show failure-reason to samo polecenie tail tylko do odczytu stosuje się do odpowiedniego logu szczegółowego, na przykład:

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

networkd.log dotyczy interfejsów fizycznych i wirtualnych, sigdb.log bazy sygnatur, a npu-startup.log wyłącznie modeli sprzętowych z NPU. Nie każdy plik istnieje na każdej platformie. Dalsze przypisanie opisano w artykule Usługi i pliki dzienników Sophos Firewall. Fragmenty logów mogą zawierać poufne dane i muszą być przesyłane w bezpieczny sposób.

Gdy WebAdmin będzie ponownie dostępny, należy dodatkowo zapisać archiwum CTR lub Troubleshooting. Procedurę opisano w artykule Zabezpieczanie logów Sophos Firewall dla wsparcia.

Wybór bezpiecznego następnego kroku

Po zabezpieczeniu materiału dowodowego można trafniej wybrać ścieżkę odzyskiwania:

1. Wyraźna niezgodność zasobów VM lub software appliance: Udokumentować stan bieżący, sprawdzić limity licencji i aktualne wartości minimalne, kontrolowanie wyłączyć VM, skorygować dokładnie potwierdzoną niezgodność i obserwować kolejne uruchomienie.
2. Komunikat dotyczący pamięci masowej lub logowania: Sprawdzić partycję i odpowiedni typ danych tylko do odczytu. Nie usuwać plików za pomocą rm. Instrukcja Bezpieczna kontrola pamięci masowej i Reports pokazuje przewidziane metody diagnostyki i czyszczenia.
3. Błąd bezpośrednio po zmianie firmware: Porównać Build ze znanymi problemami i dopiero potem kontrolowanie wybrać między aktualnym Maintenance Release, rollbackiem a wsparciem.
4. NPU, I/O lub powtarzający się komunikat sprzętowy: Przygotować zgłoszenie do wsparcia i w razie potrzeby RMA. Tymczasowo udany Reboot nie wyklucza usterki.
5. Błąd bazy danych, frameworka, reguł lub nieznany błąd startu: Zapisać dane wyjściowe i logi oraz otworzyć zgłoszenie Sophos Support z pełnym opisem błędu. Nie usuwać ręcznie plików bazy danych, zestawów reguł ani sygnatur.
6. Reimage jako metoda odzyskiwania: Stosować tylko wtedy, gdy uzasadnia go uszkodzenie systemu operacyjnego, wsparcie lub udokumentowany plan odzyskiwania. Wcześniej muszą być dostępne backup, hasło i SSMK. Pełną procedurę opisano w artykule Ponowna instalacja Sophos Firewall OS.

Po każdym działaniu należy sprawdzić nie tylko WebAdmin. Istotne są normalny start konsoli, prawidłowy stan HA, stan interfejsów i routingu, połączenia internetowe i VPN oraz ponowne wystąpienie tego samego komunikatu o błędzie. Jeśli przyczyna pozostaje niejasna lub powraca, nie należy jej przesłaniać kolejnymi spontanicznymi zmianami.