Synchronized Application Control : diagnostiquer la base de données en toute sécurité

Lorsque Synchronized Application Control ne détecte plus de nouvelles applications, que heartbeatd.log signale des erreurs ou qu’un pare-feu manque fortement d’espace de stockage après une mise à niveau, la base de données interne des applications peut être concernée. Ce n’est toutefois pas un cas où il faut reprendre des commandes PostgreSQL générales trouvées sur un forum ou dans une ancienne note de support.

Sophos Firewall gère ces données en interne et a modifié leur conservation depuis SFOS 20.0 MR1. Si le nettoyage automatique échoue faute d’espace disponible, la documentation Sophos actuelle demande explicitement de contacter le support. Cet article explique donc comment cerner le problème en toute sécurité, collecter les bonnes données et accompagner de manière contrôlée une intervention du support.

Bien cerner le problème

Synchronized Application Control utilise les informations des endpoints reliés au pare-feu par Security Heartbeat. Le pare-feu peut ainsi identifier des applications que les signatures classiques ne permettent pas d’attribuer clairement et les met à disposition sous Applications > Synchronized Application Control pour leur gestion.

Il convient de ne pas confondre les notions suivantes :

• Security Heartbeat transmet l’état de santé et de sécurité entre l’endpoint, le pare-feu et Sophos Central.
• Synchronized Application Control recense les applications et les emplacements où elles ont été détectées sur les endpoints connectés.
• Missing heartbeat désigne l’absence d’état d’un endpoint et peut être géré au moyen de commandes prises en charge dans la Device Console.
• Un problème d’App-ID ou de base de données concerne le stockage interne des applications détectées et nécessite un diagnostic distinct.

L’absence d’indicateur Heartbeat, un endpoint rouge ou une règle de pare-feu inadéquate ne signalent donc pas automatiquement un problème de base de données. Pour vérifier la connexion entre le pare-feu et Central, commencez par consulter Connecter Sophos Firewall à Sophos Central.

Ce que SFOS nettoie automatiquement

La documentation Sophos actuelle sur Synchronized Application Control indique deux limites importantes :

• Synchronized Application Control prend en charge jusqu’à 15'000 applications.
• Depuis SFOS 20.0 MR1, le pare-feu ne conserve plus que les cinq dernières occurrences de chaque application par endpoint.

Lors d’une migration vers SFOS 20.0 MR1 ou une version ultérieure, le pare-feu conserve les cinq occurrences les plus récentes et supprime automatiquement les anciennes données d’application. Sophos précise toutefois que ce nettoyage peut échouer si l’espace disponible est insuffisant. Dans ce cas, il faut faire appel au support Sophos.

En pratique, un pare-feu à jour ne nécessite normalement aucune maintenance manuelle de ces données. Une croissance récurrente, l’échec d’une migration ou l’épuisement de la plage d’App-ID sont des symptômes d’erreur, et non des opérations de maintenance ordinaires.

Distinguer les symptômes typiques

Problème de stockage après une mise à niveau

Une partition fortement occupée, des rapports ou des services qui échouent, ainsi qu’un lien temporel avec une mise à niveau vers SFOS 20.0 MR1 ou une version ultérieure peuvent constituer des indices. Cela ne prouve toutefois pas que Synchronized Application Control en soit la cause.

Il faut d’abord vérifier les rapports, les journaux de débogage, les archives de support, la file d’attente des e-mails, la quarantaine et la taille d’un disque virtuel. La procédure est décrite dans Vérifier l’espace de stockage et gérer les rapports sur Sophos Firewall.

Plage d’App-ID épuisée

Un autre symptôme est un message tel que :

Cannot create ID for application, because appId range is exhausted.
Application will be ignored.

Le pare-feu peut alors continuer d’afficher les applications existantes, mais ne plus parvenir à enregistrer correctement les nouvelles. Ce message concerne Synchronized Application Control, et non une base de données générale de rapports ou de journaux.

Security Heartbeat ne fonctionne pas

Si les endpoints ne transmettent aucun état Heartbeat ou si les règles comportant des conditions Heartbeat ne fonctionnent pas comme prévu, il faut d’abord vérifier l’enregistrement dans Central, la communication des endpoints, les zones concernées et la règle de pare-feu. Un nettoyage direct de la base de données n’est pas la bonne approche dans ce cas.

Diagnostic avant d’ouvrir un dossier de support

1. Documenter le firmware et le contexte

Les informations suivantes doivent figurer dans les notes du dossier :

• modèle du pare-feu, numéro de série et version SFOS complète, build compris
• mode Standalone, HA Primary ou HA Auxiliary
• date de la dernière mise à niveau et version SFOS précédente
• moment depuis lequel le problème est visible
• services concernés et conséquences concrètes

Dans un environnement HA, il faut identifier clairement le node sur lequel le symptôme apparaît. Les journaux locaux et l’occupation du stockage peuvent différer entre Primary et Auxiliary.

2. Vérifier la vue des applications

Sous Applications > Synchronized Application Control, vérifiez les points suivants :

• De nouvelles applications sont-elles encore détectées ?
• La liste approche-t-elle la limite de 15'000 applications ?
• Le problème concerne-t-il uniquement les nouvelles applications ou également les entrées existantes ?
• Les applications peuvent-elles être recherchées, ouvertes et gérées ?
• Les applications supprimées sont-elles recréées comme prévu lorsqu’elles sont de nouveau détectées ?

La suppression d’applications individuelles dans l’interface est une fonction prise en charge, mais elle les retire également des Application Filters. Si le pare-feu détecte de nouveau l’application, celle-ci réapparaît. Cette fonction de l’interface ne constitue donc pas une réparation de la base de données.

3. Examiner séparément l’état du stockage

L’occupation du stockage doit être documentée avant toute autre mesure. Il est important de noter la partition concernée et son évolution dans le temps, et pas seulement un pourcentage isolé.

Si des rapports, des journaux ou des archives de support sont supprimés en parallèle, il devient ensuite impossible de déterminer quelle mesure a réellement aidé. Il faut donc commencer par conserver les preuves, puis n’effectuer qu’une seule modification à la fois.

4. Sauvegarder les journaux et le rapport de dépannage

heartbeatd.log est particulièrement pertinent pour Synchronized Application Control et Security Heartbeat. Il faut également consigner l’heure exacte de l’erreur et sauvegarder un rapport de dépannage.

Les fichiers appropriés et les méthodes de collecte sont présentés dans Dépannage de Sophos Firewall : services et journaux et Sauvegarder les journaux de Sophos Firewall pour une analyse externe.

Ne pas reprendre de commandes de base de données publiques

Internet contient diverses commandes psql, DELETE, VACUUM FULL et de redémarrage de services destinées à d’anciennes versions de SFOS et à différents problèmes de Heartbeat. Ces procédures ne sont pas interchangeables :

• Un VACUUM FULL libère l’espace d’une table, mais ne supprime pas automatiquement la cause de sa croissance.
• Un DELETE peut modifier les associations entre applications, endpoints ou utilisateurs authentifiés en direct.
• Les tables et procédures de support peuvent varier d’une version de SFOS à l’autre.
• Dans un environnement HA, la procédure dépend en outre du node, de l’état de synchronisation et des instructions du support.

⚠️ Aucune modification directe ne doit être apportée à la base de données PostgreSQL interne sans instruction actuelle et spécifique au cas fournie par le support Sophos. Une sauvegarde de la configuration est importante, mais ne permet pas une restauration complète de la base de données interne.

Les commandes provenant d’un ancien ticket ne doivent pas non plus être appliquées sans vérification à un autre pare-feu, firmware ou rôle HA. Les instructions exactes doivent figurer dans le dossier de support actuel et préciser le node concerné ainsi que l’effet attendu.

Préparer un dossier de support complet

Un dossier bien préparé accélère l’analyse et évite les demandes d’informations supplémentaires. Il doit contenir :

• la version SFOS complète et le modèle du pare-feu
• le numéro de série et le rôle HA du node concerné
• l’heure et le texte exact du message d’erreur
• une capture d’écran de Applications > Synchronized Application Control
• l’occupation du stockage avant toute opération de nettoyage
• heartbeatd.log et le rapport de dépannage pour la période concernée
• la date et le chemin de la dernière mise à niveau du firmware
• une description indiquant si de nouvelles applications manquent, si l’espace de stockage est insuffisant ou si les deux problèmes surviennent

Une sauvegarde actuelle de la configuration du pare-feu doit être disponible avant toute intervention du support. La procédure d’ouverture d’un dossier est décrite dans Ouvrir un ticket de support Sophos.

Si le support ordonne une intervention sur la base de données, le changement doit consigner le numéro de ticket, les commandes autorisées, le node cible, la fenêtre de maintenance, la sortie attendue et les critères d’arrêt. Tout message d’erreur différent doit être documenté et signalé au lieu de poursuivre les essais avec des commandes similaires.

Vérifications après l’intervention du support

Après la mesure autorisée, il ne suffit pas de vérifier l’espace libre ou la bonne exécution d’une commande. L’ensemble du parcours fonctionnel doit être contrôlé :

1. Ouvrir Applications > Synchronized Application Control et contrôler les entrées existantes.
2. Lancer sur un endpoint de test une nouvelle application qui n’a encore jamais été détectée.
3. Vérifier que l’application apparaît et peut être gérée.
4. Contrôler l’état Security Heartbeat de l’endpoint de test.
5. Tester les règles de pare-feu comportant des conditions Heartbeat ou Application Control.
6. Rechercher de nouvelles erreurs dans heartbeatd.log pendant la période de test.
7. Surveiller l’occupation du stockage pendant plusieurs heures ou plusieurs jours.

Si l’erreur ou la croissance réapparaît rapidement, le nettoyage n’a apporté qu’un soulagement temporaire. Le support Sophos aura alors besoin de la nouvelle évolution temporelle, de journaux actuels et de l’action après laquelle le problème est réapparu.

FAQ