Redémarrer les services Sophos Firewall en sécurité

Le moyen le plus sûr de redémarrer un service Sophos Firewall consiste à ouvrir System services > Services. Si le service n’y figure pas, ce n’est pas une raison pour exécuter une commande shell quelconque : Advanced Shell ne doit être utilisé qu’avec une instruction Sophos actuelle et spécifique au service ou dans le cadre d’un dossier de support. Il faut d’abord identifier le service concerné et déterminer quelles connexions son redémarrage pourrait interrompre.

⚠️ Important : Le redémarrage d’un service modifie l’état du système et peut interrompre le VPN, le routage, DNS, DHCP, les accès web ou l’accès administrateur. Sauvegarder au préalable l’état et les journaux, et prévoir un autre moyen d’accès pour les sites distants.

Redémarrer un service via WebAdmin

Avant de cliquer, consigner l’état actuel, l’heure exacte de l’erreur et le test fonctionnel qui échoue. Les fichiers pertinents peuvent être téléchargés séparément sous Diagnostics > Tools > Troubleshooting logs. Pour un dossier de support, un Consolidated troubleshooting report (CTR) contient également l’état du système, les processus et l’utilisation des ressources. Pour un site distant, la vérification préalable doit aussi couvrir la fenêtre de maintenance et un accès de secours.

1. Ouvrir System services > Services.
2. Vérifier le service concerné et son état actuel. Ne pas démarrer un service volontairement arrêté ou non configuré.
3. Sous Manage, cliquer sur Restart.
4. Attendre que le service retrouve son état précédent Running, puis tester la fonction concernée.

WebAdmin affiche notamment Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot et Packet capture and Live connections. Si un service n’est pas configuré, son bouton reste grisé. Anti-spam nécessite une règle antispam entrante ou sortante. L’arrêt de Packet capture and Live connections met fin aux captures en cours et rend la vue Live Connections indisponible. Si Packet Capture ne démarre pas alors que son commutateur est activé, Sophos indique précisément ce redémarrage via WebAdmin comme étape de récupération.

Le redémarrage d’un service ne dispose d’aucun rollback permettant de restaurer les sessions actives. L’état à préserver est donc celui consigné au préalable. Si un service qui fonctionnait ne revient pas à Running, ne pas cliquer plusieurs fois sur Restart : relever un nouvel horodatage, télécharger le journal ou le CTR, puis analyser l’échec ou faire appel à Sophos Support.

Sous Control Center > System, l’état des services indique si un service est arrêté ou n’a pas pu démarrer. C’est un bon point de départ, mais il ne remplace pas un test fonctionnel. Si seule l’interface WebAdmin ne répond plus, suivre la procédure ciblée Redémarrer l’interface WebAdmin de Sophos Firewall.

Service antivirus arrêté après l’échec des mises à jour de patterns

Si le service Antivirus reste arrêté après l’échec des mises à jour de patterns SAVI et AVIRA, ne pas cliquer plusieurs fois sur Restart. Sauvegarder d’abord la version et le build du firmware, l’heure de l’erreur ainsi que les fichiers avd.log et up2date_av.log correspondants. Sous Backup & firmware > Pattern updates, relever également la dernière mise à jour réussie et l’état actuel : Ready to install, Downloading, Success ou Failed. La procédure générale de vérification de ces états figure dans Configurer et vérifier les patterns de Sophos Firewall.

Sophos répertorie ce problème sous NC-180066 ; il est corrigé dans SFOS 22.0 MR2 Build 546. Si les symptômes correspondent sur un build SFOS 22 antérieur, vérifier le chemin pris en charge à l’aide du guide de préparation de la mise à jour du firmware, puis passer d’abord à MR2 Build 546 ou à une version ultérieure approuvée. Un redémarrage unique sous System services > Services est généralement possible, mais Sophos ne le documente ni comme contournement ni comme correctif pour NC-180066, et il ne remplace pas la mise à jour du firmware.

Après la mise à jour du firmware seulement, cliquer sur Update pattern now sous Backup & firmware > Pattern updates. La mise à jour du pattern Antivirus concerné doit atteindre l’état Success et le service Antivirus doit rester actif. L’état affiché du service ne suffit pas : la mise à jour du pattern doit elle aussi se terminer correctement. Si le problème réapparaît sous MR2 Build 546 ou une version ultérieure, transmettre les journaux et les heures enregistrées à Sophos Support au lieu de continuer à supposer qu’il s’agit de NC-180066.

Redémarrer IPsec via VPN Management

Le menu principal de la CLI permet de redémarrer de manière prise en charge le daemon du service VPN sous 6. VPN Management > Restart VPN Service. Sophos précise que cette opération coupe tous les tunnels VPN. Si une seule connexion VPN doit être rétablie, utiliser plutôt son action dans WebAdmin. Avant le redémarrage du daemon, enregistrer l’état des tunnels, l’heure exacte et strongswan.log ; vérifier ensuite les Child SAs, les peers et le trafic applicatif réel. Le redémarrage ne corrige pas une erreur de proposal, de routing ou de NAT.

Le même menu permet de régénérer la paire de clés RSA utilisée pour l’authentification IPsec. Il ne s’agit pas d’un redémarrage du service, mais d’un changement de clés. Pour les connexions utilisant RSA key, les peers ont ensuite besoin de la nouvelle clé publique ; les utilisateurs d’accès distant doivent télécharger à nouveau leur configuration VPN. Sophos ne documente aucun retour en un clic vers l’ancienne paire de clés. Cette action doit donc faire partie d’une rotation planifiée avec inventaire complet des tunnels, fenêtre de maintenance et accès administrateur alternatif, jamais du troubleshooting général. Elle ne corrige pas non plus les problèmes de PSK ou de certificat.

Redémarrer un service via Advanced Shell

N’utiliser Advanced Shell que si une instruction Sophos actuelle indique le service et la commande exacts ou si Sophos Support les fournit. Pour l’accès SSH et la vérification de la clé d’hôte, suivre Se connecter à Sophos Firewall via SSH. SSH ne doit être autorisé que depuis des réseaux d’administration de confiance ; les paramètres correspondants sont décrits dans Device Access et Local Service ACL. Les sessions SSH inactives sont fermées après 15 minutes.

Après la connexion, ouvrir :

5. Device Management > 3. Advanced Shell

La Device Console, sous l’option 4 du menu, valide ses commandes documentées et sert aux diagnostics réseau et système pris en charge. En revanche, Advanced Shell, sous 5. Device Management > 3. Advanced Shell, est un shell Linux donnant un accès complet aux bases de données et aux services système. Les modifications de configuration qui y sont effectuées ne sont pas persistantes et ne figurent pas dans les sauvegardes. Effectuer d’abord des contrôles en lecture seule et ne redémarrer qu’après avoir vérifié le nom du service, l’impact, la fenêtre de maintenance et l’accès de récupération.

1. Vérifier le nom et l’état du service

Pour afficher les services connus et leur état actuel :

service -S

La sortie peut être filtrée selon le service suspecté. Pour IPsec, par exemple :

service -S | grep -i strongswan

RUNNING signifie que le service fonctionne. STOPPED, UNREGISTERED ou UNTOUCHED ne signalent pas automatiquement une panne : selon le firmware et la configuration, un service peut volontairement être inactif ou non enregistré. Vérifier d’abord si la fonction, la règle ou la licence correspondante est réellement utilisée.

Si le nom technique du service n’est pas clair, consulter Dépannage de Sophos Firewall : services et journaux. Cet article associe les domaines fonctionnels à leurs fichiers journaux.

2. Vérifier les journaux avant l’intervention

Un redémarrage peut masquer des indices importants sur la cause. Pour IPsec, lire d’abord strongswan.log et sauvegarder les messages pertinents :

less /log/strongswan.log

Appuyer sur q pour quitter less. Pour une analyse plus vaste, exporter auparavant les journaux comme décrit dans Sauvegarder les journaux Sophos Firewall pour le support et l’analyse. Dans un cluster HA, chaque nœud ne conserve que les journaux du trafic qu’il traite ; il peut être nécessaire de vérifier les deux nœuds séparément.

3. Redémarrer le service sur un pare-feu autonome

L’exemple suivant suppose un pare-feu autonome. Avant l’exécution, service -S | grep -i strongswan doit confirmer le service. Le redémarrage peut interrompre les connexions IPsec site à site et d’accès distant. Vérifier auparavant les tunnels, les pairs distants et la fenêtre de maintenance.

Sophos documente le modèle suivant :

service <service>:restart -ds nosync

Exemple complet pour le service IPsec :

service strongswan:restart -ds nosync

La syntaxe générique et service -S sont documentés dans l’aide SFOS 22 actuelle, où strongswan est associé au service IPsec. Cet exemple n’a pas été exécuté sur un pare-feu et n’est donc pas présenté comme testé en laboratoire. Ne jamais deviner le nom d’un autre service à partir d’une liste.

Pour poursuivre l’analyse, consulter Dépannage IPsec sur Sophos Firewall.

⚠️ Cluster HA : Ne pas reprendre la commande du pare-feu autonome sans vérification. Selon le service et la situation, les instructions Sophos utilisent sync ou nosync ; la documentation publique ne fournit pas de règle générale suffisante. Le service, le nœud, le build SFOS et le mode de synchronisation doivent provenir d’une instruction Sophos actuelle et spécifique au service ou d’un dossier de support.

Les commandes stop et start séparées ne doivent être utilisées que sur instruction de Sophos Support pour le service concerné. Entre les deux commandes, le service reste entièrement arrêté.

Ce redémarrage n’offre pas non plus de rollback préservant l’état : les Security Associations et les sessions interrompues ne peuvent pas être restaurées. Le critère d’arrêt sûr est la comparaison avec la vérification préalable. Si strongswan ne retrouve pas son état précédent ou si les tunnels ne se rétablissent pas, ne pas lancer un second redémarrage. Sauvegarder les journaux et le CTR, puis escalader le problème.

4. Valider le résultat

Après le redémarrage, vérifier l’état, le journal et la fonction réelle :

service -S | grep -i strongswan
tail -f /log/strongswan.log
grep -i 'error' /log/strongswan.log

tail -f affiche en continu les nouveaux messages et s’arrête avec Ctrl+C. Comparer les messages avec l’heure relevée avant le redémarrage ; un grep non filtré peut aussi afficher d’anciennes erreurs. Vérifier ensuite les tunnels IPsec et tester un hôte sur le site distant. L’état RUNNING ne prouve pas à lui seul que la connexion fonctionne de nouveau.

Si le redémarrage échoue, vérifier également csc.log. Pour les problèmes HA, ha.log, msync.log et applog.log peuvent aussi être utiles selon les symptômes.

Services courants et tests fonctionnels adaptés

Le nom exact du service doit être confirmé sur le pare-feu concerné avec service -S. Les principales correspondances sont les suivantes :

• strongswan : IPsec site à site et accès distant. Vérifier ensuite l’état des tunnels, strongswan.log et l’accessibilité du site distant.
• dnsd : Service DNS. Tester ensuite la résolution de noms interne et externe, dnsd.log et les éventuelles DNS Request Routes.
• dhcpd : Serveur DHCP. Pendant un redémarrage, les nouveaux clients ou ceux qui renouvellent leur bail peuvent ne pas recevoir de réponse. Tester ensuite l’attribution des baux et dhcpd.log.
• awed : Communication entre le pare-feu et les équipements AP/APX. Vérifier ensuite l’état de connexion des points d’accès et awed.log.
• zebra : Installe les routes dynamiques et statiques dans le noyau. Son redémarrage est donc invasif et ne doit être effectué qu’avec une instruction Sophos précise ; tester ensuite la table de routage, les passerelles et les chemins réels.
• smtpd : Proxy SMTP en mode MTA. Le proxy transparent hérité utilise un autre service ; vérifier le mode de fonctionnement et les journaux smtpd_* avant toute intervention. Tester ensuite l’envoi et la réception contrôlés d’e-mails.

Pour WAF, Web proxy, IPS, Authentication et les services disponibles dans WebAdmin, le redémarrage sous System services > Services est généralement plus clair qu’une commande shell.

Quand un redémarrage de service n’est pas approprié

Le redémarrage d’un service convient lorsqu’un module précis est concerné et que le reste du pare-feu est stable. Ne pas redémarrer aveuglément lorsque :

• la cause ou le service concerné n’est pas encore clair ;
• plusieurs services centraux tombent en panne simultanément ;
• ce service fournit le dernier accès distant disponible ;
• l’erreur est reproductible et les journaux n’ont pas encore été sauvegardés ;
• le même service a déjà été redémarré plusieurs fois ;
• le rôle HA, le nœud ou le mode de synchronisation requis n’est pas clair.

Si plusieurs services sont concernés, vérifier d’abord la charge système, l’espace de stockage, l’état de la base de données, HA et les dernières modifications de configuration ou de firmware. Les redémarrages répétés ne font souvent que masquer la cause.

Un redémarrage complet est plus invasif et ne doit être envisagé que si le pare-feu reste globalement instable, si un processus de firmware ou de hotfix l’exige ou si Sophos Support le demande. Dans la Device Console, system restart redémarre le pare-feu ; dans un cluster HA, la commande provoque un failover. system shutdown, en revanche, l’arrête uniquement. Avant l’une ou l’autre action, vérifier l’équipement et le nœud HA ciblés, la sauvegarde, la fenêtre de maintenance ainsi que l’accès local ou hors bande ; pour un arrêt, ce moyen de récupération doit réellement permettre de remettre l’équipement sous tension. Après un redémarrage, contrôler le rôle et la synchronisation HA, l’état des services et les chemins de données concernés. Les sessions interrompues ne peuvent pas être restaurées. Si l’équipement ne revient pas en ligne, ne pas répéter la commande : utiliser l’accès de récupération préparé et solliciter Sophos Support si nécessaire. Voir Planifier correctement la sauvegarde et la restauration de Sophos Firewall.

Documenter brièvement l’intervention

Pour un problème récurrent ou un dossier de support, une courte note suffit. Elle permet de déterminer ultérieurement si le redémarrage a apporté une solution durable ou a seulement masqué un symptôme :

Date/time and time zone:
Firewall / HA node:
Service and command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Avant l’intervention, consigner l’heure, la fonction concernée et les messages de journal pertinents. Ensuite, noter l’état du service, le test fonctionnel et l’action suivante. Supprimer les autorisations SSH ou Device Access temporaires et désactiver les modes de débogage après l’analyse.