Registrado de ĉiuj okazantaj eventoj estas unu el la plej gravaj funkcioj de iu ajn kompania sistemo. Registroj permesas solvi emerĝantajn problemojn, kontroli la funkciadon de informaj sistemoj kaj ankaŭ esplori incidentojn pri informa sekureco. Zimbra OSE ankaŭ konservas detalajn protokolojn de sia operacio. Ili inkluzivas ĉiujn datumojn de servila agado ĝis sendado kaj ricevado de retpoŝtoj de uzantoj. Tamen, legi la protokolojn generitajn de Zimbra OSE estas sufiĉe ne-triviala tasko. En ĉi tiu artikolo, uzante specifan ekzemplon, ni diros al vi kiel legi Zimbra OSE-protokolojn, kaj ankaŭ kiel centralizi ilin.
Zimbra OSE konservas ĉiujn lokajn protokolojn en la dosierujo /opt/zimbra/log, kaj protokoloj ankaŭ troviĝas en la /var/log/zimbra.log-dosiero. La plej grava el ĉi tiuj estas mailbox.log. Ĝi registras ĉiujn agojn, kiuj okazas sur la poŝtservilo. Ĉi tiuj inkluzivas la transdonon de retpoŝtoj, uzantajn aŭtentikajn datumojn, malsukcesajn ensalutprovojn kaj aliajn. Enskriboj en mailbox.log estas teksta ĉeno, kiu enhavas la tempon, kiam la okazaĵo okazis, la nivelon de la evento, la fadennumeron en kiu la evento okazis, la uzantnomon kaj IP-adreson, kaj ankaŭ tekstan priskribon de la evento. .
La lognivelo indikas la gradon de influo de la evento sur la funkciado de la servilo. Defaŭlte ekzistas 4 eventoniveloj: INFO, AVERTO, ERARO kaj FATAL. Ni rigardu ĉiujn nivelojn en kreskanta ordo de severeco.
- INFO - Eventoj ĉe ĉi tiu nivelo kutime intencas informi pri la progreso de Zimbra OSE. Mesaĝoj ĉe ĉi tiu nivelo inkluzivas raportojn pri kreado aŭ forigo de leterkesto ktp.
- AVERTU - eventoj de ĉi tiu nivelo informas pri situacioj potenciale danĝeraj, sed ne influas la funkciadon de la servilo. Ekzemple, la WARN-nivelo markas mesaĝon pri malsukcesa uzanta ensalutprovo.
- ERARO - ĉi tiu eventonivelo en la protokolo informas pri la okazo de eraro, kiu estas loka nature kaj ne malhelpas la funkciadon de la servilo. Ĉi tiu nivelo povas marki eraron en kiu la indeksaj datumoj de individua uzanto koruptiĝis.
- FATAL - ĉi tiu nivelo indikas erarojn pro kiuj la servilo ne povas daŭrigi normale funkcii. Ekzemple, la FATAL-nivelo estos por rekordo indikanta la malkapablon konekti al la DBMS.
La protokoldosiero de poŝtservilo estas ĝisdatigita ĉiutage. La plej nova versio de la dosiero ĉiam havas la nomon Mailbox.log, dum protokoloj por certa dato havas daton en la nomo kaj estas enhavitaj en la arkivo. Ekzemple mailbox.log.2020-09-29.tar.gz. Ĉi tio multe pli facilas konservi agadprotokolojn kaj serĉi tra protokoloj.
Por la komforto de la sistemadministranto, la dosierujo /opt/zimbra/log/ enhavas aliajn protokolojn. Ili nur inkluzivas enskribojn, kiuj rilatas al specifaj elementoj de Zimbra OSE. Ekzemple, audit.log enhavas nur rekordojn pri uzantaŭtentigo, clamd.log enhavas datumojn pri la funkciado de la antiviruso, ktp. Cetere, bonega metodo protekti Zimbra OSE-servilon kontraŭ entrudiĝintoj estas , kiu nur funkcias surbaze de audit.log. Ankaŭ estas bona praktiko aldoni cron-taskon por ekzekuti la komandon grep -ir „nevalida pasvorto“ /opt/zimbra/log/audit.logricevi ĉiutagajn informojn pri malsukcesa ensaluto.
Ekzemplo de kiel audit.log montras pasvorton enigitan dufoje malĝuste kaj sukcesan ensalutprovon.
Registroj en Zimbra OSE povas esti ekstreme utilaj por identigi la kaŭzojn de diversaj kritikaj fiaskoj. En la momento, kiam okazas kritika eraro, la administranto kutime ne havas tempon por legi la protokolojn. Necesas restarigi la servilon kiel eble plej baldaŭ. Tamen poste, kiam la servilo refunkcias kaj generas multajn protokolojn, povas esti malfacile trovi la postulatan eniron en granda dosiero. Por rapide trovi erarrekordon, sufiĉas scii la tempon, kiam la servilo estis rekomencita kaj trovi enskribon en la protokoloj de ĉi tiu tempo. La antaŭa enskribo estos rekordo de la eraro kiu okazis. Vi ankaŭ povas trovi la erarmesaĝon serĉante la ŝlosilvorton FATAL.
Zimbra OSE-protokoloj ankaŭ permesas vin identigi ne-kritikajn fiaskojn. Ekzemple, por trovi pritraktilajn esceptojn, vi povas serĉi pritraktilan escepton. Ofte, eraroj generitaj de prizorgantoj estas akompanitaj de stakspuro, kiu klarigas kio kaŭzis la escepton. En kazo de eraroj kun poŝta liverado, vi devas komenci vian serĉon per la ŝlosilvorto LmtpServer, kaj por serĉi erarojn rilatajn al la protokoloj POP aŭ IMAP, vi povas uzi la ŝlosilvortojn ImapServer kaj Pop3Server.
Registroj ankaŭ povas helpi kiam oni esploras incidentojn pri informa sekureco. Ni rigardu specifan ekzemplon. La 20-an de septembro, unu el la dungitoj sendis virus-infektitan leteron al kliento. Kiel rezulto, la datumoj sur la komputilo de la kliento estis ĉifritaj. Tamen la dungito ĵuras, ke li nenion sendis. Kadre de la enketo pri la okazaĵo, la entreprena sekureca servo petas de la sistemadministranto la poŝtservilon protokolojn por septembro 20 asociitaj kun la uzanto estanta enketita. Danke al la tempomarko, la sistemadministranto trovas la necesan protokolan dosieron, ĉerpas la necesajn informojn kaj transdonas ĝin al sekurecaj specialistoj. Tiuj, siavice, trarigardas ĝin kaj trovas, ke la IP-adreso de kiu ĉi tiu letero estis sendita respondas al la IP-adreso de la komputilo de la uzanto. CCTV-filmaĵo konfirmis ke la dungito estis ĉe sia laborejo kiam la letero estis sendita. Ĉi tiuj datumoj sufiĉis por akuzi lin pri malobservo de informsekurecaj reguloj kaj maldungi lin.
Ekzemplo de eltiro de rekordoj pri unu el la kontoj el la leterkesto.log ensaluti en apartan dosieron
Ĉio fariĝas multe pli komplika kiam temas pri plurservila infrastrukturo. Ĉar ŝtipoj estas kolektitaj loke, labori kun ili en plurservila infrastrukturo estas tre maloportuna kaj tial necesas centralizi la kolekton de ŝtipoj. Ĉi tio povas esti farita agordante gastiganton por kolekti ŝtipojn. Ne estas aparta bezono aldoni dediĉitan gastiganton al la infrastrukturo. Ajna poŝtservilo povas funkcii kiel nodo por kolekti protokolojn. En nia kazo, ĉi tio estos la nodo Mailstore01.
Sur ĉi tiu servilo ni devas enigi la subajn komandojn:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vRedaktu la /etc/sysconfig/rsyslog dosieron, kaj agordu la SYSLOGD_OPTIONS="-r -c 2″
Redaktu /etc/rsyslog.conf kaj malkomenti la sekvajn liniojn:
$ModLoad imudp
$UDPServerRun 514
Enigu la jenajn komandojn:
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/zmupdateauthkeysVi povas kontroli, ke ĉio funkcias per la komando zmprov gacf | grep zimbraLogHostname. Post ekzekuto de la komando, la nomo de la gastiganto, kiu kolektas protokolojn, devas esti montrita. Por ŝanĝi ĝin, vi devas enigi la komandon zmprov mcf zimbraLogHostname mailstore01.company.ru.
Sur ĉiuj aliaj infrastrukturaj serviloj (LDAP, MTA kaj aliaj poŝtbutikoj), rulu la komandon zmprov gacf |grep zimbraLogHostname por vidi la nomon de la gastiganto al kiu la protokoloj estas senditaj. Por ŝanĝi ĝin, vi ankaŭ povas enigi la komandon zmprov mcf zimbraLogHostname mailstore01.company.ru
Vi ankaŭ devas enigi la jenajn komandojn en ĉiu servilo:
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 restartPost ĉi tio, ĉiuj protokoloj estos registritaj sur la servilo, kiun vi specifis, kie ili povas esti oportune viditaj. Ankaŭ, en la administranto-konzolo de Zimbra OSE, sur la ekrano kun informoj pri la stato de serviloj, la funkcianta Logger-servo aperos nur por la servilo mailstore01.
Alia kapdoloro por administranto povas esti konservi trakon de specifa retpoŝto. Ĉar retpoŝtoj en Zimbra OSE trapasas plurajn malsamajn eventojn samtempe: skanado per antiviruso, kontraŭspamo, ktp, antaŭ ol esti akceptitaj aŭ senditaj, por la administranto, se la retpoŝto ne alvenas, povas esti sufiĉe probleme spuri en kiu etapo. ĝi estis perdita.
Por solvi ĉi tiun problemon, vi povas uzi specialan skripton, kiu estis ellaborita de informsekureca specialisto Viktor Dukhovny kaj rekomendita por uzo de Postfix-programistoj. Ĉi tiu skripto kunligas enskribojn el protokoloj por specifa procezo kaj, pro tio, permesas al vi rapide montri ĉiujn enskribojn asociitajn kun sendado de aparta letero bazita sur ĝia identigilo. Ĝia laboro estis provita en ĉiuj versioj de Zimbra OSE, ekde 8.7. Jen la teksto de la skripto.
#! /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";
}La skripto estas skribita en Perl kaj por ruli ĝin vi devas konservi ĝin al dosiero kolate.pl, faru ĝin efektivigebla, kaj poste rulu la dosieron specifante la protokoldosieron kaj uzante pgrep por ĉerpi la identigan informon de la letero, kiun vi serĉas. collate.pl /var/log/zimbra.log | pgrep '[retpoŝte protektita]>'. La rezulto estos sinsekva eligo de linioj enhavantaj informojn pri la movado de la letero sur la servilo.
# 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: removedPor ĉiuj demandoj rilataj al Zextras Suite, vi povas kontakti la Reprezentanton de Zextras Ekaterina Triandafilidi retpoŝte [retpoŝte protektita]
fonto: www.habr.com