Synchronized Application Control: bezpieczna diagnostyka bazy danych

Jeśli Synchronized Application Control przestaje rejestrować nowe aplikacje, w heartbeatd.log pojawiają się błędy albo po aktualizacji w Sophos Firewall pozostaje bardzo mało wolnego miejsca, problem może dotyczyć wewnętrznej bazy danych aplikacji. Nie jest to jednak sytuacja, w której należy stosować ogólne polecenia PostgreSQL znalezione na forum lub w starej notatce wsparcia.

Sophos Firewall zarządza tymi danymi wewnętrznie, a sposób ich przechowywania zmienił się w SFOS 20.0 MR1. Jeśli automatyczne czyszczenie nie powiedzie się z powodu braku wolnego miejsca, aktualna dokumentacja Sophos wyraźnie zaleca kontakt ze wsparciem. W tym artykule pokazujemy więc, jak bezpiecznie zawęzić przyczynę problemu, zebrać właściwe dane i w kontrolowany sposób przeprowadzić interwencję wsparcia.

Prawidłowe rozpoznanie problemu

Synchronized Application Control wykorzystuje informacje z endpointów połączonych z firewallem za pomocą Security Heartbeat. Dzięki temu firewall rozpoznaje aplikacje, których nie można jednoznacznie zidentyfikować przy użyciu klasycznych sygnatur, i udostępnia je do zarządzania w Applications > Synchronized Application Control.

Nie należy mylić następujących pojęć:

• Security Heartbeat przekazuje informacje o stanie i bezpieczeństwie między endpointem, firewallem a Sophos Central.
• Synchronized Application Control rejestruje aplikacje i miejsca ich występowania na połączonych endpointach.
• Missing heartbeat oznacza brak statusu endpointu i można nim zarządzać za pomocą obsługiwanych poleceń Device Console.
• Problem z App ID lub bazą danych dotyczy wewnętrznego przechowywania wykrytych aplikacji i wymaga osobnej diagnostyki.

Brak wskaźnika Heartbeat, czerwony status endpointu lub niedopasowana reguła firewalla nie oznaczają więc automatycznie problemu z bazą danych. W przypadku połączenia firewalla z Central należy najpierw skorzystać z artykułu Łączenie Sophos Firewall z Sophos Central.

Co SFOS czyści automatycznie

Aktualna dokumentacja Sophos dotycząca Synchronized Application Control podaje dwa ważne ograniczenia:

• Synchronized Application Control obsługuje do 15'000 aplikacji.
• Od wersji SFOS 20.0 MR1 firewall przechowuje tylko pięć ostatnich wystąpień każdej aplikacji na endpoint.

Podczas migracji do SFOS 20.0 MR1 lub nowszej wersji firewall zachowuje pięć najnowszych wystąpień i automatycznie usuwa starsze dane aplikacji. Sophos zwraca jednak uwagę, że przy zbyt małej ilości wolnego miejsca takie czyszczenie może się nie powieść. W takim przypadku należy skontaktować się ze wsparciem Sophos.

W praktyce oznacza to, że aktualny firewall zwykle nie wymaga ręcznej konserwacji tej bazy danych. Powtarzający się wzrost, nieudana migracja lub wyczerpany zakres App ID to objawy problemu, a nie standardowe zadania konserwacyjne.

Rozróżnianie typowych objawów

Problem z pamięcią po aktualizacji

Możliwe oznaki to bardzo mocno zapełniona partycja, nieprawidłowo działające raporty lub usługi oraz związek czasowy z aktualizacją do SFOS 20.0 MR1 lub nowszej wersji. Samo to nie dowodzi jeszcze, że przyczyną jest Synchronized Application Control.

Najpierw należy sprawdzić raporty, logi debugowania, archiwa wsparcia, kolejkę poczty, kwarantannę oraz rozmiar dysku wirtualnego. Procedurę opisano w artykule Sprawdzanie miejsca na dysku i zarządzanie raportami na Sophos Firewall.

Wyczerpany zakres App ID

Innym objawem jest komunikat podobny do poniższego:

Cannot create ID for application, because appId range is exhausted.
Application will be ignored.

Firewall może nadal wyświetlać istniejące aplikacje, ale nie rejestrować poprawnie nowych. Ten komunikat wskazuje na Synchronized Application Control, a nie na ogólną bazę danych raportów lub logów.

Security Heartbeat nie działa

Jeśli endpointy nie zgłaszają statusu Heartbeat albo reguły z warunkami Heartbeat nie działają zgodnie z oczekiwaniami, należy najpierw sprawdzić rejestrację w Central, komunikację endpointu, odpowiednie strefy oraz regułę firewalla. Bezpośrednie czyszczenie bazy danych nie jest właściwym rozwiązaniem takiego problemu.

Diagnostyka przed zgłoszeniem do wsparcia

1. Udokumentowanie firmware i kontekstu

W notatkach do zgłoszenia należy umieścić następujące informacje:

• model firewalla, numer seryjny oraz pełna wersja SFOS wraz z numerem kompilacji
• tryb Standalone, HA Primary lub HA Auxiliary
• data ostatniej aktualizacji i poprzednia wersja SFOS
• moment, od którego problem jest widoczny
• usługi, których dotyczy problem, oraz jego konkretny wpływ

W środowisku HA trzeba jednoznacznie ustalić, na którym Node występuje objaw. Lokalne logi i zajętość pamięci mogą różnić się między Primary a Auxiliary.

2. Sprawdzenie widoku aplikacji

W Applications > Synchronized Application Control należy sprawdzić:

• Czy nowe aplikacje są nadal rejestrowane?
• Czy liczba wpisów zbliża się do limitu 15'000 aplikacji?
• Czy problem dotyczy tylko nowych aplikacji, czy także istniejących wpisów?
• Czy aplikacje można wyszukiwać, otwierać i nimi zarządzać?
• Czy usunięte aplikacje są ponownie tworzone zgodnie z oczekiwaniami po ponownym wykryciu?

Usuwanie pojedynczych aplikacji w interfejsie jest obsługiwaną funkcją, ale usuwa je również z Application Filters. Po ponownym wykryciu przez firewall aplikacja pojawi się ponownie. Ta funkcja interfejsu nie służy więc do naprawy bazy danych.

3. Osobne sprawdzenie wykorzystania pamięci

Przed podjęciem dalszych działań należy udokumentować wykorzystanie pamięci. Ważne jest zapisanie odpowiedniej partycji oraz zmian w czasie, a nie tylko pojedynczej wartości procentowej.

Jeśli równocześnie usuwa się raporty, logi lub archiwa wsparcia, później nie da się ustalić, które działanie rzeczywiście pomogło. Dlatego najpierw należy zabezpieczyć dowody, a następnie wprowadzać tylko jedną zmianę naraz.

4. Zabezpieczenie logów i raportu diagnostycznego

Dla Synchronized Application Control oraz Security Heartbeat szczególnie istotny jest heartbeatd.log. Należy także zapisać dokładny czas wystąpienia błędu i przygotować raport diagnostyczny.

Odpowiednie pliki i sposoby ich pozyskania opisano w artykułach Sophos Firewall Troubleshooting: usługi i logi oraz Zabezpieczanie logów Sophos Firewall do analizy zewnętrznej.

Nie stosuj publicznych poleceń do bazy danych

W internecie można znaleźć różne polecenia psql, DELETE, VACUUM FULL oraz polecenia restartu usług przeznaczone dla starszych wersji SFOS i różnych problemów z Heartbeat. Tych procedur nie można stosować zamiennie:

• VACUUM FULL zwalnia miejsce zajmowane przez tabelę, ale nie usuwa automatycznie przyczyny jej wzrostu.
• DELETE może zmienić przypisania aplikacji, endpointów lub aktualnie uwierzytelnionych użytkowników.
• Tabele i procedury wsparcia mogą różnić się między wersjami SFOS.
• W środowisku HA procedura zależy dodatkowo od Node, stanu synchronizacji i instrukcji wsparcia.

⚠️ Bez aktualnej instrukcji Sophos Support odnoszącej się do konkretnego przypadku nie należy wprowadzać bezpośrednich zmian w wewnętrznej bazie danych PostgreSQL. Kopia zapasowa konfiguracji jest ważna, ale nie zapewnia pełnego wycofania zmian w wewnętrznej bazie danych.

Poleceń z wcześniejszego zgłoszenia również nie należy bez sprawdzenia stosować na innym firewallu, firmware lub w innej roli HA. Dokładna instrukcja musi znaleźć się w aktualnym zgłoszeniu do wsparcia i wskazywać właściwy Node oraz oczekiwany rezultat.

Kompletne przygotowanie zgłoszenia do wsparcia

Dobrze przygotowane zgłoszenie przyspiesza analizę i ogranicza liczbę dodatkowych pytań. Należy dołączyć:

• pełną wersję SFOS i model firewalla
• numer seryjny i rolę HA odpowiedniego Node
• czas i dokładną treść komunikatu o błędzie
• zrzut ekranu z Applications > Synchronized Application Control
• wykorzystanie pamięci przed własnymi działaniami porządkowymi
• heartbeatd.log oraz raport diagnostyczny dla właściwego przedziału czasu
• datę i ścieżkę ostatniej aktualizacji firmware
• informację, czy brakuje nowych aplikacji, jest mało wolnego miejsca, czy występują oba problemy

Przed interwencją wsparcia należy mieć aktualną kopię zapasową konfiguracji firewalla. Sposób otwarcia zgłoszenia opisano w artykule Otwieranie zgłoszenia wsparcia Sophos.

Jeśli wsparcie zleci ingerencję w bazę danych, w planie zmiany należy zapisać numer zgłoszenia, zatwierdzone polecenia, docelowy Node, okno konserwacyjne, oczekiwane dane wyjściowe oraz kryteria przerwania. Odmienne komunikaty o błędach trzeba udokumentować i zgłosić, zamiast kontynuować eksperymenty z podobnymi poleceniami.

Weryfikacja po działaniu wsparcia

Po wykonaniu zatwierdzonego działania nie wystarczy sprawdzić wolnego miejsca ani pomyślnego wykonania polecenia. Należy zweryfikować cały przebieg funkcjonalny:

1. Otworzyć Applications > Synchronized Application Control i sprawdzić istniejące wpisy.
2. Na testowym endpointcie uruchomić nową aplikację, która nie była wcześniej rejestrowana.
3. Sprawdzić, czy aplikacja pojawia się jako nowa i można nią zarządzać.
4. Sprawdzić status Security Heartbeat testowego endpointu.
5. Przetestować reguły firewalla z warunkami Heartbeat lub Application Control.
6. Sprawdzić heartbeatd.log pod kątem nowych błędów w okresie testowym.
7. Obserwować wykorzystanie pamięci przez kilka godzin lub dni.

Jeśli błąd lub wzrost szybko powróci, czyszczenie przyniosło jedynie krótkotrwałą poprawę. Sophos Support będzie wtedy potrzebować nowej osi czasu, aktualnych logów oraz informacji, po jakim działaniu problem wystąpił ponownie.

FAQ