Înregistrarea tuturor evenimentelor care au loc este una dintre cele mai importante funcții ale oricărei sisteme corporative. Jurnalele permit rezolvarea problemelor apărute, efectuarea auditului funcționării sistemelor informaționale, precum și investigația incidentelor de securitate informațională. Zimbra OSE de asemenea conduce jurnale detaliate ale activității sale. Acestea includ toate datele, de la performanța serverului până la trimiterea și primirea mesajelor de către utilizatori. Totuși, citirea jurnalelor generate de Zimbra OSE este o sarcină destul de complicată. În acest articol, folosind un exemplu concret, vă vom arăta cum să citiți jurnalele Zimbra OSE și cum să le centralizați.

Toate jurnalele locale Zimbra OSE sunt stocate în folderul /opt/zimbra/log, iar jurnalele pot fi găsite de asemenea în fișierul /var/log/zimbra.log. Cel mai important dintre acestea este mailbox.log. Acesta înregistrează toate acțiunile efectuate pe serverul de email. Printre acestea se numără transmiterea mesajelor, datele de autentificare ale utilizatorilor, încercările nereușite de conectare și altele. Înregistrările din mailbox.log reprezintă o linie de text care conține ora la care a avut loc evenimentul, nivelul evenimentului, numărul firului în care s-a petrecut evenimentul, numele utilizatorului și adresa sa IP, precum și o descriere textuală a evenimentului.

Nivelul jurnalului indică gradul de impact al evenimentului asupra funcționării serverului. În mod implicit sunt utilizate 4 niveluri ale evenimentelor: INFO, WARN, ERROR și FATAL. Să analizăm toate nivelurile în ordine crescătoare a gravității lor.
- INFO — evenimentele la acest nivel au ca scop să informeze despre progresul funcționării Zimbra OSE. Printre mesajele acestui nivel se află rapoartele de creare sau ștergere a unui cont de email și așa mai departe.
- WARN — evenimentele la acest nivel informează despre situații care sunt potențial periculoase, dar nu afectează funcționarea serverului. De exemplu, un mesaj despre o încercare nereușită de conectare a utilizatorului este marcat cu nivelul WARN.
- ERROR — acest nivel al evenimentului din jurnal informează despre o eroare care este de natură locală și nu împiedică funcționarea serverului. O astfel de eroare poate fi, de exemplu, o problemă în care datele indexate ale unui utilizator anume au fost corupte.
- FATAL — acest nivel marchează erorile care împiedică serverul să funcționeze în mod normal. De exemplu, un mesaj cu nivelul FATAL va fi generat în cazul imposibilității de a se conecta la baza de date.
Fișierul de loguri al serverului poștal se actualizează zilnic. Versiunea actualizată a fișierului poartă întotdeauna numele Mailbox.log, în timp ce logurile pentru anumite date au data în denumire și sunt conținute într-un arhivă. De exemplu, mailbox.log.2020-09-29.tar.gz. Datorită acestui fapt, rezervarea jurnalelor de acțiuni și căutarea în loguri devine semnificativ mai simplă.
Pentru confortul administratorului de sistem, în folderul /opt/zimbra/log/ se află și alte loguri. Acestea includ doar acele înregistrări care se referă la elementele specifice Zimbra OSE. De exemplu, în audit.log se găsesc exclusiv înregistrări despre autentificarea utilizatorilor, în clamd.log date despre activitatea antivirusului și așa mai departe. Apropo, o metodă excelentă de protecție a serverului Zimbra OSE împotriva atacatorilor este , care funcționează de fapt pe baza audit.log. De asemenea, o bună practică este adăugarea unei sarcini cron pentru a executa comanda grep -ir „invalid password“ /opt/zimbra/log/audit.log, pentru a primi zilnic informații despre cazurile de încercări nereușite de conectare.

Un exemplu de cum în logul audit.log sunt afișate de două ori o parolă introdusă greșit și o încercare de conectare reușită
Logurile în Zimbra OSE pot fi extrem de utile în stabilirea cauzelor diferitelor erori critice. În momentul în care apare o eroare critică, administratorului nu îi mai rămâne timp să citească logurile. Este necesar să se restabilească funcționarea serverului cât mai repede posibil. Cu toate acestea, ulterior, când serverul funcționează din nou și generează multe loguri, găsirea înregistrării dorite într-un fișier mare poate fi dificilă. Pentru a găsi rapid înregistrarea legată de eroare, este suficient să cunoaștem ora la care serverul a fost repornit și să căutăm în loguri o înregistrare datată în acel moment. Înregistrarea anterioară va fi cea care conține informația despre eroarea apărută. De asemenea, se poate găsi mesajul de eroare folosind căutarea după cuvântul cheie FATAL.
De asemenea, jurnalele Zimbra OSE permit identificarea și a defecțiunilor non-critice. De exemplu, pentru a găsi excepțiile din handler, se poate efectua căutarea după expresia handler exception. Adesea, erorile generate de handler sunt însoțite de un stack trace, care explică motivul apariției excepției. În cazul erorilor de livrare a e-mailurilor, ar trebui să începi căutarea cu cuvântul cheie LmtpServer, iar pentru erorile legate de protocoalele POP sau IMAP, se pot folosi cuvintele cheie ImapServer și Pop3Server.
Jurnalele pot ajuta, de asemenea, în investigarea incidentelor de securitate informațională. Să luăm un exemplu concret. Pe 20 septembrie, unul dintre angajați a trimis un e-mail contaminat cu un virus unui client. Drept rezultat, datele de pe computerul clientului au fost criptate. Totuși, angajatul susține că nu a trimis nimic. În cadrul investigației incidentului, echipa de securitate a întreprinderii solicită administratorului de sistem jurnalele serverului de e-mail pentru 20 septembrie, legate de utilizatorul în raport cu care se desfășoară investigația. Datorită timestamp-ului, administratorul de sistem găsește fișierul jurnal dorit, extrage informațiile necesare și le transmite echipei de securitate. Aceștia, la rândul lor, le revizuiesc și descoperă că adresa IP de la care a fost trimis acest e-mail corespunde adresa IP computerului utilizatorului. Înregistrările camerelor de supraveghere au confirmat că angajatul se afla la locul său de muncă în timpul trimiterii e-mailului. Aceste date au fost suficiente pentru a-l acuza de încălcarea regulilor de securitate informațională și a-l concedia.

Exemplu de extragere a înregistrărilor unei conturi din jurnalul Mailbox.log într-un fișier separat
Totul devine semnificativ mai complicat atunci când vine vorba despre infrastructura multi-server. Deoarece jurnalele sunt colectate local, lucrul cu acestea într-o infrastructură multi-server este foarte incomod și, prin urmare, apare necesitatea centralizării colectării jurnalelelor. Acest lucru se poate realiza prin configurarea unui gazdă pentru colectarea jurnalelor. Nu este absolut necesar să se adauge o gazdă dedicată în infrastructură. Oricare server de e-mail poate servi drept nod pentru colectarea jurnalelelor. În cazul nostru, acesta va fi nodul Mailstore01.
Pe acest server, trebuie să introducem comenzile de mai jos:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vEditați fișierul /etc/sysconfig/rsyslog și setați opțiunea SYSLOGD_OPTIONS=”-r -c 2″
Editați /etc/rsyslog.conf și decomentați următoarele linii:
$ModLoad imudp
$UDPServerRun 514
Introduceți următoarele comenzi:
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/zmupdateauthkeysVerificați că totul funcționează folosind comanda zmprov gacf | grep zimbraLogHostname. După executarea comenzii ar trebui să apară numele gazdei care colectează logurile. Pentru a-l schimba, trebuie să introduceți comanda zmprov mcf zimbraLogHostname mailstore01.company.ro.
Pe toate celelalte servere din infrastructură (LDAP, MTA și alte stocări de e-mail) executați comanda zmprov gacf |grep zimbraLogHostname pentru a vedea numele gazdei către care se trimite logurile. De asemenea, pentru a-l schimba, se poate introduce comanda zmprov mcf zimbraLogHostname mailstore01.company.ro
De asemenea, pe fiecare server trebuie introduse următoarele comenzi:
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 restartDupă aceasta, toate logurile vor fi înregistrate pe serverul specificat de dumneavoastră, unde vor putea fi vizualizate convenabil. De asemenea, în consola de administrare Zimbra OSE, pe ecranul cu informațiile despre starea serverelor, serviciul Logger va fi vizibil doar pe serverul mailstore01.

O altă durere de cap pentru administrator poate fi urmărirea unui anumit mesaj electronic. Deoarece mesajele de e-mail în Zimbra OSE trec prin mai multe evenimente diferite: verificare antivirus, anti-spam și așa mai departe, înainte de a fi acceptate sau trimise, pentru administrator, în cazul în care un mesaj electronic nu ajunge, poate fi destul de problematic să urmărească în ce etapă s-a pierdut.
Pentru a rezolva această problemă, se poate utiliza un script special, dezvoltat de specialistul în securitate informațională Victor Dukhovny, care este recomandat pentru utilizare de către dezvoltatorii Postfix. Acest script concatenează înregistrările din loguri pentru un anumit proces și, datorită acestuia, permite afișarea rapidă a tuturor înregistrărilor legate de trimiterea unei anumite scrisori pe baza identificatorului său. Funcționarea sa a fost testată pe toate versiunile Zimbra OSE, începând cu 8.7. Iată textul scriptului.
#! /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";
}Scriptul este scris în Perl și pentru a-l rula, este necesar să-l salvați într-un fișier collate.pl, să-i faceți execuabil și apoi să rulați fișierul cu specificarea fișierului de loguri, folosind pgrep pentru a extrage informațiile de identificare ale scrisorii căutate collate.pl /var/log/zimbra.log | pgrep ''. Rezultatul va fi o afișare secvențială a liniilor care conțin informații despre mișcarea scrisorii pe server.
# collate.pl /var/log/zimbra.log | pgrep '<20200929101700.user@mail.company.ru>'
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: removedPentru orice întrebări legate de Zextras Suite, puteți contacta reprezentanta companiei „Zextras” Ekaterina Triandafylidi la adresa de email katerina@zextras.com
Sursa: habr.com
