Cum să ștergeți jurnalele de audit Zimbra pentru a elibera spațiu pe disc în siguranță

Începeți prin a decide ce trebuie de fapt să eliminați

Un server Zimbra care nu are suficient spațiu pe disc poate face ca curățarea jurnalelor să pară urgentă, dar /opt/zimbra/log/audit.lognu este doar o ieșire de diagnostic detașabilă. Zimbra o documentează ca pistă de audit pentru evenimentele de autentificare și activitatea administrativă. Aceasta înseamnă că cea mai bună metodă de curățare depinde de nevoia imediată de spațiu, dovezi istorice sau o soluție de păstrare pe termen lung.

Cea mai sigură opțiune implicită este să lăsați audit.logfișierul activ nemodificat și să vă ocupați mai întâi de copiile mai vechi rotite. Dacă sunteți supus unei politici interne de păstrare, unei rețineri legale sau unei cerințe de conformitate, arhivați aceste fișiere într-un alt sistem de fișiere înainte de a șterge ceva. Dacă fișierul activ în sine a devenit anormal de mare, îl puteți șterge, dar acest lucru ar trebui tratat ca o măsură de urgență, deoarece elimină istoricul curent de audit și poate introduce o mică fereastră de concurență dacă serverul continuă să scrie în timp ce îl copiați.

Documentația proprie de jurnalizare a Zimbra plasează Log4j audit.logsub /opt/zimbra/logși descrie componenta responsabilă pentru rotirea fișierelor precum audit.logși mailbox.log. Alte jurnale Zimbra pot utiliza în schimb configurația sistemului de operare logrotate, așa că nu presupuneți că fiecare fișier din director urmează același mecanism. Consultați referința oficială a fișierelor jurnal Zimbra și notele de rotație a jurnalelor Zimbra .

Compară opțiunile de curățare înainte de a acționa

Pasul 1: Măsurați problema înainte de a șterge orice

Mai întâi confirmați că jurnalele de audit sunt de fapt responsabile pentru presiune. Rulați-le astfel root:

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

Prima comandă vă spune cât de plin /opteste sistemul de fișiere pe care îl conține. A doua arată amprenta generală a jurnalului Zimbra. A treia expune fișierul de audit activ și orice generații rotite. Dacă fișierele de audit reprezintă doar o mică parte din sistemul de fișiere, ștergerea lor poate să nu rezolve problema reală; în schimb, spațiul poate fi ocupat de depozitele de cutii poștale, de copiile de rezervă, de fișierele bazei de date sau de o altă familie de jurnal.

De asemenea, înregistrați versiunea instalată înainte de a schimba comportamentul:

su - zimbra -c 'zmcontrol -v'

Acest lucru este important deoarece documentația Zimbra acoperă mai multe generații de produse, iar sintaxa exactă Log4j, configurația generată și joburile de eliminare pot diferi. Nu copiați o valoare de retenție dintr-un exemplu wiki vechi și nu presupuneți că este valoarea implicită curentă.

Verificați utilizarea sistemului de fișiere, dimensiunea totală a jurnalului Zimbra și generațiile individuale de jurnal de audit înainte de a decide ce să eliminați.

Pasul 2: Verificați cum se rotește și șterge jurnalele acestui server

Zimbra documentează două mecanisme relevante: Log4j pentru fișiere care includ audit.log, și mecanismele sistemului de operare logrotatepentru alte câteva jurnale Zimbra. De asemenea, menționează că propriul crontab al Zimbra poate conține sarcini de întreținere a jurnalelor. Verificați configurația live în loc să ghiciți:

su - zimbra
crontab -l
exit

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

Dacă unul dintre aceste fișiere nu conține setarea așteptată în versiunea dvs., inspectați configurația de înregistrare în jurnal înconjurătoare, în loc să forțați un exemplu mai vechi. Fișierele generate pot fi, de asemenea, suprascrise după repornirea serviciului sau regenerarea configurației. Notele de înregistrare în jurnal ale Zimbra disting în mod specific modificările temporare ale fișierului de proprietăți generat de modificările persistente efectuate în .inșablonul corespunzător.

Pentru serverele cu un volum de audit neașteptat de mare, verificați dacă jurnalizarea suplimentară a fost activată intenționat. Notele de lansare Zimbra 10.0.6 documentează zimbra_additional_loggingatributul de configurare locală, care poate adăuga mai multe evenimente de autentificare eșuate sau utile în alt mod audit.log. Nu dezactivați jurnalizarea de securitate utilă doar pentru a economisi spațiu; dacă volumul este legitim, un răspuns mai bun este de obicei păstrarea, compresia sau stocarea centralizată a jurnalelor. Consultați notele oficiale de lansare Zimbra 10.0.6 .

Verificați configurația crontab și Log4j a serverului înainte de a modifica comportamentul de retenție sau rotație.

Pasul 3: Preferați mai întâi arhivarea sau ștergerea jurnalelor rotite

Pentru majoritatea administratorilor, jurnalele de audit vechi rotite sunt cea mai bună primă țintă. Folosiți find-le în modul doar pentru raportare înainte de a șterge ceva. Următorul exemplu listează jurnalele de audit rotite mai vechi de 30 de zile; 30 de zile este doar un exemplu de prag, nu o perioadă de păstrare prescrisă de Zimbra:

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

Dacă aceste fișiere nu mai sunt necesare, ștergeți doar fișierele rotite revizuite. Dacă trebuie să le păstrați, copiați-le sau arhivați-le mai întâi într-un alt sistem de fișiere. Utilizarea unei alte montări este importantă atunci când partiția Zimbra este deja aproape plină, deoarece crearea unei arhive comprimate pe același sistem de fișiere complet poate consuma temporar și mai mult spațiu.

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

Repetați pentru numele exacte de fișiere pe care le-ați revizuit. Verificați copia de rezervă înainte de a elimina sursa. Evitați modelele generale, cum ar fi rm -f /opt/zimbra/log/audit.log*; modelul respectiv se potrivește și cu fișierul activ.

Dacă doriți să păstrați jurnalele vechi local, dar să le reduceți amprenta, comprimați doar fișierele rotite:

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

Dacă este utilă compresia depinde de configurația actuală a rotației. Este posibil ca unele implementări să comprime deja jurnalele istorice ca parte a întreținerii. Verificați ce există de fapt înainte de a adăuga un alt strat.

Ghidul Zimbra privind înregistrarea istorică avertizează, de asemenea, că jurnalele de audit pot conține date sensibile. Tratați arhivele cu aceleași controale de acces ca și jurnalele active. Consultați ghidul oficial Zimbra privind înregistrarea .

Enumerați mai întâi fișierele vechi rotite, copiați istoricul necesar într-un spațiu de stocare separat și abia apoi eliminați generațiile revizuite.

Când trunchierea audit.log-ului activ este justificată

Dacă fișierele rotite nu reprezintă problema și fișierul activ audit.logîn sine consumă spațiu critic, trunchierea poate recupera spațiul imediat. De asemenea, este opțiunea cu cel mai clar compromis: istoricul auditului curent este distrus odată ce fișierul este trunchiat.

O procedură de urgență mai sigură este oprirea rapidă a mailboxd, copierea fișierului activ într-un alt sistem de fișiere, trunchierea originalului astfel încât proprietatea și permisiunile să fie păstrate și repornirea 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'

Acest lucru introduce perioade de nefuncționare a serviciului de cutii poștale, deci nu este alegerea potrivită pentru fiecare mediu. Copierea fișierului activ fără oprirea mailboxd evită perioadele de nefuncționare, dar creează o concurență în care intrările scrise după copiere și înainte de trunchiere se pot pierde. Dacă presiunea pe disc nu este severă, curățarea fișierelor rotite și corectarea retenției sunt de preferat.

Nu utilizați ` rmîn jurnalul activ` ca prim răspuns. Un proces poate continua să scrie printr-un descriptor de fișier deschis chiar și după ce intrarea în director este ștearsă, astfel încât spațiul pe disc așteptat s-ar putea să nu fie recuperat imediat. Trunchierea inode-ului existent este mai previzibilă atunci când o ștergere de urgență este cu adevărat necesară.

Pasul 4: Verificați atât recuperarea discului, cât și înregistrarea în jurnal continuă

După curățare, confirmați rezultatul în loc să vă bazați pe absența erorilor:

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 rezultat bun are trei semne: spațiul liber a crescut pe sistemul de fișiere dorit, audit.logexistă încă și primește evenimente noi, iar serviciile Zimbra relevante rămân în funcțiune. Dacă dfraportează în continuare un sistem de fișiere plin în timp ce dua scăzut brusc, verificați dacă există fișiere șterse care sunt încă ținute deschise de procesele care rulează înainte de a șterge mai multe date.

Verificați spațiul recuperat, activitatea recentă de audit și starea serviciului după curățare.

Alegeți soluția pe termen lung în funcție de motivul pentru care buștenii au crescut

Dacă creșterea este normală, dar retenția este prea lungă

Ajustați procesul de retenție sau de eliminare numai după documentarea perioadei de istoric necesare. Inspectați configurația existentă a crontab-ului Zimbra și a Log4j, apoi faceți cea mai mică modificare corespunzătoare versiunii. Păstrați o copie a configurației originale și testați dacă următoarea rotație creează de fapt fișierele așteptate.

Dacă zgomotul de autentificare crește volumul

Investigați sursa în loc să o ștergeți pur și simplu mai rapid. Încercările repetate de conectare, clienții configurați greșit, sondele de monitorizare sau jurnalizarea autentificării extinsă intenționat pot crește volumul auditurilor. Deoarece audit.logeste utilă pentru investigațiile de securitate, reducerea zgomotului subiacent este de obicei mai bună decât suprimarea dovezilor.

Dacă trebuie să păstrați luni întregi de istoric al auditurilor

Mutați sau expediați jurnalele către un spațiu de stocare conceput pentru păstrare. Înregistrarea centralizată, stocarea obiectelor sau un sistem de fișiere jurnal dedicat separă istoricul conformității de capacitatea necesară platformei de e-mail. Documentația fișierelor jurnal Zimbra discută în mod explicit opțiunile de înregistrare centralizată, inclusiv audit.log.

Ce să nu faci

• Nu ștergeți audit.log*cu un wildcard nerevizuit.
• Nu presupuneți că /etc/logrotate.d/zimbracontrolează jurnalul de audit activ la fiecare lansare; Zimbra documentează Log4j ca mecanism de rotație pentru audit.log.
• Nu comprimați sau arhivați pe același sistem de fișiere aproape plin decât dacă ați confirmat că există suficient spațiu temporar.
• Nu scurtați perioada de păstrare fără a verifica cerințele organizaționale, legale sau de securitate.
• Nu editați permanent fișierele Log4j generate fără a înțelege dacă Zimbra le va regenera dintr-un șablon.

Verificare finală

Dacă jurnalele vechi rotite ar fi principalul consumator, rezultatul preferat este simplu: jurnalul de audit activ rămâne intact, fișierele istorice sunt fie arhivate, fie eliminate conform politicii, iar sistemul de fișiere a recuperat suficient spațiu pentru a funcționa normal. Dacă spațiul începe imediat să dispară din nou, nu mai tratați curățarea ca soluție și investigați rata de scriere, activitatea de autentificare, configurația rotației și orice setări suplimentare de înregistrare în jurnal. Această distincție - curățare unică versus creștere recurentă - este cea care determină dacă ați rezolvat problema.