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

Le moyen le plus simple de redémarrer un service Sophos Firewall consiste à ouvrir System services > Services. Si le service n’y figure pas, il est possible d’utiliser Advanced Shell. Il faut toutefois 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

1. Ouvrir System services > Services.
2. Vérifier le service concerné et son état actuel.
3. Sous Manage, cliquer sur Restart.
4. Vérifier ensuite l’état et la fonction concernée.

WebAdmin affiche notamment Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, 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.

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 un service via Advanced Shell

Advanced Shell est utile lorsque le service n’est pas proposé dans WebAdmin ou que Sophos Support fournit une commande précise. 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

Advanced Shell offre un accès étendu au système. Effectuer d’abord des contrôles en lecture seule, puis seulement déclencher un redémarrage.

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

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é.

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. 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. Avant de redémarrer un pare-feu distant, vérifier la sauvegarde, la fenêtre de maintenance et la voie de récupération, par exemple un contact local, un accès hors bande ou un pair HA opérationnel. 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.