Vérifier correctement les alertes Missing Heartbeat sur Sophos Firewall

Une alerte Missing Heartbeat ne signifie pas automatiquement qu’un malware est présent. Sophos Firewall signale ainsi qu’un terminal précédemment détecté continue de générer du trafic réseau, mais n’envoie plus le Security Heartbeat correspondant. La cause peut être un dysfonctionnement de Sophos Endpoint, mais aussi un passage du LAN au WLAN, une mise en veille ou un réveil, une conception DNS incorrecte ou un chemin réseau inadapté.

Une bonne analyse ne commence donc pas par la désactivation de Security Heartbeat. Il faut d’abord vérifier si le pare-feu doit effectivement surveiller l’appareil, quel trafic déclenche le statut et si le terminal, le pare-feu et Sophos Fusion (anciennement Sophos Central) constatent le même état.

Vérification rapide

1. Si deux terminaux différents utilisent la même station d’accueil ou interface USB, vérifiez d’abord la version du firmware. SFOS 22.0 MR2 Build 546 corrige NC-176012 pour ce scénario. Sur un build SFOS 22 antérieur, effectuez la mise à jour avant de modifier les temporisateurs ou les stratégies.
2. Sous System > Sophos Fusion > Optional configurations, vérifiez que la zone figure volontairement dans Missing heartbeat zones.
3. Contrôlez les conditions Heartbeat dans la règle de pare-feu qui s’applique réellement, puis comparez dans Sophos Fusion le statut et les événements du même terminal.
4. Dans le Log Viewer, corrélez la Rule ID, l’adresse IP source et le statut No Heartbeat avec les changements d’adaptateur, le DNS, le VPN ou les cycles de veille et de réveil.
5. Ne modifiez un temporisateur que pour un problème de transition reproductible et après avoir mis à jour le firmware.

Comment se produit un statut Missing Heartbeat

Lors de sa première connexion, le terminal transmet au pare-feu son état de santé actuel, ses interfaces réseau et les utilisateurs connectés.

Sophos Endpoint envoie son statut à Sophos Firewall toutes les 15 secondes. Si trois Heartbeats consécutifs manquent alors que le terminal continue d’émettre du trafic réseau, le pare-feu attribue le statut Missing. Dès qu’un Heartbeat est de nouveau reçu, le terminal est à nouveau considéré comme actif.

L’association repose sur l’adresse MAC. Le pare-feu prend alors en compte toutes les interfaces de l’appareil. Lorsqu’un terminal passe d’Ethernet au WLAN, un ancien chemin réseau peut encore générer du trafic alors que le Heartbeat utilise déjà une autre interface. L’utilisation d’une même station d’accueil ou interface USB par deux terminaux différents constitue en revanche un cas d’erreur distinct qui dépend de la version.

Le statut Missing n’est par ailleurs pas équivalent à un Heartbeat rouge ou jaune :

• Missing : le pare-feu voit du trafic, mais ne reçoit aucun Heartbeat actuel.
• Yellow : le terminal signale un état d’avertissement, par exemple une signature obsolète ou une PUA.
• Red : le terminal signale un état critique, comme un malware actif qui n’a pas été nettoyé.

Un statut Missing doit donc être considéré comme un problème de communication et d’association tant que l’analyse n’a pas démontré le contraire.

Le pare-feu distribue aux terminaux la liste des appareils dont l’état de santé est rouge ou jaune tous les deux Heartbeats, soit toutes les 30 secondes. Cette distribution ne correspond ni à l’intervalle d’envoi de 15 secondes des terminaux ni au délai de détection du statut Missing.

État de santé et réponse

• Green: Le logiciel de sécurité Sophos signale un fonctionnement normal ; aucun malware actif ou inactif ni aucune application potentiellement indésirable (PUA) n’a été détecté. Cet état ne nécessite en lui-même aucune action, mais ne garantit pas que l’appareil est exempt de toute menace.
• Yellow: Les causes courantes sont une PUA nouvellement installée ou détectée, un malware inactif détecté ou un délai de 24 heures depuis la dernière mise à jour des signatures. Cet état est souvent temporaire et ne nécessite normalement aucune action immédiate. Il reste toutefois possible d’examiner et de nettoyer les PUA ou les malwares détectés ; si Yellow persiste, vérifier Endpoint Events et les mises à jour des signatures plutôt que d’ignorer systématiquement l’incident.
• Red: Une action est nécessaire, par exemple en présence d’un malware actif ou déjà en cours d’exécution, d’un malware non supprimé ou d’un logiciel de sécurité Sophos qui ne fonctionne pas correctement. Cela inclut également le trafic réseau malveillant détecté, par exemple vers un serveur de Command-and-Control (C2) d’un botnet, ainsi que la communication avec un hôte malveillant connu, identifié par son adresse IP ou par la résolution DNS.

En cas de Red, analyser Endpoint Events, vérifier le fonctionnement de la protection et le nettoyage, et traiter l’incident de sécurité selon votre propre procédure opérationnelle de gestion des incidents. Un délai Missing plus long ne résout aucune de ces causes. À l’inverse, Missing ne prouve pas à lui seul une infection.

Vérifier d’abord le périmètre et le modèle opérationnel

Security Heartbeat nécessite un Sophos Firewall enregistré, Sophos Endpoint Protection et un abonnement Network Protection valide. La configuration de base est décrite dans Connecter Sophos Firewall à Sophos Fusion.

Dans les environnements AD Windows 10 pris en charge, le même heartbeat peut aussi transporter l’identité utilisateur. Synchronized User ID Authentication explique l’association AD et pourquoi la perte du heartbeat peut déconnecter l’utilisateur détecté.

Contrôler les Missing heartbeat zones

Sous System > Sophos Fusion > Optional configurations, le champ Missing heartbeat zones détermine les zones dans lesquelles le pare-feu détecte les Heartbeats manquants. N’ajoutez que les zones dans lesquelles des terminaux Sophos administrés sont attendus.

Les réseaux invités, IoT, d’imprimantes ou de serveurs sans Sophos Endpoint ne font normalement pas partie de ce périmètre. Dans les environnements mixtes utilisant Microsoft Defender ou un autre EDR, les appareils peuvent être correctement protégés, mais ne peuvent pas envoyer de Sophos Security Heartbeat.

Le périmètre doit correspondre à la stratégie du pare-feu. Sophos signale un cas particulier peu intuitif : si une stratégie Heartbeat bloque une zone qui ne figure pas dans Missing heartbeat zones, le widget Security Heartbeat du Control Center peut tout de même afficher Missing. Il faut donc toujours vérifier ensemble le champ des zones et les règles de pare-feu concernées.

Vérifier la licence et l’état de Central

Sous System > Sophos Fusion, l’enregistrement et Security Heartbeat doivent être actifs. Dans Sophos Fusion, vérifiez les points suivants pour l’ordinateur concerné :

• Le terminal est-il en ligne et associé au bon tenant ?
• Affiche-t-il un état de santé vert, jaune ou rouge ?
• Des Endpoint Events se sont-ils produits au même moment ?
• L’appareil a-t-il été réinstallé, renommé, dupliqué ou supprimé de Central ?

Si plusieurs appareils sont touchés simultanément, la cause se situe plutôt au niveau de l’enregistrement, du chemin réseau ou de la stratégie. Des appareils isolés touchés de manière récurrente indiquent plutôt un service Endpoint, un changement d’adaptateur ou une configuration réseau locale.

Dans un environnement composé exclusivement de Sophos Endpoint, un Heartbeat peut constituer une condition d’accès stricte pertinente. Les zones, le périmètre des règles, la surveillance dans Central et un runbook pour les Heartbeats manquants doivent alors être cohérents. Dans un environnement mixte, utilisez Heartbeat de manière ciblée : les appareils équipés de Microsoft Defender ou d’un autre EDR peuvent être protégés, mais n’envoient aucun signal Sophos. Des règles distinctes et une segmentation claire sont plus fiables qu’une obligation Heartbeat globale assortie d’une liste d’exceptions toujours plus longue.

Classer correctement les causes typiques

Changements d’adaptateur, veille et matériel partagé

Si deux terminaux différents utilisent la même station d’accueil ou interface USB, la version du firmware est déterminante avant d’analyser les causes générales. Sophos a corrigé NC-176012 dans SFOS 22.0 MR2 Build 546. Les notes de publication n’indiquent pas la version dans laquelle le problème a été introduit ; sur un build SFOS 22 antérieur, effectuez d’abord la mise à jour, puis répétez le même test. Un temporisateur plus long ne ferait que masquer ce cas d’erreur.

Le temporisateur par défaut de détection d’un Heartbeat manquant est de 60 secondes. Lors d’un changement d’adaptateur, le pare-feu peut encore voir pendant ce délai des requêtes DNS ou des connexions en arrière-plan associées à l’ancienne adresse IP ou MAC. L’arrêt, la mise en veille, l’hibernation et le réveil peuvent produire un comportement similaire.

Les appareils Windows équipés de Modern Standby et de Sophos Endpoint Protection Core Agent 2023.2 ou d’une version plus récente informent le pare-feu avant de passer en veille. Modern Standby seul ne devrait donc pas déclencher d’alerte Missing. Avec des versions plus anciennes de l’agent ou d’autres états d’économie d’énergie, la corrélation temporelle reste néanmoins importante.

Après la notification de mise en veille, le pare-feu marque l’endpoint comme déconnecté et ne génère pas de Missing Heartbeat Alerts. À son réveil, l’endpoint avertit de nouveau le pare-feu, qui le marque à nouveau comme connecté. Ce processus s’applique aux appareils Windows mentionnés avec Modern Standby et Core Agent 2023.2 ou une version ultérieure, et non systématiquement à tous les types de Sleep ou Hibernate.

Exclure les fausses alertes sous macOS

Sophos continue de signaler sous MACEP-6842 de fausses interruptions de Heartbeat avec macOS 12 Monterey et les versions ultérieures. Elles peuvent se produire plusieurs fois par jour alors que la connexion n’a pas réellement été interrompue ; aucun correctif n’est encore planifié et Sophos ne propose pas de solution de contournement. Si seuls des Mac sont concernés, vérifiez d’abord les versions de macOS et d’Endpoint ainsi que les Central Events correspondants, au lieu de modifier les règles de pare-feu ou les temporisateurs sans preuve.

Trafic DNS lors d’un changement de réseau

Le DNS est souvent le dernier trafic visible d’un client qui change de réseau. Sophos documente ce comportement dans l’entrée Known Issue NC-178843 pour SFOS 21.5 GA : les résolveurs DNS externes peuvent notamment déclencher des alertes Missing supplémentaires lors d’un changement de réseau.

Une conception DNS cohérente est recommandée pour les clients administrés. Si Sophos Firewall est utilisé comme seul redirecteur DNS, les domaines internes doivent être transmis aux résolveurs internes au moyen de DNS Request Routes adaptées. La procédure est décrite dans Configurer les DNS Request Routes sur Sophos Firewall.

L’utilisation directe de serveurs DNS internes constitue également une conception légitime. L’essentiel est que le DHCP, les profils VPN et la configuration Endpoint prévoient le même chemin de résolution. Le passage au pare-feu comme redirecteur DNS n’est pas une obligation générale, mais une correction ciblée lorsque l’utilisation de résolveurs externes est manifestement à l’origine du bruit d’alertes.

Canal de communication et mode TAP

L’endpoint et le firewall échangent le heartbeat par une connexion TLS chiffrée vers 52.5.76.173 sur TCP 8347. Sophos Fusion fournit des certificats qui permettent au firewall d’associer les endpoints au bon compte. Le tenant, le certificat de l’endpoint et le statut de santé visible doivent correspondre.

Sophos Firewall établit des connexions Heartbeat exclusivement avec les endpoints dont il possède les certificats. Les certificats sont transmis au pare-feu par Sophos Fusion ; la simple appartenance au même compte ne suffit donc pas. L’ouverture d’un port à elle seule ne prouve ni la réussite d’une connexion TLS ni le bon fonctionnement de Heartbeat.

En TAP mode, le firewall doit disposer d’au moins une interface de la zone LAN connectée en permanence et accessible depuis les endpoints. SFOS transmet à Sophos Fusion les adresses de toutes les interfaces de la zone LAN, et les endpoints tentent d’y envoyer leur heartbeat. Si aucune de ces adresses n’est joignable depuis le réseau des endpoints, l’analyse TAP reste incomplète même si la réplication du trafic fonctionne correctement.

VPN, routeurs et NAT sur le chemin réseau

Security Heartbeat ne fonctionne de manière fiable que si le terminal et le pare-feu partagent le chemin prévu :

• Avant l’établissement de la connexion Heartbeat, le trafic du terminal ne doit pas déjà être acheminé par un autre tunnel VPN.
• Avec Sophos Connect, l’option Send Security Heartbeat through tunnel peut être nécessaire sous Remote access VPN > IPsec > Advanced settings.
• Derrière un routeur intermédiaire sans NAT, le terminal peut toujours partager son état de santé avec le pare-feu. Toutefois, le pare-feu ne peut pas y détecter un Heartbeat manquant ; un état de santé visible ne prouve donc pas que la surveillance Missing fonctionne.
• Derrière une passerelle NAT, les terminaux ne peuvent pas partager leur état de santé avec le pare-feu. Cette restriction est différente de l’impossibilité de détecter Missing derrière un routeur sans NAT.

Dans ce cas, une capture de paquets et la vérification du routage sont plus révélatrices qu’un examen isolé du statut dans Central.

NC-147863 constitue un autre cas particulier : lorsqu’un utilisateur derrière le pare-feu local utilise l’authentification Heartbeat et établit une connexion SSL VPN en split tunnel vers un pare-feu externe, le nouvel adaptateur VPN peut déclencher une boucle de connexion et de déconnexion qui bloque l’accès à Internet. Sophos recommande, comme solution de contournement, de retirer Match known users de la règle VPN locale ou d’utiliser Captive Portal. La procédure générale pour le client est décrite dans Configurer Sophos Connect Client pour Sophos Firewall.

Distinguer la protection latérale des règles de pare-feu

La protection contre les mouvements latéraux limite les communications entre terminaux selon leur état de santé et la stratégie Endpoint définie dans Sophos Fusion. Si un appareil signale Red, les autres terminaux cessent de communiquer avec lui uniquement si une stratégie correspondante s’applique. Le pare-feu agit comme un proxy MAC de couche 2 : il communique aux terminaux d’un même domaine de diffusion les adresses MAC et les états de santé des autres terminaux. Cela ne démontre pas une isolation au-delà des frontières réseau routées.

Ce contrôle diffère d’une condition Heartbeat dans une règle pour le trafic traversant le pare-feu. Si une communication entre terminaux est autorisée ou bloquée de manière inattendue, vérifiez d’abord la stratégie Endpoint réellement appliquée et le domaine de diffusion commun. Un test réussi de règle de pare-feu ne prouve pas à lui seul la protection latérale. Pour l’affectation des stratégies et les modifications contrôlées, consultez Configurer Sophos Endpoint Threat Protection en toute sécurité. Ne désactivez pas globalement une stratégie de production et ne provoquez pas un état de malware pour tester ; limitez les tests nécessaires à un pilote autorisé avec des valeurs initiales documentées et un retour arrière prévu.

Vérifier précisément la règle de pare-feu

Les paramètres Heartbeat se trouvent sous Rules and policies > Firewall rules > [rule] > Configure Synchronized Security Heartbeat. Les quatre options remplissent des fonctions différentes :

• Minimum source HB permitted : autorise uniquement les terminaux sources dont l’état est au moins Green ou Yellow. No restriction autorise également les appareils sans Heartbeat ou dont l’état est rouge.
• Block clients with no heartbeat : bloque les appareils sources sans Heartbeat.
• Minimum destination HB permitted : vérifie l’état de santé des appareils cibles internes. Ce contrôle ne s’applique pas aux destinations de la zone WAN.
• Block request to destination with no heartbeat : bloque les requêtes vers des destinations internes sans Heartbeat.

Un cas particulier important est facilement négligé : lorsqu’un terminal a d’abord envoyé un Heartbeat, puis le perd, le pare-feu le traite conformément à la stratégie configurée. En revanche, un appareil qui n’a encore jamais envoyé de Heartbeat reste autorisé tant que les options Block clients with no heartbeat et Block request to destination with no heartbeat ne sont pas toutes les deux activées.

Le trafic web présente une autre exception. Une exception correspondante sous Web > Exceptions peut autoriser des requêtes web malgré l’option Block clients with no heartbeat. Pour les ports 80 et 443, vérifiez donc aussi bien les journaux du pare-feu que ceux du filtre web. Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture explique comment combiner la Rule ID, Policy Test et Packet Capture.

Les conditions Heartbeat ne doivent s’appliquer qu’à des groupes clairement définis de terminaux Sophos. Les imprimantes, scanners, appareils IoT, invités et clients utilisant un EDR tiers nécessitent généralement une règle distincte et strictement délimitée plutôt qu’une exception large dans la règle principale.

Réduire les fausses alertes de manière contrôlée

Sophos fournit deux temporisateurs pris en charge dans la Device Console. Ils ne remplacent ni le correctif du firmware pour les stations d’accueil partagées, ni la vérification du problème connu sous macOS. Avant toute modification, affichez d’abord la valeur actuelle et consignez les heures des alertes.

Retarder la détection sur le pare-feu

Dans la CLI, sélectionnez 4. Device Console, puis vérifiez la valeur :

system synchronized-security delay-missing-heartbeat-detection show

La plage autorisée s’étend de 30 à 285 secondes par incréments de 15 secondes, et la valeur par défaut est de 60 secondes. Si des changements d’adaptateur sont manifestement à l’origine de fausses alertes, vous pouvez par exemple augmenter la valeur à 90 secondes :

system synchronized-security delay-missing-heartbeat-detection set seconds 90

Reproduisez ensuite le même passage LAN/WLAN ou le même scénario avec la station d’accueil. Une valeur plus élevée réduit les fausses alertes brèves, mais retarde également la détection d’un véritable Heartbeat manquant.

Une valeur plus élevée ne convient pas à tous les symptômes. Si Block clients with no heartbeat retarde l’accès aux ressources avec des commutateurs ou un LAG, la procédure Sophos commence à 30 secondes et n’augmente la valeur par incréments de 15 secondes qu’en cas de besoin. Ce cas diffère des changements d’adaptateur récurrents, pour lesquels une valeur telle que 90 secondes peut être testée.

Pour ce cas de switch/LAG, consigner d’abord le résultat actuel de system synchronized-security delay-missing-heartbeat-detection show comme référence pour le retour arrière et confirmer la règle effectivement appliquée. La modification concerne le délai de détection du pare-feu ; l’effectuer donc pendant une fenêtre de test approuvée et non en même temps que l’exemple de 90 secondes. Après connexion à la CLI du pare-feu, sélectionner 4. Device Console et définir :

system synchronized-security delay-missing-heartbeat-detection set seconds 30

Vérifier ensuite à nouveau la valeur avec show et tester l’accès réseau des appareils qui utilisent cette règle. N’augmenter la valeur par paliers de 15 secondes que si nécessaire et vérifier à nouveau après chaque modification. Si le comportement se dégrade, rétablir la valeur précédemment consignée avec la même syntaxe set seconds, puis tester à nouveau. La commande exit permet de quitter la Console. Les 30 secondes constituent la valeur de départ documentée pour ce scénario de défaillance précis, et non une nouvelle valeur par défaut générale.

Retarder la notification à Sophos Fusion

Si le pare-feu détecte correctement le statut, mais que Sophos Fusion déclenche une alerte trop rapidement lors d’une mise en veille, d’une hibernation, d’un arrêt ou d’un réveil, vérifiez la valeur suivante :

system synchronized-security suppress-missing-heartbeat-to-central show

La plage s’étend de 0 à 120 secondes, et la valeur par défaut est 0. Un délai ciblé de 60 secondes se configure ainsi :

system synchronized-security suppress-missing-heartbeat-to-central set seconds 60

Ce temporisateur ne modifie pas la stratégie Heartbeat locale. Il retarde uniquement le moment où le pare-feu signale le statut Missing à Sophos Fusion.

Nettoyer les entrées Missing obsolètes

Une fois l’analyse de la cause terminée, les anciennes entrées peuvent être supprimées du Control Center et des rapports. Les commandes suivantes sont des alternatives, pas une séquence. Exécutez uniquement l’option correspondant à la sélection approuvée dans 4. Device Console :

• Pour un seul terminal connu dont l’entrée est obsolète, privilégiez name et remplacez endpoint1 par son nom exact.
• days-missing agit indépendamment de la sélection par nom : cette option supprime toutes les entrées de statut Missing qui persistent depuis le nombre de jours choisi ou plus. La plage autorisée est de 1 à 90 jours. Avec 7, toutes les entrées en statut Missing depuis au moins sept jours sont donc supprimées, pas seulement celle de endpoint1 ni uniquement celles datant d’exactement sept jours. Remplacez 7 par l’ancienneté minimale approuvée et, avant ce nettoyage plus large, consignez l’ensemble des entrées sélectionnées selon leur ancienneté, avec l’appareil, l’heure et la cause pour chacune. N’exécutez la commande qu’après approbation du nettoyage de cet ensemble complet.

system synchronized-security missing-endpoints delete name endpoint1

system synchronized-security missing-endpoints delete days-missing 7

La suppression ne retire que le statut affiché. Elle ne répare ni le terminal ni la communication Heartbeat. Ne supprimez aucune entrée avant d’avoir consigné l’appareil, l’heure et la cause.

Après le nettoyage, rechargez le Control Center et les rapports, puis comparez-les à la sélection documentée : seules les entrées de statut Missing prévues doivent avoir disparu.

Vérification après la modification

Une modification n’est terminée que lorsque le scénario initial a été reproduit et testé :

1. Notez l’heure de l’alerte, le nom du terminal, son adresse IP, son adresse MAC, sa zone et la Rule ID concernée.
2. Dans le Control Center, vérifiez le statut Security Heartbeat et, sous System > Sophos Fusion, le périmètre des zones.
3. Dans Sophos Fusion, comparez l’état de santé et les Endpoint Events pour la même période.
4. Dans le Log Viewer, filtrez sur la Rule ID, l’adresse IP source et le statut No Heartbeat. Pour le trafic web, vérifiez également le filtre web.
5. En cas de problème de chemin réseau, contrôlez sous Diagnostics > Packet capture par quelle interface transitent le DNS et le trafic utile.
6. Reproduisez le déclencheur réel, par exemple le passage d’Ethernet au WLAN, puis vérifiez que l’alerte et l’accès réagissent désormais comme prévu.

Pour un dépannage approfondi, Diagnostics > Tools > Troubleshooting logs fournit notamment heartbeatd.log pour l’état des terminaux et les informations sur les applications, ainsi que hbtrust.log pour la communication entre le pare-feu et Sophos Fusion. Le classement des autres fichiers est expliqué dans Rechercher et interpréter les journaux de service de Sophos Firewall.

Les erreurs consignées dans heartbeatd.log lors de la détection de nouvelles applications relèvent en revanche de Synchronized Application Control et ne signalent pas automatiquement un problème Missing Heartbeat. La procédure adaptée est alors Vérifier en toute sécurité les erreurs de Synchronized Application Control.

Questions fréquentes