Sophos Firewall w trybie Failsafe: bezpieczne postępowanie

Gdy Sophos Firewall zgłasza failsafe, sytuację należy traktować jako incydent odzyskiwania. Publiczna dokumentacja SFOS 22 nie opisuje ogólnego polecenia diagnostycznego, które niezawodnie ustala przyczynę każdego stanu Failsafe. Dlatego ten runbook celowo nie używa ani show failure-reason, ani wymyślonego zamiennika.

Najpierw należy zapisać wyświetlony komunikat bez zmian, a następnie ocenić platformę, rolę HA, build firmware i ostatnią zmianę. Dopóki przyczyna nie zostanie potwierdzona, nie należy ręcznie modyfikować baz danych, sygnatur, reguł ani plików systemowych.

⚠️ Udokumentować przed restartem: Restart może zmienić widoczny błąd. Należy sfotografować całą konsolę, w tym pierwsze komunikaty boot, oraz zanotować czas, model, numer seryjny, pełną wersję SFOS z Buildem i w HA odpowiedni Node. Reset to Factory Defaults, Remove Firewall Rules i ręczne zmiany bazy danych lub systemu plików nie są bezpieczną pierwszą diagnostyką.

Bezpieczne zapisanie komunikatu Failsafe

1. Użyć dostępnej konsoli bezpośredniej: lokalnej lub szeregowej dla hardware albo konsoli hypervisora dla VM. Ta droga pozostaje dostępna, gdy WebAdmin lub sieć są nieosiągalne.
2. Sfotografować komunikat dosłownie wraz z bezpośrednio poprzedzającymi wierszami boot. Nie zastępować rzeczywistego komunikatu przykładem z Internetu.
3. Zanotować platformę i model, numer seryjny, pełny Build SFOS, czas awarii i ostatni znany czas prawidłowego działania.
4. Zapisać ostatnie zmiany, zwłaszcza upgrade firmware, rollback, restore, zmiany reguł lub obiektów, zasobów VM, dysków wirtualnych, vNIC i zdarzeń storage.
5. W HA zanotować Node, rolę, stan peera i ostatnią zmianę ról. Nie restartować obu Nodes jednocześnie ani nie wyłączać HA na podstawie przypuszczeń.

Sam niedostępny WebAdmin nie dowodzi stanu Failsafe. Jeśli firewall uruchamia się normalnie i ruch nadal płynie, ale nie odpowiada tylko interfejs, najpierw należy wykonać kontrolę ukierunkowaną lub restart WebAdmin GUI. Jawnie wyświetlony komunikat Failsafe traktuje się natomiast jako problem uruchamiania lub odzyskiwania.

Zawężenie udokumentowanych przyczyn

Sophos dokumentuje kilka konkretnych, lecz niewyczerpujących przyczyn w SFOS 22. Release Notes dla SFOS 22.0 MR2 Build 546 wymieniają Failsafe z powodu pełnej partycji konfiguracji (NC-181331), nieuruchomionego logging daemon na urządzeniu HA Primary (NC-180110), Failsafe na pierwotnym urządzeniu Primary po upgrade do 22.0 GA (NC-177441) oraz Failed to start Red server service (NC-178906). Wpisy te potwierdzają znane usunięte usterki, a nie ogólną macierz napraw.

Jeśli zaobserwowany stan, platforma lub rola HA oraz historia wersji dokładnie odpowiadają wpisowi Release Notes, w zgłoszeniu należy podać Issue ID i zainstalowany Build. Częściowa zgodność nie potwierdza tej samej przyczyny ani tego, że nieskoordynowana zmiana firmware przywróci firewall. Sophos cytuje wyświetlany komunikat dosłownie tylko dla NC-178906. Jeśli firewall uruchamia się normalnie, a offline jest jedynie tunel RED, należy skorzystać z diagnostyki RED.

Software appliance

Dla software appliance SFOS 22 zainstalowanej na własnym sprzęcie Sophos podaje między innymi poniższe wymagania minimalne istotne dla działającego systemu i wyraźnie stwierdza, że firewall przechodzi w tryb fail-safe, jeśli nie są spełnione:

• CPU x86-64 i Legacy BIOS
• co najmniej 4 GB RAM
• HDD lub SSD co najmniej 32 GB; zalecane 64 GB
• 2 karty sieciowe

Przed zmianą należy udokumentować stan bieżący. W przypadku potwierdzonego odchylenia należy ustalić z Sophos Support, czy wystarczy obsługiwana korekta zasobów, czy potrzebny jest kontrolowany reimage. Nie należy improwizować zmian dysku ani trybu rozruchu. Różnice między platformami i wymagania zasobów szczegółowo opisują appliance hardware, virtual i software.

Virtual i hardware appliance

Dla VM należy zapisać obecne i podłączone vNIC, dyski wirtualne, CPU, RAM, kontroler dysku oraz ostatnie zmiany hypervisora. Platformy cloud i hypervisor mają własne obsługiwane wymagania; wartości software appliance nie należy automatycznie stosować do każdego wdrożenia wirtualnego.

W przypadku hardware do zgłoszenia należy dodać powtarzające się błędy boot, zdarzenia zasilania, sygnały I/O lub SSD, temperaturę i wentylatory. Jeden udany restart nie wyklucza usterki. Pomagają kontrole temperatury i wentylatorów, stanu SSD i przygotowanie RMA.

Zabezpieczenie logów i backupu

Jeśli Advanced Shell jest nadal dostępna, sysinit.log, syslog.log oraz przy wskazaniu na bazę danych postgres.log są odpowiednimi oficjalnymi logami troubleshooting. Dla udokumentowanego komunikatu RED należy dodać red.log. Runbook celowo nie podaje poleceń shell do kopiowania, usuwania ani naprawy: droga dostępu i dostępne narzędzia mogą różnić się w stanie recovery.

Gdy WebAdmin znów będzie dostępny, należy wygenerować archiwum Troubleshooting lub CTR. Procedurę opisuje Zabezpieczanie logów Sophos Firewall dla wsparcia. Logi i archiwa mogą zawierać poufne dane sieci, użytkowników i konfiguracji; przekazuje się je bezpiecznie tylko uprawnionym odbiorcom.

Przed restore lub reimage muszą być dostępne odpowiedni backup, jego hasło i powiązany Secure Storage Master Key. Backup i restore Sophos Firewall wyjaśnia te zależności.

fsck-on-nextboot tylko z Sophos Support

system fsck-on-nextboot nie jest ogólnym testem kondycji. Sophos ostrzega, że wolno go używać tylko na zalecenie Sophos Support. Jest przeznaczony do błędów mount /sig, /conf lub /var; jeśli hardware albo SSD nie jest sprawny, kontrola może uszkodzić system plików.

Udokumentowana składnia Device Console to:

system fsck-on-nextboot [on | off | show]

on wymusza kontrolę wszystkich partycji przy następnym restarcie, off anuluje ją przed tym restartem, a show wyświetla bieżącą konfigurację; domyślnie jest off. SFOS może automatycznie zaplanować kontrolę w Failsafe, jeśli nie uruchamia się baza konfiguracji, raportów lub sygnatur, nie można zastosować migracji albo nie można znaleźć deployment mode.

Nie restartować tylko dlatego, że wyświetla się on. Najpierw w tym samym planie serwisowym należy uwzględnić zalecenie wsparcia, stabilny dostęp do konsoli, zasilanie, backup, możliwe błędy I/O i w HA stan peera. Sophos nie podaje stałego czasu ani gwarancji powodzenia.

Wybór bezpiecznej ścieżki recovery

• Wymaganie software wyraźnie poniżej minimum: Zapisać stan bieżący i w oknie serwisowym wykonać korektę lub reimage potwierdzony przez Sophos Support. Obserwować następny start przez konsolę.
• Komunikat odpowiada znanemu problemowi Release Notes: Zapisać pełny Build i Issue ID. Poprosić Sophos Support o potwierdzenie ścieżki recovery, upgrade lub rollback.
• Incydent HA: Chronić nadal działającego peera. Bez jednoczesnych restartów i nieplanowanych zmian roli lub klastra. Zobacz High Availability Sophos Firewall.
• Błąd storage, bazy danych, reguł, NPU, I/O lub nieznany: Nie usuwać plików ani konfiguracji na podstawie przypuszczeń. Eskalować do Sophos Support z konsolą, logami i osią czasu.
• Reimage: Używać tylko wtedy, gdy uzasadnia go Sophos Support lub udokumentowany plan recovery i spełniono wszystkie warunki restore. Zobacz Ponowna instalacja Sophos Firewall OS.

Po każdej czynności należy sprawdzić nie tylko WebAdmin i login. Kontroluje się normalny start konsoli, stan HA, interfejsy, routing oraz wymagane połączenia Internet i VPN. Jeśli komunikat wróci, należy dodać czas i niezmieniony wynik zamiast wykonywać kolejne spontaniczne zmiany.

Eskalacja do Sophos Support

Incydent Failsafe należy eskalować, gdy przyczyny nie można ograniczyć do udokumentowanego i bezpiecznie korygowalnego odchylenia zasobów. Zgłoszenie Sophos Support powinno zawierać co najmniej:

• zdjęcie lub kopię wszystkich komunikatów Failsafe i boot
• model, numer seryjny, platformę i pełny Build SFOS
• czas awarii, ostatni czas działania i oś czasu zmian
• w HA: Node, rolę, stan peera i ostatnią zmianę ról
• odpowiednie logi lub CTR oraz sygnały storage, I/O, NPU lub zasilania
• dostępny backup oraz stan hasła i SSMK, bez ujawniania sekretów w treści zgłoszenia
• wykonane już restarty lub zmiany i ich wynik

Jeśli WebAdmin jest dostępny, a Sophos poprosi o zdalny dostęp, można czasowo włączyć Support access w Diagnostics > Support access. Wygenerowany Access ID udostępnia się tylko uzgodnionym kanałem wsparcia; dostęp można wyłączyć w dowolnym momencie.