Sprawdzanie Firewall Task Queue w Sophos Central

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

My Products > Firewall Management > Tasks Queue

Dostępne są dwa widoki: Task Queue pokazuje zasady grup, a Firewall Task Queue operacje MDR i API. Pomyślne zadanie potwierdza przetworzenie w Central, ale niekoniecznie oczekiwany efekt na firewallu. Po sprawdzeniu kolejki zawsze należy więc przeprowadzić kontrolę lokalną.

Dotyczy to również automatycznie tworzonych połączeń między lokalizacjami. Pełny proces tworzenia i weryfikacji opisano w Konfiguracja i weryfikacja grupy połączeń SD-WAN w Sophos Central.

Jeżeli zadanie pochodzi ze wspólnej polityki grupy, Bezpieczne użycie Sophos Central Firewall Groups wyjaśnia również Full Sync, Skip full sync, podgrupy i lokalną walidację.

Szybka kontrola nieudanego zadania

1. Otworzyć odpowiednią kartę i rozwinąć zadanie.
2. Zapisać grupę lub firewall, którego dotyczy zadanie, status, czas, encję oraz komunikat o błędzie.
3. W przypadku zasad grup sprawdzić przynależność do grupy i stan synchronizacji firewalla.
4. W przypadku zadań MDR/API powiązać Credential ID, Entity i Action z systemem, który zainicjował operację.
5. Sprawdzić na firewallu, czy zmiana jest widoczna w całości, czy tylko częściowo.
6. W przypadku zmian konfiguracji sprawdzić Audit Trail Logs; przy problemach z ruchem użyć Log Viewer, Policy Test i Packet Capture.
7. Dopiero po ustaleniu przyczyny zdecydować o Retry, Skip lub zgłoszeniu do pomocy technicznej.
8. Zweryfikować efekt techniczny za pomocą odpowiedniego testu.

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

Różnice między Task Queue i Firewall Task Queue

Task Queue dla zasad grup

Sophos Central tworzy zadanie, gdy administrator zmienia zasadę grupy firewalli. Widok zawiera Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity i Time. Status pokazuje łączny postęp oraz liczbę firewalli, które pomyślnie otrzymały zasadę; po rozwinięciu zadania widać firewalle, których ono dotyczy.

Znacznik czasu początkowo pokazuje utworzenie lub ostatnią zmianę zasady. Jest aktualizowany podczas dystrybucji, a na końcu wskazuje moment, w którym ostatni firewall otrzymał zasadę. Show History pozwala wyświetlić ukończone lub pominięte zadania dotyczące firewalli albo grup, które zostały później usunięte.

Sophos Central usuwa zadania pozostające w stanie Pending przez trzy tygodnie. Dlatego na potrzeby zgłoszenia do pomocy technicznej należy odpowiednio wcześnie zapisać numer zadania, komunikat o błędzie, firewalle, których dotyczy, oraz 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. Przykładowe akcje to Add, Update i Delete. Credential ID pomaga ustalić, który system zainicjował operację.

Poszczególne statusy to Pending, In Progress, Success, Failed i Partial Success. Partial Success oznacza, że zastosowano tylko część operacji, na przykład dwa z trzech wskaźników MDR. Należy oddzielić pomyślne elementy lub firewalle od tych, których operacja nie objęła, usunąć przyczynę, ponownie wykonać tylko odpowiednią operację i porównać wynik z konfiguracją lokalną.

W zadaniach IoC MDR audit_ID łączy zadanie Central z działaniem analityka i lokalnym logiem Active Threat Response. Aktywacja i weryfikacja MDR Threat Feeds w Sophos Firewall przedstawia pełną weryfikację feedu, akcji, kontekstu endpointu i incydentu.

Aktualizacje oprogramowania układowego planuje się i monitoruje w Sophos Central w My Products > Firewall Management > Firewalls. Nie należą one do dwóch opisanych tutaj widoków kolejki.

Central zapisuje zmianę, ale nie tworzy zadania

Jeśli Central potwierdza zapisanie polityki grupy, ale w Task Queue nie pojawia się nowy wpis, opcje Retry i Skip nie są dostępne. Najpierw należy sprawdzić właściwą grupę i politykę, zakończenie operacji zapisu, członkostwo firewalla w grupie oraz istniejące zadania Pending. Następnie trzeba zanotować czas UTC i nazwy grupy, firewalla oraz polityki, powtórzyć operację dokładnie raz z rejestracją pliku HAR w przeglądarce i skorelować /log/fwcm-updaterd.log. Wielokrotne klonowanie lub usuwanie obiektów polityki nie jest wiarygodną standardową naprawą.

Przypadek z Community dotyczący Web Policy zawierającej użytkowników lub grupy pokazuje ten objaw, ale nie potwierdza ani tego, że problem dotyczy ogólnie określonego buildu, ani publicznie dostępnej poprawki produktu. Jest to zatem sygnał dla wsparcia, a nie dowód ogólnego błędu Sophos Central. Jeśli zachowanie można odtworzyć, plik HAR, log, czas UTC i nazwy objętych elementów należy dołączyć do zgłoszenia Sophos Support.

Bezpieczne używanie Retry, Skip i Force sync

Retry i Skip dotyczą wyłącznie zasad grup w Task Queue. Sophos Central udostępnia Retry dla statusów Failed, Skipped i Invalid license, a Skip dla Created, Pending, Invalid license i Failed.

• Retry: użyć dopiero po usunięciu przyczyny, na przykład przerwania połączenia z Central, konfliktu obiektów lub poprawienia przypisania licencji.
• Skip: użyć tylko wtedy, gdy wiadomo, która zmiana nie zostanie zastosowana i jak zostanie później sprawdzony firewall, którego dotyczy zadanie.
• Czekanie: gdy zadanie jest nadal przetwarzane i nie ma wiarygodnego komunikatu o błędzie.
• Zgłoszenie do pomocy technicznej: gdy błąd się powtarza, dotyczy kilku firewalli produkcyjnych lub nie można go jednoznacznie sklasyfikować.

⚠️ Nie należy pomijać nieudanego zadania tylko po to, aby opróżnić kolejkę. Skip jest decyzją operacyjną; pominiętą zmianę trzeba później sprawdzić lub wdrożyć osobno.

Jeśli firewall został dodany do grupy z opcją Skip full sync, jego konfiguracja lokalna może różnić się od zasady grupy. Stan sprawdza się w My Products > Firewall Management > Firewalls. Jeśli w Sync & Management widnieje Failed to apply a policy, należy sprawdzić odpowiedni wpis w Task Queue. Force sync stosuje pełną konfigurację grupy i dlatego powinien być uruchamiany tylko świadomie. W parze HA łącze jest dostępne tylko na aktywnym firewallu.

Lokalna weryfikacja zasady Central

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

Po pomyślnym wykonaniu zadania należy sprawdzić na firewallu:

• Czy zmieniona reguła, zasada, lista lub obiekt są widoczne?
• Czy Audit Trail pokazuje oczekiwaną zmianę konfiguracji?
• Czy ruch testowy jest zgodny z oczekiwanym Firewall Rule ID, a w przypadku NAT z oczekiwanym NAT Rule ID?
• Czy w przypadku zmian Web lub TLS klient testowy, domena docelowa oraz logi Web i SSL/TLS Inspection są zgodne?
• Czy w przypadku zmian VPN lub innych funkcji konkretny przypadek użycia działa z oczekiwanym przypisaniem użytkownika lub obiektu?
• Czy w przypadku zadań MDR/API encja lub wskaźniki są widoczne lokalnie, a wynik jest zgodny z Credential ID i oczekiwanym zdarzeniem w logu?

Do zwięzłego potwierdzenia odbioru wystarczą status zadania, firewall, którego ono dotyczy, test lokalny oraz dowód z logu lub audytu. Przy rozległych zmianach Sophos Firewall Config Studio może dodatkowo pomóc porównać oczekiwaną konfigurację z rzeczywistą. Jeśli nie wiadomo, który log jest właściwy, Rozwiązywanie problemów z Sophos Firewall: usługi i logi zawiera odpowiednie przyporządkowanie.

Znane błędy zależne od wersji

Zasada grupy pozostaje w stanie Pending

NC-181175 opisuje błąd, w wyniku którego Group Policy Push z Sophos Central pozostawał w stanie Pending i nie był stosowany na firewallach. Sophos usunął ten błąd w SFOS 22.0 MR2 Build 546. W przypadku wcześniejszej wersji 22.0 i zadania, które długo pozostaje w stanie Pending, należy również sprawdzić wersję oprogramowania układowego.

XGS 88/w: Local TLS exclusion list

NC-177522 dotyczy XGS 88/w z SFOS 21.5 MR2 Build 323 lub 22.0 GA Build 411. Podczas synchronizacji zasady Central edycja Local TLS exclusion list mogła zakończyć się błędem Failed to apply a policy, ponieważ nie można było zaktualizować grupy adresów URL.

Udokumentowanym obejściem jest pominięcie nieudanej transakcji, aby umożliwić wykonanie kolejnych zadań. Następnie należy sprawdzić lokalną listę wykluczeń TLS i powiązane zasady. Aktualna Known Issues List zawiera sprzeczne informacje o statusie poprawki: w sekcji Fix versions wskazuje SFOS 22.0 MR1 Build 490, podczas gdy opis obejścia nadal zapowiada poprawkę w następnym maintenance release. Przed oceną problemu należy więc sprawdzić bieżący wpis i release notes.