Jak wyczyścić dzienniki audytu Zimbra, aby bezpiecznie zwolnić miejsce na dysku

Zacznij od zdecydowania, co faktycznie musisz usunąć

Serwer Zimbra, któremu brakuje miejsca na dysku, może sprawiać, że czyszczenie logów wydaje się pilne, ale /opt/zimbra/log/audit.lognie jest to tylko jednorazowy wynik diagnostyki. Zimbra dokumentuje to jako ślad audytu zdarzeń uwierzytelniania i aktywności administracyjnej. Oznacza to, że najlepsza metoda czyszczenia zależy od tego, czy potrzebujesz natychmiastowego miejsca, historycznych dowodów, czy też długoterminowego rozwiązania.

Najbezpieczniejszym rozwiązaniem domyślnym jest pozostawienie aktywnego audit.logpliku w spokoju i zajęcie się najpierw starszymi, rotowanymi kopiami. Jeśli obowiązuje wewnętrzna polityka przechowywania, nakaz sądowy lub wymóg zgodności, zarchiwizuj te pliki w innym systemie plików przed usunięciem czegokolwiek. Jeśli sam aktywny plik stał się nienormalnie duży, możesz go wyczyścić, ale należy to traktować jako środek awaryjny, ponieważ usuwa on bieżącą historię audytu i może wprowadzić niewielkie okno czasowe, jeśli serwer będzie kontynuował zapis podczas kopiowania.

Własna dokumentacja Zimbra dotycząca rejestrowania logów audit.logopisuje /opt/zimbra/logLog4j jako komponent odpowiedzialny za rotację plików, takich jak audit.logi mailbox.log. Inne logi Zimbra mogą korzystać z konfiguracji systemu operacyjnego logrotate, więc nie należy zakładać, że każdy plik w katalogu działa zgodnie z tym samym mechanizmem. Zapoznaj się z oficjalnymi informacjami dotyczącymi plików dziennika Zimbra oraz notatkami dotyczącymi rotacji dziennika Zimbra .

Porównaj opcje czyszczenia przed podjęciem działania

Krok 1: Zmierz problem przed usunięciem czegokolwiek

Najpierw sprawdź, czy logi audytu rzeczywiście odpowiadają za ciśnienie. Uruchom je jako root:

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

Pierwsze polecenie informuje o zapełnieniu systemu plików /opt. Drugie pokazuje ogólny rozmiar logów Zimbra. Trzecie ujawnia aktywny plik audytu i wszelkie rotowane generacje. Jeśli pliki audytu stanowią tylko niewielką część systemu plików, ich wyczyszczenie może nie rozwiązać rzeczywistego problemu; zamiast tego miejsce mogą zajmować magazyny skrzynek pocztowych, kopie zapasowe, pliki bazy danych lub inna rodzina logów.

Przed zmianą zachowania zapisz także zainstalowaną wersję:

su - zimbra -c 'zmcontrol -v'

Ma to znaczenie, ponieważ dokumentacja Zimbra obejmuje wiele generacji produktów, a dokładna składnia Log4j, generowana konfiguracja i zadania czyszczenia mogą się różnić. Nie kopiuj wartości retencji ze starego przykładu wiki i nie zakładaj, że jest to Twoja aktualna wartość domyślna.

Sprawdź wykorzystanie systemu plików, całkowity rozmiar dziennika Zimbra i poszczególne generacje dziennika audytu przed podjęciem decyzji, co usunąć.

Krok 2: Sprawdź, jak ten serwer obraca i przycina logi

Zimbra dokumentuje dwa istotne mechanizmy: Log4j dla plików, w tym audit.log, oraz system operacyjny logrotatedla kilku innych logów Zimbry. Zauważa również, że własny crontab Zimbry może zawierać zadania związane z konserwacją logów. Zamiast zgadywać, sprawdź konfigurację na żywo:

su - zimbra
crontab -l
exit

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

Jeśli któryś z tych plików nie zawiera oczekiwanego ustawienia w Twojej wersji, sprawdź otaczającą go konfigurację logowania, zamiast na siłę instalować starszy przykład. Wygenerowane pliki można również nadpisać po ponownym uruchomieniu usługi lub regeneracji konfiguracji. Uwagi dotyczące logowania Zimbry wyraźnie odróżniają tymczasowe zmiany w wygenerowanym pliku właściwości od trwałych zmian wprowadzonych w odpowiednim .inszablonie.

W przypadku serwerów o nieoczekiwanie dużej objętości audytu należy sprawdzić, czy celowo włączono dodatkowe logowanie. Informacje o wydaniu Zimbra 10.0.6 dokumentują zimbra_additional_loggingatrybut konfiguracji lokalnej, który może dodać więcej nieudanych lub w inny sposób użytecznych zdarzeń uwierzytelniania audit.log. Nie należy wyłączać przydatnego logowania bezpieczeństwa tylko po to, aby zaoszczędzić miejsce; jeśli objętość jest prawidłowa, lepszym rozwiązaniem jest zazwyczaj retencja, kompresja lub scentralizowane przechowywanie logów. Zobacz oficjalne informacje o wydaniu Zimbra 10.0.6 .

Przed zmianą zachowania retencji lub rotacji sprawdź aktualną konfigurację crontab i Log4j serwera.

Krok 3: Preferuj archiwizację lub usuwanie obróconych dzienników w pierwszej kolejności

Dla większości administratorów najlepszym pierwszym celem są stare, rotowane dzienniki audytu. Używaj ich findw trybie tylko raportowania, zanim cokolwiek usuniesz. Poniższy przykład przedstawia rotowane dzienniki audytu starsze niż 30 dni; 30 dni to tylko przykładowy próg, a nie okres przechowywania określony przez Zimbra:

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

Jeśli te pliki nie są już potrzebne, usuń tylko sprawdzone pliki po rotacji. Jeśli musisz je zachować, najpierw skopiuj je lub zarchiwizuj do innego systemu plików. Użycie innego montowania jest ważne, gdy partycja Zimbra jest już prawie pełna, ponieważ utworzenie skompresowanego archiwum na tym samym pełnym systemie plików może tymczasowo zająć jeszcze więcej miejsca.

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

Powtórz dla dokładnie tych samych nazw plików, które sprawdziłeś. Przed usunięciem źródła sprawdź kopię zapasową. Unikaj szerokich wzorców, takich jak rm -f /opt/zimbra/log/audit.log*; ten wzorzec pasuje również do aktywnego pliku.

Jeśli chcesz zachować stare logi lokalnie, ale zmniejszyć ich rozmiar, kompresuj tylko obrócone pliki:

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

To, czy kompresja jest opłacalna, zależy od aktualnej konfiguracji rotacji. Niektóre wdrożenia mogą już kompresować historyczne logi w ramach konserwacji. Sprawdź, co faktycznie istnieje, zanim dodasz kolejną warstwę.

Wskazówki Zimbra dotyczące rejestrowania danych historycznych ostrzegają również, że logi audytu mogą zawierać poufne dane. Archiwa należy traktować z takimi samymi uprawnieniami dostępu jak logi bieżące. Zapoznaj się z oficjalnymi wskazówkami Zimbra dotyczącymi rejestrowania danych .

Najpierw wypisz stare, obrócone pliki, skopiuj wymaganą historię do osobnego magazynu i dopiero wtedy usuń sprawdzone generacje.

Kiedy uzasadnione jest obcięcie aktywnego dziennika audytu

Jeśli obrócone pliki nie stanowią problemu, a audit.logsam plik aktywny zajmuje krytyczne miejsce, obcięcie pozwala natychmiast odzyskać miejsce. Jest to również opcja z najwyraźniejszym kompromisem: bieżąca historia audytu zostaje zniszczona po obcięciu pliku.

Bezpieczniejszą procedurą awaryjną jest chwilowe zatrzymanie mailboxd, skopiowanie aktywnego pliku do innego systemu plików, przycięcie oryginału w miejscu, tak aby zachować własność i uprawnienia, a następnie ponowne uruchomienie 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'

Wprowadza to przestoje w działaniu usługi pocztowej, więc nie jest to właściwy wybór dla każdego środowiska. Skopiowanie pliku live bez zatrzymywania mailboxd pozwala uniknąć przestoju, ale stwarza ryzyko utraty wpisów zapisanych po skopiowaniu i przed obcięciem. Jeśli obciążenie dysku nie jest duże, zaleca się wyczyszczenie obróconych plików i skorygowanie retencji.

Nie używaj opcji „ rmon the active log” jako pierwszej odpowiedzi. Proces może kontynuować zapis przez otwarty deskryptor pliku nawet po usunięciu wpisu w katalogu, więc oczekiwana przestrzeń dyskowa może nie zostać odzyskana od razu. Obcięcie istniejącego i-węzła jest bardziej przewidywalne, gdy awaryjne wyczyszczenie jest rzeczywiście konieczne.

Krok 4: Sprawdź odzyskiwanie dysku i dalsze rejestrowanie

Po oczyszczeniu potwierdź wynik zamiast polegać na braku błędów:

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'

Dobry wynik ma trzy oznaki: ilość wolnego miejsca w docelowym systemie plików wzrosła, audit.logmiejsce nadal istnieje i odbiera nowe zdarzenia, a odpowiednie usługi Zimbra nadal działają. Jeśli dfsystem plików nadal zgłasza zapełnienie du, a jego ilość gwałtownie spadła, przed usunięciem kolejnych danych sprawdź, czy nie usunięto plików, które są nadal otwarte przez uruchomione procesy.

Po oczyszczeniu sprawdź odzyskaną przestrzeń, ostatnią aktywność audytu i stan usługi.

Wybierz rozwiązanie długoterminowe w oparciu o przyczynę wzrostu logów

Jeśli wzrost jest normalny, ale zatrzymanie jest zbyt długie

Dostosuj proces retencji lub usuwania danych dopiero po udokumentowaniu wymaganego okresu historii. Sprawdź istniejącą konfigurację crontab Zimbra i Log4j, a następnie wprowadź najmniejszą zmianę odpowiednią do wersji. Zachowaj kopię oryginalnej konfiguracji i sprawdź, czy kolejna rotacja rzeczywiście utworzy oczekiwane pliki.

Jeśli hałas uwierzytelniania powoduje wzrost głośności

Zbadaj źródło, zamiast po prostu szybciej usuwać. Wielokrotne próby logowania, błędnie skonfigurowani klienci, sondy monitorujące lub celowo rozszerzone rejestrowanie uwierzytelniania mogą zwiększyć liczbę audytów. Ponieważ audit.logjest to przydatne w dochodzeniach dotyczących bezpieczeństwa, redukcja szumu informacyjnego jest zazwyczaj lepsza niż tłumienie dowodów.

Jeśli musisz zachować historię audytów obejmującą miesiące

Przenieś lub prześlij logi do pamięci masowej przeznaczonej do przechowywania. Scentralizowane rejestrowanie, przechowywanie obiektów lub dedykowany system plików logów oddziela historię zgodności od pojemności wymaganej przez platformę pocztową. Dokumentacja plików logów Zimbra wyraźnie omawia kandydatów do scentralizowanego rejestrowania, w tym pliki audit.log.

Czego nie robić

• Nie usuwaj audit.log*przy użyciu nieprzeanalizowanego symbolu wieloznacznego.
• Nie zakładaj, że /etc/logrotate.d/zimbrakontrolujesz aktywny dziennik audytu przy każdym wydaniu; Zimbra dokumentuje Log4j jako mechanizm rotacji dla audit.log.
• Nie kompresuj ani nie archiwizuj na niemal pełnym systemie plików, dopóki nie upewnisz się, że jest w nim wystarczająca ilość miejsca tymczasowego.
• Nie należy skracać okresu przechowywania danych bez sprawdzenia wymogów organizacyjnych, prawnych lub bezpieczeństwa.
• Nie edytuj wygenerowanych plików Log4j w sposób trwały, jeśli nie wiesz, czy Zimbra wygeneruje je ponownie na podstawie szablonu.

Ostateczna kontrola

Gdyby głównym odbiorcą były stare, rotowane logi, preferowany wynik byłby prosty: aktywny dziennik audytu pozostaje nienaruszony, historyczne pliki są archiwizowane lub usuwane zgodnie z polityką, a system plików odzyskuje wystarczającą ilość wolnej przestrzeni, aby działać normalnie. Jeśli miejsce natychmiast zacznie ponownie znikać, przestań traktować czyszczenie jako rozwiązanie i sprawdź szybkość zapisu, aktywność uwierzytelniania, konfigurację rotacji i wszelkie dodatkowe ustawienia rejestrowania. To rozróżnienie – jednorazowe czyszczenie w porównaniu z cyklicznym wzrostem – decyduje o tym, czy problem został faktycznie rozwiązany.