Лагіраванне ўсіх падзей, якія адбываюцца, - адна з найбольш важных функцый любой карпаратыўнай сістэмы. Логі дазваляюць вырашаць узнікаючыя праблемы, праводзіць аўдыт працы інфармацыйных сістэм, а таксама расследаваць інцыдэнты інфармацыйнай бяспекі. 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";
}Cкрыпт напісаны на 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» Кацярыны Трыяндафілідзі па электроннай пошце. [электронная пошта абаронена]
Крыніца: habr.com