Регистрирането на всички настъпили събития е една от най-важните функции на всяка корпоративна система. Логовете позволяват да се решават възникнали проблеми, да се провежда одит на работата на информационните системи и да се разследват инциденти в информационната сигурност. Zimbra OSE също така поддържа подробни логове на работата си. В тях попадат всички данни от производителността на сървъра до изпращането и получаването на имейли от потребителите. Въпреки това, четенето на логовете, генерирани от Zimbra OSE, е доста нетривиална задача. В тази статия с конкретен пример ще ви разкажем как да четете логовете на Zimbra OSE и как да ги централизирате.
Всички локални логове на Zimbra OSE се съхраняват в папката /opt/zimbra/log, както и логовете могат да бъдат намерени в файла /var/log/zimbra.log. Най-важният от тях е mailbox.log. В него се регистрират всички действия, които се извършват на пощенския сървър. Сред тях са предаването на имейли, данни за удостоверяване на потребители, неуспешни опити за влизане и други. Записите в mailbox.log представляват текстова линия, която съдържа времето, в което е настъпило събитието, нивото на събитието, номера на потока, в рамките на който е протекло събитието, името на потребителя и неговия IP адрес, както и текстово описание на събитието.
Нивото на логовете означава степента на влияние на събитието върху работата на сървъра. По подразбиране се използват 4 нива на събития: INFO, WARN, ERROR и FATAL. Нека разгледаме всички нива по възходящ ред на тяхната сериозност.
- INFO — събитията на това ниво обикновено са предназначени да информират за хода на работата на Zimbra OSE. Сред съобщенията на това ниво са отчетите за създаване или изтриване на пощенска кутия и т.н.
- WARN — събитията на това ниво информират за ситуации, които са потенциално опасни, но не влияят на работата на сървъра. Нивото WARN например обозначава съобщение за неуспешен опит за влизане на потребител.
- ERROR — това ниво на събития в логовете информира за възникнала грешка, която е локална и не пречи на работата на сървъра. Такава грешка може да бъде обозначена, когато индексните данни на отделен потребител са повредени.
- FATAL — с това ниво се обозначават грешки, поради които сървърът не може да продължи да работи нормално. Например, запис за невъзможност да се свърже с базата данни ще има ниво FATAL.
Файл с логовете на пощенския сървър се обновява всеки ден. Свежата версия на файла винаги носи името Mailbox.log, докато логовете за определен период имат датата в названието и се съдържат в архива. Например mailbox.log.2020-09-29.tar.gz. Благодарение на това резервирането на журналите за действия и търсенето в логовете значително се улеснява.
За удобство на системния администратор в папката /opt/zimbra/log/ се намират и други логове. В тях са включени само записи, които се отнасят до конкретни елементи на Zimbra OSE. Например в audit.log се съдържат единствено записи за удостоверяване на потребители, в clamd.log данни за работата на антивируса и така нататък. Между другото, отличен метод за защита на Zimbra OSE от злонамерени атаки е , която функционира на базата на audit.log. Също така, добра практика е да се добави cron задача за изпълнение на командата grep -ir „invalid password“ /opt/zimbra/log/audit.log, за да се получава ежедневно информация за неуспешни опити за влизане.
Пример как в лог файла audit.log се записват два неуспешни опита за въвеждане на парола и един успешен опит за влизане.
Логовете в Zimbra OSE могат да бъдат изключително полезни за установяване на причините за различни критични сривове. В момента, когато се случи критична грешка, администраторът обикновено няма време да чете логовете. Необходимо е възможно най-бързо да се възстанови работата на сървъра. Въпреки това, след това, когато сървърът отново работи и генерира множество логове, намирането на необходимия запис в голям файл може да бъде трудно. За да намерите бързо записа за грешка, е достатъчно да знаете времето, в което сървърът е бил рестартиран и да намерите в логовете записа, датиран с това време. Предходният запис ще бъде записът за възникналата грешка. Можете също така да намерите съобщение за грешка, използвайки ключовата дума FATAL.
Също така логовете на Zimbra OSE позволяват откриването на некритични грешки. Например, за да намерите изключения на обработчика, можете да търсите по фразата handler exception. Често грешките, генерирани от обработчиците, са придружени от трасировка на стека, която обяснява причините за възникването на изключението. В случай на грешки с доставката на поща, трябва да започнете търсенето с ключовата дума LmtpServer, а за търсене на грешки, свързани с протоколите POP или IMAP, можете да използвате ключовите думи ImapServer и Pop3Server.
Логовете също могат да помогнат при разследване на инциденти с информационна сигурност. Нека разгледаме конкретен пример. На 20 септември един от служителите е изпратил на клиент заразено с вирус писмо. В резултат на това данните на компютъра на клиента са били криптирани. Въпреки това служителят твърди, че не е изпращал нищо. В рамките на разследването на инцидента, службата за сигурност на предприятието изисква от системния администратор логовете на пощенския сървър за 20 септември, свързани с потребителя, по отношение на когото върви разследването. Благодарение на времевия отпечатък системният администратор открива нужния файл с логовете, извлича необходимата информация и я предава на служителите по сигурността. Те от своя страна я преглеждат и откриват, че IP адресът, от който е изпратено писмото, съответства IP адрес на компютъра на потребителя. Записите от видеонаблюдението потвърдили, че служителят е бил на работното си място в момента на изпращане на писмото. Тези данни бяха достатъчни, за да го обвинят в нарушаване на правилата за информационна сигурност и да го уволнят.
Пример за извличане на записи за една от сметките от лога Mailbox.log в отделен файл
Всичко става значително по-трудно, когато става въпрос за много-сървърна инфраструктура. Тъй като логовете се събират локално, работата с тях в условия на много-сървърна инфраструктура е много неудобна и поради това се налага централизация на събирането на логовете. Това може да се постигне чрез настройка на хост за събиране на логове. Няма особена нужда да добавяте в инфраструктурата специален хост. В качеството на възел за събиране на логове може да служи всеки пощенски сървър. В нашия случай това ще бъде възел Mailstore01.
На този сървър е необходимо да въведем командите, посочени по-долу:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vРедактирайте файла /etc/sysconfig/rsyslog и задайте параметър SYSLOGD_OPTIONS="-r -c 2"
Редактирайте /etc/rsyslog.conf и разкоментирайте следните редове:
$ModLoad imudp
$UDPServerRun 514
Въведете следните команди:
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/zmupdateauthkeysМожете да проверите дали всичко работи с командата zmprov gacf | grep zimbraLogHostname. След изпълнението на командата трябва да се покаже името на хоста, който събира логовете. За да го промените, въведете командата zmprov mcf zimbraLogHostname mailstore01.company.ru.
На всички останали сървъри в инфраструктурата (LDAP, MTA и други пощински хранилища) изпълнете командата zmprov gacf | grep zimbraLogHostname, за да видите името на хоста, на който отиват логовете. За да го промените, можете също да въведете командата zmprov mcf zimbraLogHostname mailstore01.company.ru.
Също така на всеки сървър е необходимо да се въведат следните команди:
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 restartСлед това всички логове ще се записват на указаното от вас сървър, откъдето може да ги преглеждате удобно. Също така в консолата на администратора Zimbra OSE на екрана с информация за състоянието на сървърите, стартираната услуга Logger ще се показва само на сървера mailstore01.
Още една болка в главата за администратора може да стане проследяването на конкретно електронно съобщение. Понеже електронните писма в Zimbra OSE преминават през няколко различни събития: проверка с антивирус, антиспам и така нататък, преди да бъдат приети или изпратени, на администратора, в случай че електронното писмо не достига, може да бъде доста трудно да проследи на кой етап е загубено.
За да се реши този проблем, може да се използва специален скрипт, разработен от експерта по информационна сигурност Виктор Духовни, препоръчан за употреба от разработчиците на Postfix. Този скрипт конкатенира записи от логовете по определен процес и така позволява бързо да се отразят всички записи, свързани с изпращането на конкретно писмо на базата на неговия идентификатор. Работата му е тествана на всички версии на Zimbra OSE, започвайки от 8.7. Представяме текста на скрипта.
#! /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";
}Скриптът е написан на Perl и за неговото стартиране е необходимо да бъде запазен в файл collate.pl, да се направи изпълним и след това да се стартира файлът с указание за файла с логовете и с помощта на pgrep да се извлече идентификационната информация на търсеното писмо collate.pl /var/log/zimbra.log | pgrep ''. Резултатът ще бъде последователен изход на редове, съдържащи информация за движението на писмото на сървъра.
# 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: removedЗа всички въпроси, свързани с Zextras Suite, можете да се свържете с представителя на компанията „Zextras“ Екатерина Триандафилиди на имейл katerina@zextras.com
Източник: habr.com
