Wie man Zimbra-Audit-Protokolle sicher löscht, um Speicherplatz freizugeben

Entscheiden Sie zunächst, was Sie tatsächlich entfernen müssen.

Bei einem Zimbra-Server mit knappem Speicherplatz erscheint die Protokollbereinigung dringlich, doch /opt/zimbra/log/audit.loghandelt es sich dabei nicht nur um verzichtbare Diagnosedaten. Zimbra dokumentiert sie als Audit-Trail für Authentifizierungsereignisse und administrative Aktivitäten. Die beste Bereinigungsmethode hängt daher davon ab, ob Sie kurzfristig Speicherplatz, historische Nachweise oder eine langfristige Aufbewahrungslösung benötigen.

Am sichersten ist es, die aktive audit.logDatei unverändert zu lassen und zuerst ältere, rotierte Kopien zu bearbeiten. Wenn Sie internen Aufbewahrungsrichtlinien, rechtlichen Aufbewahrungspflichten oder Compliance-Anforderungen unterliegen, archivieren Sie diese Dateien auf einem anderen Dateisystem, bevor Sie etwas löschen. Falls die aktive Datei selbst ungewöhnlich groß geworden ist, können Sie sie löschen. Dies sollte jedoch nur im Notfall erfolgen, da dadurch der aktuelle Prüfverlauf gelöscht wird und ein kleines Zeitfenster entstehen kann, in dem der Server während des Kopiervorgangs weiter Daten schreibt.

Die Zimbra-eigene Protokollierungsdokumentation audit.logbeschreibt /opt/zimbra/logLog4j als die Komponente, die für die Rotation von Dateien wie ` audit.log.log` und `.log` zuständig ist mailbox.log. Andere Zimbra-Protokolle verwenden möglicherweise die Konfiguration des Betriebssystems logrotate. Gehen Sie daher nicht davon aus, dass alle Dateien im Verzeichnis demselben Mechanismus folgen. Weitere Informationen finden Sie in der offiziellen Zimbra-Protokolldateireferenz und den Hinweisen zur Zimbra-Protokollrotation .

Vergleichen Sie die Sanierungsoptionen, bevor Sie handeln.

Schritt 1: Messen Sie das Problem, bevor Sie etwas löschen.

Prüfen Sie zunächst, ob die Audit-Logs tatsächlich für den Speicherdruck verantwortlich sind. Führen Sie dazu folgende Befehle aus root:

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

Der erste Befehl zeigt die Auslastung des Dateisystems an /opt. Der zweite Befehl zeigt den gesamten Speicherplatzbedarf der Zimbra-Protokolle. Der dritte Befehl zeigt die aktive Audit-Datei und alle rotierten Generationen an. Wenn die Audit-Dateien nur einen kleinen Teil des Dateisystems ausmachen, behebt deren Löschung möglicherweise nicht das eigentliche Problem; stattdessen könnten Mailbox-Speicher, Backups, Datenbankdateien oder andere Protokollfamilien den Speicherplatz belegen.

Notieren Sie sich außerdem Ihre installierte Version, bevor Sie das Verhalten ändern:

su - zimbra -c 'zmcontrol -v'

Dies ist wichtig, da die Zimbra-Dokumentation mehrere Produktgenerationen umfasst und sich die genaue Log4j-Syntax, die generierte Konfiguration und die Pruning-Jobs unterscheiden können. Kopieren Sie keinen Aufbewahrungswert aus einem alten Wiki-Beispiel und gehen Sie nicht davon aus, dass dies Ihr aktueller Standardwert ist.

Prüfen Sie die Dateisystemnutzung, die Gesamtgröße der Zimbra-Protokolle und die einzelnen Audit-Protokollgenerationen, bevor Sie entscheiden, was entfernt werden soll.

Schritt 2: Überprüfen Sie, wie dieser Server die Protokolldateien rotiert und bereinigt.

Zimbra dokumentiert zwei relevante Mechanismen: Log4j für Dateien wie z. B. `.log` audit.logund den systemeigenen Log-Mechanismus logrotatefür diverse andere Zimbra-Logs. Außerdem wird darauf hingewiesen, dass die Zimbra-eigene Crontab Aufgaben zur Log-Wartung enthalten kann. Überprüfen Sie die aktuelle Konfiguration, anstatt zu raten.

su - zimbra
crontab -l
exit

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

Wenn eine dieser Dateien in Ihrer Version nicht die erwartete Einstellung enthält, überprüfen Sie die zugehörige Protokollierungskonfiguration, anstatt eine ältere Version zu erzwingen. Generierte Dateien können nach einem Neustart des Dienstes oder einer Neukonfiguration überschrieben werden. Die Protokollierungshinweise von Zimbra unterscheiden ausdrücklich zwischen temporären Änderungen an der generierten Eigenschaftendatei und permanenten Änderungen in der zugehörigen .inVorlage.

Bei Servern mit unerwartet hohem Protokollaufkommen sollten Sie prüfen, ob die zusätzliche Protokollierung absichtlich aktiviert wurde. Die Versionshinweise zu Zimbra 10.0.6 beschreiben das zimbra_additional_logginglokale Konfigurationsattribut, mit dem weitere fehlgeschlagene oder anderweitig nützliche Authentifizierungsereignisse hinzugefügt werden können audit.log. Deaktivieren Sie die nützliche Sicherheitsprotokollierung nicht nur, um Speicherplatz zu sparen. Bei einem berechtigten Protokollaufkommen sind Aufbewahrung, Komprimierung oder eine zentrale Protokollspeicherung in der Regel die bessere Lösung. Weitere Informationen finden Sie in den offiziellen Versionshinweisen zu Zimbra 10.0.6 .

Überprüfen Sie die tatsächliche Crontab- und Log4j-Konfiguration des Servers, bevor Sie das Aufbewahrungs- oder Rotationsverhalten ändern.

Schritt 3: Archivieren oder löschen Sie vorzugsweise zuerst die rotierten Protokolle.

Für die meisten Administratoren sind alte, rotierte Audit-Logs der beste erste Anlaufpunkt. Verwenden Sie findden Berichtsmodus, bevor Sie Daten löschen. Das folgende Beispiel listet rotierte Audit-Logs auf, die älter als 30 Tage sind; 30 Tage sind lediglich ein Beispielwert und keine von Zimbra vorgegebene Aufbewahrungsfrist:

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

Wenn diese Dateien nicht mehr benötigt werden, löschen Sie nur die überprüften, rotierten Dateien. Falls Sie sie behalten müssen, kopieren oder archivieren Sie sie zuvor auf ein anderes Dateisystem. Die Verwendung eines anderen Mountpunkts ist wichtig, wenn die Zimbra-Partition bereits fast voll ist, da das Erstellen eines komprimierten Archivs auf demselben vollen Dateisystem vorübergehend noch mehr Speicherplatz belegen kann.

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

Wiederholen Sie den Vorgang für die exakten Dateinamen, die Sie überprüft haben. Überprüfen Sie die Sicherung, bevor Sie die Quelle entfernen. Vermeiden Sie allgemeine Muster wie rm -f /opt/zimbra/log/audit.log*„; dieses Muster stimmt auch mit der aktiven Datei überein.“

Wenn Sie alte Protokolle lokal speichern, aber deren Speicherbedarf reduzieren möchten, komprimieren Sie nur die rotierten Dateien:

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

Ob eine Komprimierung sinnvoll ist, hängt von Ihrer aktuellen Protokollierungskonfiguration ab. Einige Systeme komprimieren historische Protokolle bereits im Rahmen der Wartung. Prüfen Sie, welche Daten bereits vorhanden sind, bevor Sie eine weitere Ebene hinzufügen.

Die Richtlinien von Zimbra zur Protokollierung historischer Daten weisen darauf hin, dass Audit-Logs sensible Daten enthalten können. Behandeln Sie Archive mit denselben Zugriffskontrollen wie die Live-Logs. Weitere Informationen finden Sie in den offiziellen Richtlinien zur Protokollierung von Zimbra .

Zuerst die alten rotierten Dateien auflisten, den benötigten Verlauf auf einen separaten Speicher kopieren und erst dann die überprüften Generationen entfernen.

Wann ist das Kürzen der aktiven audit.log-Datei gerechtfertigt?

Wenn rotierte Dateien nicht das Problem darstellen und die aktive Datei audit.logselbst kritischen Speicherplatz belegt, kann durch Kürzen sofort Speicherplatz freigegeben werden. Dies ist auch die Option mit dem deutlichsten Nachteil: Der aktuelle Prüfverlauf wird beim Kürzen der Datei gelöscht.

Ein sichereres Notfallverfahren besteht darin, mailboxd kurzzeitig anzuhalten, die aktive Datei auf ein anderes Dateisystem zu kopieren, das Original an Ort und Stelle zu kürzen, sodass Eigentumsrechte und Berechtigungen erhalten bleiben, und mailboxd anschließend wieder zu starten:

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'

Dies führt zu Ausfallzeiten des Postfachdienstes und ist daher nicht für jede Umgebung geeignet. Das Kopieren der Live-Datei ohne Stoppen von mailboxd vermeidet zwar Ausfallzeiten, erzeugt aber einen Wettlauf, bei dem Einträge, die nach dem Kopieren und vor dem Abschneiden geschrieben wurden, verloren gehen können. Bei geringer Festplattenauslastung ist das Bereinigen rotierter Dateien und das Korrigieren der Aufbewahrungseinstellungen vorzuziehen.

Verwenden Sie die aktive Protokolldatei nicht rmals erste Maßnahme. Ein Prozess kann auch nach dem Löschen des Verzeichniseintrags weiterhin über einen geöffneten Dateideskriptor schreiben, sodass der erwartete Speicherplatz möglicherweise nicht sofort freigegeben wird. Das Kürzen des vorhandenen Inodes ist berechenbarer, wenn eine Notfalllöschung wirklich notwendig ist.

Schritt 4: Überprüfen Sie sowohl die Datenträgerwiederherstellung als auch die fortgesetzte Protokollierung.

Nach der Bereinigung sollte das Ergebnis überprüft werden, anstatt sich auf die Fehlerfreiheit zu verlassen:

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'

Ein positives Ergebnis zeigt sich durch drei Anzeichen: Der freie Speicherplatz im betreffenden Dateisystem hat sich erhöht, das System audit.logexistiert weiterhin und empfängt neue Ereignisse, und die relevanten Zimbra-Dienste laufen weiterhin. dfMeldet Zimbra weiterhin ein volles Dateisystem, obwohl duder Speicherplatz stark gesunken ist, prüfen Sie, ob gelöschte Dateien noch von laufenden Prozessen geöffnet sind, bevor Sie weitere Daten löschen.

Überprüfen Sie nach der Bereinigung den freigegebenen Speicherplatz, die letzten Auditaktivitäten und den Zustand der Dienste.

Wählen Sie die langfristige Lösung basierend auf den Gründen für das Wachstum der Protokolle.

Wenn das Wachstum normal ist, die Retention aber zu lange dauert

Passen Sie die Aufbewahrungs- oder Löschprozesse erst an, nachdem Sie den benötigten Verlaufszeitraum dokumentiert haben. Überprüfen Sie die bestehende Zimbra-Crontab- und Log4j-Konfiguration und nehmen Sie dann die kleinstmögliche, versionsspezifische Änderung vor. Bewahren Sie eine Kopie der ursprünglichen Konfiguration auf und testen Sie, ob die nächste Rotation die erwarteten Dateien erzeugt.

Wenn das Authentifizierungsrauschen die Lautstärke bestimmt

Untersuchen Sie die Quelle, anstatt Daten einfach nur schneller zu löschen. Wiederholte Anmeldeversuche, falsch konfigurierte Clients, Überwachungssonden oder absichtlich erweiterte Authentifizierungsprotokollierung können das Auditvolumen erhöhen. Da dies audit.logfür Sicherheitsuntersuchungen nützlich ist, ist die Reduzierung des zugrundeliegenden Rauschens in der Regel besser als die Unterdrückung der Beweise.

Wenn Sie die Prüfungshistorie mehrerer Monate aufbewahren müssen

Protokolle sollten in einem speziell für die Aufbewahrung vorgesehenen Speichersystem verschoben oder versendet werden. Zentralisierte Protokollierung, Objektspeicherung oder ein dediziertes Protokolldateisystem trennen die Compliance-Historie von der für die E-Mail-Plattform benötigten Kapazität. Die Protokolldateidokumentation von Zimbra beschreibt explizit verschiedene Optionen für die zentrale Protokollierung, darunter audit.log…

Was man nicht tun sollte

• Nicht audit.log*mit einem nicht überprüften Platzhalter löschen.
• Gehen Sie nicht davon aus, dass /etc/logrotate.d/zimbradie aktiven Audit-Logs bei jeder Veröffentlichung von Zimbra verwaltet werden; Zimbra dokumentiert Log4j als Rotationsmechanismus für audit.log.
• Komprimieren oder archivieren Sie nicht auf demselben, nahezu vollen Dateisystem, es sei denn, Sie haben sich vergewissert, dass genügend temporärer Speicherplatz vorhanden ist.
• Verkürzen Sie die Aufbewahrungsfrist nicht, ohne vorher die organisatorischen, rechtlichen oder sicherheitsrelevanten Anforderungen zu prüfen.
• Bearbeiten Sie generierte Log4j-Dateien nicht dauerhaft, ohne vorher zu prüfen, ob Zimbra diese anhand einer Vorlage neu generiert.

Endprüfung

Wenn alte, rotierte Protokolldateien den größten Speicherplatzbedarf verursachten, ist das optimale Ergebnis einfach: Das aktive Audit-Protokoll bleibt erhalten, historische Dateien werden gemäß den Richtlinien archiviert oder gelöscht, und das Dateisystem hat wieder ausreichend Speicherplatz für den normalen Betrieb. Sollte der Speicherplatz jedoch sofort wieder knapp werden, ist die Bereinigung nicht mehr die alleinige Lösung. Stattdessen sollten Sie die Schreibrate, die Authentifizierungsaktivitäten, die Rotationskonfiguration und alle weiteren Protokollierungseinstellungen überprüfen. Diese Unterscheidung – einmalige Bereinigung versus wiederkehrendes Wachstum – entscheidet darüber, ob das Problem tatsächlich behoben wurde.