Sophos Central Vérifier la file d'attente des tâches de gestion du pare-feu

Si une modification a été enregistrée dans le Sophos Central mais n’arrive pas sur le Sophos Firewall, le pare-feu local n’est pas toujours la première source d’erreur. Pour les pare-feu gérés de manière centralisée, vous devez également vérifier la File d’attente des tâches dans Sophos Central. Vous pouvez y voir si Central a encore traité une stratégie de groupe, une tâche de pare-feu basée sur une API ou une autre modification centrale, l’a partiellement appliquée, l’a ignorée ou l’a terminée avec une erreur.

Ceci est particulièrement important lorsque plusieurs pare-feu sont gérés dans un groupe. Un seul échec de tâche peut retarder les modifications ultérieures ou perturber le dépannage, car la configuration sur Sophos Central est différente de celle du pare-feu concerné.

La Task Queue ne remplace donc pas les journaux, Packet Capture ou la vérification locale. Elle répond d’abord à la question de transport: Sophos Central a-t-il accepté, traité et appliqué la tâche au firewall ou au groupe concerné? Ce n’est qu’ensuite que l’analyse réelle du firewall a du sens.

Quand la file d’attente des tâches est pertinente

La file d’attente des tâches est pertinente dès lors que les modifications ne sont pas effectuées directement localement sur le firewall, mais via Sophos Central. Cela affecte particulièrement les environnements dans lesquels les pare-feu sont connectés à Sophos Central et dans lesquels la gestion centrale du pare-feu est activement utilisée.

Situations typiques :

• une stratégie de groupe a été modifiée en Sophos Central
• un changement est arrivé sur certains firewalls, mais pas sur d’autres
• une mise à jour du firmware a été programmée ou démarrée via Sophos Central
• Les tâches de pare-feu MDR ou basées sur l’API ne semblent pas entièrement mises en œuvre
• une tâche est sur Pending ou In Progress depuis longtemps
• une tâche est Failed, Skipped, Invalid license ou n’est que partiellement réussie
• après une erreur, les modifications ultérieures ne sont pas traitées comme prévu

Le pare-feu Log Viewer reste important pour le dépannage local en direct. Mais la file d’attente des tâches répond à une autre question : Sophos Central a-t-il réussi à transmettre la modification au pare-feu ?

Où trouver la file d’attente des tâches

Le chemin Sophos Central est :

My Products > Firewall Management > Tasks Queue

Sophos distingue deux onglets. Cette séparation est importante pour ne pas mélanger les politiques de groupe et les tâches API/MDR.

• Task Queue: statut des politiques de groupe firewall appliquées aux firewalls via Sophos Central.
• Firewall Task Queue: tâches firewall provenant de MDR Settings, MDR IOCs et Firewall Configuration API. La vue regroupe les tâches notamment par Pending, In Progress, Failed, Partial Successful et Successful.

Pour les problèmes classiques de Central Firewall Management, la Task Queue est généralement le premier point à consulter. La Firewall Task Queue devient plus importante lorsque les changements ont été déclenchés via Firewall Configuration API ou des fonctions firewall liées à MDR.

Dans la vue de la file d’attente des tâches, l’historique est également important. Utilisez Show History pour afficher les tâches terminées ou ignorées pour les pare-feu ou les groupes qui ont depuis été supprimés. Pour les révisions de modifications ou les cas de support, vous devez toujours documenter rapidement les détails des tâches pertinentes, car les tâches Pending ne restent pas en permanence dans l’interface après une longue période.

Quelles informations sont importantes

Une seule tâche n’est utile que si elle est correctement organisée. Avant d’effectuer une modification ou un Retry, vous devez noter au moins ces champs :

• Numéro de tâche
• groupe ou pare-feu concerné
• Statut
• le timing
• Administrateur ou ID d’identification
• Entité et sous-entité
• message d’erreur affiché
• Nombre de pare-feu réussis et échoués

Le timing n’est pas toujours synonyme de début de traitement sur chaque pare-feu. Pour les stratégies de groupe, Sophos Central affiche d’abord l’heure de création ou de modification, puis la met à jour lorsque la stratégie est appliquée aux pare-feu. C’est pourquoi vous ne devriez pas vous contenter de chercher dès la première fois des déploiements plus longs.

La source de la tâche est importante pour le dépannage. Un nom d’utilisateur est plus susceptible d’indiquer un changement dans le portail Sophos Central. Un identifiant d’identification indique une commande liée à l’API ou à MDR. Dans ce cas, vous devez également vérifier quel système ou processus a déclenché le changement.

Pour les politiques de groupe, la vue du groupe compte aussi: le firewall se trouve-t-il réellement dans le groupe ou sous-groupe attendu, une politique a-t-elle été héritée, ou le firewall a-t-il été ajouté avec Skip full sync? Un full sync ignoré peut être voulu, mais il peut facilement créer un écart entre Central et le firewall local.

Si un firewall a été ajouté volontairement avec Skip full sync, il ne faut pas partir aveuglément d’une base de groupe propre. Dans Sophos Central, un Force sync peut être déclenché via le statut de synchronisation du firewall. Pour les paires HA, cette synchronisation complète doit être lancée sur le firewall actif, car Sophos n’affiche pas le lien pour les firewalls passifs.

Interpréter correctement le statut

• Pending: La tâche est toujours en attente de traitement. Si la durée est plus longue, vérifiez la connectivité, la licence et la connexion centrale.
• In Progress: Central est toujours en train de traiter la tâche. Ne démarrez pas plusieurs corrections en parallèle si la tâche est en cours d’exécution.
• Success: Central signale que la tâche est réussie. Ensuite, validez toujours sur le pare-feu si l’effet attendu est visible.
• Partial Success: Certaines ont été appliquées, d’autres non. Ceci est particulièrement important pour les groupes ou plusieurs objets.
• Failed: La modification n’a pas été effectuée avec succès. Documentez le message d’erreur et le pare-feu concerné.
• Skipped: La tâche a été délibérément ignorée. Une inspection de suivi professionnelle est alors requise.
• Invalid license: La licence ou l’autorisation ne correspond pas à l’action prévue. Ne pas essayer de résoudre le problème en répétant Retry.

Sophos Central peut supprimer automatiquement les tâches avec le statut Pending après trois semaines. Les erreurs pertinentes doivent donc être sauvegardées rapidement pour la documentation opérationnelle, les dossiers de support ou les revues de modifications.

Success signifie uniquement que Sophos Central a traité la commande avec succès. Cela ne prouve pas automatiquement que le trafic souhaité fonctionne, qu’une règle correspond réellement ou qu’un utilisateur peut à nouveau travailler. Pour des changements productifs, trois niveaux sont toujours requis : vérifier la tâche centrale, vérifier la configuration du pare-feu local et tester l’effet technique.

La politique Central n’est pas automatiquement la vérité locale

Pour les règles firewall et NAT gérées via Sophos Central, il existe une différence opérationnelle importante: la position Top ou Bottom décrit d’abord l’ordre au sein de la politique Central. Sur le firewall, les règles poussées depuis Central sont insérées en haut de la liste locale. Si des règles locales existent également, l’ordre effectif peut être différent de ce que l’on attend dans l’éditeur Central.

Avanet recommande donc de prendre une décision opérationnelle claire pour les firewalls gérés centralement: soit gérer les règles de manière cohérente via Sophos Central, soit documenter consciemment les exceptions locales et les vérifier après chaque changement Central. Le mode mixte fonctionne techniquement, mais il est plus sujet aux erreurs, car Task Queue, Rule ID locale, NAT Rule ID locale et Audit Trail doivent être lus ensemble.

Pour le dépannage, cela signifie qu’une tâche Central réussie indique seulement que la politique a été distribuée. Il faut vérifier localement dans le jeu de règles, puis dans Log Viewer, si la règle agit au bon endroit.

Processus de test propre

Lorsqu’un changement Central est bloqué, une procédure calme aide davantage que des clics répétés sur Retry.

1. Ouvrir dans Sophos Central My Products > Firewall Management > Tasks Queue.
2. Limiter la période et le firewall ou groupe de firewalls concerné.
3. Déplier la tâche et vérifier les firewalls concernés.
4. Documenter le statut, le message d’erreur, l’entity, le sub-entity et l’heure.
5. Pour les firewalls ou groupes supprimés, activer Show History si nécessaire.
6. Pour les politiques de groupe, vérifier si le firewall se trouve dans le bon groupe ou sous-groupe.
7. En cas de suspicion d’écart de groupe, vérifier le statut de synchronisation et décider consciemment si Force sync est pertinent.
8. Sur le firewall, vérifier si le changement est visible ou seulement enregistré dans Central.
9. Pour les règles firewall ou NAT, contrôler la position locale, la Rule ID et la NAT Rule ID.
10. Pour les changements de configuration, vérifier aussi les Audit Trail Logs.
11. Pour les problèmes de trafic, analyser Log Viewer, Policy Test et les journaux de service pertinents.
12. Décider seulement ensuite si Retry, Skip ou un cas de support est pertinent.

Si le journal local pertinent n’est pas clair, Sophos Firewall troubleshooting: services et logs aide à s’orienter. Pour l’analyse des règles et du trafic, tester les règles firewall avec Log Viewer, Policy Test et Packet Capture est également utile.

Partial Success traité proprement

Partial Success est plus dangereux qu’une erreur évidente car une partie de l’environnement a déjà été modifiée. Avec les stratégies de groupe, vous devez donc d’abord ouvrir et déconnecter les pare-feu concernés :

• Pare-feu avec application réussie
• Pare-feu avec erreurs
• Pare-feu hors ligne, ingérables ou bloqués par licence
• Pare-feu avec différentes versions ou plateformes SFOS

Par la suite, vous ne devez pas réappliquer immédiatement la même modification à l’ensemble du groupe. Il est préférable d’effectuer une correction ciblée sur le pare-feu ou le groupe concerné, puis un Retry vérifié et enfin une comparaison de la configuration du pare-feu local. Pour les modifications plus importantes, Sophos Firewall Utiliser Config Studio permet de comparer les configurations attendues et réelles de manière compréhensible.

Skip ou Retry ?

Sophos Central propose des promotions Skip et Retry selon le statut. Les deux sont utiles, mais ne doivent pas être considérés comme un pur nettoyage.

• Retry: la cause a été résolue, par exemple connexion, licence, conflit d’objets ou panne centrale temporaire Est-il clair pourquoi la tâche a échoué ?
• Skip: une tâche ayant échoué ou n’étant plus pertinente bloque les tâches ultérieures et l’impact technique est compris Est-ce délibérément ne pas appliquer un changement de politique prévu ?
• Attendez: la tâche est en cours d’exécution ou Central traite de nombreux pare-feu Y a-t-il des preuves d’un véritable blocage ou simplement d’un décalage normal ?
• Cas d’assistance: l’erreur se produit de manière répétée, affecte plusieurs pare-feu productifs ou le message n’est pas clair Les détails de la tâche, l’heure, le nom du pare-feu et les journaux sont-ils sécurisés ?

⚠️ Ne sautez pas une tâche ayant échoué juste pour que la file d’attente paraisse propre. Skip est une décision opérationnelle : le changement qui n’est pas appliqué doit alors être consciemment vérifié ou mis en œuvre séparément.

Avant un Retry, vous devez au moins vérifier si le pare-feu du Sophos Central est en ligne, si Gérer à partir du Sophos Central est toujours actif, si la licence et la version du micrologiciel correspondent à l’action planifiée et si le pare-feu local ne rejette pas la tâche en raison de différences d’objet, de politique ou de plate-forme. Un Retry répété sans vérification de la cause profonde ne produit que de nouvelles entrées, mais rarement de la clarté.

Modèles d’erreur typiques

Le changement est visible dans Central mais pas sur le pare-feu

Dans ce cas, vérifiez d’abord si la tâche appropriée a été exécutée avec succès. Si la tâche est toujours Pending, In Progress, Failed ou Partial Success, le problème ne vient pas nécessairement de la règle de pare-feu locale. Ce n’est que lorsque Central signale que la tâche est réussie que vous devez approfondir l’analyse de la politique locale, des objets ou des journaux.

Si la tâche réussit mais que le pare-feu local semble différent, vous devez vérifier si le pare-feu est réellement membre du groupe attendu, si une modification locale rend l’interprétation difficile et si vous travaillez dans le bon pare-feu ou dans le bon client. Ce contrôle banal est étonnamment précieux, surtout lorsqu’il existe plusieurs comptes Sophos Central ou transferts de comptes.

La règle agit autrement que prévu après Success

Pour les règles firewall et NAT, il ne suffit pas de vérifier après une tâche réussie que la règle existe. Il faut surtout savoir si elle se trouve, dans l’ordre local, avant ou après les règles existantes pertinentes. Central peut avoir poussé correctement la politique alors qu’une règle locale spéciale, une règle Central plus ancienne ou une règle NAT modifie tout de même le matching attendu.

La vérification pratique est courte: générer du trafic de test, filtrer dans Log Viewer par source, destination et service, puis comparer la Firewall Rule ID et la NAT Rule ID réelles avec la règle attendue. Si ces ID ne correspondent pas, la tâche Central n’est pas le vrai problème; c’est l’ordre local des règles ou du NAT.

Seuls les pare-feu individuels d’un groupe sont concernés

Avec la stratégie de groupe, une modification peut réussir sur plusieurs pare-feu et échouer sur un pare-feu. Ensuite, vous ne devez pas modifier l’ensemble du groupe, mais plutôt ouvrir le pare-feu concerné et vérifier les différences : licence, version du firmware, connexion centrale, conflits d’objets locaux, plate-forme et problèmes connus.

La tâche du micrologiciel via Central ne démarre pas correctement

Si une Mise à jour du micrologiciel Sophos Firewall a été planifiée via Sophos Central, la file d’attente des tâches doit faire partie du suivi. Si le pare-feu reste sur l’ancienne version, vérifiez d’abord si Central a déclenché et terminé la tâche. Pour les versions majeures, la SFOS 22 Upgrade Check fait également partie de la préparation.

La synchronisation des politiques Web ou TLS échoue

Pour la protection Web, les groupes d’URL ou les exclusions TLS, une synchronisation Central peut être particulièrement déroutante car Central a accepté une modification mais le pare-feu ne la traite pas entièrement. Ensuite, vous devez comparer l’entité affectée de la file d’attente des tâches avec la configuration locale. Pour la classification technique, Sophos Firewall Insérer correctement TLS Inspection et Sophos Firewall Créer une politique de protection Web conviennent.

XGS 88/w et liste d’exclusion TLS locale

Un problème spécifique avec les modèles XGS 88/w est documenté dans la liste des problèmes connus : lors de la synchronisation d’une stratégie Sophos Central, le traitement de la liste d’exclusion TLS locale peut échouer. Le message d’erreur affiché concerne un groupe d’URL qui n’a pas pu être mis à jour. Dans ce cas, vous pouvez ignorer la transaction ayant échoué de la file d’attente des tâches afin que les tâches ultérieures continuent de s’exécuter.

Dans la pratique, cependant, il ne faut pas passer à autre chose après coup. Un contrôle de suivi est important :

• L’exception TLS souhaitée est-elle présente localement sur le pare-feu ?
• Les politiques web et TLS sur le pare-feu sont-elles toujours techniquement correctes ?
• Le problème concerne-t-il uniquement un XGS 88/w ou plusieurs pare-feu ?
• Le changement doit-il être mis en œuvre temporairement localement ou reporté ?
• Existe-t-il une version de maintenance ou un avis Sophos pour la version concernée ?

Contrôle de suivi sur le pare-feu

Une tâche centrale réussie est un bon signal, mais ne constitue pas un test opérationnel complet. En fonction du changement, vous devrez vérifier localement :

• La règle, la politique, la liste ou la version du micrologiciel modifiée sont-elles visibles ?
• Le Log Viewer affiche-t-il les événements attendus ?
• Le changement a-t-il été enregistré dans la piste d’audit ?
• La connexion centrale et le reporting sont-ils toujours actifs ?
• Les utilisateurs concernés, les VPN, l’accès Web ou les applications fonctionnent-ils ?

Pour les modifications liées à la sécurité, vous devez également définir un court point de restauration. Cela est particulièrement vrai pour la protection Web, TLS Inspection, les règles de pare-feu, les clusters VPN, HA et les mises à jour du micrologiciel.

Valider Success avec un cas de test

Un Success dans la Task Queue doit toujours être associé à un cas de test adapté. Sinon, on sait seulement que Central a traité la tâche, mais pas si la fonction concernée fonctionne réellement.

Validation pratique :

• Règle firewall modifiée : générer un trafic de test avec source, destination, service et Rule ID attendu.
• NAT ou DNAT modifié : tester l’accès externe ou interne et vérifier la Firewall Rule ID ainsi que la NAT Rule ID dans Log Viewer.
• Politique Web ou TLS modifiée : comparer le client de test, le domaine cible, le journal Web et le journal SSL/TLS-inspection.
• Modification VPN ou Remote Access : vérifier la connexion, l’IP du pool, l’accès interne et l’association utilisateur.
• Tâche firmware ou backup : contrôler la version, l’état de démarrage, le rôle HA, la connexion Central et l’heure du dernier backup.
• Tâche MDR, ATR ou API : documenter la Credential ID, le système déclencheur, la visibilité locale et l’événement de journal attendu.

Pour les revues de changement, une preuve courte suffit : statut de la tâche, firewall concerné, test local, preuve dans les logs ou l’audit et point ouvert. Cela évite qu’une tâche Central réussie soit interprétée plus tard comme une validation technique complète.

Liste de contrôle opérationnel

• Avant d’apporter des modifications via Sophos Central, précisez quels pare-feu ou groupes sont concernés.
• Vérifiez la file d’attente des tâches après les modifications centrales.
• Documentez les tâches ayant échoué avec le message d’erreur, l’heure et le nom du pare-feu.
• Ne considérez pas Partial Success comme complet.
• Pour les pare-feu ou les groupes supprimés, cochez Show History.
• N’utilisez le Retry qu’après avoir vérifié la cause.
• N’utilisez le Skip que si l’impact technique est compris.
• Success validé avec un test local et une preuve dans les logs ou l’audit.
• Pour les tâches API ou MDR, attribuez un identifiant d’identification et un système de déclenchement.
• Planifiez les fenêtres de maintenance, la sauvegarde et l’accès local pour les tâches du firmware.
• En cas d’erreurs répétées, sauvegardez les informations d’Audit Trail, Log Viewer et Sophos Support.

FAQ