Kontrollera Firewall Task Queue i Sophos Fusion (tidigare Sophos Central)

Om en ändring från Sophos Fusion inte når brandväggen öppnar man först:

My Products > Firewall Management > Tasks Queue

Sidan har två separata vyer: Task Queue för brandväggsgruppolicyer och Firewall Task Queue för MDR- och API-operationer. En lyckad uppgift bekräftar att operationen har bearbetats, men inte att den fick avsedd effekt på brandväggen. Därför hör kögranskning och lokal verifiering alltid ihop.

Om uppgiften kommer från en gemensam gruppolicy förklarar Använd Sophos Fusion Firewall Groups säkert även Full Sync, Skip full sync, undergrupper och förberedelse av återställningsvägen. Automatiskt genererade platsanslutningar verifieras enligt Konfigurera och verifiera en SD-WAN-anslutningsgrupp i Sophos Fusion.

Kontrollera en misslyckad uppgift säkert

1. Öppna rätt flik och expandera uppgiften.
2. Dokumentera uppgiftsnummer, grupp eller brandvägg, Status, Modified by, Entity, Sub-entity, Time och det synliga felmeddelandet.
3. Fastställ om det är en gruppolicy eller en MDR/API-operation. De tillgängliga åtgärderna skiljer sig.
4. Kontrollera gruppmedlemskap och Sync & Management under My Products > Firewall Management > Firewalls för en gruppolicy.
5. Koppla Credential ID, Entity och Action till det system eller den API-klient som initierade en MDR/API-uppgift.
6. Fastställ på brandväggen om ändringen saknas, är fullständig eller endast delvis finns på plats.
7. Besluta om Retry, Skip, en korrigerande ändring eller ett supportärende först när orsaken är klarlagd.
8. Verifiera den tekniska effekten med ett definierat positivt test och, när det kan göras säkert, ett negativt test.

Processen skiljer mellan två frågor: Har Sophos Fusion bearbetat operationen och fungerar ändringen faktiskt på brandväggen?

Skilj på Task Queue och Firewall Task Queue

Task Queue för gruppolicyer

Sophos Fusion skapar automatiskt en uppgift när en administratör ändrar en brandväggsgruppolicy. Vyn visar Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity och Time. Den övergripande statusen innehåller även antalet brandväggar där policyn har tillämpats korrekt. Expandera uppgiften för att se varje målbrandvägg.

Tidsstämpeln visar först när policyn skapades eller uppdaterades, inte nödvändigtvis när distributionen började. Den uppdateras under tillämpningen och visar slutligen när den sista brandväggen tog emot policyn. Show History visar slutförda eller överhoppade uppgifter för brandväggar eller grupper som senare har tagits bort.

Sophos Fusion tar bort uppgifter som står kvar som Pending i tre veckor. Spara därför uppgiftsnummer, fel, målbrandväggar och tidpunkt tidigt om en eskalering kan behövas.

Firewall Task Queue för MDR- och API-operationer

Firewall Task Queue visar MDR Settings och MDR IOCs som initierats via Firewall Configuration API. Översikten grupperar dem under Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful och Successful.

En expanderad uppgift visar brandvägg, status, Credential ID under Modified by, entitet, åtgärd och tidpunkt. Sophos anger Add, Update och Delete som exempel på åtgärder. Credential ID identifierar de API-autentiseringsuppgifter som användes för operationen; det är inte en administratörsvisning som för en gruppolicy.

De enskilda statusvärdena är Pending, In Progress, Success, Failed och Partial Success. Partial Success innebär att endast en del av operationen tillämpades. Sophos ger exemplet tre MDR Threat Feed-indikatorer där två lyckades och en misslyckades. Dokumentera inte detta som en övergripande framgång: registrera lyckade och misslyckade element eller brandväggar separat och jämför det lokala tillståndet.

För MDR IOC-operationer kopplar audit_ID Sophos Fusion-uppgiften till analytikerns åtgärd och den lokala Active Threat Response-loggen. Aktivera och verifiera MDR Threat Feeds på Sophos Firewall beskriver den fullständiga verifieringen.

Firmwareuppgraderingar schemaläggs och övervakas i stället under My Products > Firewall Management > Firewalls. De ingår inte i de två kövyer som beskrivs här.

Begränsa Retry, Skip och Force sync

Den aktuella Sophos Fusion-hjälpen för Tasks Queue dokumenterar Retry och Skip för misslyckade gruppolicyuppgifter. Den dokumenterar inte motsvarande åtgärder för Firewall Task Queue.

• Retry: använd först när den synliga orsaken har åtgärdats och det har bekräftats att samma gruppändring fortfarande önskas. Kontrollera därefter den nya statusen per brandvägg och verifiera lokalt igen.
• Skip: använd endast när det är känt vilken gruppändring som utelämnas. Skip ersätter inte lokal kontroll eller en senare korrigerande ändring.
• Vänta: vid Pending eller In Progress, så länge bearbetningen rimligen går framåt och inget fel visas. Spara underlaget före treveckorsgränsen för borttagning.
• Supportärende: när felet fortfarande kan reproduceras, påverkar flera produktionsbrandväggar eller det synliga meddelandet inte medger en säker korrigering.

⚠️ Hoppa inte över en uppgift enbart för att tömma kön. Den utelämnade ändringen förblir olöst och måste uttryckligen accepteras, korrigeras eller genomföras separat.

Köhjälpen dokumenterar ingen åtgärd Cancel eller Rollback. Skip återställer inte en redan distribuerad gruppändring; det gör inte heller borttagning av brandväggen från gruppen. För att återgå till tidigare tillstånd korrigerar man medvetet gruppolicyn, följer den nya uppgiften och verifierar det tidigare definierade måltillståndet lokalt igen.

Force sync är inte heller ett Retry. Om en brandvägg har lagts till med Skip full sync kan den lokala konfigurationen skilja sig från gruppolicyn. Öppna dess status i Sync & Management under My Products > Firewall Management > Firewalls; Force sync tillämpar sedan alla gruppkonfigurationer. Skillnader och avsett måltillstånd måste vara kända först. För ett HA-par är länken endast tillgänglig för den aktiva brandväggen.

Avgränsa vanliga symptom

Gruppolicyn står kvar som Pending

Kontrollera först om uppgiftens tidsstämpel fortfarande ändras och vilka brandväggar som saknas i den expanderade uppgiften. Kontrollera sedan gruppmedlemskap och Sync & Management under My Products > Firewall Management > Firewalls. På den berörda brandväggen måste System > Sophos Fusion visa hanteringsstatusen Managed. Om operationen inte går framåt sparar man underlaget före automatisk borttagning och eskalerar med uppgiftsnummer, tidpunkt och berörda brandväggar.

Kontrollera även firmwareversionen för äldre SFOS 22.0-installationer. NC-181175 i de officiella versionskommentarerna för SFOS 22.0 beskriver en Group Policy Push som stod kvar som Pending i Sophos Fusion och inte tillämpades. Sophos anger problemet som löst i SFOS 22.0 MR2 Build 546. Posten förklarar inte varje Pending-uppgift; kontrollera status och målbrandväggar först.

Gruppolicyn misslyckas

Expandera uppgiften och registrera berörd brandvägg, Entity och Sub-entity. Lägg inte flera ändringar i kö samtidigt. Om orsaken kan korrigeras använder man Retry för den misslyckade gruppolicyuppgiften och verifierar sedan lokalt. Om det uttryckligen har accepterats att ändringen utelämnas dokumenterar man Skip; eskalera annars med felmeddelandet.

Firewall Task Queue visar Partial Success eller Failed

Registrera Credential ID, Entity, Action, tidpunkt och resultat per brandvägg eller element. Sophos Fusion-hjälpen dokumenterar inget Retry-, Skip- eller Cancel-flöde för denna kö. Överför inte kontroller från gruppolicykön: utred operationen i den initierande MDR/API-processen och kontrollera det aktuella lokala tillståndet före en ny ändring.

Sophos Fusion sparar, men ingen uppgift visas

Kontrollera först att en faktisk gruppolicy ändrades och sparades via Manage Policy. Direkta ändringar av en enskild brandvägg som öppnats via Sophos Fusion skapar inte samma gruppolicyuppgift. Kontrollera sedan rätt flik, rätt grupp och Show History. Om den förväntade posten fortfarande saknas sparar man UTC-tid, grupp- och brandväggsnamn, ändrad Entity och Sophos Fusion-administratör för Sophos Support. Retry och Skip är inte tillgängliga utan en köpost.

Om beteendet kan reproduceras upprepar man sparandet exakt en gång medan webbläsaren registrerar en HAR-fil och korrelerar UTC-tiden med /log/fwcm-updaterd.log. HAR-filer kan innehålla sessionstoken och andra konfidentiella uppgifter: granska och rensa dem före delning. Bifoga HAR-filen, loggutdraget, tidpunkten och berörda namn i ett Sophos-supportärende; att upprepade gånger klona eller ta bort policyobjekt är ingen tillförlitlig standardlösning.

XGS 88/w: Local TLS exclusion list

En Sophos-post om NC-177522, som sedan dess har tagits bort från den aktuella Known Issues List, dokumenterade att redigering av Local TLS exclusion list under synkronisering av Sophos Fusion-policy kunde misslyckas med Failed to apply a policy på XGS 88/w med SFOS 21.5 MR2 Build 323 eller 22.0 GA Build 411. En URL Group kunde inte uppdateras, och posten tillät Skip av den misslyckade uppgiften så att efterföljande uppgifter kunde fortsätta.

Den officiella informationen om korrigeringen var då motsägelsefull: Fix versions angav SFOS 22.0 MR1 Build 490, medan texten om lösningen fortfarande utlovade en korrigering i nästa maintenance release. Eftersom den aktuella listan inte längre innehåller NC-177522 ska ingen annan korrigeringsversion härledas. För exakt denna kombination av modell, build och fel ska underlaget sparas först, följderna av Skip förstås och den lokala TLS-undantagslistan samt tillhörande policyer kontrolleras; bekräfta aktuell korrigeringsstatus med Sophos Support.

Verifiera ändringen lokalt

För brandväggs- och NAT-regler styr Top och Bottom endast ordningen inom Sophos Fusion-policyn. Sophos Fusion placerar dessa regler högst upp i den lokala regellistan. Lokala regler kan därför göra den faktiska utvärderingen svårare att förutsäga; Sophos rekommenderar att regler på centralt hanterade brandväggar konsekvent skapas via Sophos Fusion.

Efter en lyckad eller korrigerad uppgift ska man inte godkänna ett allmänt resultat som ”sync successful”. Kontrollera exakt den ändrade funktionen på målbrandväggen:

• Syns den ändrade regeln, policyn, listan eller objektet i relevant SFOS-meny?
• Visar Configuration Audit den förväntade ändringen för objekt som stöds? Revisionsbevis ersätter inte ett funktionstest.
• Matchar definierad testtrafik förväntat Firewall Rule ID och, för NAT, förväntat NAT Rule ID?
• Stämmer testklient, måldomän samt Web- och SSL/TLS Inspection-loggar överens vid webb- eller TLS-ändringar?
• Fungerar det specifika användningsfallet med förväntade användar- och objekttilldelningar vid VPN- eller andra ändringar?
• Finns förväntade entiteter eller indikatorer lokalt för MDR/API-uppgifter och motsvarar logghändelsen operationen?

För trafikändringar ger Testa brandväggsregler med Log Viewer, Policy Test och Packet Capture arbetsflödet för lokal verifiering. Vid omfattande ändringar kan Sophos Firewall Config Studio dessutom jämföra avsedd och faktisk konfiguration. Om det är oklart vilken logg som är relevant, se Felsökning av Sophos Firewall: tjänster och loggar.

Spara minst uppgiftsnummer och status, målbrandvägg, lokal jämförelse av avsett och faktiskt tillstånd, testresultat samt logg- eller revisionsbevis i ändringsunderlaget. Först då är Sophos Fusion-ändringen verifierad.