Sprawdzanie Firewall Task Queue w Sophos Fusion

Jeśli zmiana z Sophos Fusion (dawniej Sophos Central) nie dociera do firewalla, należy najpierw otworzyć:

My Products > Firewall Management > Tasks Queue

Strona zawiera dwa oddzielne widoki: Task Queue dla zasad grup firewalli oraz Firewall Task Queue dla operacji MDR i API. Pomyślne zadanie potwierdza przetworzenie operacji, ale nie jej oczekiwany efekt na firewallu. Dlatego sprawdzenie kolejki i lokalna weryfikacja zawsze powinny być wykonywane razem.

Jeśli zadanie pochodzi ze wspólnej zasady grupy, Bezpieczne używanie Sophos Fusion Firewall Groups wyjaśnia także Full Sync, Skip full sync, podgrupy i przygotowanie powrotu do poprzedniego stanu. Automatycznie tworzone połączenia między lokalizacjami należy zweryfikować według artykułu Konfiguracja i weryfikacja grupy połączeń SD-WAN w Sophos Fusion.

Bezpieczne sprawdzanie nieudanego zadania

1. Otworzyć odpowiednią kartę i rozwinąć zadanie.
2. Zapisać numer zadania, grupę lub firewall, Status, Modified by, Entity, Sub-entity, Time i widoczny komunikat o błędzie.
3. Ustalić, czy jest to zasada grupy, czy operacja MDR/API. Dostępne działania są różne.
4. Dla zasady grupy sprawdzić członkostwo w grupie i Sync & Management w My Products > Firewall Management > Firewalls.
5. Dla zadania MDR/API powiązać Credential ID, Entity i Action z systemem lub klientem API, który uruchomił operację.
6. Sprawdzić na firewallu, czy zmiana nie występuje, jest kompletna czy obecna tylko częściowo.
7. Dopiero po ustaleniu przyczyny zdecydować o Retry, Skip, zmianie korygującej lub zgłoszeniu do pomocy technicznej.
8. Zweryfikować efekt techniczny za pomocą zdefiniowanego testu pozytywnego i, jeśli jest to bezpieczne, testu negatywnego.

Ta procedura rozdziela dwa pytania: Czy Sophos Fusion przetworzył operację i czy zmiana faktycznie działa na firewallu?

Rozróżnianie Task Queue i Firewall Task Queue

Task Queue dla zasad grup

Sophos Fusion automatycznie tworzy zadanie, gdy administrator zmienia zasadę grupy firewalli. Widok zawiera Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity i Time. Ogólny status obejmuje również liczbę firewalli, na których pomyślnie zastosowano zasadę. Po rozwinięciu zadania widać każdy firewall docelowy.

Znacznik czasu początkowo pokazuje utworzenie lub aktualizację zasady, a niekoniecznie rozpoczęcie dystrybucji. Jest aktualizowany podczas stosowania zasady, a na końcu wskazuje, kiedy otrzymał ją ostatni firewall. Show History wyświetla ukończone lub pominięte zadania dotyczące firewalli albo grup, które zostały później usunięte.

Sophos Fusion usuwa zadania pozostające w stanie Pending przez trzy tygodnie. Jeśli może być potrzebna eskalacja, należy odpowiednio wcześnie zachować numer zadania, błąd, firewalle docelowe i czas.

Firewall Task Queue dla operacji MDR i API

Firewall Task Queue pokazuje MDR Settings i MDR IOCs zainicjowane przez Firewall Configuration API. Widok ogólny grupuje je według Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful i Successful.

Rozwinięte zadanie pokazuje firewall, status, Credential ID w polu Modified by, encję, akcję i czas. Sophos podaje Add, Update i Delete jako przykładowe akcje. Credential ID identyfikuje dane uwierzytelniające API użyte do operacji; nie jest to wskazanie administratora jak w przypadku zasady grupy.

Poszczególne statusy to Pending, In Progress, Success, Failed i Partial Success. Partial Success oznacza, że zastosowano tylko część operacji. Sophos podaje przykład trzech wskaźników MDR Threat Feed, z których dwa dodano pomyślnie, a jeden nie. Nie należy dokumentować tego jako ogólnego sukcesu: trzeba oddzielnie zapisać udane i nieudane elementy lub firewalle oraz porównać stan lokalny.

W operacjach IOC MDR audit_ID łączy zadanie Sophos Fusion z działaniem analityka i lokalnym logiem Active Threat Response. Aktywacja i weryfikacja MDR Threat Feeds w Sophos Firewall opisuje pełną weryfikację.

Aktualizacje firmware planuje się i monitoruje w My Products > Firewall Management > Firewalls. Nie należą one do dwóch opisanych tutaj widoków kolejki.

Ograniczenia Retry, Skip i Force sync

Aktualna pomoc Sophos Fusion dotycząca Tasks Queue opisuje Retry i Skip dla nieudanych zadań zasad grup. Nie opisuje analogicznych działań dla Firewall Task Queue.

• Retry: użyć dopiero po usunięciu widocznej przyczyny i potwierdzeniu, że ta sama zmiana grupy jest nadal potrzebna. Następnie sprawdzić nowy status każdego firewalla i ponownie zweryfikować lokalnie.
• Skip: użyć tylko wtedy, gdy wiadomo, która zmiana grupy zostanie pominięta. Skip nie zastępuje lokalnego sprawdzenia ani późniejszej zmiany korygującej.
• Czekanie: dla Pending lub In Progress, dopóki przetwarzanie w wiarygodny sposób postępuje i nie widać błędu. Zachować dowody przed trzytygodniowym terminem usunięcia.
• Zgłoszenie do pomocy technicznej: gdy błąd można nadal odtworzyć, dotyczy kilku firewalli produkcyjnych lub widoczny komunikat nie pozwala na bezpieczną korektę.

⚠️ Nie należy pomijać zadania tylko po to, aby opróżnić kolejkę. Pominięta zmiana pozostaje nierozwiązana i musi zostać wyraźnie zaakceptowana, skorygowana lub wdrożona osobno.

Pomoc dotycząca kolejki nie opisuje działania Cancel ani Rollback. Skip nie cofa już rozprowadzonej zmiany grupy; usunięcie firewalla z grupy również jej nie cofa. Aby powrócić do poprzedniego stanu, należy świadomie skorygować zasadę grupy, śledzić powstałe zadanie i ponownie lokalnie zweryfikować wcześniej zdefiniowany stan docelowy.

Force sync również nie jest Retry. Jeśli firewall dodano z opcją Skip full sync, jego konfiguracja lokalna może różnić się od zasady grupy. W My Products > Firewall Management > Firewalls należy otworzyć jego status w Sync & Management; Force sync zastosuje następnie wszystkie konfiguracje grupy. Najpierw trzeba znać różnice i oczekiwany stan docelowy. W parze HA łącze jest dostępne tylko dla aktywnego firewalla.

Zawężanie typowych objawów

Zasada grupy pozostaje w stanie Pending

Najpierw sprawdzić, czy znacznik czasu zadania nadal się zmienia i których firewalli brakuje w rozwiniętym zadaniu. Następnie skontrolować członkostwo w grupie i Sync & Management w My Products > Firewall Management > Firewalls. Na firewallu objętym zadaniem System > Sophos Fusion musi pokazywać stan zarządzania Managed. Jeśli operacja nie postępuje, należy zachować dowody przed automatycznym usunięciem i eskalować z numerem zadania, czasem i listą firewalli.

W starszych instalacjach SFOS 22.0 trzeba także sprawdzić wersję firmware. NC-181175 w oficjalnych informacjach o wersji SFOS 22.0 opisuje Group Policy Push, który pozostawał w Sophos Fusion w stanie Pending i nie był stosowany. Sophos wymienia ten błąd jako usunięty w SFOS 22.0 MR2 Build 546. Ten wpis nie wyjaśnia każdego zadania Pending: najpierw należy sprawdzić status i firewalle docelowe.

Zasada grupy kończy się niepowodzeniem

Rozwinąć zadanie i zapisać firewall, którego dotyczy, Entity i Sub-entity. Nie dodawać jednocześnie kilku zmian do kolejki. Jeśli można usunąć przyczynę, użyć Retry dla tego nieudanego zadania zasady grupy, a potem zweryfikować lokalnie. Jeśli pominięcie zmiany zostało wyraźnie zaakceptowane, udokumentować Skip; w przeciwnym razie eskalować z komunikatem o błędzie.

Firewall Task Queue pokazuje Partial Success lub Failed

Zapisać Credential ID, Entity, Action, czas i wyniki dla każdego firewalla lub elementu. Pomoc Sophos Fusion nie opisuje procesu Retry, Skip ani Cancel dla tej kolejki. Nie należy przenosić obsługi z kolejki zasad grup: trzeba zbadać operację w inicjującym procesie MDR/API i sprawdzić aktualny stan lokalny przed kolejną zmianą.

Sophos Fusion zapisuje zmianę, ale zadanie się nie pojawia

Najpierw upewnić się, że rzeczywiście zmieniono i zapisano zasadę grupy przez Manage Policy. Bezpośrednie zmiany pojedynczego firewalla otwartego z Sophos Fusion nie tworzą takiego samego zadania zasady grupy. Następnie sprawdzić właściwą kartę, grupę i Show History. Jeśli oczekiwany wpis nadal się nie pojawia, zachować czas UTC, nazwy grupy i firewalla, zmienioną Entity oraz administratora Sophos Fusion dla Sophos Support. Bez wpisu w kolejce Retry i Skip nie są dostępne.

Jeśli zachowanie można odtworzyć, należy dokładnie raz powtórzyć zapis z rejestrowaniem pliku HAR w przeglądarce i skorelować czas UTC z /log/fwcm-updaterd.log. Pliki HAR mogą zawierać tokeny sesji i inne dane poufne, dlatego przed udostępnieniem trzeba je przejrzeć i zanonimizować. Plik HAR, fragment logu, czas i nazwy objęte problemem należy dołączyć do zgłoszenia Sophos Support; wielokrotne klonowanie lub usuwanie obiektów zasad nie jest wiarygodnym standardowym rozwiązaniem.

XGS 88/w: Local TLS exclusion list

Usunięty już z aktualnej Known Issues List wpis Sophos NC-177522 dokumentował, że edycja Local TLS exclusion list podczas synchronizacji zasady Sophos Fusion mogła zakończyć się błędem Failed to apply a policy na urządzeniach XGS 88/w z SFOS 21.5 MR2 Build 323 lub 22.0 GA Build 411. Nie można było zaktualizować URL Group, a wpis zezwalał na użycie Skip dla nieudanego zadania, aby kolejne zadania mogły być przetwarzane.

Oficjalne informacje o poprawce były wtedy sprzeczne: Fix versions wskazywało SFOS 22.0 MR1 Build 490, natomiast tekst obejścia nadal zapowiadał poprawkę w kolejnej maintenance release. Ponieważ aktualna lista nie zawiera już NC-177522, nie należy wyprowadzać z tego innej wersji poprawki. Dla dokładnie takiej kombinacji modelu, kompilacji i błędu trzeba najpierw zachować dowody, zrozumieć skutki Skip oraz sprawdzić lokalną listę wykluczeń TLS i powiązane zasady; aktualny stan poprawki należy potwierdzić z Sophos Support.

Lokalna weryfikacja zmiany

W przypadku reguł firewalla i NAT opcje Top i Bottom określają wyłącznie kolejność w zasadzie Sophos Fusion. Sophos Fusion umieszcza te reguły na początku lokalnej listy. Reguły lokalne mogą więc utrudniać przewidywanie rzeczywistej oceny; Sophos zaleca konsekwentne tworzenie reguł przez Sophos Fusion na centralnie zarządzanych firewallach.

Po udanym lub skorygowanym zadaniu nie należy akceptować ogólnego wyniku „sync successful”. Trzeba sprawdzić dokładnie zmienioną funkcję na firewallu docelowym:

• Czy zmieniona reguła, zasada, lista lub obiekt są widoczne w odpowiednim menu SFOS?
• Czy dla obsługiwanych obiektów Configuration Audit pokazuje oczekiwaną zmianę? Dowód audytowy nie zastępuje testu funkcjonalnego.
• Czy zdefiniowany ruch testowy jest zgodny z oczekiwanym Firewall Rule ID, a dla NAT z oczekiwanym NAT Rule ID?
• Czy przy zmianach Web lub TLS klient testowy, domena docelowa oraz logi Web i SSL/TLS Inspection są zgodne?
• Czy przy zmianach VPN lub innych funkcji konkretny przypadek użycia działa z oczekiwanymi przypisaniami użytkowników i obiektów?
• Czy przy zadaniach MDR/API oczekiwane encje lub wskaźniki są obecne lokalnie, a zdarzenie w logu odpowiada operacji?

Dla zmian ruchu Testowanie reguł firewalla za pomocą Log Viewer, Policy Test i Packet Capture opisuje lokalny proces weryfikacji. Przy rozległych zmianach Sophos Firewall Config Studio może dodatkowo porównać oczekiwaną i rzeczywistą konfigurację. Jeśli nie wiadomo, który log jest właściwy, pomoc zawiera Rozwiązywanie problemów z Sophos Firewall: usługi i logi.

W dokumentacji zmiany należy zachować co najmniej numer i status zadania, firewall docelowy, lokalne porównanie stanu oczekiwanego z rzeczywistym, wynik testu oraz dowód z logu lub audytu. Dopiero wtedy zmiana z Sophos Fusion jest zweryfikowana.