Vérifier la Firewall Task Queue dans Sophos Central

Lorsqu’une modification provenant de Sophos Central n’arrive pas sur le pare-feu, il faut d’abord ouvrir :

My Products > Firewall Management > Tasks Queue

Deux vues sont disponibles : Task Queue affiche les stratégies de groupe, tandis que Firewall Task Queue affiche les opérations MDR et API. Une tâche réussie confirme le traitement dans Central, mais pas nécessairement l’effet attendu sur le pare-feu. Le contrôle de la file d’attente doit donc toujours être suivi d’une vérification locale.

Cela vaut également pour les connexions entre sites générées automatiquement. Le processus complet de création et de validation est décrit dans Configurer et vérifier un groupe de connexions SD-WAN dans Sophos Central.

Lorsque le task provient d’une group policy partagée, Utiliser Sophos Central Firewall Groups en sécurité explique aussi Full Sync, Skip full sync, les sous-groupes et la validation locale.

Contrôle rapide d’une tâche ayant échoué

Ouvrir l’onglet approprié et développer la tâche.
Consigner le groupe ou le pare-feu concerné, le statut, l’heure, l’entité et le message d’erreur.
Pour les stratégies de groupe, vérifier l’appartenance au groupe et l’état de synchronisation du pare-feu.
Pour les tâches MDR/API, associer Credential ID, Entity et Action au système à l’origine de l’opération.
Vérifier sur le pare-feu si la modification est entièrement ou seulement partiellement présente.
Pour les modifications de configuration, consulter les Audit Trail Logs ; pour les problèmes de trafic, utiliser Log Viewer, Policy Test et Packet Capture.
Ne décider d’un Retry, d’un Skip ou de l’ouverture d’un dossier de support qu’après avoir identifié la cause.
Valider l’effet technique avec un cas de test approprié.

Cette procédure sépare deux questions : Central a-t-il traité l’opération et la modification fonctionne-t-elle réellement sur le pare-feu ?

Distinguer Task Queue et Firewall Task Queue

Task Queue pour les stratégies de groupe

Sophos Central crée une tâche lorsqu’un administrateur modifie une stratégie de groupe de pare-feu. La vue affiche Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity et Time. Status indique la progression globale et le nombre de pare-feu ayant reçu la stratégie avec succès ; lorsqu’on développe la tâche, les pare-feu concernés s’affichent.

L’horodatage indique d’abord la création ou la dernière modification de la stratégie. Il est actualisé pendant la distribution et indique finalement le moment où le dernier pare-feu a reçu la stratégie. Show History permet d’afficher les tâches terminées ou ignorées pour des pare-feu ou groupes supprimés depuis.

Sophos Central supprime les tâches qui restent Pending pendant trois semaines. Pour un dossier de support, il faut donc enregistrer à temps le numéro de tâche, le message d’erreur, les pare-feu concernés et l’heure.

Firewall Task Queue pour les opérations MDR et API

Firewall Task Queue affiche les MDR Settings et MDR IOCs déclenchés par la Firewall Configuration API. La vue d’ensemble les regroupe sous Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful et Successful.

Une tâche développée affiche le pare-feu, le statut, le Credential ID sous Modified by, l’entité, l’action et l’heure. Les actions possibles comprennent notamment Add, Update et Delete. Le Credential ID permet d’identifier le système à l’origine de l’opération.

Les différents statuts sont Pending, In Progress, Success, Failed et Partial Success. Partial Success signifie que seule une partie de l’opération a été appliquée, par exemple deux indicateurs MDR sur trois. Il faut séparer les éléments ou pare-feu ayant réussi de ceux ayant échoué, corriger la cause, relancer uniquement l’opération concernée et comparer le résultat à la configuration locale.

Pour les tâches d’IoC MDR, l’audit_ID relie la tâche Central à l’action de l’analyste et au log Active Threat Response local. Activer et vérifier les MDR Threat Feeds sur Sophos Firewall fournit la validation complète du flux, de l’action, du contexte endpoint et de l’incident.

Les mises à niveau du firmware sont planifiées et surveillées dans Sophos Central sous My Products > Firewall Management > Firewalls. Elles ne font pas partie des deux files d’attente décrites ici.

Central enregistre la modification, mais ne crée aucune tâche

Si Central confirme l’enregistrement d’une stratégie de groupe, mais qu’aucune nouvelle entrée n’apparaît dans Task Queue, Retry et Skip ne sont pas disponibles. Vérifier d’abord le groupe et la stratégie concernés, la fin de l’enregistrement, l’appartenance du firewall au groupe et les tâches Pending déjà présentes. Noter ensuite l’heure UTC ainsi que les noms du groupe, du firewall et de la stratégie, répéter l’opération exactement une fois en enregistrant un HAR du navigateur et corréler /log/fwcm-updaterd.log. Cloner ou supprimer plusieurs fois les objets de stratégie n’est pas une solution standard fiable.

Un cas de la Community concernant une Web Policy contenant des utilisateurs ou des groupes présente ce symptôme, mais ne confirme ni un build généralement affecté ni un correctif public du produit. Il s’agit donc d’un signal pour le support et non de la preuve d’un défaut général de Sophos Central. Si le comportement est reproductible, joindre le HAR, le log, l’heure UTC et les noms concernés à un ticket de support Sophos.

Utiliser Retry, Skip et Force sync en toute sécurité

Retry et Skip s’appliquent uniquement aux stratégies de groupe dans Task Queue. Sophos Central propose Retry pour Failed, Skipped et Invalid license ; Skip pour Created, Pending, Invalid license et Failed.

Retry : à utiliser uniquement après avoir corrigé la cause, par exemple une interruption de la connexion à Central, un conflit d’objets ou une attribution de licence corrigée entre-temps.
Skip : à utiliser uniquement lorsque la modification qui ne sera pas appliquée est clairement identifiée et que le contrôle ultérieur du pare-feu concerné est défini.
Attendre : lorsque la tâche est encore en cours de traitement et qu’aucun message d’erreur fiable n’est disponible.
Dossier de support : lorsque l’erreur se répète, affecte plusieurs pare-feu de production ou ne peut pas être classée avec certitude.

⚠️ Il ne faut pas ignorer une tâche ayant échoué uniquement pour vider la file d’attente. Skip est une décision opérationnelle ; la modification omise doit encore être contrôlée ou mise en œuvre séparément.

Si un pare-feu a été ajouté à un groupe avec Skip full sync, sa configuration locale peut différer de la stratégie de groupe. Son état se vérifie sous My Products > Firewall Management > Firewalls. Si Sync & Management affiche Failed to apply a policy, il faut consulter l’entrée correspondante dans Task Queue. Un Force sync applique la configuration complète du groupe et ne doit donc être déclenché que de manière délibérée. Pour une paire HA, le lien n’est disponible que sur le pare-feu actif.

Vérifier localement la stratégie Central

Pour les règles de pare-feu et NAT, Top et Bottom définissent uniquement l’ordre au sein de la stratégie Central. Les règles distribuées depuis Central sont insérées en haut de la liste locale des règles sur le pare-feu. Les règles locales peuvent donc rendre l’ordre effectif plus difficile à prévoir ; Sophos recommande de créer systématiquement les règles via Central sur les pare-feu gérés de manière centralisée.

Après la réussite d’une tâche, il faut vérifier les points suivants sur le pare-feu :

La règle, la stratégie, la liste ou l’objet modifié est-il visible ?
Audit Trail affiche-t-il la modification de configuration attendue ?
Le trafic de test correspond-il au Firewall Rule ID attendu et, pour NAT, au NAT Rule ID attendu ?
Pour les modifications Web ou TLS, le client de test, le domaine cible et les journaux Web et SSL/TLS Inspection concordent-ils ?
Pour les modifications VPN ou d’autres fonctions, le cas d’usage concret fonctionne-t-il avec l’affectation d’utilisateur ou d’objet attendue ?
Pour les tâches MDR/API, l’entité ou les indicateurs sont-ils visibles localement et le résultat correspond-il au Credential ID et à l’événement de journal attendu ?

Pour un justificatif d’acceptation concis, le statut de la tâche, le pare-feu concerné, le test local et la preuve issue des journaux ou de l’audit suffisent. Pour les modifications importantes, Sophos Firewall Config Studio peut également aider à comparer les configurations attendue et réelle. Si le journal pertinent n’est pas clair, Dépannage de Sophos Firewall : services et journaux fournit la correspondance.

Erreurs connues dépendantes de la version

La stratégie de groupe reste sur Pending

NC-181175 décrit un problème où un Group Policy Push depuis Sophos Central restait Pending et n’était pas appliqué aux pare-feu. Sophos l’a corrigé dans SFOS 22.0 MR2 Build 546. Avec une version 22.0 antérieure et une tâche qui reste durablement Pending, il faut également vérifier la version du firmware.

XGS 88/w : Local TLS exclusion list

NC-177522 affecte les XGS 88/w exécutant SFOS 21.5 MR2 Build 323 ou 22.0 GA Build 411. Lors de la synchronisation d’une stratégie Central, la modification de la Local TLS exclusion list pouvait échouer avec Failed to apply a policy, car un groupe d’URL ne pouvait pas être mis à jour.

La solution de contournement documentée consiste à ignorer la transaction ayant échoué afin de permettre la poursuite des tâches suivantes. Il faut ensuite contrôler la liste locale des exclusions TLS et les stratégies associées. La Known Issues List actuelle est contradictoire quant à l’état du correctif : sous Fix versions, elle indique SFOS 22.0 MR1 Build 490, tandis que le texte de la solution de contournement annonce toujours un correctif dans la prochaine maintenance release. Il faut donc consulter l’entrée actuelle et les release notes avant d’évaluer le problème.