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

Miejsce na dysku 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 raportów w Advanced Shell. Najpierw trzeba ustalić przyczynę i użyć udokumentowanej procedury czyszczenia. Zobacz Sprawdzanie miejsca na dysku Sophos Firewall i zarządzanie raportami.

SFOS 22 może wymagać dodatkowego miejsca na dysku. 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 raportami 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.

Konfigurowanie cyklicznych aktualizacji serwisowych

Recurring Firmware Upgrade pozwala ustawić cykliczne okno serwisowe dla konta Sophos Fusion. Plan dotyczy wszystkich firewalli na koncie; gdy dostępny jest odpowiedni firmware, urządzenia spełniające wymagania są aktualizowane zgodnie z tym planem. Funkcję trzeba świadomie włączyć; nie gwarantuje ona, że każdy firewall otrzyma nową wersję przy każdym terminie. Backup, obsługiwana ścieżka aktualizacji, uprawnienia do wsparcia i pozostałe punkty zatwierdzenia opisane w tym artykule nadal są wymagane.

1. W My Products > Firewall Management > Firewalls otworzyć Recurring Firmware Upgrade i włączyć Schedule maintenance updates.
2. Wybrać Weekly (Default) dla cyklu tygodniowego i ustawić dzień tygodnia oraz godzinę. Dla Monthly wybrać najpierw 1st, 2nd, 3rd, 4th lub Last jako tydzień miesiąca, a następnie dzień tygodnia i godzinę. Nie jest to dowolnie wybrana data kalendarzowa.
3. W Staging firewalls wybrać odpowiednie firewalle pilotażowe. Można wybrać kilka urządzeń; wybór i jego ograniczenia wyjaśniono w następnej sekcji.
4. Włączyć Schedule major version updates dopiero po wyraźnej decyzji o automatyzacji przejść do nowych wersji głównych. Bez tej opcji plan obejmuje wyłącznie aktualizacje serwisowe w obrębie bieżącej wersji głównej. Po jej włączeniu ten sam harmonogram i proces stagingu obejmują również wersje główne spełniające wymagania. Nowe funkcje i zmiany architektury nadal wymagają osobnego sprawdzenia zgodności.
5. Za pomocą Review sprawdzić ustawienia i w razie potrzeby je poprawić. Dopiero Confirm zatwierdza plan.
6. Następnie otworzyć ikonę Scheduled obok każdego objętego planem firewalla i sprawdzić faktycznie zaplanowany termin. Zapisać w dokumentacji zmiany wersję docelową, lokalizację, strefę czasową firewalla i lokalne okno serwisowe.

Przykładowe okno miesięczne to Monthly, 2nd, niedziela, 02:00. Oznacza ono drugą niedzielę miesiąca o 02:00 w strefie czasowej każdego firewalla. Nie jest to zalecenie dla wszystkich lokalizacji: okno musi uwzględniać godziny pracy, wykonywanie backupu, dostępność osób odpowiedzialnych i późniejsze testy. Lokalizacje w różnych strefach czasowych nie rozpoczynają aktualizacji jednocześnie. Przed zatwierdzeniem sprawdzić więc strefę czasową każdego firewalla i wyświetlane terminy.

Dla par HA Sophos Fusion planuje zadanie aktualizacji na Primary. Auxiliary jest aktualizowany automatycznie w ramach istniejącego procesu aktualizacji HA i nie otrzymuje oddzielnego zadania ręcznego. Kontrole HA i możliwe przerwy opisane w sekcji Klaster HA obowiązują również przy planowaniu cyklicznym. Ani godzina rozpoczęcia, ani ikona stanu wskazująca powodzenie nie gwarantują stałego czasu zakończenia lub pracy bez przerw; okno serwisowe musi obejmować także walidację i ewentualny rollback.

Staging jest kontrolą techniczną, a nie odbiorem aplikacji

Firewalle stagingowe otrzymują firmware jako pierwsze. Jeśli usługa uzna aktualizację za udaną, pozostałe firewalle są aktualizowane zgodnie z harmonogramem. Jeśli aktualizacja stagingowa się nie powiedzie, wdrażanie zostaje zatrzymane, a objęte błędem firewalle wracają do poprzedniego firmware. Przyczynę trzeba usunąć przed wznowieniem harmonogramu. Dotychczasowy plan backupu i odzyskiwania nadal jest potrzebny: ten mechanizm usługi nie gwarantuje możliwości powrotu przy każdym możliwym błędzie.

Urządzenia pilotażowe powinny odpowiednio reprezentować używane funkcje i platformy, a ich awaria musi być możliwa do opanowania. Lokalizacja zapewniająca wyłącznie dostęp do Internetu nie testuje na przykład automatycznie konfiguracji WAF lub VPN innych lokalizacji. Jeśli nie wybrano firewalli stagingowych, wszystkie firewalle spełniające wymagania są aktualizowane bezpośrednio według harmonogramu; nie ma wtedy poprzedzającego etapu pilotażowego.

⚠️ Brak ręcznego zatwierdzenia po pilotażu: Powodzenie stagingu stwierdzone przez usługę nie dowodzi, że DNS, VPN, publikowane usługi lub aplikacje biznesowe działają. Testy funkcjonalne opisane poniżej nadal są wymagane. Nie zakładaj, że po udanym stagingu wdrożenie zatrzyma się na dodatkowym ręcznym zatwierdzeniu. Jeśli najpierw wymagany jest odbiór funkcjonalny pilotażu, nie należy zakładać, że usługa na niego poczeka; planowanie automatyczne włączyć dopiero wtedy, gdy wybrana procedura spełnia ten wymóg.

Zmienianie lub pomijanie pojedynczych terminów albo dostosowanie stagingu

Bez planu cyklicznego pojedynczą aktualizację konfiguruje się za pomocą ikony niebieskiej strzałki obok firewalla i Schedule upgrade: wybrać wersję docelową, określić Immediately lub At, dla At wybrać datę i godzinę, a następnie potwierdzić przez Schedule upgrade. Gdy istnieje plan cykliczny, dla pojedynczych firewalli należy zamiast tego używać poniższych działań. Nie zmieniają one planu cyklicznego pozostałych firewalli.

• Override schedule: Otworzyć ikonę Schedule obok firewalla i wybrać Override schedule. W oknie Firmware upgrades wybrać wersję docelową oraz Immediately lub At. Dla At ustawić datę i godzinę za pomocą ikony kalendarza; potwierdzić przez Override schedule. Immediately uruchamia zadanie bez późniejszego terminu, dlatego należy używać tej opcji tylko w już zatwierdzonym oknie serwisowym. Sprawdzić wybraną wersję za pomocą ikony Release notes; po najechaniu na ikonę Clock wyświetlane są data, godzina i lokalny czas firewalla dla bieżącego planu. Po zmianie ponownie sprawdzić wyświetlany termin.
• Skip occurrence: Otworzyć ikonę Schedule i wybrać Skip occurrence, jeśli ma zostać pominięta tylko najbliższa zaplanowana aktualizacja tego firewalla. Zadanie zostaje przesunięte do następnego wystąpienia w cyklu. Przy cotygodniowym terminie w piątek oznacza to kolejny piątek, a nie trwały wyjątek. Sprawdzić nowy termin i ponownie porównać go z oknem serwisowym.
• Remove from upgrade staging: Za pomocą ikony Schedule otworzyć Remove from upgrade staging. W oknie Recurring Firmware Upgrade Schedule odznaczyć dany firewall w Staging firewalls, a następnie wykonać Review i Confirm. Usuwa to jego rolę pilotażową, a nie udział w ogólnym planowaniu aktualizacji firmware. Następnie sprawdzić pozostałe wybrane firewalle stagingowe i termin danego firewalla. Aby urządzenie znów pełniło rolę pilota, ponownie wybrać je w ustawieniach stagingu planu cyklicznego i zatwierdzić plan przez Review i Confirm.

Jeśli brakuje wersji docelowej, najpierw sprawdzić fazę Available to all, zamiast omijać to ograniczenie przez nieplanowane lokalne przesłanie firmware. Jeśli terminy nie zgadzają się z dokumentacją zmiany, najpierw porównać strefę czasową firewalla i czas lokalny wyświetlany przez Clock. Po błędzie stagingu sprawdzić aktywny firmware, komunikat rollback i logi, wyjaśnić przyczynę i wykonać rzeczywiste testy funkcjonalne przed zatwierdzeniem dalszych aktualizacji. Zmiana terminu lub usunięcie ze stagingu nie cofa już wykonanej aktualizacji firmware; obowiązują opisane wyżej procedury rollback i odzyskiwania.

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