Rejestrowanie wszystkich zdarzeń to jedna z najważniejszych funkcji każdej korporacyjnej systemu. Logi pozwalają rozwiązywać pojawiające się problemy, prowadzić audyt pracy systemów informacyjnych oraz badać incydenty związane z bezpieczeństwem informacji. Zimbra OSE również prowadzi szczegółowe logi swojej pracy. Zawierają one wszystkie dane, od wydajności serwera po wysyłanie i odbieranie wiadomości przez użytkowników. Jednak czytanie logów generowanych przez Zimbra OSE jest dość złożonym zadaniem. W tym artykule na konkretnym przykładzie opowiemy, jak czytać logi Zimbra OSE oraz jak je scentralizować.
Wszystkie lokalne logi Zimbra OSE są przechowywane w folderze /opt/zimbra/log, a logi można również znaleźć w pliku /var/log/zimbra.log. Najważniejszym z nich jest mailbox.log. Rejestruje on wszystkie działania, które zachodzą na serwerze pocztowym. Wśród nich są przesyłanie wiadomości, dane dotyczące uwierzytelniania użytkowników, nieudane próby logowania i inne. Wpisy w mailbox.log stanowią tekstowy ciąg, który zawiera czas, w którym zdarzenie wystąpiło, poziom zdarzenia, numer wątku, w ramach którego miało miejsce zdarzenie, nazwę użytkownika i jego adres IP, a także tekstowy opis zdarzenia.
Poziom logu oznacza stopień wpływu zdarzenia na działanie serwera. Domyślnie używane są 4 poziomy zdarzeń: INFO, WARN, ERROR i FATAL. Przyjrzymy się wszystkim poziomom w kolejności rosnącej ich powagi.
- INFO — zdarzenia na tym poziomie mają na celu informowanie o postępie pracy Zimbra OSE. Wśród komunikatów tego poziomu znajdują się raporty o tworzeniu lub usuwaniu skrzynek pocztowych itp.
- WARN — zdarzenia tego poziomu informują o sytuacjach, które mogą być potencjalnie niebezpieczne, ale nie wpływają na działanie serwera. Poziom WARN oznacza na przykład komunikat o nieudanej próbie logowania użytkownika.
- ERROR — ten poziom zdarzenia w logu informuje o wystąpieniu błędu, który ma charakter lokalny i nie przeszkadza w działaniu serwera. Takim poziomem może być oznaczony błąd, w którym dane indeksowe konkretnego użytkownika uległy uszkodzeniu.
- FATAL — tym poziomem oznaczane są błędy, przez które serwer nie może kontynuować normalnej pracy. Na przykład poziom FATAL będzie miał wpis o niemożności połączenia się z bazą danych.
Plik z logami serwera pocztowego jest aktualizowany codziennie. Najnowsza wersja pliku zawsze nosi nazwę Mailbox.log, podczas gdy logi z konkretnej daty mają datę w nazwie i znajdują się w archiwum. Na przykład mailbox.log.2020-09-29.tar.gz. Dzięki temu znacznie ułatwia się tworzenie kopii zapasowych i przeszukiwanie logów.
Dla wygody administratora systemu w folderze /opt/zimbra/log/ znajdują się inne logi. Zawierają one tylko te wpisy, które odnoszą się do konkretnych elementów Zimbra OSE. Na przykład w audit.log znajdują się wyłącznie wpisy dotyczące uwierzytelnienia użytkowników, w clamd.log dane o działaniu oprogramowania antywirusowego i tak dalej. Swoją drogą, doskonałą metodą ochrony serwera Zimbra OSE przed atakującymi jest , która działa na podstawie audit.log. Również dobrą praktyką jest dodanie zadania cron do wykonania polecenia grep -ir „invalid password“ /opt/zimbra/log/audit.log, aby codziennie uzyskiwać informacje o nieudanych próbach logowania.
Przykład tego, jak w logu audit.log wyświetlane są dwukrotnie błędnie wprowadzone hasło i udana próba logowania.
Logi w Zimbra OSE mogą być niezwykle przydatne podczas ustalania przyczyn różnych krytycznych awarii. W momencie, gdy dochodzi do krytycznego błędu, administratorowi zazwyczaj nie jest do czytania logów. Wymagane jest jak najszybsze przywrócenie działania serwera. Jednak później, gdy serwer ponownie działa i generuje mnóstwo logów, ciężko znaleźć potrzebny wpis w dużym pliku. Aby szybko znaleźć wpis dotyczący błędu, wystarczy znać czas, w którym serwer został ponownie uruchomiony i znaleźć w logach wpis datowany na ten czas. Poprzedni wpis będzie tym zawierającym informację o wystąpieniu błędu. Można również znaleźć komunikat o błędzie za pomocą wyszukiwania po słowie kluczowym FATAL.
Logi Zimbra OSE umożliwiają również wykrywanie drobnych awarii. Na przykład, aby znaleźć wyjątki w obsłudze, można wyszukać frazę handler exception. Często błędy generowane przez obsługę są związane z trasowaniem stosu, które wyjaśnia, co było przyczyną wystąpienia wyjątku. W przypadku błędów z dostarczaniem poczty warto rozpocząć poszukiwania od słowa kluczowego LmtpServer, a w przypadku błędów związanych z protokołami POP lub IMAP można użyć słów kluczowych ImapServer i Pop3Server.
Logi mogą również pomóc w dochodzeniach dotyczących incydentów związanych z bezpieczeństwem informacji. Rozważmy konkretny przykład. 20 września jeden z pracowników wysłał klientowi zainfekowany wirusem e-mail. W wyniku tego dane na komputerze klienta zostały zaszyfrowane. Jednak pracownik przysięga, że nic nie wysyłał. W ramach dochodzenia w sprawie incydentu dział bezpieczeństwa firmy zwraca się do administratora systemu o logi serwera pocztowego z 20 września dotyczące użytkownika, wobec którego prowadzone jest dochodzenie. Dzięki znacznikowi czasowemu administrator systemu znajduje odpowiedni plik z logami, wydobywa potrzebne informacje i przekazuje je do działu bezpieczeństwa. Ci z kolei przeglądają je i odkrywają, że adres IP, z którego wysłano ten e-mail, odpowiada adresem IP komputerowi użytkownika. Nagrania z kamer monitorujących potwierdziły, że pracownik w momencie wysyłania wiadomości znajdował się na swoim stanowisku. Tych danych wystarczyło, aby oskarżyć go o naruszenie zasad bezpieczeństwa informacji i zwolnić.
Przykład wydobycia zapisów z jednego z kont z loga Mailbox.log do oddzielnego pliku.
Wszystko staje się znacznie bardziej skomplikowane, gdy mowa o infrastrukturze wieloserwerowej. Ponieważ logi są zbierane lokalnie, praca z nimi w warunkach wieloserwerowej infrastruktury jest bardzo niewygodna, co prowadzi do potrzeby centralizacji zbierania logów. Można to osiągnąć przez konfigurację hosta do zbierania logów. Nie ma szczególnej potrzeby dodawania do infrastruktury dedykowanego hosta. Jako węzeł do zbierania logów może służyć dowolny serwer pocztowy. W naszym przypadku będzie to węzeł Mailstore01.
Na tym serwerze musimy wprowadzić poniższe komendy:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vEdytuj plik /etc/sysconfig/rsyslog i ustaw parametr SYSLOGD_OPTIONS=”-r -c 2″
Edytuj /etc/rsyslog.conf i odkomentuj następujące linie:
$ModLoad imudp
$UDPServerRun 514
Wprowadź następujące komendy:
sudo /etc/init.d/rsyslog stop
sudo /etc/init.d/rsyslog start
sudo su – zimbra
zmcontrol start
exit
sudo /opt/zimbra/libexec/zmloggerinit
sudo /opt/zimbra/bin/zmsshkeygen
sudo /opt/zimbra/bin/zmupdateauthkeysMożesz sprawdzić, czy wszystko działa, używając komendy zmprov gacf | grep zimbraLogHostname. Po wykonaniu komendy powinno zostać wyświetlone imię hosta, który zbiera logi. Aby go zmienić, wprowadź komendę zmprov mcf zimbraLogHostname mailstore01.company.ru.
Na wszystkich pozostałych serwerach infrastruktury (LDAP, MTA i innych magazynach pocztowych) wykonaj komendę zmprov gacf |grep zimbraLogHostname, aby zobaczyć nazwę hosta, na który są wysyłane logi. Aby go zmienić, również możesz wprowadzić komendę zmprov mcf zimbraLogHostname mailstore01.company.ru.
Na każdym serwerze należy również wpisać następujące komendy:
sudo su - zimbra
/opt/zimbra/bin/zmsshkeygen
/opt/zimbra/bin/zmupdateauthkeys
exit
sudo /opt/zimbra/libexec/zmsyslogsetup
sudo service rsyslog restart
sudo su - zimbra
zmcontrol restartPo tym wszystkie logi będą zapisywane na wskazanym przez Ciebie serwerze, gdzie można je wygodnie przeglądać. W konsoli administratora Zimbra OSE na ekranie z informacjami o stanie serwerów, uruchomiona usługa Logger będzie wyświetlana tylko na serwerze mailstore01.
Kolejnym problemem dla administratora może być śledzenie konkretnej wiadomości e-mail. Ponieważ wiadomości e-mail w Zimbra OSE przechodzą przez kilka różnych zdarzeń: skanowanie antywirusowe, antyspamowe i tak dalej, zanim zostaną przyjęte lub wysłane, dla administratora, w przypadku gdy wiadomość e-mail nie dotrze, może być dość problematyczne ustalenie, na którym etapie zaginęła.
Aby rozwiązać ten problem, można skorzystać ze specjalnego skryptu, który został opracowany przez specjalistę ds. bezpieczeństwa informacji, Wiktora Duchownego, i jest polecany do użycia przez programistów Postfix. Skrypt ten konkatenacyjne zapisy z logów dotyczące określonego procesu, co pozwala szybko wyświetlić wszystkie zapisy związane z wysyłaniem danego listu na podstawie jego identyfikatora. Jego działanie zostało przetestowane na wszystkich wersjach Zimbra OSE, począwszy od 8.7. Oto treść skryptu.
#! /usr/bin/perl
use strict;
use warnings;
# Postfix delivery agents
my @agents = qw(discard error lmtp local pipe smtp virtual);
my $instre = qr{(?x)
A # Absolute line start
(?:S+ s+){3} # Timestamp, adjust for other time formats
S+ s+ # Hostname
(postfix(?:-[^/s]+)?) # Capture instance name stopping before first '/'
(?:/S+)* # Optional non-captured '/'-delimited qualifiers
/ # Final '/' before the daemon program name
};
my $cmdpidre = qr{(?x)
G # Continue from previous match
(S+)[(d+)]:s+ # command[pid]:
};
my %smtpd;
my %smtp;
my %transaction;
my $i = 0;
my %seqno;
my %isagent = map { ($_, 1) } @agents;
while (<>) {
next unless m{$instre}ogc; my $inst = $1;
next unless m{$cmdpidre}ogc; my $command = $1; my $pid = $2;
if ($command eq "smtpd") {
if (m{Gconnect from }gc) {
# Start new log
$smtpd{$pid}->{"log"} = $_; next;
}
$smtpd{$pid}->{"log"} .= $_;
if (m{G(w+): client=}gc) {
# Fresh transaction
my $qid = "$inst/$1";
$smtpd{$pid}->{"qid"} = $qid;
$transaction{$qid} = $smtpd{$pid}->{"log"};
$seqno{$qid} = ++$i;
next;
}
my $qid = $smtpd{$pid}->{"qid"};
$transaction{$qid} .= $_
if (defined($qid) && exists $transaction{$qid});
delete $smtpd{$pid} if (m{Gdisconnect from}gc);
next;
}
if ($command eq "pickup") {
if (m{G(w+): uid=}gc) {
my $qid = "$inst/$1";
$transaction{$qid} = $_;
$seqno{$qid} = ++$i;
}
next;
}
# bounce(8) logs transaction start after cleanup(8) already logged
# the message-id, so the cleanup log entry may be first
#
if ($command eq "cleanup") {
next unless (m{G(w+): }gc);
my $qid = "$inst/$1";
$transaction{$qid} .= $_;
$seqno{$qid} = ++$i if (! exists $seqno{$qid});
next;
}
if ($command eq "qmgr") {
next unless (m{G(w+): }gc);
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
if (m{Gremoved$}gc) {
print delete $transaction{$qid}, "n";
}
}
next;
}
# Save pre-delivery messages for smtp(8) and lmtp(8)
#
if ($command eq "smtp" || $command eq "lmtp") {
$smtp{$pid} .= $_;
if (m{G(w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $smtp{$pid};
}
delete $smtp{$pid};
}
next;
}
if ($command eq "bounce") {
if (m{G(w+): .*? notification: (w+)$}gc) {
my $qid = "$inst/$1";
my $newid = "$inst/$2";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
$transaction{$newid} =
$_ . $transaction{$newid};
$seqno{$newid} = ++$i if (! exists $seqno{$newid});
}
next;
}
if ($isagent{$command}) {
if (m{G(w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
}
next;
}
}
# Dump logs of incomplete transactions.
foreach my $qid (sort {$seqno{$a} <=> $seqno{$b}} keys %transaction) {
print $transaction{$qid}, "n";
}Skrypt napisany jest w Perl i aby go uruchomić, należy go zapisać w pliku collate.pl, nadać mu uprawnienia wykonawcze, a następnie uruchomić plik, wskazując na plik logów i za pomocą pgrep wyodrębnić identyfikacyjne informacje poszukiwanego listu collate.pl /var/log/zimbra.log | pgrep ‘’. Rezultatem będzie sekwencyjny wydruk linii, które zawierają informacje o ruchu listu na serwerze.
# collate.pl /var/log/zimbra.log | pgrep '<20200929101700.user@mail.company.ru>'
Oct 13 10:17:00 mail postfix/pickup[4089]: 4FF14284F45: uid=1034 from=********
Oct 13 10:17:00 mail postfix/cleanup[26776]: 4FF14284F45: message-id=*******
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: from=********, size=1387, nrcpt=1 (queue active)
Oct 13 10:17:00 mail postfix/smtp[7516]: Anonymous TLS connection established to mail.*******[168.*.*.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:00 mail postfix/smtp[7516]: 4FF14284F45: to=*********, relay=mail.*******[168.*.*.4]:25, delay=0.25, delays=0.02/0.02/0.16/0.06, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 878833424CF)
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: removed
Oct 13 10:17:07 mail postfix/smtpd[21777]: connect from zimbra.******[168.*.*.4]
Oct 13 10:17:07 mail postfix/smtpd[21777]: Anonymous TLS connection established from zimbra.******[168.*.*.4]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:08 mail postfix/smtpd[21777]: 0CB69282F4E: client=zimbra.******[168.*.*.4]
Oct 13 10:17:08 mail postfix/cleanup[26776]: 0CB69282F4E: message-id=zimbra.******
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: from=zimbra.******, size=3606, nrcpt=1 (queue active)
Oct 13 10:17:08 mail postfix/virtual[5291]: 0CB69282F4E: to=zimbra.******, orig_to=zimbra.******, relay=virtual, delay=0.03, delays=0.02/0/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: removedWszelkie pytania dotyczące Zextras Suite można kierować do przedstawiciela firmy „Zextras” Ekateriny Triandafiliidi pod adresem e-mail katerina@zextras.com
Źródło: habr.com
