Pengelogan semua peristiwa yang berlaku adalah salah satu fungsi terpenting mana-mana sistem korporat. Log membolehkan anda menyelesaikan masalah yang timbul, mengaudit operasi sistem maklumat, dan juga menyiasat insiden keselamatan maklumat. Zimbra OSE juga menyimpan log terperinci operasinya. Ia termasuk semua data daripada prestasi pelayan kepada penghantaran dan penerimaan e-mel oleh pengguna. Walau bagaimanapun, membaca log yang dijana oleh Zimbra OSE adalah tugas yang agak tidak remeh. Dalam artikel ini, menggunakan contoh khusus, kami akan memberitahu anda cara membaca log Zimbra OSE, serta cara menjadikannya terpusat.
Zimbra OSE menyimpan semua log tempatan dalam folder /opt/zimbra/log, dan log juga boleh ditemui dalam fail /var/log/zimbra.log. Yang paling penting ialah peti mel.log. Ia merekodkan semua tindakan yang berlaku pada pelayan mel. Ini termasuk penghantaran e-mel, data pengesahan pengguna, percubaan log masuk yang gagal dan lain-lain. Entri dalam mailbox.log ialah rentetan teks yang mengandungi masa peristiwa itu berlaku, tahap acara, nombor urutan peristiwa itu berlaku, nama pengguna dan alamat IP, serta perihalan teks acara itu. .
Tahap log menunjukkan tahap pengaruh peristiwa pada operasi pelayan. Secara lalai terdapat 4 peringkat acara: INFO, WARN, ERROR dan FATAL. Mari kita lihat semua peringkat dalam urutan keterukan yang semakin meningkat.
- INFO - Acara di peringkat ini biasanya bertujuan untuk memaklumkan tentang kemajuan Zimbra OSE. Mesej pada tahap ini termasuk laporan tentang penciptaan atau pemadaman peti mel dan sebagainya.
- AMARAN - peristiwa peringkat ini memaklumkan tentang situasi yang berpotensi berbahaya, tetapi tidak menjejaskan operasi pelayan. Sebagai contoh, tahap WARN menandakan mesej tentang percubaan log masuk pengguna yang gagal.
- ERROR - peringkat peristiwa dalam log ini memaklumkan tentang berlakunya ralat yang bersifat setempat dan tidak mengganggu operasi pelayan. Tahap ini boleh membenderakan ralat di mana data indeks pengguna individu telah rosak.
- FATAL - tahap ini menunjukkan ralat yang disebabkan oleh pelayan tidak dapat terus beroperasi seperti biasa. Sebagai contoh, tahap FATAL adalah untuk rekod yang menunjukkan ketidakupayaan untuk menyambung ke DBMS.
Fail log pelayan mel dikemas kini setiap hari. Versi terkini fail sentiasa mempunyai nama Mailbox.log, manakala log untuk tarikh tertentu mempunyai tarikh dalam nama dan terkandung dalam arkib. Contohnya mailbox.log.2020-09-29.tar.gz. Ini menjadikannya lebih mudah untuk membuat sandaran log aktiviti dan mencari melalui log.
Untuk kemudahan pentadbir sistem, folder /opt/zimbra/log/ mengandungi log lain. Ia hanya memasukkan entri yang berkaitan dengan elemen OSE Zimbra tertentu. Contohnya, audit.log hanya mengandungi rekod tentang pengesahan pengguna, clamd.log mengandungi data tentang pengendalian antivirus dan sebagainya. Dengan cara ini, kaedah terbaik untuk melindungi pelayan OSE Zimbra daripada penceroboh adalah , yang hanya berfungsi berdasarkan audit.log. Ia juga merupakan amalan yang baik untuk menambah tugas cron untuk melaksanakan arahan grep -ir βkata laluan tidak sahβ /opt/zimbra/log/audit.loguntuk menerima maklumat kegagalan log masuk harian.
Contoh cara audit.log menunjukkan kata laluan yang dimasukkan dua kali secara salah dan percubaan log masuk yang berjaya.
Log masuk Zimbra OSE boleh menjadi sangat berguna dalam mengenal pasti punca pelbagai kegagalan kritikal. Pada masa ralat kritikal berlaku, pentadbir biasanya tidak mempunyai masa untuk membaca log. Ia diperlukan untuk memulihkan pelayan secepat mungkin. Walau bagaimanapun, kemudian, apabila pelayan disandarkan dan menjana banyak log, sukar untuk mencari entri yang diperlukan dalam fail besar. Untuk mencari rekod ralat dengan cepat, sudah cukup untuk mengetahui masa pelayan dimulakan semula dan mencari entri dalam log bertarikh dari masa ini. Entri sebelumnya akan menjadi rekod ralat yang berlaku. Anda juga boleh mencari mesej ralat dengan mencari kata kunci FATAL.
Log OSE Zimbra juga membolehkan anda mengenal pasti kegagalan yang tidak kritikal. Contohnya, untuk mencari pengecualian pengendali, anda boleh mencari pengecualian pengendali. Selalunya, ralat yang dijana oleh pengendali disertakan dengan surih tindanan yang menerangkan perkara yang menyebabkan pengecualian. Sekiranya berlaku ralat dengan penghantaran mel, anda harus memulakan carian anda dengan kata kunci LmtpServer dan untuk mencari ralat yang berkaitan dengan protokol POP atau IMAP, anda boleh menggunakan kata kunci ImapServer dan Pop3Server.
Log juga boleh membantu semasa menyiasat insiden keselamatan maklumat. Mari lihat contoh khusus. Pada 20 September, salah seorang pekerja menghantar surat yang dijangkiti virus kepada pelanggan. Akibatnya, data pada komputer pelanggan telah disulitkan. Bagaimanapun, pekerja itu bersumpah bahawa dia tidak menghantar apa-apa. Sebagai sebahagian daripada penyiasatan insiden, perkhidmatan keselamatan perusahaan meminta daripada pentadbir sistem log pelayan mel untuk 20 September yang dikaitkan dengan pengguna yang sedang disiasat. Terima kasih kepada cap masa, pentadbir sistem mencari fail log yang diperlukan, mengekstrak maklumat yang diperlukan dan memindahkannya kepada pakar keselamatan. Mereka, seterusnya, melihat melaluinya dan mendapati bahawa alamat IP dari mana surat ini dihantar sepadan dengan alamat IP komputer pengguna. Rakaman CCTV mengesahkan pekerja itu berada di tempat kerjanya ketika surat itu dihantar. Data ini sudah cukup untuk menuduhnya melanggar peraturan keselamatan maklumat dan memecatnya.
Contoh mengekstrak rekod tentang salah satu akaun daripada Peti Mel.log log masuk ke dalam fail berasingan
Segala-galanya menjadi lebih rumit apabila melibatkan infrastruktur berbilang pelayan. Memandangkan log dikumpulkan secara tempatan, bekerja dengan mereka dalam infrastruktur berbilang pelayan adalah sangat menyusahkan dan oleh itu terdapat keperluan untuk memusatkan pengumpulan log. Ini boleh dilakukan dengan menyediakan hos untuk mengumpul log. Tidak ada keperluan khusus untuk menambah hos khusus pada infrastruktur. Mana-mana pelayan mel boleh bertindak sebagai nod untuk mengumpul log. Dalam kes kami, ini akan menjadi nod Mailstore01.
Pada pelayan ini kita perlu memasukkan arahan di bawah:
sudo su β zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vEdit fail /etc/sysconfig/rsyslog, dan tetapkan SYSLOGD_OPTIONS=β-r -c 2β³
Edit /etc/rsyslog.conf dan nyahkomen baris berikut:
$ModLoad imudp
$UDPServerRun 514
Masukkan arahan berikut:
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/zmupdateauthkeysAnda boleh menyemak sama ada semuanya berfungsi menggunakan perintah zmprov gacf | grep zimbraLogHostname. Selepas melaksanakan arahan, nama hos yang mengumpul log harus dipaparkan. Untuk menukarnya, anda mesti memasukkan perintah zmprov mcf zimbraLogHostname mailstore01.company.ru.
Pada semua pelayan infrastruktur lain (LDAP, MTA dan kedai mel lain), jalankan perintah zmprov gacf |grep zimbraLogHostname untuk melihat nama hos yang mana log dihantar. Untuk menukarnya, anda juga boleh memasukkan perintah zmprov mcf zimbraLogHostname mailstore01.company.ru
Anda juga mesti memasukkan arahan berikut pada setiap pelayan:
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 restartSelepas ini, semua log akan direkodkan pada pelayan yang anda tentukan, di mana ia boleh dilihat dengan mudah. Juga, dalam konsol pentadbir Zimbra OSE, pada skrin dengan maklumat tentang status pelayan, perkhidmatan Logger yang sedang berjalan akan dipaparkan hanya untuk pelayan mailstore01.
Satu lagi sakit kepala untuk pentadbir boleh menjejaki e-mel tertentu. Memandangkan e-mel dalam Zimbra OSE melalui beberapa acara yang berbeza serentak: mengimbas menggunakan antivirus, antispam, dan sebagainya, sebelum diterima atau dihantar, untuk pentadbir, jika e-mel tidak tiba, ia boleh menjadi agak bermasalah untuk mengesan di peringkat mana ia telah hilang.
Untuk menyelesaikan masalah ini, anda boleh menggunakan skrip khas, yang dibangunkan oleh pakar keselamatan maklumat Viktor Dukhovny dan disyorkan untuk digunakan oleh pembangun Postfix. Skrip ini menggabungkan entri daripada log untuk proses tertentu dan, disebabkan ini, membolehkan anda memaparkan dengan cepat semua entri yang berkaitan dengan menghantar surat tertentu berdasarkan pengecamnya. Kerjanya telah diuji pada semua versi Zimbra OSE, bermula dari 8.7. Berikut ialah teks skrip.
#! /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";
}Skrip ditulis dalam Perl dan untuk menjalankannya anda perlu menyimpannya ke fail collate.pl, jadikannya boleh laku, dan kemudian jalankan fail yang menyatakan fail log dan menggunakan pgrep untuk mengekstrak maklumat pengenalan surat yang anda cari collate.pl /var/log/zimbra.log | pgrep '[e-mel dilindungi]>'. Hasilnya akan menjadi output berurutan baris yang mengandungi maklumat tentang pergerakan huruf pada pelayan.
# 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: removedUntuk semua soalan berkaitan Zextras Suite, anda boleh menghubungi Wakil Zextras Ekaterina Triandafilidi melalui e-mel [e-mel dilindungi]
Sumber: www.habr.com