Vérifier la Firewall Task Queue dans Sophos Fusion

Lorsqu’une modification provenant de Sophos Fusion (anciennement Sophos Central) n’arrive pas sur le pare-feu, ouvrir d’abord :

My Products > Firewall Management > Tasks Queue

Cette page propose deux vues distinctes : Task Queue pour les stratégies de groupe de pare-feu et Firewall Task Queue pour les opérations MDR et API. Une tâche réussie confirme le traitement de l’opération, mais pas son effet attendu sur le pare-feu. Le contrôle de la file et la validation locale vont donc toujours de pair.

Si la tâche provient d’une stratégie de groupe partagée, Utiliser Sophos Fusion Firewall Groups en toute sécurité explique aussi Full Sync, Skip full sync, les sous-groupes et la préparation du retour arrière. Les connexions de sites générées automatiquement sont validées dans Configurer et vérifier un groupe de connexions SD-WAN dans Sophos Fusion.

Contrôler en sécurité une tâche ayant échoué

1. Ouvrir l’onglet approprié et développer la tâche.
2. Consigner le numéro de tâche, le groupe ou le pare-feu, Status, Modified by, Entity, Sub-entity, Time et le message d’erreur visible.
3. Déterminer s’il s’agit d’une stratégie de groupe ou d’une opération MDR/API. Les actions disponibles diffèrent.
4. Pour une stratégie de groupe, vérifier l’appartenance au groupe et Sync & Management sous My Products > Firewall Management > Firewalls.
5. Pour une tâche MDR/API, associer Credential ID, Entity et Action au système ou au client API à l’origine de l’opération.
6. Sur le pare-feu, déterminer si la modification est absente, complète ou seulement partielle.
7. Ne choisir Retry, Skip, une modification corrective ou un dossier de support qu’après avoir identifié la cause.
8. Valider l’effet technique avec un test positif défini et, si cela ne présente pas de risque, un test négatif.

Cette procédure sépare deux questions : Sophos Fusion 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 Fusion crée automatiquement 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. Le statut global indique aussi le nombre de pare-feu sur lesquels la stratégie a été appliquée correctement. Développer la tâche permet de voir chaque pare-feu cible.

L’horodatage indique d’abord quand la stratégie a été créée ou actualisée, pas nécessairement le début de sa distribution. Il est mis à jour pendant l’application et indique finalement quand le dernier pare-feu l’a reçue. Show History affiche les tâches terminées ou ignorées pour des pare-feu ou des groupes supprimés depuis.

Sophos Fusion supprime les tâches qui restent Pending pendant trois semaines. Si une escalade peut être nécessaire, conserver suffisamment tôt le numéro de tâche, l’erreur, les pare-feu cibles et l’heure.

Firewall Task Queue pour les opérations MDR et API

La Firewall Task Queue affiche les MDR Settings et MDR IOCs lancé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. Sophos cite Add, Update et Delete comme exemples d’actions. Le Credential ID identifie les identifiants API utilisés pour l’opération ; il ne représente pas un administrateur comme pour une stratégie de groupe.

Les statuts individuels sont Pending, In Progress, Success, Failed et Partial Success. Partial Success signifie qu’une partie seulement de l’opération a été appliquée. Sophos donne l’exemple de trois indicateurs MDR Threat Feed, dont deux ont réussi et un a échoué. Ne pas consigner ce résultat comme une réussite globale : documenter séparément les éléments ou pare-feu réussis et échoués, puis comparer l’état local.

Pour les opérations MDR IOC, l’audit_ID relie la tâche Sophos Fusion à l’action de l’analyste et au journal Active Threat Response local. Activer et vérifier les MDR Threat Feeds sur Sophos Firewall décrit la validation complète.

Les mises à niveau du firmware sont, quant à elles, planifiées et surveillées sous My Products > Firewall Management > Firewalls. Elles ne font pas partie des deux vues décrites ici.

Encadrer Retry, Skip et Force sync

L’aide Sophos Fusion actuelle sur Tasks Queue documente Retry et Skip pour les tâches de stratégie de groupe ayant échoué. Elle ne documente pas d’actions équivalentes pour Firewall Task Queue.

• Retry : l’utiliser seulement après avoir corrigé la cause visible et confirmé que la même modification de groupe est toujours souhaitée. Contrôler ensuite le nouveau statut pour chaque pare-feu et valider de nouveau localement.
• Skip : l’utiliser seulement lorsque la modification de groupe omise est connue. Skip ne remplace ni le contrôle local ni une modification corrective ultérieure.
• Attendre : pour Pending ou In Progress, tant que le traitement progresse de façon plausible et qu’aucune erreur n’apparaît. Conserver les preuves avant le délai de suppression de trois semaines.
• Dossier de support : lorsque l’échec reste reproductible, affecte plusieurs pare-feu de production ou que le message visible ne permet aucune correction sûre.

⚠️ Ne pas ignorer une tâche uniquement pour vider la file. La modification omise reste non résolue et doit être explicitement acceptée, corrigée ou mise en œuvre séparément.

L’aide de la file ne documente aucune action Cancel ou Rollback. Skip n’annule pas une modification de groupe déjà distribuée, pas plus que le retrait d’un pare-feu de son groupe. Pour revenir à l’état précédent, corriger délibérément la stratégie de groupe, suivre la nouvelle tâche et valider de nouveau localement l’état cible défini auparavant.

Force sync n’est pas non plus un Retry. Si un pare-feu a été ajouté avec Skip full sync, sa configuration locale peut différer de la stratégie de groupe. Sous My Products > Firewall Management > Firewalls, ouvrir son statut dans Sync & Management ; Force sync applique alors toutes les configurations du groupe. Il faut d’abord connaître les différences et l’état cible voulu. Pour une paire HA, le lien n’est disponible que pour le pare-feu actif.

Identifier les symptômes courants

La stratégie de groupe reste sur Pending

Vérifier d’abord si l’horodatage de la tâche continue à changer et quels pare-feu manquent dans la tâche développée. Contrôler ensuite l’appartenance au groupe et Sync & Management sous My Products > Firewall Management > Firewalls. Sur le pare-feu concerné, System > Sophos Fusion doit afficher le statut de gestion Managed. Si l’opération ne progresse plus, conserver les preuves avant sa suppression automatique et escalader avec le numéro de tâche, l’heure et les pare-feu concernés.

Pour les anciennes installations SFOS 22.0, vérifier aussi la version du firmware. NC-181175 dans les notes de version officielles SFOS 22.0 décrit un Group Policy Push qui restait Pending dans Sophos Fusion et n’était pas appliqué. Sophos le répertorie parmi les problèmes résolus dans SFOS 22.0 MR2 Build 546. Cet élément n’explique pas chaque tâche Pending : contrôler d’abord le statut et les pare-feu cibles.

La stratégie de groupe échoue

Développer la tâche et noter le pare-feu concerné, Entity et Sub-entity. Ne pas ajouter plusieurs modifications simultanément. Si la cause peut être corrigée, utiliser Retry pour cette tâche de stratégie de groupe ayant échoué, puis valider localement. Si l’omission de la modification est expressément acceptée, documenter Skip ; sinon, escalader avec le message d’erreur.

Firewall Task Queue affiche Partial Success ou Failed

Consigner le Credential ID, Entity, Action, l’heure et les résultats pour chaque pare-feu ou élément. L’aide Sophos Fusion ne documente aucun processus Retry, Skip ou Cancel pour cette file. Ne pas transposer les commandes de la file des stratégies de groupe : analyser l’opération dans le processus MDR/API d’origine et contrôler l’état local actuel avant toute nouvelle modification.

Sophos Fusion enregistre, mais aucune tâche n’apparaît

Vérifier d’abord qu’une véritable stratégie de groupe a été modifiée et enregistrée avec Manage Policy. Une modification directe sur un pare-feu individuel ouvert depuis Sophos Fusion ne crée pas la même tâche de stratégie de groupe. Contrôler ensuite le bon onglet, le bon groupe et Show History. Si l’entrée attendue reste absente, conserver l’heure UTC, les noms du groupe et du pare-feu, l’Entity modifiée et l’administrateur Sophos Fusion pour Sophos Support. Retry et Skip ne sont pas disponibles sans entrée dans la file.

Si le comportement est reproductible, répéter l’enregistrement une seule fois en capturant un fichier HAR dans le navigateur et corréler son heure UTC avec /log/fwcm-updaterd.log. Un fichier HAR peut contenir des jetons de session et d’autres données confidentielles : le contrôler et l’assainir avant tout partage. Joindre le HAR, l’extrait du journal, l’heure et les noms concernés à un dossier Sophos Support ; cloner ou supprimer plusieurs fois les objets de stratégie n’est pas une solution standard fiable.

XGS 88/w : Local TLS exclusion list

Une entrée Sophos relative à NC-177522, retirée depuis de la Known Issues List actuelle, indiquait que la modification de Local TLS exclusion list pendant la synchronisation d’une stratégie Sophos Fusion pouvait échouer avec Failed to apply a policy sur les XGS 88/w exécutant SFOS 21.5 MR2 Build 323 ou 22.0 GA Build 411. Elle mentionnait un groupe d’URL impossible à actualiser et autorisait l’utilisation de Skip pour que les tâches suivantes puissent continuer.

Les informations officielles sur le correctif étaient alors contradictoires : Fix versions indiquait SFOS 22.0 MR1 Build 490, tandis que le texte du contournement annonçait toujours un correctif dans la prochaine maintenance release. Comme la liste actuelle ne contient plus NC-177522, aucune autre version corrective ne doit en être déduite. Pour ce modèle, cette build et cette erreur précise, conserver d’abord les preuves, comprendre l’effet de Skip et contrôler la liste locale d’exclusions TLS ainsi que les stratégies associées ; confirmer l’état actuel du correctif auprès de Sophos Support.

Valider localement la modification

Pour les règles de pare-feu et NAT, Top et Bottom contrôlent uniquement l’ordre dans la stratégie Sophos Fusion. Sophos Fusion place ces règles en haut de la liste locale. Les règles locales peuvent donc rendre l’évaluation effective plus difficile à prévoir ; Sophos recommande de créer systématiquement les règles via Sophos Fusion sur les pare-feu gérés de manière centralisée.

Après une tâche réussie ou corrigée, ne pas accepter un simple résultat « sync successful ». Contrôler précisément la fonction modifiée sur le pare-feu cible :

• La règle, la stratégie, la liste ou l’objet modifié est-il visible dans le menu SFOS correspondant ?
• Pour les objets pris en charge, Configuration Audit montre-t-il la modification attendue ? La preuve d’audit ne remplace pas un test fonctionnel.
• Le trafic de test défini 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 de destination et les journaux Web et SSL/TLS Inspection concordent-ils ?
• Pour une modification VPN ou autre, le cas d’usage précis fonctionne-t-il avec les affectations d’utilisateurs et d’objets attendues ?
• Pour les tâches MDR/API, les entités ou indicateurs attendus sont-ils présents localement et l’événement du journal correspond-il à l’opération ?

Pour les changements de trafic, Tester les règles de pare-feu avec Log Viewer, Policy Test et Packet Capture fournit la procédure de validation locale. Pour des modifications importantes, Sophos Firewall Config Studio peut aussi comparer les configurations prévue et réelle. Si le journal pertinent n’est pas clair, consulter Dépannage de Sophos Firewall : services et journaux.

Pour le dossier de changement, conserver au minimum le numéro et le statut de la tâche, le pare-feu cible, la comparaison locale prévu/réel, le résultat du test et la preuve issue du journal ou de l’audit. La modification Sophos Fusion n’est validée qu’après ces contrôles.