Ang pag-log ng lahat ng nagaganap na kaganapan ay isa sa pinakamahalagang tungkulin ng anumang sistema ng korporasyon. Binibigyang-daan ka ng mga log na lutasin ang mga umuusbong na problema, i-audit ang pagpapatakbo ng mga sistema ng impormasyon, at imbestigahan din ang mga insidente sa seguridad ng impormasyon. Pinapanatili din ng Zimbra OSE ang mga detalyadong log ng operasyon nito. Kasama sa mga ito ang lahat ng data mula sa pagganap ng server hanggang sa pagpapadala at pagtanggap ng mga email ng mga user. Gayunpaman, ang pagbabasa ng mga log na nabuo ng Zimbra OSE ay isang hindi maliit na gawain. Sa artikulong ito, gamit ang isang partikular na halimbawa, sasabihin namin sa iyo kung paano basahin ang mga log ng Zimbra OSE, pati na rin kung paano gawin itong sentralisado.
Iniimbak ng Zimbra OSE ang lahat ng lokal na log sa /opt/zimbra/log folder, at ang mga log ay maaari ding matagpuan sa /var/log/zimbra.log file. Ang pinakamahalaga sa mga ito ay mailbox.log. Itinatala nito ang lahat ng mga aksyon na nangyayari sa mail server. Kabilang dito ang pagpapadala ng mga email, data ng pagpapatunay ng user, mga nabigong pagtatangka sa pag-log in, at iba pa. Ang mga entry sa mailbox.log ay isang text string na naglalaman ng oras kung kailan nangyari ang kaganapan, ang antas ng kaganapan, ang numero ng thread kung saan nangyari ang kaganapan, ang user name at IP address, pati na rin ang isang text na paglalarawan ng kaganapan. .
Ang antas ng log ay nagpapahiwatig ng antas ng impluwensya ng kaganapan sa pagpapatakbo ng server. Bilang default, mayroong 4 na antas ng kaganapan: INFO, WARN, ERROR at FATAL. Tingnan natin ang lahat ng antas sa pagtaas ng pagkakasunud-sunod ng kalubhaan.
- INFO - Ang mga kaganapan sa antas na ito ay karaniwang nilayon upang ipaalam ang tungkol sa pag-unlad ng Zimbra OSE. Kasama sa mga mensahe sa antas na ito ang mga ulat sa paggawa o pagtanggal ng isang mailbox, at iba pa.
- WARN - ang mga kaganapan sa antas na ito ay nagpapaalam tungkol sa mga sitwasyon na posibleng mapanganib, ngunit hindi nakakaapekto sa pagpapatakbo ng server. Halimbawa, ang antas ng WARN ay nagmamarka ng isang mensahe tungkol sa isang nabigong pagsubok sa pag-login ng user.
- ERROR - ang antas ng kaganapang ito sa log ay nagpapaalam tungkol sa paglitaw ng isang error na lokal sa kalikasan at hindi nakakasagabal sa pagpapatakbo ng server. Ang antas na ito ay maaaring mag-flag ng isang error kung saan ang data ng index ng indibidwal na user ay naging sira.
- FATAL - ang antas na ito ay nagpapahiwatig ng mga error dahil sa kung saan ang server ay hindi maaaring magpatuloy na gumana nang normal. Halimbawa, ang antas ng FATAL ay para sa isang talaan na nagsasaad ng kawalan ng kakayahang kumonekta sa DBMS.
Ang file ng log ng mail server ay ina-update araw-araw. Ang pinakabagong bersyon ng file ay palaging may pangalan na Mailbox.log, habang ang mga log para sa isang tiyak na petsa ay may petsa sa pangalan at nasa archive. Halimbawa mailbox.log.2020-09-29.tar.gz. Ginagawa nitong mas madali ang pag-back up ng mga log ng aktibidad at paghahanap sa pamamagitan ng mga log.
Para sa kaginhawahan ng system administrator, ang /opt/zimbra/log/ folder ay naglalaman ng iba pang mga log. Kasama lang nila ang mga entry na nauugnay sa mga partikular na elemento ng Zimbra OSE. Halimbawa, ang audit.log ay naglalaman lamang ng mga tala tungkol sa pagpapatunay ng user, ang clamd.log ay naglalaman ng data tungkol sa pagpapatakbo ng antivirus, at iba pa. Sa pamamagitan ng paraan, ang isang mahusay na paraan ng pagprotekta sa isang Zimbra OSE server mula sa mga intruder ay , na gumagana lamang batay sa audit.log. Ito rin ay isang mahusay na kasanayan upang magdagdag ng isang cron gawain upang isagawa ang utos grep -ir "invalid password" /opt/zimbra/log/audit.logupang makatanggap ng pang-araw-araw na impormasyon sa pagkabigo sa pag-login.
Isang halimbawa kung paano ipinapakita ng audit.log ang isang password na naipasok nang dalawang beses nang hindi tama at isang matagumpay na pagtatangka sa pag-login.
Ang mga log sa Zimbra OSE ay maaaring maging lubhang kapaki-pakinabang sa pagtukoy sa mga sanhi ng iba't ibang kritikal na pagkabigo. Sa sandaling mangyari ang isang kritikal na error, ang administrator ay karaniwang walang oras upang basahin ang mga log. Kinakailangan na ibalik ang server sa lalong madaling panahon. Gayunpaman, sa paglaon, kapag ang server ay naka-back up at bumubuo ng maraming mga log, maaaring mahirap hanapin ang kinakailangang entry sa isang malaking file. Upang mabilis na makahanap ng isang talaan ng error, ito ay sapat na upang malaman ang oras kung saan ang server ay na-restart at makahanap ng isang entry sa mga log mula sa oras na ito. Ang nakaraang entry ay magiging isang talaan ng error na naganap. Maaari mo ring mahanap ang mensahe ng error sa pamamagitan ng paghahanap para sa keyword na FATAL.
Nagbibigay-daan din sa iyo ang mga log ng Zimbra OSE na tukuyin ang mga hindi kritikal na pagkabigo. Halimbawa, upang makahanap ng mga exception sa handler, maaari kang maghanap ng exception sa handler. Kadalasan, ang mga error na nabuo ng mga humahawak ay sinamahan ng isang stack trace na nagpapaliwanag kung ano ang naging sanhi ng pagbubukod. Sa kaso ng mga error sa paghahatid ng mail, dapat mong simulan ang iyong paghahanap gamit ang LmtpServer na keyword, at upang maghanap ng mga error na nauugnay sa POP o IMAP na mga protocol, maaari mong gamitin ang ImapServer at Pop3Server na mga keyword.
Makakatulong din ang mga log kapag nag-iimbestiga sa mga insidente ng seguridad ng impormasyon. Tingnan natin ang isang partikular na halimbawa. Noong Setyembre 20, nagpadala ang isa sa mga empleyado ng sulat na nahawaan ng virus sa isang kliyente. Bilang resulta, ang data sa computer ng kliyente ay na-encrypt. Gayunpaman, nanunumpa ang empleyado na wala siyang ipinadala. Bilang bahagi ng pagsisiyasat sa insidente, hinihiling ng enterprise security service mula sa system administrator ang mga log ng mail server para sa Setyembre 20 na nauugnay sa user na iniimbestigahan. Salamat sa time stamp, hinahanap ng system administrator ang kinakailangang log file, kinukuha ang kinakailangang impormasyon at inililipat ito sa mga security specialist. Ang mga iyon, sa turn, ay tingnan ito at makita na ang IP address kung saan ipinadala ang liham na ito ay tumutugma sa IP address ng computer ng gumagamit. Kinumpirma ng CCTV footage na nasa kanyang pinagtatrabahuan ang empleyado nang ipadala ang sulat. Ang data na ito ay sapat na upang akusahan siya ng paglabag sa mga panuntunan sa seguridad ng impormasyon at sibakin siya.
Isang halimbawa ng pagkuha ng mga tala tungkol sa isa sa mga account mula sa Mailbox.log log sa isang hiwalay na file
Ang lahat ay nagiging mas kumplikado pagdating sa multi-server na imprastraktura. Dahil ang mga log ay lokal na kinokolekta, ang pagtatrabaho sa kanila sa isang multi-server na imprastraktura ay napaka-abala at samakatuwid ay may pangangailangan na isentro ang koleksyon ng mga log. Magagawa ito sa pamamagitan ng pag-set up ng host para mangolekta ng mga log. Walang partikular na pangangailangang magdagdag ng dedikadong host sa imprastraktura. Ang anumang mail server ay maaaring kumilos bilang isang node para sa pagkolekta ng mga log. Sa aming kaso, ito ang magiging Mailstore01 node.
Sa server na ito kailangan nating ipasok ang mga utos sa ibaba:
sudo su β zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vI-edit ang /etc/sysconfig/rsyslog file, at itakda ang SYSLOGD_OPTIONS=β-r -c 2β³
I-edit ang /etc/rsyslog.conf at alisin sa komento ang mga sumusunod na linya:
$ModLoad imudp
$UDPServerRun 514
Ipasok ang sumusunod na mga utos:
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/zmupdateauthkeysMaaari mong suriin kung gumagana ang lahat gamit ang command na zmprov gacf | grep zimbraLogHostname. Pagkatapos isagawa ang utos, dapat ipakita ang pangalan ng host na nangongolekta ng mga log. Upang mabago ito, dapat mong ipasok ang command na zmprov mcf zimbraLogHostname mailstore01.company.ru.
Sa lahat ng iba pang mga server ng imprastraktura (LDAP, MTA at iba pang mga mail store), patakbuhin ang command na zmprov gacf |grep zimbraLogHostname upang makita ang pangalan ng host kung saan ipinapadala ang mga log. Upang baguhin ito, maaari mo ring ipasok ang command na zmprov mcf zimbraLogHostname mailstore01.company.ru
Dapat mo ring ipasok ang mga sumusunod na command sa bawat server:
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 restartPagkatapos nito, ang lahat ng mga log ay itatala sa server na iyong tinukoy, kung saan sila ay maginhawang matingnan. Gayundin, sa Zimbra OSE administrator console, sa screen na may impormasyon tungkol sa status ng mga server, ang tumatakbong serbisyo ng Logger ay ipapakita lamang para sa mailstore01 server.
Ang isa pang sakit ng ulo para sa isang administrator ay ang pagsubaybay sa isang partikular na email. Dahil ang mga email sa Zimbra OSE ay dumaan sa maraming magkakaibang mga kaganapan nang sabay-sabay: pag-scan sa pamamagitan ng antivirus, antispam, at iba pa, bago tanggapin o ipadala, para sa administrator, kung hindi dumating ang email, maaari itong maging medyo may problema sa pagsubaybay sa kung anong yugto ito ay nawala.
Upang malutas ang problemang ito, maaari kang gumamit ng isang espesyal na script, na binuo ng espesyalista sa seguridad ng impormasyon na si Viktor Dukhovny at inirerekomenda para sa paggamit ng mga developer ng Postfix. Pinagsasama-sama ng script na ito ang mga entry mula sa mga log para sa isang partikular na proseso at, dahil dito, nagbibigay-daan sa iyong mabilis na ipakita ang lahat ng mga entry na nauugnay sa pagpapadala ng isang partikular na liham batay sa identifier nito. Ang gawain nito ay nasubok sa lahat ng bersyon ng Zimbra OSE, simula sa 8.7. Narito ang teksto ng script.
#! /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";
}Ang script ay nakasulat sa Perl at upang patakbuhin ito kailangan mong i-save ito sa isang file collate.pl, gawin itong executable, at pagkatapos ay patakbuhin ang file na tumutukoy sa log file at gamit ang pgrep upang kunin ang impormasyon ng pagkakakilanlan ng sulat na iyong hinahanap collate.pl /var/log/zimbra.log | pgrep '[protektado ng email]> '. Ang resulta ay isang sequential output ng mga linya na naglalaman ng impormasyon tungkol sa paggalaw ng sulat sa server.
# 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: removedPara sa lahat ng tanong na may kaugnayan sa Zextras Suite, maaari kang makipag-ugnayan kay Zextras Representative Ekaterina Triandafilidi sa pamamagitan ng email [protektado ng email]
Pinagmulan: www.habr.com