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

Le redémarrage de certains services Sophos Firewall peut aider lorsqu’un module ne réagit plus correctement, lorsqu’un journal ne reçoit plus de nouvelles entrées ou lorsque Sophos Support demande un redémarrage ciblé. Il ne remplace toutefois pas un dépannage propre. Un mauvais redémarrage de service peut interrompre brièvement des tunnels VPN, le routage, WebAdmin, DNS, DHCP, le reporting ou d’autres fonctions.

Cet article explique comment redémarrer des services via WebAdmin ou Advanced Shell, vérifier les journaux adaptés avant l’action et contrôler ensuite si le service fonctionne à nouveau correctement. Si le service technique correspondant à un module n’est pas clair au départ, la vue d’ensemble Sophos Firewall Troubleshooting: Services et journaux aide à l’identifier. Pour les bases de sécurité CLI, le débogage et tcpdump, consultez également Sophos Firewall CLI Troubleshooting: commandes importantes.

⚠️ Important : Les redémarrages de services doivent être planifiés dans les environnements productifs. Il faut savoir à l’avance quel service est concerné, quels utilisateurs ou tunnels peuvent être interrompus et s’il existe un accès alternatif au pare-feu.

Quand un redémarrage de service est utile

Un redémarrage ciblé de service est utile lorsqu’un module précis est concerné et que le reste du pare-feu fonctionne globalement de manière stable.

Exemples typiques :

• WebAdmin ne charge plus, mais le routage et les règles de pare-feu continuent de fonctionner.
• Un service VPN est bloqué, tandis que les autres fonctions du pare-feu ne montrent rien d’anormal.
• Un journal affiche des erreurs actuelles pour un service précis.
• Sophos Support indique un service concret à redémarrer.
• Un service ne s’est pas activé proprement après une modification de configuration.

Il n’est pas judicieux de redémarrer plusieurs services à l’aveugle simplement parce qu’un problème n’est pas encore clair. Il faut alors d’abord vérifier les journaux, la charge système, l’espace disque, l’état HA, le routage et les modules concernés.

Quand ne pas redémarrer les services

Un redémarrage de service est tentant parce qu’il agit vite. Dans certaines situations, il détériore toutefois l’analyse ou crée des interruptions supplémentaires.

• La cause est encore complètement inconnue: Le redémarrage modifie l’état et peut masquer des traces importantes dans les journaux ou les sorties de statut.
• Plusieurs services centraux tombent en panne en même temps: Le problème n’est alors souvent pas un service isolé, mais la charge système, l’espace disque, la base de données, HA ou l’état de la plateforme.
• Le pare-feu n’est plus accessible que par ce service précis: Un redémarrage peut faire perdre le dernier accès distant.
• Des services VPN, de routage ou DHCP productifs sont concernés: Des utilisateurs, sites ou leases existants peuvent être brièvement interrompus.
• Un debug est déjà en cours et l’erreur est reproductible: Sécuriser d’abord les journaux pertinents, puis redémarrer.
• Le service a déjà été redémarré plusieurs fois: Il faut alors une analyse de cause plutôt qu’une répétition.

Si un redémarrage est tout de même nécessaire, il faut au minimum noter auparavant l’heure actuelle, les utilisateurs ou sites concernés, le nom du service, le fichier journal et l’impact attendu.

Vérifier avant le redémarrage

Avant un redémarrage de service, il faut documenter brièvement ce qui est concerné. Cela fait gagner du temps si l’erreur réapparaît ou si un cas support devient nécessaire.

Pré-vérification pratique :

1. Délimiter le module concerné, par exemple WebAdmin, IPsec, DNS, DHCP, IPS ou WAF.
2. Vérifier si le pare-feu est globalement stable ou si plusieurs services tombent en panne.
3. Vérifier si des administrateurs, utilisateurs VPN ou sites critiques sont actuellement connectés.
4. Dans les clusters HA, vérifier sur quel nœud on travaille et quel nœud est actif.
5. Ouvrir le fichier journal adapté et sauvegarder les derniers messages.
6. Vérifier l’espace disque si du debug, de gros journaux ou des fichiers PCAP sont impliqués.
7. Si nécessaire, exporter les journaux avant le redémarrage.
8. Définir le critère d’arrêt : quand le redémarrage est-il stoppé, reporté ou escaladé ?

Pour les environnements HA, Comprendre les variantes de cluster HA de Sophos Firewall est également pertinent. Si des journaux sont nécessaires pour une analyse externe, consultez Sauvegarder les journaux Sophos Firewall pour support et analyse.

Conserver d’abord les preuves si l’erreur revient

Un redémarrage de service peut résoudre temporairement un symptôme, mais il peut aussi modifier l’état utile à l’analyse de cause. Si un problème revient, il faut donc conserver une petite fenêtre de preuves avant le prochain redémarrage.

Données minimales utiles :

• heure exacte avec fuseau horaire
• service concerné et fonction concernée
• derniers messages pertinents du fichier journal approprié
• sortie d’état du service avant le redémarrage
• charge système, espace disque ou indications report/base de données si la GUI est lente
• utilisateurs, tunnels, interfaces, règles ou sites concernés
• dernier changement de configuration, firmware, hotfix ou événement HA

C’est particulièrement important si le même service a déjà été redémarré plusieurs fois. Le redémarrage n’est alors qu’une mesure immédiate. Le vrai travail consiste à comprendre pourquoi le service se bloque, plante, reste en attente ou n’écrit plus de nouveaux logs.

Documenter le redémarrage dans un cas support

Si un redémarrage de service fait partie d’un cas support, d’une fenêtre de maintenance ou d’un problème récurrent, l’action doit être brièvement documentée. Il ne faut pas un long rapport. L’important est qu’il reste clair plus tard quel service a été redémarré, quand, pourquoi et avec quel résultat.

Modèle de note pratique :

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

Cette note est particulièrement utile lorsqu’une erreur revient après quelques heures ou jours. On voit alors immédiatement si le même service est toujours concerné, si le redémarrage n’aide qu’à court terme ou si un problème plus profond comme l’espace disque, l’état de la base de données, le comportement HA ou un défaut produit devient plus probable.

Redémarrer les services via WebAdmin

Certains services peuvent être redémarrés directement via WebAdmin. C’est la voie la plus simple lorsque l’interface graphique est encore accessible et que le service souhaité y est visible.

Le menu exact dépend de la version et de la vue. Le point décisif est le suivant : WebAdmin convient uniquement pour les services qui y sont réellement proposés. Pour un dépannage plus profond, l’analyse de journaux ou les services sans action GUI, il faut Advanced Shell.

Si seule l’interface WebAdmin GUI ne réagit plus, cet article général ne doit pas être la première étape. Il existe pour cela le guide ciblé Redémarrer Sophos Firewall WebAdmin GUI.

Ouvrir Advanced Shell

Pour les commandes de service, il faut Advanced Shell. L’accès se fait le plus souvent par SSH avec l’utilisateur admin.

Si SSH n’est pas encore préparé, consultez Se connecter à Sophos Firewall via SSH. L’accès SSH doit être autorisé uniquement depuis des réseaux d’administration de confiance. Avant la connexion, il faut vérifier le fingerprint SSH, surtout après un reimage, un remplacement matériel ou un changement d’IP. Le durcissement correspondant se trouve dans Device Access et Local Service ACL sur Sophos Firewall.

Après la connexion, Advanced Shell s’ouvre via :

5. Device Management > Advanced Shell

Advanced Shell donne un accès système étendu. Les commandes ne doivent y être exécutées que lorsque le service concerné et l’impact attendu sont clairs.

Si l’on veut seulement vérifier le statut ou lire un fichier journal, il faut d’abord rester sur des commandes en lecture. Les redémarrages, stop/start et debug sont des interventions et doivent être effectués dans une fenêtre d’analyse consciente.

Lister les services

La liste des services disponibles s’affiche avec :

service -S

Pour rechercher un service précis, on peut filtrer la sortie :

service -S | grep strongswan
service -S | grep zebra
service -S | grep dns

Les noms techniques des services ne sont pas toujours explicites. Avant un redémarrage, il faut donc rapprocher le nom du service du domaine fonctionnel concerné.

• strongswan: IPsec site-à-site et IPsec Remote Access; état du tunnel, pair distant, interruption planifiée, strongswan.log
• zebra: routage et routes statiques; table de routage, état SD-WAN/gateway, sites concernés
• dnsd: service DNS de la firewall; DNS Request Routes, test client, dnsd.log
• dhcpd: attribution des baux DHCP; zone concernée, plage de baux, client de test, dhcpd.log
• awed: Wireless Controller; Access Points concernés, gestion Central ou locale, journaux wireless

L’association plus détaillée se trouve dans Sophos Firewall Troubleshooting: Services et journaux.

Redémarrer un service

Le modèle de base pour un redémarrage est :

service <service>:restart -ds nosync

Exemple pour le service de routage zebra :

service zebra:restart -ds nosync

La syntaxe avec espace est importante : -ds nosync. Des variantes comme -dsnosync ne sont pas identiques et ne doivent pas être reprises depuis d’anciennes notes.

Lors d’un redémarrage, le service est arrêté puis redémarré. Selon le service, cela peut interrompre des connexions actives. Pour le routage, VPN, DNS, DHCP, Web Proxy, WAF ou Wireless, il faut donc évaluer à l’avance qui peut être concerné.

Si le service appartient à un module lié à la sécurité, il ne suffit pas de vérifier son statut après le redémarrage. Il faut surtout contrôler si la fonction de protection ou de connexion attendue fonctionne à nouveau et si de nouvelles erreurs apparaissent dans le journal.

Arrêter et démarrer un service

Si un service ne réagit pas proprement à restart ou si Sophos Support le demande ainsi, on peut exécuter stop et start séparément :

service zebra:stop -ds nosync
service zebra:start -ds nosync

Entre stop et start, il ne faut pas attendre inutilement longtemps si le service est nécessaire en production. Il faut ensuite vérifier le statut et effectuer un test fonctionnel.

Vérifier le statut du service

service zebra:status -ds nosync

Il faut aussi vérifier le fichier journal adapté. Pour le routage, ce serait par exemple :

tail -n 80 /log/zebra.log

Un statut réussi ne suffit pas toujours. Le point décisif est de savoir si la fonction concernée travaille à nouveau : les tunnels VPN se connectent, DNS répond, DHCP attribue des leases, WebAdmin charge ou le routage fonctionne.

Exemples de services fréquents

Les exemples suivants montrent des redémarrages de services typiques et ne remplacent pas l’analyse de la cause.

Redémarrer Wireless Controller

service awed:restart -ds nosync

Redémarrer SMTP Service

service smtpd:restart -ds nosync

Redémarrer VPN IPsec Service

service strongswan:restart -ds nosync

Redémarrer DNS Service

service dnsd:restart -ds nosync

En cas de problèmes IPsec, il faut aussi utiliser Sophos Firewall IPsec Troubleshooting. En cas de problèmes DNS, Configurer DNS Request Routes sur Sophos Firewall ou l’association DNS/DHCP dans Sophos Firewall Troubleshooting: Services et journaux est souvent plus pertinente qu’un simple redémarrage de service.

Traiter consciemment les domaines de services sensibles

Tous les redémarrages de services n’ont pas le même impact. Certains services ne concernent qu’une interface d’administration, d’autres se trouvent directement dans le chemin de données ou pilotent l’authentification, VPN, le routage ou des services locaux. Plus un service est proche du trafic productif, plus la fenêtre de maintenance, la vérification des journaux et le plan de retour arrière sont importants.

• IPsec / SSL VPN: Des tunnels ou sessions Remote Access peuvent tomber; Informer les utilisateurs et sites à l’avance, puis vérifier activement les tunnels
• DNS / DHCP: La résolution de noms ou l’attribution de leases peut être brièvement perturbée; Prévoir un test client et une vérification des journaux après le redémarrage
• Routing / SD-WAN: Les chemins, le gateway monitoring ou les connexions de sites peuvent être concernés; Vérifier la table de routage, le statut des passerelles et l’accessibilité
• Web Proxy / IPS / TLS Inspection: Les accès web ou l’inspection peuvent être brièvement influencés; Contrôler le Log Viewer et les policies concernées après le redémarrage
• WAF / Reverse Proxy: Les applications publiées peuvent être brièvement inaccessibles; Tester l’URL externe et l’accessibilité backend
• WebAdmin: L’accès administrateur est brièvement interrompu; Prévoir un accès alternatif par SSH ou console locale
• Reporting / Base de données / Stockage: L’analyse, les rapports ou la stabilité GUI peuvent être concernés; Ne pas redémarrer à l’aveugle, vérifier d’abord l’espace disque et les journaux

Si un domaine de service n’est pas clair, il faut d’abord consulter Sophos Firewall Troubleshooting: Services et journaux avant d’exécuter un redémarrage. Pour les sujets de base de données, stockage ou reporting, un redémarrage non ciblé est rarement la meilleure première mesure.

Valider après le redémarrage

Après un redémarrage de service, il ne faut pas seulement vérifier si la commande revient sans message d’erreur. Le test fonctionnel est important.

Contrôles utiles :

• Vérifier le statut du service avec service <service>:status -ds nosync.
• Vérifier le fichier journal adapté dans /log pour de nouvelles erreurs.
• Valider la fonction concernée avec un vrai test.
• Vérifier le Log Viewer si des règles de pare-feu, NAT, Web, IPS ou VPN sont concernés.
• Dans les clusters HA, vérifier si le nœud actif travaille toujours comme attendu.
• Désactiver le debug s’il a été activé avant ou pendant le redémarrage.
• Supprimer les autorisations SSH ou Device Access temporaires si elles ont été mises en place uniquement pour le cas support.
• En cas d’erreurs récurrentes, sauvegarder les journaux et analyser la cause au lieu de redémarrer les services à répétition.

Selon le service, un autre test fonctionnel est pertinent :

• IPsec / strongswan: statut du tunnel, Log Viewer, strongswan.log, accessibilité d’un hôte de l’autre côté
• DNS / dnsd: résolution de noms interne et externe, DNS Request Routes, dnsd.log
• Routing / zebra: table de routage, gateway monitoring, ping ou traceroute via le chemin concerné
• WAF / Reverse Proxy: tester l’URL publiée depuis l’extérieur, reverseproxy.log, accessibilité backend
• WebAdmin / tomcat et apache: vérifier login, dashboard, Log Viewer et tomcat.log
• DHCP / dhcpd: vérifier l’attribution de lease avec un client de test et dhcpd.log

Quand un reboot est préférable

Un reboot complet est plus invasif qu’un redémarrage de service, mais peut devenir pertinent lorsque plusieurs services centraux sont bloqués, que des problèmes de stockage ou de base de données ont été corrigés, que Sophos Support le demande ou que le pare-feu reste instable après des redémarrages ciblés.

La décision ne doit pas se prendre à l’instinct. Un redémarrage de service est préférable lorsqu’un module isolé est clairement concerné et que le pare-feu fonctionne sinon de manière stable. Un reboot est plutôt adapté lorsque l’état global du système est incertain ou reste dégradé après un redémarrage ciblé.

• Un service isolé est bloqué: Oui, si le service et l’impact sont clairs; Seulement si le redémarrage n’aide pas
• Plusieurs services montrent des erreurs: Vérifier d’abord les journaux et l’espace disque; Oui, si l’état global du système est instable
• Une fenêtre firmware ou hotfix est en cours: Pas comme remplacement d’un redémarrage planifié; Oui, si le processus de mise à jour le prévoit
• Le cluster HA est instable: Seulement après vérification des rôles et validation support; Seulement avec fenêtre de maintenance et plan HA
• L’espace disque ou la base de données a été nettoyé: Seulement pour le service concerné; Oui, si Sophos Support le demande comme étape finale
• L’accès distant est incertain: Prudent, le dernier accès peut tomber; Seulement avec accès local ou alternatif

Avant un reboot, la sauvegarde, la fenêtre de maintenance, l’accès au site, le comportement HA et les impacts sur VPN, RED, Wireless, le routage et les services publiés doivent être connus. Pour les sites distants, il faut en plus un chemin de retour si le pare-feu ne revient pas correctement en ligne après le redémarrage : contact local, accès out-of-band, homologue HA fonctionnel ou processus support clair.

Après le reboot, la même validation doit être effectuée qu’après un redémarrage de service, mais plus largement : statut HA, statut de licence, tunnels VPN, passerelles SD-WAN, journaux centraux, WebAdmin, connexion Central et principaux services publiés. Pour les sujets de récupération, consultez également Bien planifier sauvegarde et restauration de Sophos Firewall.

Checklist d’exploitation

• Module concerné et nom du service identifiés.
• Fichier journal adapté vérifié avant le redémarrage.
• Impacts possibles sur les utilisateurs, VPN, le routage ou les sites évalués.
• Fenêtre de maintenance ou contexte HA clarifié si nécessaire.
• Accès SSH et vérification host-key préparés proprement si Advanced Shell est nécessaire.
• Service redémarré de manière ciblée.
• Statut et fichier journal vérifiés après le redémarrage.
• Fonction validée avec un vrai test.
• Debug et accès temporaires retirés après l’analyse.
• Erreurs récurrentes documentées et non masquées par des redémarrages répétés.

FAQ