Aktualizacja firmware Sophos Firewall: przygotowanie i dobre praktyki

Aktualizacja firmware Sophos Firewall powinna zostać zatwierdzona dopiero wtedy, gdy wyjaśniono ścieżkę upgrade, backup, dostęp, stan systemu, HA i sposób odzyskania działania. Artykuł Przeprowadzanie aktualizacji firmware Sophos Firewall opisuje instalację w WebAdmin lub przez Sophos Fusion (dawniej Sophos Central).

⚠️ Przed każdą aktualizacją: Muszą być dostępne aktualny backup, przypisany do niego Secure Storage Master Key i konkretny plan rollback. Dla SFOS 22 lub nowszej wersji należy również wykonać kontrolę przed upgrade do SFOS 22.

Zatwierdzenie w dziesięciu punktach

Zmiana firmware jest gotowa, gdy na wszystkie dziesięć punktów można odpowiedzieć twierdząco:

1. Aktualna wersja, wersja docelowa i obsługiwana ścieżka upgrade są udokumentowane.
2. Release notes i known issues sprawdzono pod kątem używanej platformy i konfiguracji.
3. Licencja i uprawnienia do wsparcia pozwalają na instalację.
4. Dostępne są świeży backup, hasło backupu i właściwy Secure Storage Master Key.
5. Wolne miejsce, stan systemu oraz, w odpowiednich modelach urządzeń XGS Appliance, firmware SSD spełniają wymagania.
6. Stan, role i synchronizacja HA są prawidłowe; oba węzły spełniają wymagania.
7. Okno serwisowe, osoby odpowiedzialne, termin przerwania i kryteria rollback są określone.
8. Przygotowano lokalny lub alternatywny dostęp administracyjny.
9. Zdefiniowano testy WAN, VPN, DNS, NAT, WAF, uwierzytelniania i kluczowych aplikacji.
10. Przygotowano monitoring, komunikację i dokumentację zmiany.

Jeśli brakuje jednego z tych punktów, aktualizacji nie należy rozpoczynać pod presją czasu. Przełożenie okna serwisowego jest tańsze niż nieplanowany reimage lub interwencja na miejscu.

Sprawdzenie wersji, platformy i uprawnień

Stały proces operacyjny sprawdza co najmniej raz w miesiącu w Sophos Fusion lub w Backup & Firmware > Firmware, czy jest dostępna aktualizacja. Należy też aktywnie śledzić nowe release notes i zapowiedziane maintenance release. Każdy MR powinien trafić do planu aktualizacji, ponieważ nawet wydanie wyłącznie serwisowe może zawierać ważne poprawki bezpieczeństwa. Instalacja, testy i rollback nadal odbywają się w kontrolowanym oknie serwisowym.

Release notes i ścieżka upgrade

Przed zmianą należy porównać w release notes aktualną wersję SFOS, wersję docelową i obsługiwaną ścieżkę. Trzeba też sprawdzić znane problemy dotyczące platformy, HA, VPN, routingu, uwierzytelniania i faktycznie używanych funkcji.

Sophos Firewall może wyświetlić ostrzeżenie dla nieobsługiwanej ścieżki migracji. Jeśli zmiana zostanie mimo to potwierdzona, firewall może uruchomić się z Factory Configuration i utracić istniejącą konfigurację. Automatyczny rollback nie chroni przy nieobsługiwanej ścieżce upgrade. Należy używać wyłącznie zatwierdzonej ścieżki; przy niezgodnej zmianie wersji właściwą metodą jest reimage, a następnie restore.

⚠️ Ograniczenie platformy: SFOS 21.0 GA i nowsze wersje nie obsługują appliance’ów sprzętowych XG i SG. Przed upgrade tych urządzeń należy zaplanować migrację na urządzenie XGS Appliance.

Kontrola upgrade’u do SFOS 22 dokumentuje wersje źródłowe obsługujące bezpośredni upgrade oraz interpretację blockerów dla SFOS 22.0 MR2 Build 546. Ta matryca dotyczy wyłącznie tego buildu i nie jest uniwersalną ścieżką dla SFOS 22; dla każdego innego buildu docelowego należy bezpośrednio przed zmianą sprawdzić obsługiwane wersje źródłowe i właściwe blockery w aktualnych release notes.

Należy jednoznacznie wykluczyć dwa blockery SFOS 22:

• SFOS 22.0 MR1 i nowsze: Pozostała starsza konfiguracja Remote Access IPsec blokuje upgrade. Trzeba ją usunąć zgodnie z aktualnymi wskazówkami migracyjnymi Sophos; samo wyłączenie nie wystarcza.
• SFOS 22.0 MR2 i nowsze: Starsze tagowanie VLAN skonfigurowane przez CLI na interfejsach bridge blokuje upgrade. Należy zidentyfikować odpowiednie bridge i najpierw rozwiązać tę konfigurację zgodnie z release notes.

Osobna kontrola obejmuje pozostałe tematy SFOS 22, takie jak pamięć, nazwy interfejsów, STAS, firmware SSD i obsługa platformy. Dla innych wersji docelowych obowiązują ich aktualne release notes.

⚠️ Przed pierwszym upgrade’em do SFOS 21 lub nowszej wersji: W Certificates > Certificate authorities wyszukać zarezerwowane nazwy CA Let’s Encrypt. Istniejący wpis o dokładnie takiej samej nazwie może przerwać migrację z powodu NC-146082. Nie usuwać CA bez sprawdzenia; najpierw zabezpieczyć i zweryfikować backup, klucz prywatny, zależne certyfikaty oraz usługi.

Licencja i wsparcie

Od SFOS 19.0 MR1 bez Enhanced Support lub Enhanced Plus Support dozwolone są trzy bezpłatne przejścia do wersji GA, MR lub EAP. Później firmware nadal można pobrać, ale nie zainstalować; opcja Install jest wyłączona.

Pattern Updates, hotfixes, reimage, Mandatory Firmware Upgrades i Assistant Firmware Upgrades nie podlegają tej regule wsparcia. Przed oknem serwisowym mimo to należy sprawdzić, czy:

• Administration > Licensing pokazuje oczekiwaną licencję i uprawnienia do wsparcia.
• Sophos Fusion pokazuje właściwy firewall i numer seryjny.
• Wersja docelowa i plik do pobrania są dostępne.
• Znane są dostęp do wsparcia, osoby kontaktowe i ścieżka eskalacji.

Jeśli zmiana wymaga dostępu zewnętrznego, trzeba przetestować go wcześniej. Dla Avanet zobacz Konfiguracja dostępu wsparcia do Sophos Firewall.

Oddzielne sprawdzanie automatycznych hotfixów

Hotfix nie jest ani slotem firmware, ani Pattern Update. SFOS 22 co 30 minut sprawdza dostępność hotfixów i domyślnie instaluje je automatycznie. Sophos zaleca, aby nie zmieniać tego ustawienia. Stan należy odczytać w Device Console przed zmianą firmware i po niej:

system hotfix show

Dla SFOS 22 Sophos opisuje, że już zainstalowane hotfixy pozostają również po aktualizacji firmware. Natomiast lista powiązana z wersją w SFOS 23 jest ponownie oceniana po każdej zmianie wersji, jak wyjaśniono w kolejnym podrozdziale. Jeśli kontrola pokazuje, że automatyczna instalacja jest wyłączona, należy najpierw ustalić, kto ją wyłączył i dlaczego. Bez udokumentowanego wyjątku trzeba włączyć ją ponownie:

system hotfix enable

system hotfix disable wyłącza tylko automatyczną instalację i nie jest ogólnym krokiem troubleshooting. Stan włączony nie dowodzi też, że konkretny hotfix został już zastosowany ani że działa ścieżka pobierania. Dla określonego błędu należy dodatkowo sprawdzić build, czas, dostęp do Internetu, logi i referencję błędu Sophos.

SFOS 23: potwierdzanie zastosowanych aktualizacji bezpieczeństwa

W SFOS 23 strona Backup & firmware > Hotfix: Security updates pokazuje, które aktualizacje bezpieczeństwa w postaci hotfixów zostały zastosowane od czasu przejścia na aktualnie działającą wersję SFOS. Hotfixy korygują działający system bez aktualizacji firmware i nie należy ich mylić z listą dostępnych obrazów firmware. Automatyczna instalacja hotfixów musi być włączona; domyślnie jest aktywna. system hotfix show sprawdza to ustawienie, ale nie potwierdza zastosowania konkretnej poprawki bezpieczeństwa.

Aby udokumentować zmianę przed przejściem na nowy firmware i po nim:

1. Zapisać aktywną wersję SFOS wraz z buildem i czasem kontroli oraz otworzyć stronę Hotfix: Security updates.
2. Posortować wpisy według daty zastosowania i zapisać aktualizacje związane z analizowanym problemem. Kolumna Advisory odsyła do odpowiedniego komunikatu bezpieczeństwa w przypadku publicznie opisanych podatności. Wewnętrzne poprawki mogą pojawiać się bez identyfikatora CVE i bez linku Advisory.
3. W przypadku HA uwzględnić oba urządzenia w kontroli po zmianie: aktualny Primary otrzymuje hotfix i synchronizuje się z Auxiliary, na którym hotfix również jest stosowany. Pomyślna kontrola jednego urządzenia nie zastępuje potwierdzenia dla całego klastra.

Ta sama podatność może pojawić się wielokrotnie, ponieważ do jej całkowitego usunięcia może być potrzebnych kilka hotfixów. Pojedynczy pasujący wpis nie jest więc ogólnym potwierdzeniem pełnej ochrony. W przypadku konkretnej poprawki bezpieczeństwa należy porównać wymagania odpowiedniego komunikatu bezpieczeństwa z działającym buildem i faktycznie zastosowanymi aktualizacjami.

Powiadomienia i logi: W System services > Notification list, w sekcji Firmware, włączyć opcję Email dla Security updates. Dla tych aktualizacji nie są dostępne powiadomienia SNMP. Aktualizacje bezpieczeństwa w postaci hotfixów pojawiają się również w Log viewer; generowane są ich logi audytowe, które następnie są przekazywane do Sophos Fusion na potrzeby Central Firewall Reporting. Te informacje o powiadomieniach i logach dotyczą aktualizacji bezpieczeństwa w postaci hotfixów, a nie ogólnie każdej poprawki hotfix. Sam brak wiadomości e-mail nie potwierdza zatem ani powodzenia, ani niepowodzenia.

Po zmianie wersji: SFOS najpierw instaluje nowy firmware, a następnie stosuje hotfixy dostępne dla tej wersji. Poprzednia lista hotfixów jest usuwana i zastępowana listą nowej wersji; nie jest to archiwum obejmujące wiele wersji. Ta sama poprawka może pojawić się ponownie, ponieważ została niezależnie zastosowana do nowej wersji. Jeśli wcześniejsze poprawki są już zawarte w nowym firmware, mogą nie pojawiać się jako osobne wpisy hotfixów.

Pusta lista oznacza jedynie, że dla aktualnej wersji nie zastosowano i nie wyświetlono jeszcze żadnych aktualizacji bezpieczeństwa w postaci hotfixów. Nie dowodzi ona ani braku ochrony, ani pełnego zabezpieczenia, ani prawidłowego działania automatycznej instalacji. W razie niejasności należy wspólnie sprawdzić aktywną wersję i build, ustawienie CLI, komunikat bezpieczeństwa, release notes i logi; nie należy na podstawie pustej strony zapobiegawczo wyłączać automatycznej instalacji ani uznawać, że konieczny jest rollback.

Przygotowanie backupu, recovery i dokumentacji

Backup, SSMK i sloty firmware

Przed aktualizacją należy pobrać świeży backup konfiguracji i sprawdzić, który Secure Storage Master Key jest z nim powiązany. W dokumentacji zmiany trzeba również zapisać hasło backupu, dostęp administratora, aktywną wersję firmware i wersję docelową.

Sophos Firewall przechowuje maksymalnie dwie wersje firmware: aktywną i nieaktywną. Każda partycja ma własny stan konfiguracji. Rollback aktywuje więc nie tylko poprzedni firmware, lecz także jego konfigurację. Zmiany wprowadzone po upgrade mogą zostać utracone po powrocie.

Automatyczny rollback jest dostępny od SFOS 20.0 dla określonych błędów migracji konfiguracji. Jest to funkcja bezpieczeństwa, ale nie zastępuje backupu ani analizy przyczyny i nie jest dostępna dla nieobsługiwanej ścieżki upgrade.

Pełny proces opisano w Tworzenie lub przywracanie backupu Sophos Firewall. Jeśli zwykła zmiana wersji nie jest możliwa, zobacz Ponowna instalacja Sophos Firewall OS z pamięci USB.

Wcześniejsze określenie kryteriów rollback

Przed rozpoczęciem należy ustalić, jak długo błąd będzie analizowany i kiedy rozpocznie się recovery. Rollback ma sens, jeśli WAN, HA, centralne VPN lub krytyczne publikacje produkcyjne nie mogą zostać ustabilizowane w uzgodnionym czasie. W przypadku pojedynczej reguły, obiektu lub usługi zewnętrznej często lepszy jest ukierunkowany troubleshooting.

Przy zwykłym Maintenance Release jako dokumentacja wystarczą backup, zrzut strony firmware, okno serwisowe i wynik testu. Przy większych zmianach Sophos Firewall Config Studio pomaga porównać konfiguracje, a Audit Trail rejestruje zmiany podczas okna serwisowego.

Sprawdzenie stanu systemu, pamięci i HA

Pamięć i SSD

Przed większym upgrade należy sprawdzić w WebAdmin, czy:

• Control center nie pokazuje nierozwiązanych krytycznych ostrzeżeń.
• Backup & Firmware > Firmware pokazuje oczekiwane sloty firmware.
• Diagnostics > Log viewer nie zawiera powtarzających się błędów systemu lub migracji.
• Odpowiednie usługi działają stabilnie.
• Firewall Health Check nie zawiera otwartych punktów wpływających na zmianę.

Po zalogowaniu przez SSH należy otworzyć Device Management > Advanced Shell i sprawdzić wolne miejsce:

df -kh

Jeśli partycja jest prawie pełna, nie należy bez analizy usuwać plików, logów ani reports w Advanced Shell. Najpierw trzeba ustalić przyczynę i użyć udokumentowanej procedury czyszczenia. Zobacz Sprawdzanie pamięci Sophos Firewall i zarządzanie reports.

SFOS 22 może wymagać dodatkowej pamięci. W niektórych modelach urządzeń XGS Appliance trzeba także najpierw zaktualizować firmware SSD; WebAdmin wyświetla odpowiedni komunikat. W klastrze HA każdy węzeł jest oceniany oddzielnie. Jeśli jedno urządzenie nie spełnia wymagań, może zablokować cały upgrade.

W starszych appliance’ach lub przy problemach z I/O, bazą danych albo reports należy również sprawdzić stan SSD przez SMART. Bez konkretnego ustalenia ręczne zmiany w bazach danych lub systemach plików nie są sensownym przygotowaniem.

Sophos wymienia restart przed upgrade jedynie jako opcjonalny sposób wyczyszczenia pamięci podręcznej. Nie jest to wymaganie i powoduje dodatkową przerwę. Restart należy więc wykonać wyłącznie w oknie serwisowym, po zapisaniu istotnych logów i potwierdzeniu ścieżki odzyskania dostępu administracyjnego. Jeśli firewall wykazuje niewyjaśnioną niestabilność, upgrade trzeba zatrzymać; restart nie może zastępować analizy przyczyny ani jedynie tymczasowo tworzyć wrażenia prawidłowego stanu systemu.

Klaster HA

Przy zwykłej aktualizacji firmware nie trzeba wyłączać HA. Przed zatwierdzeniem oba urządzenia muszą jednak być połączone, zsynchronizowane i jednoznacznie rozpoznawalne jako Primary i Auxiliary. Aktualizacja HA również wymaga okna serwisowego, ponieważ failover może na krótko przerwać pojedyncze sesje, tunele VPN lub ping.

Przed rozpoczęciem należy udokumentować:

• Role, stan HA i synchronizację.
• Stan łącza HA.
• Wymagania dotyczące firmware, pamięci i SSD obu węzłów.
• Alternatywny dostęp administracyjny.
• Oczekiwany failover i możliwe krótkie przerwy.

Urządzenia Auxiliary nie wolno aktualizować oddzielnie. Artykuł wykonawczy opisuje dokładną kolejność: aktualizacja Auxiliary, failover i aktualizacja poprzedniego Primary. Inne scenariusze HA opisano w Klaster HA Sophos Firewall: warianty i konserwacja.

Pattern Updates są instalowane na Primary, a następnie synchronizowane z Auxiliary. Hotfixes i ich stan należy rozpatrywać oddzielnie i sprawdzić na obu urządzeniach po oknie serwisowym.

Planowanie okna serwisowego, Central i testów

Okno serwisowe i dostęp

Okno serwisowe obejmuje więcej niż sam czas instalacji:

• Czas rozpoczęcia, najpóźniejszy moment przerwania i decyzję o rollback.
• Osoby odpowiedzialne za firewall, sieć, serwery, aplikacje i wsparcie.
• Lokalny kontakt, dostęp out-of-band lub drugi kanał administracyjny.
• Kanał komunikacji na wypadek awarii WAN lub Remote Access.
• Tryb konserwacji dla monitoringu i alertów.
• Kolejność testów najważniejszych procesów biznesowych.

W lokalizacjach zdalnych nie należy polegać wyłącznie na Sophos Fusion lub istniejącym połączeniu VPN. Jeśli właśnie ten kanał przestanie działać podczas aktualizacji, zdefiniowany dostęp lub ścieżka eskalacji muszą pozostać dostępne.

Planowanie firmware przez Sophos Fusion

Aktualizacje firmware zarządzane przez Central przygotowuje się i monitoruje w My Products > Firewall Management > Firewalls. Task Queue dotyczy zasad grupowych i zadań konfiguracyjnych MDR/API, a nie aktualizacji firmware.

Przez Central można instalować tylko wersje docelowe, które osiągnęły fazę Available to all procesu wydawania. Zaplanowane aktualizacje rozpoczynają się zgodnie ze strefą czasową ustawioną na firewallu, a nie czasem przeglądarki administratora. Dla lokalizacji międzynarodowych w zmianie trzeba zapisać strefę czasową, lokalne okno i wersję docelową.

Podczas upgrade obok firewalla obraca się ikona stanu, która znika po zakończeniu. Następnie nadal trzeba lokalnie sprawdzić aktywną wersję firmware. Przy automatycznym rollback Central wyświetla odpowiedni komunikat obok wersji.

Rzeczywiste testy funkcjonalne

Sam ping nie dowodzi, że firewall działa poprawnie po aktualizacji. Wcześniej należy zdefiniować konkretne testy ze źródłem, celem i oczekiwanym wynikiem:

• Dostęp do Internetu i rozwiązywanie DNS.
• DHCP, VLAN, uplinki WAN i trasy SD-WAN.
• Site-to-Site VPN, Remote Access VPN i RED.
• Reguły firewalla, NAT i publikowane usługi.
• WAF, Web Protection i TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID i inne centralne uwierzytelnianie.
• Przepływ poczty i aplikacje krytyczne dla działalności.
• Syslog, SIEM i monitoring.

Walidacja po aktualizacji

Po ponownym uruchomieniu należy najpierw sprawdzić aktywną wersję i oczekiwany nieaktywny slot w Backup & Firmware > Firmware. Następnie:

• Sprawdzić Control center pod kątem nowych ostrzeżeń lub automatycznego rollback.
• Zweryfikować interfejsy, WAN, SD-WAN, role HA i synchronizację.
• Przetestować VPN, RED, DNS, DHCP, reguły, NAT, WAF i uwierzytelnianie za pomocą przygotowanych testów.
• Sprawdzić stan patterns i hotfixes.
• Zweryfikować synchronizację Sophos Fusion, monitoring, syslog i SIEM.
• Zapisać w zmianie wynik, czasy, odchylenia i ewentualne działania następcze.

Jeśli nie działa pojedyncza funkcja, należy najpierw użyć Log Viewer, Policy Test, Packet Capture i odpowiednich service logs. Zobacz Testowanie reguły firewalla za pomocą Log Viewer, Policy Test i Packet Capture oraz Troubleshooting Sophos Firewall: usługi i logi.

FAQ