Регистрирането на всички настъпили събития е една от най-важните функции на всяка корпоративна система. Дневниците ви позволяват да решавате възникващи проблеми, да проверявате работата на информационните системи, както и да разследвате инциденти, свързани със сигурността на информацията. 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. Нека разгледаме всички нива в нарастващ ред на тежест.
- ИНФОРМАЦИЯ – Събитията на това ниво обикновено имат за цел да информират за напредъка на Zimbra OSE. Съобщенията на това ниво включват отчети за създаване или изтриване на пощенска кутия и т.н.
- ПРЕДУПРЕЖДЕНИЕ - събития от това ниво информират за ситуации, които са потенциално опасни, но не засягат работата на сървъра. Например нивото WARN маркира съобщение за неуспешен опит за влизане на потребител.
- ГРЕШКА - това ниво на събитие в дневника информира за възникване на грешка, която е локална по характер и не пречи на работата на сървъра. Това ниво може да маркира грешка, при която индексните данни на отделен потребител са се повредили.
- 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 „невалидна парола“ /opt/zimbra/log/audit.logза да получавате ежедневна информация за неуспешно влизане.
Пример за това как audit.log показва парола, въведена два пъти неправилно, и успешен опит за влизане.
Регистрационни файлове в Zimbra OSE могат да бъдат изключително полезни при идентифициране на причините за различни критични повреди. В момента, когато възникне критична грешка, администраторът обикновено няма време да прочете регистрационните файлове. Необходимо е да възстановите сървъра възможно най-скоро. Въпреки това, по-късно, когато сървърът се архивира и генерира много регистрационни файлове, може да бъде трудно да се намери необходимия запис в голям файл. За да намерите бързо запис за грешка, достатъчно е да знаете часа, в който сървърът е рестартиран, и да намерите запис в регистрационните файлове, датиращ от този момент. Предишният запис ще бъде запис на възникналата грешка. Можете също да намерите съобщението за грешка, като потърсите ключовата дума FATAL.
Регистрационните файлове на Zimbra OSE също ви позволяват да идентифицирате некритични грешки. Например, за да намерите изключения на манипулатора, можете да търсите изключение на манипулатора. Често грешките, генерирани от манипулатори, са придружени от проследяване на стека, което обяснява какво е причинило изключението. В случай на грешки при доставката на поща, трябва да започнете търсенето си с ключовата дума 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 '<[email protected]>'
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 Екатерина Триандафилиди по имейл [имейл защитен]
Източник: www.habr.com