Scripts Sophos Firewall sans tâche cron : alternatives sûres

Lorsqu’une commande doit être exécutée régulièrement sur une Sophos Firewall, on pense vite aux tâches cron, aux scripts de démarrage ou aux fichiers shell persistants. La documentation publique d’administration de SFOS ne décrit toutefois aucune méthode générale d’exploitation à cet effet. Le firewall est une appliance de sécurité et ne doit pas devenir un serveur d’automatisation.

Pour modifier la configuration, XML API, Sophos Central ou les fonctions natives de SFOS constituent de meilleures solutions. Les états et les erreurs doivent être surveillés par des systèmes externes via Syslog, SNMP ou sFlow. Un contournement shell local ne doit être installé sur un firewall que si Sophos le décrit publiquement pour le cas précis ou si Sophos Support ou Professional Services l’accompagne.

⚠️ Important : Une sauvegarde de configuration ne prouve pas que les fichiers, mécanismes de démarrage ou processus en arrière-plan créés manuellement sont sauvegardés et seront de nouveau présents après une restauration, un basculement HA ou une mise à niveau du firmware.

Décision rapide

Avant de choisir une solution technique, il faut déterminer clairement quelle tâche doit être automatisée. Cette classification évite qu’un petit script ne devienne discrètement un élément critique de l’exploitation du firewall.

Si un script doit régulièrement redémarrer des services, supprimer des fichiers ou réinitialiser des connexions, il ne s’agit pas d’une solution d’automatisation. Il masque probablement un dysfonctionnement. Il faut alors commencer par analyser les logs, le stockage, la version du firmware et le symptôme concret.

Pourquoi les scripts locaux posent problème

Un script shell peut être techniquement modeste tout en rendant l’exploitation difficile à maîtriser. Il se situe en dehors de la configuration WebAdmin normale, ne dispose souvent d’aucun Audit Trail et peut entrer en conflit avec d’autres fichiers, services ou autorisations après une mise à jour.

Quatre risques sont particulièrement importants :

• Sauvegarde et restauration : Sophos décrit la sauvegarde comme une sauvegarde de la configuration du firewall. Il n’existe aucune garantie générale de restauration pour les fichiers shell ou mécanismes de démarrage personnalisés.
• HA : Sophos synchronise la configuration du Primary vers l’Auxiliary. On ne peut pas en déduire que des fichiers locaux quelconques ou des processus personnalisés fonctionnent de manière identique sur les deux nodes.
• Firmware : Une mise à niveau peut modifier des chemins internes, des services ou le comportement d’exécution. Toute adaptation locale doit donc être réévaluée après chaque mise à niveau.
• Support : Sophos prend en charge les API officielles et les scripts Sophos non modifiés. Pour les intégrations développées sur mesure, Sophos renvoie vers ses partenaires ou Professional Services.

À cela s’ajoutent les secrets en clair, des volumes de logs incontrôlés, des boucles infinies et un dépannage où personne ne sait plus avec certitude si SFOS ou le contournement local est à l’origine du comportement.

Alternatives prises en charge

Utiliser une fonction native de SFOS

Il faut d’abord vérifier si SFOS accomplit déjà la tâche. Les sauvegardes planifiées, les notifications, le routage, SD-WAN, le monitoring et la journalisation centralisée doivent être configurés dans les menus prévus à cet effet. Une sauvegarde récurrente, par exemple, ne nécessite aucun script shell ; sa planification se trouve sous Backup & firmware > Backup & restore.

Pour les tâches de routage ou de trafic système, une politique correctement configurée est souvent préférable à une commande exécutée après chaque redémarrage. L’article Routage SD-WAN pour les Reply Packets et le System Traffic décrit la méthode prise en charge.

Gérer plusieurs firewalls avec Sophos Central

Lorsque plusieurs firewalls doivent recevoir la même politique, un groupe de firewalls dans Sophos Central peut être plus adapté qu’un script personnalisé. Le chemin est My Products > Firewall Management > Firewalls. Les politiques de groupe sont appliquées aux firewalls attribués ; leur état est visible sous Tasks Queue.

Les groupes Central ne sont pas une fonction de copie universelle. Les règles locales et celles gérées centralement peuvent influer sur leur ordre respectif, et chaque configuration ne peut pas être représentée dans toutes les structures de groupe. Il faut donc commencer par un groupe de test, puis contrôler la Tasks Queue ainsi que les règles effectivement appliquées.

Utiliser XML API depuis un système externe

Pour les modifications récurrentes d’objets ou de politiques, XML API est la voie programmatique prévue. L’automatisation doit s’exécuter sur un système administré où le code, les secrets, les logs, la planification et le rollback peuvent être maîtrisés.

Le firewall est préparé comme suit :

1. Sous Profiles > Device access, créer un profil administrateur disposant uniquement des droits réellement nécessaires et l’enregistrer avec Save.
2. Sous Authentication > Users, cliquer sur Add, définir User type sur Administrator, sélectionner le nouveau profil, limiter volontairement Login restriction for device access, puis enregistrer avec Save.
3. Sous Hosts and services > IP host, enregistrer le système d’automatisation sous forme d’objet hôte strictement défini.
4. Sous Administration > API access, sélectionner API access.
5. Sous Allowed IP hosts, sélectionner uniquement l’objet hôte préparé, l’ajouter avec le bouton Add, puis enregistrer avec Apply. SFOS autorise au maximum 64 entrées à cet endroit.
6. Sous Administration > Device access, vérifier que HTTPS est autorisé depuis la zone requise. Pour un accès depuis le WAN, il est préférable d’utiliser une Local service ACL exception rule restrictive plutôt que d’ouvrir globalement HTTPS pour le WAN.

API access est désactivé par défaut. Après une mise à niveau vers SFOS 22.0, les anciennes adresses IP autorisées sont converties en objets hôtes avec le préfixe apiconfig ; ces anciennes autorisations doivent être examinées lors de la prochaine révision des accès.

L’article Sécuriser l’accès à XML API de Sophos Firewall traite en détail du compte de service, du comportement MFA, du port d’administration, de Local Service ACL et de la protection des secrets. Pour préparer ou comparer des modifications de configuration, Sophos Firewall Config Studio peut également être utile.

⚠️ Une API n’est pas automatiquement sûre : Limiter l’adresse IP source, ne pas utiliser de compte Full Admin personnel, ne pas stocker de secrets dans un dépôt, un ticket ou l’historique du shell, et tester d’abord les opérations d’écriture dans un environnement de test.

Exploiter le monitoring en dehors du firewall

Un système de monitoring doit observer le firewall depuis l’extérieur. Sinon, le processus local risque précisément d’être indisponible lorsque le firewall lui-même connaît un problème. Selon l’objectif, il est possible d’utiliser le monitoring matériel par SNMP, le monitoring sFlow ou Central Firewall Reporting.

Pour l’analyse à long terme des événements et de la sécurité, un récepteur Syslog ou SIEM externe est plus adapté que des fichiers de logs locaux supplémentaires. Les données restent ainsi disponibles même lorsque le firewall redémarre, tombe en panne ou est remplacé.

Quand un contournement local peut être acceptable

Certains cas de support ou déploiements cloud nécessitent un contournement strictement limité. Le critère déterminant n’est pas que la commande fonctionne techniquement, mais qu’il existe pour ce scénario précis une procédure Sophos actuelle ou une instruction de support confirmée.

Avant la mise en œuvre, la version, la plateforme, le mode HA et la méthode de retour arrière doivent correspondre à la procédure. Un script provenant d’un ancien article de la communauté, d’un autre modèle d’appliance ou d’une version antérieure de SFOS ne constitue pas une autorisation fiable pour son propre environnement.

Si seule une approche développée en interne existe, elle doit d’abord être examinée avec le partenaire Sophos ou Professional Services. Une procédure générique pour intégrer ses propres scripts de démarrage serait ici plus dangereuse qu’utile.

Remplacer un script existant en toute sécurité

Il ne faut pas supprimer immédiatement un script existant. Il faut d’abord rendre visible la dépendance de l’exploitation à son égard.

1. Geler les modifications : Ne plus modifier temporairement le script, le mécanisme de démarrage ni le firewall concerné.
2. Documenter l’objectif : Consigner le symptôme, le déclencheur, le résultat attendu, le chemin, l’utilisateur, la planification, les secrets et la personne responsable.
3. Observer les effets : Relever les logs, l’état du processus, les fichiers créés ainsi que les routes, services ou interfaces affectés. En HA, vérifier séparément les deux nodes.
4. Choisir la solution cible : Associer la fonction à un réglage natif de SFOS, à Central, à XML API ou à un monitoring externe.
5. Tester le remplacement : Tester le nouveau processus en dehors du firewall de production et consigner le succès, les erreurs et le rollback.
6. Effectuer la migration de manière contrôlée : Pendant une fenêtre de maintenance, activer le remplacement, désactiver le script local et effectuer le test fonctionnel métier.
7. Planifier un contrôle ultérieur : Vérifier de nouveau après un redémarrage, un basculement et la prochaine mise à niveau du firmware, dans la mesure où ces événements sont pertinents pour la fonction.

Une sauvegarde actuelle est indispensable avant le changement. Créer ou restaurer une sauvegarde Sophos Firewall explique Secure Storage Master Key, la restauration et la compatibilité. La sauvegarde protège la configuration documentée, mais ne remplace pas un inventaire distinct des adaptations locales.

Validation et rollback

Une réponse API réussie ou un processus en cours d’exécution ne prouve pas encore que la tâche métier est accomplie. Après la migration, il faut tester exactement le résultat dont dépendait auparavant le script : règle présente, route active, sauvegarde créée, cible accessible ou alerte reçue dans le monitoring.

Pour les modifications via l’API, il faut également contrôler Audit Trail et les objets concernés. Lorsque le trafic est affecté, Log Viewer, Rule ID, NAT Rule ID, Policy Test ou Packet Capture doivent faire partie de la validation. Les modifications Central sont contrôlées dans Tasks Queue, puis directement sur un firewall concerné.

Le rollback ne consiste pas à réactiver précipitamment l’ancien script. Il faut d’abord annuler la nouvelle modification et restaurer l’état initial documenté. L’ancien contournement ne peut être réactivé pour une durée limitée que s’il a été délibérément vérifié comme solution de repli.

Recommandation d’exploitation

Les scripts locaux doivent apparaître dans la documentation d’exploitation comme des exceptions temporaires, et non comme des fonctions normales du firewall. Chaque exception nécessite un responsable, une date de révision, une procédure de retrait testée et une indication claire des versions de Sophos couvertes.

Pour les nouveaux besoins, l’ordre de priorité est le suivant : fonction native de SFOS, Sophos Central, automatisation externe via XML API, monitoring externe, puis seulement un cas particulier confirmé par Sophos. Les modifications restent ainsi traçables, la HA et la restauration sont plus prévisibles, et le firewall reste plus proche de l’état produit pris en charge.

FAQ