Aller au contenu
Avanet

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. Depuis SFOS 20.0 MR1, il limite les occurrences par application et par endpoint ; SFOS 21.0 et les versions ultérieures proposent en plus un nettoyage configurable selon l’ancienneté. Cet article explique comment définir la conservation normale, cerner un problème en toute sécurité et accompagner de manière contrôlée une éventuelle 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 Fusion (anciennement 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 Sophos Fusion, commencez par consulter Connecter Sophos Firewall à Sophos Fusion.

Comprendre la conservation et le nettoyage

Deux règles produit importantes s’appliquent à Synchronized Application Control :

  • 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’occurrence. Sophos précise toutefois que ce nettoyage de migration peut échouer si l’espace disponible est insuffisant. Dans ce cas, il faut faire appel au support Sophos.

Indépendamment de ce mécanisme, SFOS peut supprimer les applications dont la dernière détection est antérieure à la durée de conservation configurée. Le pare-feu effectue un contrôle quotidien et supprime des lots de 100 applications toutes les cinq minutes. Les applications ajoutées individuellement aux Application Filters en sont également retirées.

Lors d’une migration vers SFOS 21.0 ou une version ultérieure avec Synchronized Application Control activé, Clean up application database est activé avec la durée par défaut de 12 mois. Une durée personnalisée auparavant est conservée. La désactivation de Synchronized Application Control désactive aussi le nettoyage.

La distinction est importante : la conservation selon l’ancienneté se configure dans l’interface. La maintenance directe de la base de données ne fait toujours pas partie des tâches d’administration ordinaires.

Configurer le nettoyage régulier

Le pare-feu doit être enregistré auprès de Sophos Fusion et disposer d’un abonnement Web Protection valide. Sans cet abonnement, Synchronized Application Control peut être configuré, mais pas utilisé. Le domaine créé sur le pare-feu doit également correspondre au domaine sélectionné sur l’endpoint.

  1. Ouvrez System > Sophos Fusion et vérifiez que le pare-feu est enregistré et que Synchronized Application Control est activé.
  2. Activez Clean up application database.
  3. Choisissez la durée de conservation. 12 mois est la valeur de migration par défaut et un point de départ raisonnable en l’absence de politique spécifique. Une durée plus courte réduit plus vite les anciennes entrées, mais retire aussi plus tôt des Application Filters les applications ajoutées individuellement.
  4. Enregistrez le réglage et surveillez l’inventaire au fil des prochains nettoyages quotidiens.

Le nettoyage est volontairement progressif. Un nombre inchangé juste après l’enregistrement n’indique donc pas encore une erreur. Pour valider le fonctionnement, comparez la détection visible la plus ancienne et le nombre d’anciennes applications avant et après au moins un passage quotidien ; les nouvelles applications doivent continuer d’apparaître.

⚠️ La désactivation du nettoyage arrête les suppressions futures, mais ne restaure ni les applications ni les affectations de filtre déjà supprimées. Une application détectée réapparaît dans la liste, mais doit être réaffectée à un Application Filter si nécessaire.

Distinguer les symptômes typiques

Problème de stockage après une mise à niveau ou un nettoyage

Une partition fortement occupée, des rapports ou des services qui échouent, ainsi qu’un lien temporel avec une mise à niveau ou un nettoyage selon l’ancienneté qui n’avance plus 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.

Une liste proche de la limite produit de 15'000 applications indique un problème de capacité de Synchronized Application Control. Une partition pleine constitue en revanche un problème de stockage distinct. Les deux symptômes peuvent survenir simultanément, mais aucun ne prouve la cause de l’autre ; ils doivent donc être examinés séparément.

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 Sophos Fusion, 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

Faut-il nettoyer régulièrement la base de données de Synchronized Application Control ?

Oui, mais uniquement avec Clean up application database sous System > Sophos Fusion. À partir de SFOS 21.0, ce nettoyage selon l’ancienneté est réglé par défaut sur 12 mois après une migration lorsque Synchronized Application Control est activé. La maintenance directe de PostgreSQL reste du ressort du support.

Que signifie appId range is exhausted ?

Le pare-feu ne peut pas créer de nouvel ID interne pour une application détectée et ignore celle-ci. Ce symptôme appartient à Synchronized Application Control et doit être analysé à l’aide de la vue des applications, de heartbeatd.log, de la version du firmware et du support.

Peut-on utiliser d’anciennes commandes psql provenant de la Sophos Community ?

Pas sans autorisation actuelle du support Sophos. Les commandes publiques peuvent être destinées à une autre version de SFOS, à un autre problème ou à un autre node HA, et modifier les associations entre applications, endpoints ou utilisateurs.

Une sauvegarde de la configuration suffit-elle comme solution de repli ?

Non. Une sauvegarde de la configuration est importante avant une opération de maintenance, mais elle ne constitue pas une restauration complète des modifications directes apportées à la base de données PostgreSQL interne. La procédure de restauration doit donc faire partie des instructions du support.