Kontrollera Firewall Task Queue i Sophos Central

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

My Products > Firewall Management > Tasks Queue

Det finns två vyer: Task Queue visar gruppolicyer och Firewall Task Queue visar MDR- och API-operationer. En lyckad uppgift bekräftar bearbetningen i Central, men inte automatiskt den avsedda effekten på brandväggen. Därför ska granskningen av kön alltid följas av en lokal kontroll.

Detta gäller även automatiskt genererade anslutningar mellan platser. Hela processen för skapande och verifiering beskrivs i Konfigurera och verifiera en SD-WAN-anslutningsgrupp i Sophos Central.

Om tasken kommer från en gemensam gruppolicy förklarar Använd Sophos Central Firewall Groups säkert även Full Sync, Skip full sync, undergrupper och lokal validering.

Snabbkontroll av en misslyckad uppgift

1. Öppna rätt flik och expandera uppgiften.
2. Dokumentera berörd grupp eller brandvägg, status, tidpunkt, entitet och felmeddelande.
3. Kontrollera brandväggens gruppmedlemskap och synkroniseringsstatus för gruppolicyer.
4. Koppla Credential ID, Entity och Action till det initierande systemet för MDR/API-uppgifter.
5. Kontrollera på brandväggen om ändringen finns fullständigt eller endast delvis.
6. Kontrollera Audit Trail Logs vid konfigurationsändringar; använd Log Viewer, Policy Test och Packet Capture vid trafikproblem.
7. Besluta om Retry, Skip eller ett supportärende först när orsaken är klarlagd.
8. Verifiera den tekniska effekten med ett lämpligt testfall.

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

Skillnaden mellan Task Queue och Firewall Task Queue

Task Queue för gruppolicyer

Sophos Central skapar en uppgift när en administratör ändrar en brandväggsgruppolicy. Vyn visar Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity och Time. Status visar det totala förloppet och hur många brandväggar som har tagit emot policyn; när uppgiften expanderas visas de berörda brandväggarna.

Tidsstämpeln visar först när policyn skapades eller senast ändrades. Den uppdateras under distributionen och visar slutligen när den sista brandväggen tog emot policyn. Med Show History kan man visa slutförda eller överhoppade uppgifter för brandväggar eller grupper som senare har tagits bort.

Sophos Central tar bort uppgifter som står kvar som Pending i tre veckor. Inför ett supportärende bör man därför spara uppgiftsnummer, felmeddelande, berörda brandväggar och tidpunkt i god tid.

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

Firewall Task Queue visar MDR Settings och MDR IOCs som har 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. Möjliga åtgärder är exempelvis Add, Update och Delete. Credential ID hjälper till att identifiera vilket system som initierade operationen.

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, exempelvis två av tre MDR-indikatorer. Separera lyckade och misslyckade element eller brandväggar, åtgärda orsaken, kör endast den berörda operationen igen och jämför resultatet med den lokala konfigurationen.

För MDR-IoC-uppgifter kopplar audit_ID Central-uppgiften till analytikerns åtgärd och den lokala Active Threat Response-loggen. Aktivera och verifiera MDR Threat Feeds på Sophos Firewall ger fullständig verifiering av feed, åtgärd, endpointkontext och incident.

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

Central sparar ändringen men skapar ingen uppgift

Om Central bekräftar att en gruppolicy har sparats men ingen ny post visas i Task Queue är Retry och Skip inte tillgängliga. Kontrollera först rätt grupp och policy, att sparandet slutfördes, brandväggens gruppmedlemskap och befintliga Pending-uppgifter. Dokumentera därefter UTC-tid och namnen på grupp, brandvägg och policy, upprepa åtgärden exakt en gång samtidigt som en HAR-fil registreras i webbläsaren och korrelera /log/fwcm-updaterd.log. Att upprepade gånger klona eller ta bort policyobjekt är ingen tillförlitlig standardlösning.

Ett Community-fall med en Web Policy som innehåller användare eller grupper visar detta symptom, men bekräftar varken en allmänt berörd build eller en offentlig produktfix. Behandla därför uppgiften som en supportsignal och inte som bevis för ett generellt Sophos Central-fel. Om beteendet kan reproduceras ska HAR, logg, UTC-tid och berörda namn bifogas i ett Sophos-supportärende.

Använda Retry, Skip och Force sync säkert

Retry och Skip gäller endast för gruppolicyer i Task Queue. Sophos Central erbjuder Retry för Failed, Skipped och Invalid license; Skip för Created, Pending, Invalid license och Failed.

• Retry: använd först när orsaken har åtgärdats, exempelvis en avbruten Central-anslutning, en objektkonflikt eller en licenstilldelning som har korrigerats.
• Skip: använd endast när det är tydligt vilken ändring som inte kommer att tillämpas och hur den berörda brandväggen ska kontrolleras efteråt.
• Vänta: när uppgiften fortfarande bearbetas och det inte finns något tillförlitligt felmeddelande.
• Supportärende: när felet återkommer, påverkar flera produktionsbrandväggar eller inte kan klassificeras med säkerhet.

⚠️ Hoppa inte över en misslyckad uppgift enbart för att tömma kön. Skip är ett driftbeslut; den utelämnade ändringen måste fortfarande kontrolleras eller genomföras separat.

Om en brandvägg har lagts till i en grupp med Skip full sync kan den lokala konfigurationen skilja sig från gruppolicyn. Kontrollera statusen under My Products > Firewall Management > Firewalls. Om Sync & Management visar Failed to apply a policy kontrollerar man motsvarande post i Task Queue. En Force sync tillämpar hela gruppkonfigurationen och bör därför endast startas medvetet. För ett HA-par är länken endast tillgänglig på den aktiva brandväggen.

Kontrollera Central-policyn lokalt

För brandväggs- och NAT-regler styr Top och Bottom endast ordningen inom Central-policyn. Regler som distribueras från Central infogas högst upp i brandväggens lokala regellista. Lokala regler kan därför göra den faktiska ordningen svårare att förutsäga; Sophos rekommenderar att regler på centralt hanterade brandväggar konsekvent skapas via Central.

Kontrollera följande på brandväggen efter en lyckad uppgift:

• Syns den ändrade regeln, policyn, listan eller objektet?
• Visar Audit Trail den förväntade konfigurationsändringen?
• Matchar testtrafiken 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 Web- eller TLS-ändringar?
• Fungerar det konkreta användningsfallet med förväntad användar- eller objekttilldelning vid VPN- eller andra funktionsändringar?
• Är entiteten eller indikatorerna synliga lokalt för MDR/API-uppgifter, och stämmer resultatet överens med Credential ID och förväntad logghändelse?

För ett kort verifieringsunderlag räcker uppgiftsstatus, berörd brandvägg, lokalt test och logg- eller revisionsbevis. Vid omfattande ändringar kan Sophos Firewall Config Studio dessutom hjälpa till att jämföra förväntad och faktisk konfiguration. Om det är oklart vilken logg som är relevant finns mappningen i Felsökning av Sophos Firewall: tjänster och loggar.

Kända versionsberoende fel

Gruppolicyn står kvar som Pending

NC-181175 beskriver ett fel där en Group Policy Push från Sophos Central stod kvar som Pending och inte tillämpades på brandväggar. Sophos åtgärdade felet i SFOS 22.0 MR2 Build 546. På en tidigare 22.0-version med en uppgift som står kvar som Pending bör man därför även kontrollera firmwareversionen.

XGS 88/w: Local TLS exclusion list

NC-177522 påverkar XGS 88/w med SFOS 21.5 MR2 Build 323 eller 22.0 GA Build 411. Under synkronisering av en Central-policy kunde redigering av Local TLS exclusion list misslyckas med Failed to apply a policy eftersom en URL-grupp inte kunde uppdateras.

Den dokumenterade lösningen är att hoppa över den misslyckade transaktionen så att efterföljande uppgifter kan fortsätta. Därefter måste den lokala TLS-undantagslistan och tillhörande policyer kontrolleras. Den aktuella Known Issues List är motsägelsefull om statusen för korrigeringen: under Fix versions anger den SFOS 22.0 MR1 Build 490, medan texten om lösningen fortfarande anger att en korrigering kommer i nästa maintenance release. Kontrollera därför den aktuella posten och release notes innan problemet bedöms.