Înregistrarea tuturor evenimentelor care au loc este una dintre cele mai importante funcții ale oricărui sistem corporativ. Jurnalele vă permit să rezolvați problemele emergente, să auditați funcționarea sistemelor de informații și, de asemenea, să investigați incidentele de securitate a informațiilor. Zimbra OSE păstrează, de asemenea, jurnalele detaliate ale funcționării sale. Acestea includ toate datele de la performanța serverului până la trimiterea și primirea de e-mailuri de către utilizatori. Cu toate acestea, citirea jurnalelor generate de Zimbra OSE este o sarcină destul de netrivială. În acest articol, folosind un exemplu specific, vă vom spune cum să citiți jurnalele Zimbra OSE, precum și cum să le centralizați.
Zimbra OSE stochează toate jurnalele locale în folderul /opt/zimbra/log, iar jurnalele pot fi găsite și în fișierul /var/log/zimbra.log. Cel mai important dintre acestea este mailbox.log. Înregistrează toate acțiunile care au loc pe serverul de e-mail. Acestea includ transmiterea de e-mailuri, date de autentificare a utilizatorilor, încercări eșuate de autentificare și altele. Intrările din mailbox.log sunt un șir de text care conține ora la care a avut loc evenimentul, nivelul evenimentului, numărul firului în care a avut loc evenimentul, numele utilizatorului și adresa IP, precum și o descriere text a evenimentului. .
Nivelul de jurnal indică gradul de influență a evenimentului asupra funcționării serverului. În mod implicit, există 4 niveluri de eveniment: INFO, WARN, EROARE și FATAL. Să ne uităm la toate nivelurile în ordinea crescătoare a severității.
- INFORMAȚII - Evenimentele de la acest nivel sunt de obicei destinate să informeze despre progresul Zimbra OSE. Mesajele de la acest nivel includ rapoarte privind crearea sau ștergerea unei căsuțe poștale și așa mai departe.
- WARN - evenimentele de acest nivel informează despre situații care sunt potențial periculoase, dar nu afectează funcționarea serverului. De exemplu, nivelul WARN marchează un mesaj despre o încercare eșuată de conectare a utilizatorului.
- EROARE - acest nivel de eveniment din jurnal informează despre apariția unei erori care este de natură locală și nu interferează cu funcționarea serverului. Acest nivel poate semnala o eroare în care datele de index ale unui utilizator individual au fost corupte.
- FATAL - acest nivel indică erori din cauza cărora serverul nu poate continua să funcționeze normal. De exemplu, nivelul FATAL va fi pentru o înregistrare care indică incapacitatea de a se conecta la DBMS.
Fișierul jurnal al serverului de e-mail este actualizat în fiecare zi. Cea mai recentă versiune a fișierului are întotdeauna numele Mailbox.log, în timp ce jurnalele pentru o anumită dată au o dată în nume și sunt conținute în arhivă. De exemplu, mailbox.log.2020-09-29.tar.gz. Acest lucru face mult mai ușor să faceți copii de rezervă ale jurnalelor de activitate și să căutați prin jurnale.
Pentru comoditatea administratorului de sistem, folderul /opt/zimbra/log/ conține alte jurnale. Acestea includ doar intrări care se referă la elemente specifice Zimbra OSE. De exemplu, audit.log conține doar înregistrări despre autentificarea utilizatorului, clamd.log conține date despre funcționarea antivirusului și așa mai departe. Apropo, o metodă excelentă de a proteja un server Zimbra OSE de intruși este , care funcționează doar pe baza audit.log. De asemenea, este o practică bună să adăugați o sarcină cron pentru a executa comanda grep -ir „parolă nevalidă” /opt/zimbra/log/audit.logpentru a primi zilnic informații despre erori de conectare.
Un exemplu despre modul în care audit.log arată o parolă introdusă incorect de două ori și o încercare de conectare reușită.
Jurnalele din Zimbra OSE pot fi extrem de utile în identificarea cauzelor diferitelor defecțiuni critice. În momentul în care apare o eroare critică, administratorul nu are de obicei timp să citească jurnalele. Este necesar să restaurați serverul cât mai curând posibil. Cu toate acestea, mai târziu, când serverul face backup și generează o mulțime de jurnale, poate fi dificil să găsești intrarea necesară într-un fișier mare. Pentru a găsi rapid o înregistrare de eroare, este suficient să cunoașteți ora la care a fost repornit serverul și să găsiți o intrare în jurnalele care datează din această oră. Intrarea anterioară va fi o înregistrare a erorii care a apărut. De asemenea, puteți găsi mesajul de eroare căutând cuvântul cheie FATAL.
Jurnalele Zimbra OSE vă permit, de asemenea, să identificați eșecurile necritice. De exemplu, pentru a găsi excepții de handler, puteți căuta excepția de handler. Adesea, erorile generate de handleri sunt însoțite de o urmărire a stivei care explică ce a cauzat excepția. În cazul unor erori la livrarea e-mailului, ar trebui să începeți căutarea cu cuvântul cheie LmtpServer, iar pentru a căuta erori legate de protocoalele POP sau IMAP, puteți utiliza cuvintele cheie ImapServer și Pop3Server.
Jurnalele pot ajuta și la investigarea incidentelor de securitate a informațiilor. Să ne uităm la un exemplu concret. Pe 20 septembrie, unul dintre angajați a trimis o scrisoare infectată cu virus unui client. Ca urmare, datele de pe computerul clientului au fost criptate. Totuși, angajatul jură că nu a trimis nimic. Ca parte a investigației incidentului, serviciul de securitate al întreprinderii solicită administratorului de sistem jurnalele serverului de e-mail pentru 20 septembrie asociate utilizatorului investigat. Datorită ștampilei de timp, administratorul de sistem găsește fișierul jurnal necesar, extrage informațiile necesare și le transferă specialiștilor în securitate. Aceștia, la rândul lor, se uită prin el și constată că adresa IP de la care a fost trimisă această scrisoare corespunde adresei IP a computerului utilizatorului. Imaginile CCTV au confirmat că angajatul se afla la locul său de muncă când a fost trimisă scrisoarea. Aceste date au fost suficiente pentru a-l acuza de încălcarea regulilor de securitate a informațiilor și a-l concedia.
Un exemplu de extragere a înregistrărilor despre unul dintre conturi din jurnalul Mailbox.log într-un fișier separat
Totul devine mult mai complicat când vine vorba de infrastructura multi-server. Deoarece jurnalele sunt colectate local, lucrul cu ele într-o infrastructură cu mai multe servere este foarte incomod și, prin urmare, este nevoie de a centraliza colectarea de jurnale. Acest lucru se poate face prin configurarea unei gazde pentru a colecta jurnalele. Nu este nevoie în mod special de a adăuga o gazdă dedicată la infrastructură. Orice server de mail poate actiona ca un nod pentru colectarea jurnalelor. Î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 SYSLOGD_OPTIONS="-r -c 2″
Editați /etc/rsyslog.conf și decomentați următoarele rânduri:
$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/zmupdateauthkeysPuteți verifica dacă totul funcționează folosind comanda zmprov gacf | grep zimbraLogHostname. După executarea comenzii, ar trebui să fie afișat numele gazdei care colectează jurnalele. Pentru a-l schimba, trebuie să introduceți comanda zmprov mcf zimbraLogHostname mailstore01.company.ru.
Pe toate celelalte servere de infrastructură (LDAP, MTA și alte magazine de corespondență), rulați comanda zmprov gacf |grep zimbraLogHostname pentru a vedea numele gazdei către care sunt trimise jurnalele. Pentru a o schimba, puteți introduce și comanda zmprov mcf zimbraLogHostname mailstore01.company.ru
De asemenea, trebuie să introduceți următoarele comenzi pe fiecare 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 restartDupă aceasta, toate jurnalele vor fi înregistrate pe serverul pe care l-ați specificat, unde pot fi vizualizate convenabil. De asemenea, în consola de administrator Zimbra OSE, pe ecranul cu informații despre starea serverelor, serviciul Logger care rulează va fi afișat doar pentru serverul mailstore01.
O altă durere de cap pentru un administrator poate fi urmărirea unui anumit e-mail. Deoarece e-mailurile din Zimbra OSE trec prin mai multe evenimente diferite simultan: scanare prin antivirus, antispam și așa mai departe, înainte de a fi acceptate sau trimise, pentru administrator, dacă e-mailul nu ajunge, poate fi destul de problematic să urmărești în ce stadiu s-a pierdut.
Pentru a rezolva această problemă, puteți utiliza un script special, care a fost dezvoltat de specialistul în securitatea informațiilor Viktor Dukhovny și recomandat pentru utilizare de către dezvoltatorii Postfix. Acest script concatenează intrările din jurnale pentru un anumit proces și, datorită acestui fapt, vă permite să afișați rapid toate intrările asociate cu trimiterea unei anumite scrisori pe baza identificatorului acesteia. Lucrarea sa a fost testată pe toate versiunile Zimbra OSE, începând cu 8.7. Iată textul scenariului.
#! /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 trebuie să îl salvați într-un fișier colate.pl, faceți-l executabil și apoi rulați fișierul specificând fișierul jurnal și folosind pgrep pentru a extrage informațiile de identificare ale literei pe care o căutați colate.pl /var/log/zimbra.log | pgrep '[e-mail protejat]> '. Rezultatul va fi o ieșire secvențială de linii care conțin informații despre mișcarea literei pe 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: removedPentru toate întrebările legate de Zextras Suite, puteți contacta Reprezentantul Zextras Ekaterina Triandafilidi prin e-mail [e-mail protejat]
Sursa: www.habr.com