Bezpieczny restart usług Sophos Firewall

Restart pojedynczych Sophos Firewall Services może pomóc, gdy moduł nie reaguje już poprawnie, log nie pokazuje nowych wpisów albo Sophos Support wymaga celowego restartu. Nie zastępuje jednak czystego troubleshootingu. Niewłaściwy restart usługi może krótko przerwać VPN tunnels, routing, WebAdmin, DNS, DHCP, reporting lub inne funkcje.

Ten artykuł wyjaśnia, jak restartować usługi przez WebAdmin lub Advanced Shell, wcześniej sprawdzić odpowiednie logi i potem skontrolować, czy usługa znowu działa poprawnie. Jeśli najpierw nie jest jasne, która techniczna usługa należy do którego modułu, pomaga przegląd Sophos Firewall Troubleshooting: usługi i logi. Do podstawowego bezpieczeństwa CLI, debug i tcpdump pasuje dodatkowo Sophos Firewall CLI Troubleshooting: ważne polecenia.

⚠️ Ważne: Restarty usług w środowiskach produkcyjnych powinny być planowane. Wcześniej powinno być jasne, której usługi dotyczy zmiana, którzy użytkownicy lub które tunele mogą zostać przerwane i czy istnieje alternatywny dostęp do firewalla.

Kiedy restart usługi ma sens

Celowy restart usługi ma sens, gdy dotknięty jest konkretny moduł, a reszta firewalla zasadniczo działa stabilnie.

Typowe przykłady:

• WebAdmin już się nie ładuje, ale routing i reguły firewalla nadal działają.
• Usługa VPN zawiesiła się, podczas gdy inne funkcje firewalla wyglądają normalnie.
• Log pokazuje bieżące błędy dla określonej usługi.
• Sophos Support podaje konkretną usługę, którą należy zrestartować.
• Usługa po zmianie konfiguracji nie aktywowała się poprawnie.

Nie ma sensu ślepo restartować kilku usług tylko dlatego, że problem jest jeszcze niejasny. Wtedy najpierw należy sprawdzić logi, obciążenie systemu, miejsce na dysku, stan HA, routing i dotknięte moduły.

Kiedy nie należy restartować usług

Restart usługi kusi, bo działa szybko. W niektórych sytuacjach pogarsza jednak analizę albo powoduje dodatkowe przerwy.

• Przyczyna jest jeszcze całkowicie niejasna: Restart zmienia stan i może ukryć ważne ślady w logach lub statusach.
• Kilka centralnych usług wypada jednocześnie: Wtedy problemem często nie jest jedna usługa, lecz obciążenie systemu, miejsce na dysku, baza danych, HA lub stan platformy.
• Firewall jest osiągalny tylko przez dokładnie tę usługę: Restart może spowodować utratę ostatniego zdalnego dostępu.
• Dotknięte są produkcyjne usługi VPN, routingu lub DHCP: Istniejący użytkownicy, lokalizacje lub lease mogą zostać krótko przerwane.
• Debug już działa i błąd jest odtwarzalny: Najpierw zabezpieczyć istotne logi, potem restartować.
• Usługa była już restartowana kilka razy: Wtedy potrzebna jest analiza przyczyny, a nie powtarzanie.

Jeśli restart mimo to jest potrzebny, wcześniej należy zanotować co najmniej aktualny czas, dotkniętych użytkowników lub lokalizacje, nazwę usługi, plik logu i oczekiwany wpływ.

Co sprawdzić przed restartem

Przed restartem usługi należy krótko udokumentować, co jest dotknięte. Oszczędza to czas, jeśli błąd wróci albo potrzebny będzie support case.

Praktyczna kontrola wstępna:

1. Zawęzić dotknięty moduł, na przykład WebAdmin, IPsec, DNS, DHCP, IPS lub WAF.
2. Sprawdzić, czy firewall jako całość jest stabilny, czy wypada kilka usług.
3. Sprawdzić, czy obecnie połączeni są administratorzy, użytkownicy VPN lub krytyczne lokalizacje.
4. W klastrach HA sprawdzić, na którym node wykonuje się pracę i który node jest aktywny.
5. Otworzyć pasujący plik logu i zabezpieczyć ostatnie komunikaty.
6. Sprawdzić miejsce na dysku, jeśli używane są debug, duże logi lub pliki PCAP.
7. W razie potrzeby wyeksportować logi przed restartem.
8. Ustalić kryterium przerwania: kiedy restart zostanie zatrzymany, przesunięty albo eskalowany?

Dla środowisk HA istotne jest dodatkowo Zrozumienie wariantów klastra HA Sophos Firewall. Jeśli logi są potrzebne do zewnętrznej analizy, pasuje Zabezpieczenie logów Sophos Firewall do supportu i analizy.

Najpierw zabezpiecz dowody, jeśli błąd wraca

Restart usługi może tymczasowo rozwiązać objaw, ale może też zmienić stan potrzebny do analizy przyczyny. Jeśli problem występuje ponownie, przed kolejnym restartem warto zabezpieczyć małe okno dowodowe.

Przydatne minimum danych:

• dokładny czas ze strefą czasową
• dotknięta usługa i funkcja
• ostatnie istotne komunikaty z właściwego pliku logu
• status usługi przed restartem
• obciążenie systemu, miejsce na dysku lub wskazania reportów/bazy danych, jeśli GUI jest wolne
• dotknięci użytkownicy, tunele, interfejsy, reguły lub lokalizacje
• ostatnia zmiana konfiguracji, firmware, hotfix lub zdarzenie HA

Jest to szczególnie ważne, jeśli ta sama usługa była restartowana kilka razy. Wtedy restart jest już tylko działaniem doraźnym. Właściwa praca polega na ustaleniu, dlaczego usługa się zawiesza, crashuje, blokuje albo przestaje pisać nowe logi.

Dokumentacja restartu w przypadku supportu

Jeśli restart usługi jest częścią support case, okna konserwacyjnego lub powracającego problemu, należy krótko udokumentować akcję. Nie musi to być długi raport. Ważne jest, aby później było jasne, która usługa została zrestartowana, kiedy, dlaczego i z jakim wynikiem.

Praktyczny szablon notatki:

Date/time and time zone:
Firewall / HA node:
Service:
Command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Taka notatka jest szczególnie pomocna, gdy błąd wraca po kilku godzinach lub dniach. Od razu widać wtedy, czy zawsze dotknięta jest ta sama usługa, czy restart pomaga tylko krótkoterminowo, albo czy bardziej prawdopodobny jest głębszy problem, taki jak miejsce na dysku, stan bazy danych, zachowanie HA lub błąd produktu.

Restart usług przez WebAdmin

Część usług można restartować bezpośrednio przez WebAdmin. To najprostsza droga, jeśli GUI jest jeszcze osiągalne i żądana usługa jest tam widoczna.

Oficjalna ścieżka menu to System services > Services. Można tam uruchamiać, zatrzymywać i restartować usługi. Jeśli usługa nie jest skonfigurowana, przycisk pod Manage jest wyszarzony.

WebAdmin udostępnia głównie jasno wydzielone usługi, na przykład Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot oraz Packet capture and Live connections. Przed kliknięciem powinno być jasne, czy usługa leży bezpośrednio w data path, czy dotyczy aktywnych użytkowników i jak sprawdzisz wynik później.

Dwa szczegóły są ważne operacyjnie: Anti-spam można uruchomić tylko wtedy, gdy istnieje inbound albo outbound spam policy. Jeśli zatrzymasz Packet capture and Live connections, zakończone zostaną nie tylko bieżące przechwytywania, ale także live connections przestaną być wyświetlane.

Do pierwszej oceny przydaje się również Control Center > System. Status services pokazuje tam, czy wszystkie usługi działają normalnie, czy występuje warning albo alert. Kliknięcie ikony pokazuje dotknięte usługi. Nie zastępuje to testu funkcjonalnego, ale pomaga odróżnić problem pojedynczej usługi od szerszego stanu systemu.

Do głębszego troubleshootingu, analizy logów lub usług bez akcji GUI potrzebna jest Advanced Shell.

Jeśli nie reaguje tylko samo WebAdmin GUI, ten ogólny artykuł nie powinien być pierwszym krokiem. Do tego istnieje celowa instrukcja Restart WebAdmin GUI Sophos Firewall.

Otwarcie Advanced Shell

Do poleceń usług potrzebna jest Advanced Shell. Dostęp odbywa się najczęściej przez SSH z użytkownikiem admin.

Jeśli SSH nie jest jeszcze przygotowany, pomaga Połączenie z Sophos Firewall przez SSH. Dostęp SSH powinien być dozwolony tylko z zaufanych sieci administracyjnych. Przed logowaniem należy sprawdzić fingerprint SSH, szczególnie po reimage, wymianie sprzętu lub zmianie IP. Odpowiednie utwardzenie opisuje Device Access i Local Service ACL na Sophos Firewall.

Sophos zamyka nieaktywne sesje SSH po 15 minutach. Przy dłuższych analizach należy więc świadomie zaplanować uruchomione polecenia, otwarte widoki logów i możliwe przerwy.

Po zalogowaniu otwiera się Advanced Shell przez:

5. Device Management > Advanced Shell

Advanced Shell daje daleko idący dostęp systemowy. Polecenia należy wykonywać tam tylko wtedy, gdy dotknięta usługa i oczekiwany wpływ są jasne.

Jeśli ma zostać sprawdzony tylko status albo odczytany plik logu, najpierw należy pozostać przy poleceniach odczytujących. Restart, Stop/Start i debug są ingerencjami i należą do świadomego okna analizy.

Lista usług

Listę dostępnych usług pokazuje:

service -S

Jeśli szukana jest konkretna usługa, można filtrować wynik:

service -S | grep strongswan
service -S | grep zebra
service -S | grep dns

Techniczne nazwy usług nie zawsze są oczywiste. Przed restartem warto więc porównać nazwę usługi z obszarem funkcjonalnym, którego dotyczy problem.

• strongswan: Site-to-Site IPsec i IPsec Remote Access; status tuneli, peer zdalny, zaplanowana przerwa, strongswan.log
• zebra: routing i trasy statyczne; tabela routingu, status SD-WAN/gateway, dotknięte lokalizacje
• dnsd: usługa DNS firewalla; DNS Request Routes, test klienta, dnsd.log
• dhcpd: przydzielanie dzierżaw DHCP; dotknięta strefa, zakres dzierżaw, klient testowy, dhcpd.log
• awed: Wireless Controller; dotknięte Access Points, zarządzanie Central lub lokalne, logi wireless

Bardziej szczegółowe przypisanie znajduje się w Sophos Firewall Troubleshooting: usługi i logi.

Restart usługi

Podstawowy wzorzec restartu brzmi:

service <service>:restart -ds nosync

Przykład dla usługi routingu zebra:

service zebra:restart -ds nosync

Ważna jest składnia ze spacją: -ds nosync. Warianty takie jak -dsnosync nie są tym samym i nie powinny być przejmowane ze starych notatek.

Podczas restartu usługa jest zatrzymywana i ponownie uruchamiana. W zależności od usługi może to przerwać aktywne połączenia. Przy routingu, VPN, DNS, DHCP, Web Proxy, WAF lub Wireless należy więc wcześniej ocenić, kto może być dotknięty.

Jeśli usługa należy do modułu istotnego dla bezpieczeństwa, po restarcie nie wystarczy sprawdzić statusu. Decydujące jest, czy oczekiwana funkcja ochrony lub połączenia znowu działa i czy w logu pojawiają się nowe błędy.

Stop i start usługi

Jeśli usługa nie reaguje czysto na restart albo Sophos Support tak zaleca, można wykonać Stop i Start osobno:

service zebra:stop -ds nosync
service zebra:start -ds nosync

Między Stop i Start nie należy czekać niepotrzebnie długo, jeśli usługa jest potrzebna produkcyjnie. Potem należy sprawdzić status i wykonać test funkcjonalny.

Sprawdzenie statusu usługi

service zebra:status -ds nosync

Dodatkowo należy sprawdzić odpowiedni plik logu. Dla routingu byłoby to na przykład:

tail -n 80 /log/zebra.log

Pomyślny status nie zawsze wystarcza. Decydujące jest, czy dotknięta funkcja znowu działa: VPN tunnels się łączą, DNS odpowiada, DHCP przydziela leases, WebAdmin się ładuje albo routing działa.

Przykłady częstych usług

Poniższe przykłady pokazują typowe restarty usług i nie zastępują analizy przyczyny.

Restart Wireless Controller

service awed:restart -ds nosync

Restart SMTP Service

service smtpd:restart -ds nosync

Restart VPN IPsec Service

service strongswan:restart -ds nosync

Restart DNS Service

service dnsd:restart -ds nosync

Przy problemach IPsec należy dodatkowo użyć Sophos Firewall IPsec Troubleshooting. Przy problemach DNS często bardziej istotne są Konfiguracja DNS Request Routes na Sophos Firewall albo przypisanie DNS/DHCP w Sophos Firewall Troubleshooting: usługi i logi niż sam restart usługi.

Świadome traktowanie wrażliwych obszarów usług

Nie każdy restart usługi ma taki sam wpływ. Niektóre usługi dotyczą tylko interfejsu zarządzania, inne leżą bezpośrednio w ścieżce danych albo sterują uwierzytelnianiem, VPN, routingiem lub usługami lokalnymi. Im bliżej usługa znajduje się ruchu produkcyjnego, tym ważniejsze są okno konserwacyjne, kontrola logów i plan powrotu.

• IPsec / SSL VPN: Tunele lub sesje Remote Access mogą się rozłączyć; Wcześniej poinformować użytkowników i lokalizacje, potem aktywnie sprawdzić tunele
• DNS / DHCP: Rozwiązywanie nazw lub przydział lease może być krótko zakłócony; Zaplanować test klienta i kontrolę logów po restarcie
• Routing / SD-WAN: Ścieżki, Gateway Monitoring lub połączenia lokalizacji mogą być dotknięte; Sprawdzić tablicę routingu, status gateway i osiągalność
• Web Proxy / IPS / TLS Inspection: Dostępy webowe lub inspection mogą być krótko dotknięte; Skontrolować Log Viewer i dotknięte policies po restarcie
• WAF / Reverse Proxy: Opublikowane aplikacje mogą być krótko niedostępne; Przetestować zewnętrzny URL i osiągalność backendu
• WebAdmin: Dostęp administracyjny zostanie krótko przerwany; Przygotować alternatywny dostęp przez SSH lub lokalną konsolę
• Reporting / baza danych / pamięć: Analiza, raporty lub stabilność GUI mogą być dotknięte; nie restartować ślepo, najpierw sprawdzić miejsce na dysku i logi

Jeśli obszar usługi nie jest jednoznaczny, najpierw należy sprawdzić Sophos Firewall Troubleshooting: usługi i logi, zanim wykona się restart. Przy tematach bazy danych, pamięci lub reportingu niecelowy restart rzadko jest najlepszym pierwszym krokiem.

Walidacja po restarcie

Po restarcie usługi nie należy sprawdzać tylko, czy polecenie wróciło bez komunikatu błędu. Ważny jest test funkcjonalny.

Sensowne kontrole:

• Sprawdzić status usługi przez service <service>:status -ds nosync.
• Sprawdzić pasujący plik logu w /log pod kątem nowych błędów.
• Zweryfikować dotkniętą funkcję realnym testem.
• Sprawdzić Log Viewer, jeśli dotknięte są reguły firewalla, NAT, web, IPS lub VPN.
• W klastrach HA sprawdzić, czy aktywny node nadal działa zgodnie z oczekiwaniem.
• Wyłączyć debug, jeśli był aktywowany przed restartem albo w jego trakcie.
• Usunąć tymczasowe zezwolenia SSH lub Device Access, jeśli zostały ustawione tylko na potrzeby support case.
• Przy powracających błędach zabezpieczyć logi i analizować przyczynę, zamiast wielokrotnie restartować usługi.

W zależności od usługi sensowny jest inny test funkcjonalny:

• IPsec / strongswan: status tunelu, Log Viewer, strongswan.log, osiągalność hosta po drugiej stronie
• DNS / dnsd: wewnętrzne i zewnętrzne rozwiązywanie nazw, DNS Request Routes, dnsd.log
• Routing / zebra: tablica routingu, Gateway Monitoring, Ping lub Traceroute przez dotkniętą ścieżkę
• WAF / Reverse Proxy: zewnętrzny test opublikowanego URL, reverseproxy.log, osiągalność backendu
• WebAdmin / tomcat i apache: sprawdzić login, Dashboard, Log Viewer i tomcat.log
• DHCP / dhcpd: sprawdzić przydział lease klientem testowym i dhcpd.log

Kiedy reboot jest lepszy

Pełny reboot jest bardziej inwazyjny niż restart usługi, ale może mieć sens, gdy zawiesza się kilka centralnych usług, problemy z pamięcią lub bazą danych zostały usunięte, Sophos Support tego wymaga albo firewall po celowych restartach nadal pozostaje niestabilny.

Decyzja nie powinna być intuicyjna. Restart usługi jest lepszy, gdy jednoznacznie dotknięty jest pojedynczy moduł, a firewall poza tym działa stabilnie. Reboot jest raczej właściwy, gdy stan jest niejasny w skali systemu albo po celowym restarcie nadal uszkodzony.

• Pojedyncza usługa zawiesza się: Tak, jeśli usługa i wpływ są jasne; Tylko jeśli restart nie pomaga
• Kilka usług pokazuje błędy: Najpierw sprawdzić logi i miejsce na dysku; Tak, jeśli stan systemu jest ogólnie niestabilny
• Trwa okno firmware lub hotfix: Nie jako zamiennik planowanego restartu; Tak, jeśli proces aktualizacji tego przewiduje
• Klaster HA jest niestabilny: Tylko po sprawdzeniu ról i zgodzie supportu; Tylko z oknem konserwacyjnym i planem HA
• Miejsce na dysku lub baza danych zostały oczyszczone: Tylko dla dotkniętej usługi; Tak, jeśli Sophos Support wymaga tego jako zakończenia
• Zdalny dostęp jest niepewny: Ostrożnie, ostatni dostęp może się urwać; Tylko z lokalnym lub alternatywnym dostępem

Przed rebootem powinny być znane backup, okno konserwacyjne, dostęp do lokalizacji, zachowanie HA i wpływ na VPN, RED, Wireless, routing oraz opublikowane usługi. W lokalizacjach zdalnych potrzebna jest dodatkowo droga powrotna, jeśli firewall po restarcie nie wróci poprawnie online: lokalny kontakt, Out-of-band Access, działający odpowiednik HA albo jasny proces supportu.

Po reboocie należy wykonać tę samą walidację co po restarcie usługi, tylko szerzej: status HA, status licencji, VPN tunnels, SD-WAN gateways, centralne logi, WebAdmin, połączenie z Central i najważniejsze opublikowane usługi. Do tematów recovery pasuje dodatkowo Poprawne planowanie backupu i restore Sophos Firewall.

Checklista operacyjna

• Dotknięty moduł i nazwa usługi zidentyfikowane.
• Pasujący plik logu sprawdzony przed restartem.
• Możliwy wpływ na użytkowników, VPN, routing lub lokalizacje oceniony.
• W razie potrzeby wyjaśnione okno konserwacyjne lub kontekst HA.
• Dostęp SSH i kontrola Host Key poprawnie przygotowane, jeśli potrzebna jest Advanced Shell.
• Usługa zrestartowana celowo.
• Status i plik logu sprawdzone po restarcie.
• Funkcja zweryfikowana realnym testem.
• Debug i tymczasowe dostępy cofnięte po analizie.
• Powracające błędy udokumentowane i nie maskowane wielokrotnymi restartami.

FAQ