Comment effacer les journaux d'audit Zimbra pour libérer de l'espace disque en toute sécurité

Commencez par déterminer ce que vous devez réellement enlever

Un serveur Zimbra dont l'espace disque est insuffisant peut rendre le nettoyage des journaux urgent, mais /opt/zimbra/log/audit.logil ne s'agit pas simplement de données de diagnostic jetables. Zimbra les documente comme journal d'audit des événements d'authentification et des activités d'administration. Par conséquent, la meilleure méthode de nettoyage dépend de vos besoins : libérer de l'espace immédiatement, conserver des preuves historiques ou assurer une conservation à plus long terme.

Par défaut, la solution la plus sûre consiste à ne pas modifier le audit.logfichier actif et à traiter d'abord les copies archivées. Si vous êtes soumis à une politique de conservation interne, à une obligation légale de conservation ou à une exigence de conformité, archivez ces fichiers sur un autre système de fichiers avant toute suppression. Si le fichier actif est devenu anormalement volumineux, vous pouvez le supprimer, mais cette opération doit être considérée comme une mesure d'urgence car elle efface l'historique d'audit actuel et peut engendrer un court délai de concurrence si le serveur continue d'écrire pendant la copie.

La documentation de Zimbra relative à la journalisation place les fichiers journaux audit.logsous le répertoire `/ etc/log /opt/zimbra/log/log` et décrit Log4j comme le composant responsable de leur rotation . D'autres journaux Zimbra peuvent utiliser la configuration du système d'exploitation ; il est donc important de ne pas supposer que tous les fichiers de ce répertoire suivent le même mécanisme. Consultez la documentation officielle de Zimbra sur les fichiers journaux et les notes relatives à la rotation des journaux Zimbra .audit.logmailbox.loglogrotate

Comparez les options de nettoyage avant d'agir

Étape 1 : Évaluer le problème avant de supprimer quoi que ce soit

Vérifiez d'abord que les journaux d'audit sont bien à l'origine de la pression. Exécutez les commandes suivantesroot :

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

La première commande indique le taux de remplissage du système de fichiers /opt. La deuxième affiche l'espace occupé par les journaux Zimbra. La troisième révèle le fichier d'audit actif et ses générations archivées. Si les fichiers d'audit ne représentent qu'une petite partie du système de fichiers, leur suppression ne résoudra peut-être pas le problème ; il est possible que ce soient plutôt les boîtes aux lettres, les sauvegardes, les fichiers de base de données ou d'autres types de journaux qui consomment cet espace.

Veuillez également noter la version installée avant de modifier le comportement :

su - zimbra -c 'zmcontrol -v'

Cela est important car la documentation Zimbra couvre plusieurs générations de produits, et la syntaxe exacte de Log4j, la configuration générée et les tâches d'élagage peuvent différer. Ne copiez pas une valeur de rétention d'un ancien exemple du wiki en supposant qu'elle est votre valeur par défaut actuelle.

Vérifiez l'utilisation du système de fichiers, la taille totale du journal Zimbra et les générations individuelles du journal d'audit avant de décider ce qu'il faut supprimer.

Étape 2 : Vérifiez comment ce serveur gère la rotation et l’élagage des journaux.

Zimbra documente deux mécanismes pertinents : Log4j pour les fichiers, notamment les fichiers .zimbra audit.log, et le système d'exploitation logrotatepour plusieurs autres journaux Zimbra. Il est également indiqué que la crontab de Zimbra peut contenir des tâches de maintenance des journaux. Consultez la configuration en production plutôt que de faire des suppositions.

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

Si l'un de ces fichiers ne contient pas le paramètre attendu dans votre version, examinez la configuration de journalisation associée plutôt que d'imposer un exemple antérieur. Les fichiers générés peuvent également être écrasés après un redémarrage du service ou une régénération de la configuration. Les notes de journalisation de Zimbra font clairement la distinction entre les modifications temporaires apportées au fichier de propriétés généré et les modifications permanentes effectuées dans le .inmodèle correspondant.

Pour les serveurs présentant un volume d'audit anormalement élevé, vérifiez si la journalisation supplémentaire a été activée intentionnellement. Les notes de version de Zimbra 10.0.6 documentent l' zimbra_additional_loggingattribut de configuration local permettant d'ajouter des événements d'authentification supplémentaires, qu'ils aient échoué ou soient utiles audit.log. Ne désactivez pas la journalisation de sécurité utile uniquement pour gagner de l'espace ; si le volume est justifié, il est généralement préférable d'opter pour la conservation, la compression ou le stockage centralisé des journaux. Consultez les notes de version officielles de Zimbra 10.0.6 .

Veuillez vérifier la configuration crontab et Log4j réelle du serveur avant de modifier le comportement de rétention ou de rotation.

Étape 3 : Privilégiez l’archivage ou la suppression des journaux de rotation en premier.

Pour la plupart des administrateurs, les journaux d'audit anciens et archivés constituent la première cible à supprimer. Utilisez find-les en mode « rapport uniquement » avant toute suppression. L'exemple suivant liste les journaux d'audit archivés datant de plus de 30 jours ; 30 jours n'est qu'un seuil indicatif et ne correspond pas à une période de conservation préconisée par Zimbra.

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

Si ces fichiers ne sont plus nécessaires, supprimez uniquement ceux qui ont été vérifiés et pivotés. Si vous devez les conserver, copiez-les ou archivez-les d'abord sur un autre système de fichiers. Il est important d'utiliser un autre point de montage lorsque la partition Zimbra est presque pleine, car la création d'une archive compressée sur ce même système de fichiers saturé peut temporairement consommer encore plus d'espace.

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

Répétez l'opération pour les fichiers portant exactement le même nom que celui que vous avez examiné. Vérifiez la sauvegarde avant de supprimer la source. Évitez les motifs trop généraux, comme rm -f /opt/zimbra/log/audit.log*« ; », car ce motif correspond également au fichier actif.

Si vous souhaitez conserver les anciens journaux localement tout en réduisant leur taille, compressez uniquement les fichiers archivés :

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

L'intérêt de la compression dépend de votre configuration de rotation actuelle. Certains déploiements compressent déjà les journaux historiques dans le cadre de la maintenance. Vérifiez la configuration existante avant d'ajouter une couche supplémentaire.

Les recommandations de Zimbra concernant l'historique des journaux indiquent également que les journaux d'audit peuvent contenir des données sensibles. Appliquez aux archives les mêmes contrôles d'accès qu'aux journaux actifs. Consultez les recommandations officielles de Zimbra relatives à la journalisation .

Lister d'abord les fichiers anciens archivés, copier l'historique nécessaire sur un support de stockage séparé, et seulement ensuite supprimer les générations vérifiées.

Quand la troncature du fichier audit.log actif est-elle justifiée ?

Si la rotation des fichiers n'est pas en cause et que le fichier actif audit.loglui-même occupe un espace critique, la troncature permet de récupérer cet espace immédiatement. C'est également l'option présentant le compromis le plus évident : l'historique d'audit actuel est effacé une fois le fichier tronqué.

Une procédure d'urgence plus sûre consiste à arrêter brièvement mailboxd, à copier le fichier actif sur un autre système de fichiers, à tronquer l'original sur place afin de préserver la propriété et les permissions, puis à redémarrer mailboxd :

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

Cette méthode entraîne une interruption du service de messagerie et n'est donc pas adaptée à tous les environnements. Copier le fichier actif sans arrêter mailboxd évite l'interruption, mais crée un risque de perte d'entrées écrites après la copie et avant la troncature. Si la charge disque n'est pas trop importante, il est préférable de nettoyer les fichiers archivés et de corriger la durée de rétention.

N'utilisez pas cette rmméthode sur le journal actif comme première solution. Un processus peut continuer à écrire via un descripteur de fichier ouvert même après la suppression de l'entrée de répertoire ; l'espace disque attendu peut donc ne pas être récupéré immédiatement. La troncature de l'inode existant est plus prévisible lorsqu'un nettoyage d'urgence est réellement nécessaire.

Étape 4 : Vérifiez la récupération du disque et la poursuite de l’enregistrement.

Après le nettoyage, vérifiez le résultat au lieu de vous fier à l'absence d'erreurs :

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

Un résultat positif se manifeste par trois signes : l’espace libre a augmenté sur le système de fichiers prévu, le audit.logprocessus continue de fonctionner et de recevoir de nouveaux événements, et les services Zimbra concernés restent actifs. Si dfle système de fichiers est toujours indiqué comme plein alors que l’espace libre dua fortement diminué, vérifiez si des fichiers supprimés sont encore ouverts par des processus en cours d’exécution avant de supprimer davantage de données.

Vérifiez l'espace récupéré, l'activité d'audit récente et l'état du service après le nettoyage.

Choisissez la solution à long terme en fonction de la cause de la croissance des bûches.

Si la croissance est normale mais que la rétention est trop longue

N’ajustez le processus de conservation ou d’élagage qu’après avoir documenté la période d’historique souhaitée. Examinez la configuration crontab Zimbra et Log4j existante, puis effectuez la modification minimale adaptée à votre version. Conservez une copie de la configuration originale et vérifiez que la rotation suivante crée bien les fichiers attendus.

Si le bruit d'authentification fait monter le volume

Il est préférable d'enquêter sur la source plutôt que de simplement supprimer rapidement les données. Les tentatives de connexion répétées, les clients mal configurés, les sondes de surveillance ou l'extension intentionnelle des journaux d'authentification peuvent tous augmenter le volume d'audits. Comme ces journaux audit.logsont utiles pour les enquêtes de sécurité, il est généralement préférable de réduire le bruit de fond plutôt que de supprimer les preuves.

Si vous devez conserver des mois d'historique d'audit

Déplacez ou transférez les journaux vers un stockage conçu pour leur conservation. La journalisation centralisée, le stockage objet ou un système de fichiers de journalisation dédié permettent de séparer l'historique de conformité de la capacité requise par la plateforme de messagerie. La documentation de Zimbra relative aux fichiers journaux aborde explicitement les solutions de journalisation centralisée possibles, notamment audit.log…

Ce qu'il ne faut pas faire

• Ne pas supprimer audit.log*avec un caractère générique non vérifié.
• Ne présumez pas /etc/logrotate.d/zimbraque le journal d'audit actif est contrôlé à chaque version ; Zimbra documente Log4j comme mécanisme de rotation pour audit.log.
• Ne compressez pas et n'archivez pas sur le même système de fichiers presque plein, sauf si vous avez vérifié qu'il y a suffisamment d'espace temporaire.
• Ne réduisez pas la durée de conservation sans vérifier les exigences organisationnelles, légales ou de sécurité.
• Ne modifiez pas définitivement les fichiers Log4j générés sans savoir si Zimbra les régénérera à partir d'un modèle.

Vérification finale

Si les anciens journaux de rotation étaient la principale source de consommation d'espace, le résultat souhaité est simple : le journal d'audit actif reste intact, les fichiers historiques sont archivés ou supprimés conformément à la politique en vigueur, et le système de fichiers retrouve suffisamment d'espace pour fonctionner normalement. Si l'espace recommence immédiatement à disparaître, cessez de considérer le nettoyage comme la solution et examinez le taux d'écriture, l'activité d'authentification, la configuration de rotation et tous les paramètres de journalisation supplémentaires. C'est cette distinction – nettoyage ponctuel ou croissance récurrente – qui détermine si le problème est réellement résolu.