Sophos Fusion Firewall Task Queue prüfen

Wenn eine Änderung aus Sophos Fusion (ehemals Sophos Central) nicht auf der Firewall ankommt, öffnet man zuerst:

My Products > Firewall Management > Tasks Queue

Dort stehen zwei getrennte Ansichten bereit: Task Queue für Firewall-Gruppenrichtlinien und Firewall Task Queue für MDR- und API-Aufträge. Ein erfolgreicher Task bestätigt die Verarbeitung des Auftrags, aber noch nicht die gewünschte Wirkung auf der Firewall. Deshalb gehören Queue-Prüfung und lokale Abnahme immer zusammen.

Entsteht der Task aus einer gemeinsamen Gruppenpolicy, erklärt Sophos Fusion Firewall Groups sicher verwenden zusätzlich Full Sync, Skip full sync, Untergruppen und die Vorbereitung des Rückwegs. Automatisch erzeugte Standortverbindungen werden unter Sophos Fusion SD-WAN Connection Group einrichten und prüfen vollständig abgenommen.

Fehlgeschlagenen Task sicher prüfen

1. Den passenden Tab öffnen und den Task aufklappen.
2. Task-Nummer, Gruppe oder Firewall, Status, Modified by, Entity, Sub-entity, Time und die sichtbare Fehlermeldung dokumentieren.
3. Klären, ob es sich um eine Gruppenrichtlinie oder einen MDR-/API-Auftrag handelt. Die verfügbaren Aktionen unterscheiden sich.
4. Bei einer Gruppenrichtlinie Gruppenmitgliedschaft und Sync & Management unter My Products > Firewall Management > Firewalls prüfen.
5. Bei einem MDR-/API-Task die Credential ID, Entity und Action dem auslösenden System beziehungsweise API-Client zuordnen.
6. Auf der Firewall feststellen, ob die Änderung fehlt, vollständig oder nur teilweise vorhanden ist.
7. Erst nach geklärter Ursache über Retry, Skip, eine korrigierende Änderung oder einen Supportfall entscheiden.
8. Die technische Wirkung mit einem definierten Positiv- und, wenn sicher möglich, Negativtest abnehmen.

Dieser Ablauf trennt zwei Fragen: Hat Sophos Fusion den Auftrag verarbeitet, und funktioniert die Änderung auf der Firewall tatsächlich?

Task Queue und Firewall Task Queue unterscheiden

Task Queue für Gruppenrichtlinien

Sophos Fusion erstellt automatisch einen Task, wenn ein Administrator eine Firewall-Gruppenrichtlinie ändert. Die Ansicht zeigt Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity und Time. Der Gesamtstatus enthält auch die Anzahl der Firewalls, auf denen die Policy erfolgreich angewendet wurde. Aufgeklappt sieht man die einzelnen Ziel-Firewalls.

Der Zeitstempel zeigt zunächst, wann die Policy erstellt oder aktualisiert wurde, nicht zwingend den Beginn der Verteilung. Während der Anwendung wird er aktualisiert; am Ende zeigt er den Zeitpunkt, an dem die letzte Firewall die Policy erhalten hat. Show History blendet abgeschlossene oder übersprungene Tasks für inzwischen gelöschte Firewalls oder Gruppen ein.

Sophos Fusion löscht Tasks, die drei Wochen lang auf Pending stehen. Für eine Eskalation sollte man Task-Nummer, Fehlermeldung, Ziel-Firewalls und Zeitpunkt daher frühzeitig sichern.

Firewall Task Queue für MDR- und API-Aufträge

Die Firewall Task Queue zeigt MDR Settings und MDR IOCs, die über die Firewall Configuration API angestossen wurden. Die Übersicht gruppiert sie nach Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful und Successful.

Ein aufgeklappter Task zeigt Firewall, Status, Credential ID unter Modified by, Entity, Action und Zeitpunkt. Als Action nennt Sophos beispielsweise Add, Update und Delete. Die Credential ID verbindet den Auftrag mit den verwendeten API-Zugangsdaten; sie ist keine Benutzeranzeige wie bei einer Gruppenpolicy.

Die einzelnen Statuswerte sind Pending, In Progress, Success, Failed und Partial Success. Partial Success bedeutet, dass nur ein Teil des Auftrags angewendet wurde. Sophos nennt als Beispiel drei MDR-Threat-Feed-Indikatoren, von denen zwei erfolgreich waren und einer fehlschlug. Diesen Zustand darf man nicht als Gesamterfolg dokumentieren: erfolgreiche und fehlgeschlagene Elemente beziehungsweise Firewalls getrennt erfassen und den lokalen Zustand vergleichen.

Bei MDR-IOC-Aufträgen verbindet die audit_ID den Sophos Fusion-Task mit der Analystenaktion und dem lokalen Active-Threat-Response-Log. Die vollständige Abnahme steht unter MDR Threat Feeds auf Sophos Firewall aktivieren und prüfen.

Firmware-Upgrades werden dagegen unter My Products > Firewall Management > Firewalls geplant und überwacht. Sie gehören nicht zu den beiden hier beschriebenen Queue-Ansichten.

Retry, Skip und Force sync begrenzen

Die aktuelle Sophos-Fusion-Hilfe zur Tasks Queue dokumentiert Retry und Skip für fehlgeschlagene Gruppenpolicy-Tasks. Für die Firewall Task Queue dokumentiert diese Seite keine entsprechende Aktion.

• Retry: erst verwenden, wenn die erkennbare Ursache behoben ist und dieselbe Gruppenänderung weiterhin gelten soll. Danach den neuen Status pro Firewall und den lokalen Zustand erneut prüfen.
• Skip: nur verwenden, wenn klar ist, welche Gruppenänderung ausgelassen wird. Skip ersetzt weder die lokale Kontrolle noch eine spätere korrigierende Änderung.
• Warten: bei Pending oder In Progress, solange die Verarbeitung plausibel fortschreitet und keine Fehlermeldung vorliegt. Vor Ablauf der dreiwöchigen Löschfrist die Belege sichern.
• Supportfall: wenn der Fehler reproduzierbar bleibt, mehrere produktive Firewalls betrifft oder die sichtbare Meldung keine sichere Korrektur zulässt.

⚠️ Einen Task nicht nur überspringen, damit die Queue sauber aussieht. Die ausgelassene Änderung bleibt fachlich offen und muss ausdrücklich akzeptiert, korrigiert oder separat umgesetzt werden.

Die Queue-Hilfe beschreibt keine Cancel- oder Rollback-Aktion. Eine bereits verteilte Gruppenänderung wird deshalb nicht durch Skip und auch nicht durch das Entfernen der Firewall aus der Gruppe zurückgesetzt. Für einen Rückweg korrigiert man die Gruppenpolicy bewusst, verfolgt den daraus entstehenden Task und nimmt den vorher definierten Sollzustand erneut lokal ab.

Force sync ist ebenfalls kein Retry. Wurde eine Firewall mit Skip full sync aufgenommen, kann ihre lokale Konfiguration von der Gruppenpolicy abweichen. Unter My Products > Firewall Management > Firewalls öffnet man den Status in Sync & Management; Force sync übernimmt anschliessend alle Gruppenkonfigurationen. Vorher müssen die Abweichungen und der gewünschte Sollzustand bekannt sein. Bei einem HA-Paar steht der Link nur für die aktive Firewall zur Verfügung.

Fehlerbilder eingrenzen

Gruppenpolicy bleibt auf Pending

Zuerst prüfen, ob der Task-Zeitstempel noch aktualisiert wird und welche Firewalls im aufgeklappten Task fehlen. Danach unter My Products > Firewall Management > Firewalls Gruppenmitgliedschaft und Sync & Management kontrollieren. Auf der betreffenden Firewall muss unter System > Sophos Fusion der Managementstatus Managed sein. Bleibt der Auftrag ohne Fortschritt, Belege vor der automatischen Löschung sichern und mit Task-Nummer, Zeit und betroffenen Firewalls eskalieren.

Für ältere SFOS-22.0-Installationen ist zusätzlich der Firmwarestand relevant: NC-181175 in den offiziellen SFOS-22.0-Release-Notes beschreibt einen Group Policy Push, der in Sophos Fusion auf Pending blieb und nicht angewendet wurde. Sophos führt den Fehler unter den in SFOS 22.0 MR2 Build 546 behobenen Problemen. Der Eintrag erklärt aber nicht automatisch jeden Pending-Task; zuerst Status und Ziel-Firewalls prüfen.

Gruppenpolicy schlägt fehl

Task aufklappen und die betroffene Firewall sowie Entity und Sub-entity festhalten. Nicht mehrere Änderungen gleichzeitig nachschieben. Wenn die Ursache korrigiert werden kann, genau den fehlgeschlagenen Gruppenpolicy-Task mit Retry erneut verarbeiten und anschliessend lokal prüfen. Ist die ausgelassene Änderung bewusst akzeptiert, Skip dokumentieren; sonst mit der Fehlermeldung eskalieren.

Firewall Task Queue zeigt Partial Success oder Failed

Credential ID, Entity, Action, Zeitpunkt und Ergebnisse pro Firewall beziehungsweise Element sichern. Die Sophos Fusion-Hilfe dokumentiert in dieser Queue keinen Retry-, Skip- oder Cancel-Ablauf. Deshalb nicht die Bedienung der Gruppenpolicy-Queue übertragen, sondern den Auftrag im auslösenden MDR-/API-Prozess klären und den lokalen Ist-Zustand vor einer weiteren Änderung prüfen.

Sophos Fusion speichert, aber es erscheint kein Task

Zuerst sicherstellen, dass tatsächlich eine Gruppenpolicy über Manage Policy geändert und gespeichert wurde; direkte Änderungen an einer einzelnen, über Sophos Fusion geöffneten Firewall erzeugen nicht denselben Gruppenpolicy-Task. Danach den richtigen Tab, die richtige Gruppe und Show History prüfen. Bleibt der erwartete Eintrag aus, UTC-Zeitpunkt, Gruppen- und Firewall-Namen, geänderte Entity und Sophos Fusion-Administrator sichern und an Sophos Support geben. Ohne Queue-Eintrag stehen Retry und Skip nicht zur Verfügung.

Ist das Verhalten reproduzierbar, den Speichervorgang genau einmal mit einer Browser-HAR-Aufzeichnung wiederholen und den UTC-Zeitpunkt mit /log/fwcm-updaterd.log korrelieren. HAR-Dateien können Sitzungstoken und andere vertrauliche Daten enthalten: vor der Weitergabe prüfen und bereinigen. HAR, Logauszug, Zeitpunkt und betroffene Namen gehören anschliessend in ein Sophos Supportticket; wiederholtes Klonen oder Löschen von Policy-Objekten ist kein belastbarer Standardfix.

XGS 88/w: Local TLS exclusion list

Ein inzwischen aus der aktuellen Known Issues List entfernter Sophos-Eintrag zu NC-177522 dokumentierte für XGS 88/w mit SFOS 21.5 MR2 Build 323 oder 22.0 GA Build 411, dass die Bearbeitung der Local TLS exclusion list während einer Sophos Fusion-Policy-Synchronisierung mit Failed to apply a policy scheitern konnte. Als Grund wurde eine URL Group genannt, die nicht aktualisiert werden konnte; als Workaround durfte der fehlgeschlagene Task übersprungen werden, damit nachfolgende Tasks weiterliefen.

Die damalige offizielle Angabe zum Fix war widersprüchlich: Fix versions nannte SFOS 22.0 MR1 Build 490, während der Workaround-Text weiterhin einen Fix in der nächsten Maintenance Release ankündigte. Da die aktuelle Liste NC-177522 nicht mehr enthält, wird daraus keine neue Fix-Version abgeleitet. Bei exakt diesem Modell-, Build- und Fehlerbild erst die Belege sichern, die Auswirkungen von Skip verstehen und die lokale TLS-Ausnahmeliste sowie zugehörige Policies prüfen; den aktuellen Fixstand mit Sophos Support klären.

Änderung lokal abnehmen

Bei Firewall- und NAT-Regeln steuern Top und Bottom nur die Reihenfolge innerhalb der Sophos Fusion-Policy. Sophos Fusion verteilt diese Regeln an den Anfang der lokalen Regelliste. Lokale Regeln können die tatsächliche Auswertung deshalb schwerer vorhersehbar machen; Sophos empfiehlt, die Regeln zentral verwalteter Firewalls konsequent über Sophos Fusion zu erstellen.

Nach einem erfolgreichen oder korrigierten Task prüft man auf der Ziel-Firewall nicht pauschal „Sync erfolgreich“, sondern genau die geänderte Funktion:

• Ist die geänderte Regel, Policy, Liste oder das Objekt im zuständigen SFOS-Menü sichtbar?
• Zeigt der Configuration Audit bei unterstützten Objekten die erwartete Änderung? Der Audit-Nachweis ersetzt keinen Funktionstest.
• Trifft definierter Testtraffic die erwartete Firewall Rule ID und bei NAT die erwartete NAT Rule ID?
• Stimmen bei Web- oder TLS-Änderungen Testclient, Ziel-Domain sowie Web- und SSL/TLS-Inspection-Log überein?
• Funktioniert bei VPN- oder anderen Änderungen der konkrete Anwendungsfall mit der erwarteten Benutzer- und Objektzuordnung?
• Sind bei MDR-/API-Tasks die erwarteten Entities oder Indikatoren lokal vorhanden, und passt der Logeintrag zum Auftrag?

Für Traffic-Änderungen führt Firewall-Regeln mit Log Viewer, Policy Test und Packet Capture prüfen durch die lokale Abnahme. Bei umfangreichen Änderungen kann Sophos Firewall Config Studio zusätzlich Soll- und Ist-Konfiguration vergleichen. Wenn der passende Log unklar ist, hilft Sophos Firewall Troubleshooting: Services und Logs.

Für den Change-Nachweis mindestens Task-Nummer und -Status, Ziel-Firewall, lokalen Soll-/Ist-Vergleich, Testresultat und Log- oder Audit-Beleg festhalten. Erst dann gilt die Sophos Fusion-Änderung als abgenommen.