Ponowne uruchamianie interfejsu WebAdmin Sophos Firewall

Jeśli interfejs WebAdmin Sophos Firewall przestanie odpowiadać, nie trzeba od razu uruchamiać ponownie całej zapory. Dopóki routing, VPN i reguły zapory nadal działają, a SSH lub konsola lokalna pozostają dostępne, można oddzielnie sprawdzić i ponownie uruchomić dwie usługi WebAdmin: tomcat i apache.

Poniższe polecenia są przeznaczone dla autonomicznej zapory sieciowej. W klastrze HA właściwy tryb synchronizacji zależy od usługi, węzła, kompilacji SFOS oraz konkretnego problemu. Nie należy używać -ds nosync w HA bez wcześniejszego sprawdzenia, czy jest to właściwe.

⚠️ Ponowne uruchomienie usługi zmienia stan systemu, kończy aktywne sesje WebAdmin i może również na krótko przerwać działanie User Portal. Najpierw należy zabezpieczyć odpowiednie logi, poinformować innych administratorów i przygotować alternatywny dostęp do lokalizacji zdalnych.

Szybka procedura dla autonomicznej zapory

Ta procedura jest odpowiednia, gdy WebAdmin wyświetla Internal Server Error, HTTP 503, niepełną stronę logowania lub trwale nie odpowiadający interfejs, a SSH i pozostałe funkcje zapory są nadal dostępne.

1. Zalogować się jako admin przez SSH lub konsolę lokalną. Jeśli SSH nie zostało jeszcze skonfigurowane, artykuł Łączenie z Sophos Firewall przez SSH wyjaśnia, jak przygotować bezpieczny dostęp.
2. Otworzyć 5. Device Management > 3. Advanced Shell.
3. Wyświetlić ostatnie błędy WebAdmin i skopiować istotne dane wyjściowe do dokumentacji zmiany lub zgłoszenia do pomocy technicznej:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

4. Sprawdzić aktualny stan usług:

service -S | grep -iE 'tomcat|apache'

5. Jeśli usługa ma stan STOPPED, wykonać tylko odpowiadające jej polecenie uruchomienia:

# Jeśli tomcat ma stan STOPPED:
service tomcat:start -ds nosync

# Jeśli apache ma stan STOPPED:
service apache:start -ds nosync

6. Jeśli usługa ma stan DEAD, uruchomić ponownie tylko tę usługę. Jeśli obie mają stan RUNNING, ale WebAdmin nadal nie działa prawidłowo, rozpocząć od tomcat:

service tomcat:restart -ds nosync

Ponownie przetestować WebAdmin. Następujące polecenie wykonać tylko wtedy, gdy apache ma stan DEAD lub problem nie ustąpił po ponownym uruchomieniu tomcat:

service apache:restart -ds nosync

7. Odczekać kilka sekund, ponownie otworzyć WebAdmin z właściwej sieci zarządzającej i jeszcze raz sprawdzić stan usług:

service -S | grep -iE 'tomcat|apache'

Obie usługi powinny mieć stan RUNNING. Decydujący jest jednak test działania: logowanie, panel, Log Viewer i niekrytyczna strona konfiguracji muszą ładować się stabilnie. Sam działający proces nie dowodzi, że WebAdmin działa prawidłowo.

Nieaktywne sesje SSH są zamykane po 15 minutach. Przed otwarciem Advanced Shell należy więc przygotować sprawdzenie logów, restart i kontrolę, aby wygaśnięcie sesji nie przerwało procedury.

Sprawdzenie, czy restart usługi jest właściwym działaniem

Za nazwą usługi tomcat kryje się serwer aplikacji internetowych Jetty; apache jest serwerem HTTP Apache. Oba komponenty są używane przez WebAdmin oraz User Portal. Ich logi znajdują się w Advanced Shell:

• Serwer aplikacji: /log/tomcat.log
• Serwer WWW: /log/apache.log i /log/apache_access.log
• Pozostałe błędy serwera WWW: /log/error_log.log

Nie każdy problem z WebAdmin ma źródło w tych usługach. Rodzaj błędu określa następny krok:

• Internal Server Error, HTTP 503 lub niepełna strona logowania: Sprawdzić tomcat, apache i wymienione logi. W tym przypadku ukierunkowany restart jest uzasadniony.
• Ostrzeżenie dotyczące certyfikatu: Sprawdzić nazwę, ważność i łańcuch zaufania certyfikatu. Restart usługi nie naprawi nieprawidłowego certyfikatu.
• Przekroczenie limitu czasu lub brak dostępu tylko z jednej sieci: Sprawdzić trasę, sieć zarządzającą i Administration > Device access. Lokalne usługi zapory udostępnia się przez Device Access, a nie za pomocą zwykłej reguły zapory. Artykuł Device Access i Local Service ACL opisuje bezpieczną konfigurację.
• Problem dotyczy tylko jednej przeglądarki: Przed ingerencją w zaporę przetestować sesję prywatną, drugą przeglądarkę lub innego klienta administracyjnego.
• WebAdmin, SSH, VPN lub inne usługi przestają działać jednocześnie: Wskazuje to raczej na obciążenie systemu, pamięć masową, bazę danych, HA lub ogólny problem systemowy. Nie należy losowo restartować usług.

Jeśli trwa aktualizacja firmware, hotfixa lub wzorców, synchronizacja HA, sesja debugowania dla pomocy technicznej albo aktywne zadanie Central, należy najpierw zidentyfikować ten proces i, jeśli to możliwe, poczekać na jego zakończenie. W przeciwnym razie trudno będzie później ustalić, czy problem spowodowała aktualizacja, Central, HA czy restart usługi.

Zabezpieczenie danych diagnostycznych przed ingerencją

Restart może usunąć bieżące komunikaty o błędach z widocznego kontekstu. W przypadku powtarzającego się problemu lub zgłoszenia do pomocy technicznej należy zapisać co najmniej czas, kompilację SFOS, dotkniętą ścieżkę dostępu oraz ostatnie wpisy z tomcat.log, apache.log i error_log.log.

Jeśli WebAdmin działa jeszcze częściowo, w Diagnostics > Tools można pobrać pojedyncze logi lub Consolidated Troubleshooting Report. Jeśli dostępna jest już tylko powłoka, artykuł Zapisywanie logów Sophos Firewall na potrzeby pomocy technicznej i analizy opisuje procedurę. W klastrze HA każdy węzeł zapisuje własne logi; w razie potrzeby należy sprawdzić oddzielnie Primary i Auxiliary.

Przed restartem w środowisku produkcyjnym należy również potwierdzić:

• czy zmiana wpłynie na innych administratorów lub trwające prace;
• czy SSH, konsola lokalna, Sophos Central lub inne połączenie zarządzające zapewnia drogę powrotu;
• czy WebAdmin jest jedyną dotkniętą usługą;
• czy dla klastra HA dostępny jest właściwy węzeł oraz aktualna instrukcja Sophos dotycząca konkretnej usługi.

Artykuł Bezpieczne ponowne uruchamianie usług Sophos Firewall wyjaśnia ogólne zasady pracy z nazwami usług, stanem, logami i ograniczeniami HA. Rozwiązywanie problemów z Sophos Firewall: usługi i logi zawiera dodatkowe powiązania między funkcjami a plikami logów.

Weryfikacja wyniku i analiza powtarzających się problemów

Po restarcie należy ponownie odczytać logi. Nowe błędy pojawiające się bezpośrednio po uruchomieniu są bardziej przydatne niż stare komunikaty bez odniesienia do czasu:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

Następnie otworzyć panel, Log Viewer i niekrytyczną stronę. Tymczasowo dozwolony dostęp SSH lub Device Access należy ponownie ograniczyć do właściwych źródeł administracyjnych.

Jeśli problem powróci, restart usługi był tylko rozwiązaniem tymczasowym. Analiza przyczyny powinna wtedy obejmować:

• wolne miejsce na partycjach, lokalne raporty i stan bazy danych;
• obciążenie CPU i RAM oraz nietypowe logi systemowe;
• równoległe sesje administratorów lub intensywne przechwytywanie pakietów;
• aktywne lub nieudane zadania Central;
• rolę HA, synchronizację i dotknięty węzeł;
• zmiany konfiguracji, certyfikatu, interfejsu lub Device Access bezpośrednio przed problemem.

Artykuł Zarządzanie pamięcią masową i raportami Sophos Firewall pomaga w przypadku problemów z pamięcią masową i raportami. Zmiany wprowadzone przed awarią można prześledzić w logach Audit Trail Sophos Firewall.

Krótka notatka operacyjna pozwala uniknąć obsługi powtarzającego się problemu wyłącznie przez kolejne restarty:

Data, godzina i strefa czasowa:
Zapora i węzeł HA, jeśli dotyczy:
Wersja i kompilacja SFOS:
Objawy:
Sprawdzone logi:
Wykonane polecenie:
Wynik i następne działanie:

Jeśli WebAdmin nadal jest niedostępny

Jeśli usługa pozostaje w stanie STOPPED lub DEAD, restart zwraca błąd albo problem natychmiast powraca, należy zabezpieczyć tomcat.log, apache.log, error_log.log, stan systemu i CTR do analizy z Sophos Support. Losowe restartowanie kolejnych usług najprawdopodobniej pogorszy materiał diagnostyczny.

Jeśli ani WebAdmin, ani SSH nie są dostępne, ścieżka odzyskiwania zależy od środowiska: konsola lokalna przez kabel konsolowy lub Micro-USB w obsługiwanych modelach, Sophos Central, przygotowana ścieżka awaryjna HA albo planowany restart. W lokalizacjach zdalnych trzeba ustalić, kto może uzyskać dostęp lokalny, jeśli zapora nie uruchomi się prawidłowo. W klastrze HA nie należy bez weryfikacji przełączać awaryjnie tylko dlatego, że WebAdmin nie odpowiada, dopóki ruch produkcyjny nadal działa stabilnie.

Pełny restart jest bardziej inwazyjny niż ponowne uruchomienie dotkniętych usług. Należy go rozważyć dopiero wtedy, gdy problem dotyczy kilku centralnych usług, zapora pozostaje niestabilna, wymaga go proces firmware lub hotfix albo zaleca go Sophos Support. Najpierw należy potwierdzić kopię zapasową, okno konserwacyjne oraz wpływ na VPN, routing, RED, wireless i opublikowane usługi. Artykuł Prawidłowe planowanie kopii zapasowej i przywracania Sophos Firewall opisuje przygotowanie.