Regjistrimi i të gjitha ngjarjeve që ndodhin është një nga funksionet më të rëndësishme të çdo sistemi korporativ. Logët lejojnë zgjidhjen e problemeve që lindin, kryerjen e auditit të punës së sistemeve informacionit, si dhe hetimin e incidenteve të sigurisë informatike. Zimbra OSE gjithashtu mbledh detaje të hollësishme të punës së saj. Ato përfshijnë të dhëna nga performanca e serverit deri te dërgimi dhe marrja e e-maileve nga përdoruesit. Megjithatë, leximi i logëve të gjeneruar nga Zimbra OSE është një detyrë mjaft e komplikuar. Në këtë artikull, përmes një shembulli konkret, ne do t'ju tregojmë se si të lexoni logët e Zimbra OSE, si dhe si t'i centralizoni ato.

Të gjitha loget lokale të Zimbra OSE ruhen në dosjen /opt/zimbra/log, ndërsa loget e tjera mund të gjenden në skedarin /var/log/zimbra.log. Më e rëndësishme prej tyre është mailbox.log. Ai regjistron të gjitha veprimet që ndodhin në serverin e postës. Ndër to janë transferimi i e-maileve, të dhënat për autentifikimin e përdoruesve, përpjekjet e pasuksesshme për t'u lidhur dhe të tjera. Shënimet në mailbox.log përbëhen nga një varg tekstual, në të cilin përfshihet koha kur ndodhi ngjarja, niveli i ngjarjes, numri i thread-it nën të cilin ndodhi ngjarja, emri i përdoruesit dhe adresa e tij IP, si dhe përshkrimi tekstual i ngjarjes.

Niveli i logut tregon gradën e ndikimit të ngjarjes në funksionimin e serverit. Në mënyrë standarde përdoren katër nivele ngjarjesh: INFO, WARN, ERROR dhe FATAL. Do t'i shqyrtojmë të gjitha nivelet sipas rritjes së seriozitetit të tyre.
- INFO â ngjarjet nĂ« kĂ«tĂ« nivel zakonisht kanĂ« pĂ«r qĂ«llim tĂ« informojnĂ« pĂ«r ecurinĂ« e punĂ«s sĂ« Zimbra OSE. NdĂ«r mesazhet e kĂ«tij niveli janĂ« raportet pĂ«r krijimin ose fshirjen e kutive postare dhe kĂ«shtu me radhĂ«.
- WARN â ngjarjet e kĂ«tij niveli informojnĂ« pĂ«r situata qĂ« janĂ« potencialisht tĂ« rrezikshme, por nuk ndikojnĂ« nĂ« funksionimin e serverit. Niveli WARN shĂ«non, pĂ«r shembull, njĂ« mesazh pĂ«r njĂ« pĂ«rpjekje tĂ« dĂ«shtuara pĂ«r t'u futur nga pĂ«rdoruesi.
- ERROR â ky nivel i ngjarjeve nĂ« log informon pĂ«r ndodhinĂ« e njĂ« gabimi, i cili Ă«shtĂ« lokal dhe nuk pengon funksionimin e serverit. NjĂ« gabim tĂ« kĂ«tij niveli mund tĂ« shĂ«nojĂ« njĂ« gabim ku tĂ« dhĂ«nat indeksuese tĂ« njĂ« pĂ«rdoruesi janĂ« dĂ«mtuar.
- FATAL â ky nivel shĂ«non gabime, pĂ«r shkak tĂ« tĂ« cilave serveri nuk mund tĂ« vazhdojĂ« tĂ« funksionojĂ« normalisht. PĂ«r shembull, niveli FATAL do tĂ« jetĂ« pĂ«r njĂ« regjistrim mbi pamundĂ«sinĂ« pĂ«r t'u lidhur me DBMS.
Skedari me logjet e serverit të postës përditësohet çdo ditë. Versioni i ri i skedarit gjithmonë ka emrin Mailbox.log, ndërsa logjet për një numër të caktuar kanë datën në titull dhe ndodhen në arkiv. Për shembull, mailbox.log.2020-09-29.tar.gz. Kjo e lehtëson ndjeshëm rezervimin e regjistrave dhe kërkimin përmes logjeve.
Për lehtësinë e administratorit të sistemit, në dosjen /opt/zimbra/log/ ndodhen edhe logje të tjera. Aty përfshihen vetëm ato të dhëna që i përkasin elementeve specifikë të Zimbra OSE. Për shembull, në audit.log gjenden vetëm regjistrimet mbi autentikimin e përdoruesve, në clamd.log informacioni mbi funksionimin e antivirusit dhe kështu me radhë. Për më tepër, një metodë e shkëlqyer për të mbrojtur serverin Zimbra OSE nga sulmuesit është , i cili punon në bazë të audit.log. Gjithashtu, një praktikë e mirë është të shtoni një detyrë cron për të ekzekutuar komandën grep -ir "invalid password" /opt/zimbra/log/audit.log, për të marrë informacion çdo ditë mbi rastet e përpjekjeve të dështuara për t'u futurose.

Shembuj të asaj siç shfaqen dy herë në audit.log fjalëkalimi i gabuar dhe përpjekja e suksesshme për t'u futurose
Logët në Zimbra OSE mund të jenë jashtëzakonisht të dobishme për të zbuluar arsyet e ndryshme për dështimet kritike. Në momentin kur ndodh një gabim kritik, administratori zakonisht nuk ka kohë për të lexuar logët. Kërkohet sa më shpejt që të jetë e mundur rifillimi i punës së serverit. Megjithatë, më vonë, kur serveri përsëri funksionon dhe gjeneron shumë logë, gjetja e regjistrimit të nevojshëm në një skedar të madh mund të jetë e vështirë. Për të gjetur shpejt regjistrimin e gabimit, mjafton të dini orën kur serveri është rinisur dhe të kërkoni në logët për regjistrime të datuara në këtë kohë. Regjistrimi paraardhës do të jetë regjistrimi i gabimit të ndodhur. Gjithashtu, mund të gjeni mesazhin e gabimit duke kërkuar për fjalën kyç FATAL.
Po kështu, logjet e Zimbra OSE lejojnë identifikimin edhe të dështimeve jo kritike. Për shembull, për të gjetur përjashtime të trajtuesit, mund të bëni kërkimin me frazën handler exception. Shpesh, gabimet që gjeneron trajtuesi shoqërohen me një gjurmë të grumbullimit, që shpjegon se çfarë ishte shkaku i shfaqjes së përjashtimit. Në rastin e komplikimeve me dorëzimin e postës, është mirë të filloni kërkimin me fjalën kyçe LmtpServer, ndërsa për të gjetur gabimet e lidhura me protokollet POP ose IMAP, mund të përdorni fjalët kyçe ImapServer dhe Pop3Server.
TĂ« dhĂ«nat nga log-et gjithashtu mund tĂ« ndihmojnĂ« nĂ« hetimin e incidenteve tĂ« sigurisĂ« sĂ« informacionit. Le tĂ« shqyrtojmĂ« njĂ« rast konkret. MĂ« 20 Shtator, njĂ« nga punonjĂ«sit dĂ«rgoi njĂ« email tĂ« infektuar me virus pĂ«r njĂ« klient. Si rezultat, tĂ« dhĂ«nat nĂ« kompjuterin e klientit u koduan. MegjithatĂ«, punonjĂ«si betohet se nuk ka dĂ«rguar asgjĂ«. NĂ« kuadĂ«r tĂ« hetimit tĂ« incidentit, shĂ«rbimi i sigurisĂ« i ndĂ«rmarrjes kĂ«rkon nga administratori i sistemit log-et e serverit tĂ« postĂ«s pĂ«r 20 Shtator, tĂ« lidhura me pĂ«rdoruesin pĂ«r tĂ« cilin po kryhet hetimi. FalĂ« shenjĂ«s temporale, administratori i sistemit gjen skedarin e duhur me log-et, nxjerr informacionin e nevojshĂ«m dhe ia kalon sigurisĂ«. Ata, nga ana e tyre, e shqyrtojnĂ« atĂ« dhe zbulojnĂ« se adresa IP nga e cila ishte dĂ«rguar ky email pĂ«rputhet adresĂ«n IP me kompjuterin e pĂ«rdoruesit. Regjistrimet e kamerave tĂ« mbikĂ«qyrjes e konfirmuan se punonjĂ«si gjatĂ« dĂ«rgimit tĂ« emailit ishte nĂ« vendin e tij tĂ« punĂ«s. KĂ«to tĂ« dhĂ«na ishin tĂ« mjaftueshme pĂ«r ta akuzuar atĂ« pĂ«r shkelje tĂ« rregullave tĂ« sigurisĂ« sĂ« informacionit dhe pĂ«r ta pushuar nga puna.Â

Shembuj ekstraktimi i regjistrimeve për një nga llogaritë nga logu Mailbox.log në një skedë të veçantë
Gjithçka komplikohet ndjeshĂ«m kur bĂ«het fjalĂ« pĂ«r njĂ« infrastrukturĂ« me shumĂ« serverĂ«. Pasi loget mblidhen lokal, puna me to nĂ«n kushtet e infrastrukturĂ«s multi-server Ă«shtĂ« shumĂ« e papĂ«rshtatshme dhe prandaj lind nevoja pĂ«r centralizimin e mbledhjes sĂ« logeve. KĂ«tĂ« mund ta realizoni duke konfiguruar njĂ« host pĂ«r mbledhjen e logeve. Nuk ka nevojĂ« tĂ« shtoni njĂ« host tĂ« dedikuar nĂ« infrastrukturĂ«. Ădo server i postĂ«s mund tĂ« shĂ«rbejĂ« si njĂ« nyje pĂ«r mbledhjen e logeve. NĂ« rastin tonĂ«, ky do tĂ« jetĂ« nyja Mailstore01.
Në këtë server, ne duhet të futim komandat e mëposhtme:
sudo su â zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vEditoni skedarin /etc/sysconfig/rsyslog dhe vendosni parametrin SYSLOGD_OPTIONS=â-r -c 2âł
Editoni /etc/rsyslog.conf dhe ndizni rreshtat e mëposhtëm:
$ModLoad imudp
$UDPServerRun 514
Futni komandat e mëposhtme:
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/zmupdateauthkeysKontrolloni që gjithçka funksionon me komandën zmprov gacf | grep zimbraLogHostname. Pas ekzekutimit të komandës, do të shfaqet emri i hostit që realizon grumbullimin e logeve. Për ta ndryshuar, duhet të futni komandën zmprov mcf zimbraLogHostname mailstore01.company.ru.
Në të gjitha serverat e tjerë të infrastrukturës (LDAP, MTA dhe depo të tjera postare) ekzekutoni komandën zmprov gacf | grep zimbraLogHostname për të parë emrin e hostit ku shkojnë loget. Për ta ndryshuar, mund të futni gjithashtu komandën zmprov mcf zimbraLogHostname mailstore01.company.ru.
Gjithashtu, në çdo server duhet të futni komandat e mëposhtme:
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 restartPas kësaj, të gjitha loget do të regjistrohen në serverin që keni specifikuar, ku mund të shihen lehtësisht. Po ashtu, në konsolën e administratorit Zimbra OSE, në ekranin me informacionin mbi gjendjen e serverëve, shërbimi Logger do të shfaqet vetëm në serverin mailstore01.

Një tjetër dhimbje koke për administratorin mund të bëhet monitorimi i një mesazhi të caktuar elektronik. Duke parë se emailet në Zimbra OSE kalojnë nëpër disa ngjarje të ndryshme: kontrollimi nga antivirus, antispam, dhe kështu me radhë, para se të pranohet ose të dërgohet, për administratorin, në rast se emaili nuk arrin, mund të jetë mjaft problematike të përcaktojë në cilin hap ai është humbur.
Për të zgjidhur këtë problem, mund të përdorni një skript të veçantë, i zhvilluar nga specialisti i sigurisë informative Viktor Duhovny dhe i rekomanduar për përdorim nga zhvilluesit e Postfix. Ky skript konkatenton regjistrimet nga log-et për një proces të caktuar dhe përmes kësaj lejon të shfaqen shpejt të gjitha regjistrimet e lidhura me dërgimin e një emaili në bazë të identifikuesit të tij. Funksionimi i tij është testuar në të gjitha versionet e Zimbra OSE, duke filluar nga 8.7. Po sjellim tekstin e skriptit.
#! /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";
}Skripti Ă«shtĂ« shkruar nĂ« Perl dhe pĂ«r ta ekzekutuar, duhet ta ruani atĂ« nĂ« njĂ« skedar collate.pl, e bĂ«n atĂ« ekzekutiv, pastaj nisni skedarin me tregimin e skedarit tĂ« logs dhe me ndihmĂ«n e pgrep nxirrni informacionin identifikues tĂ« emailit tĂ« kĂ«rkuar collate.pl /var/log/zimbra.log | pgrep ââ. Rezultati do tĂ« jetĂ« njĂ« renditje e radhĂ«s sĂ« rreshtave qĂ« pĂ«rmbajnĂ« informacionin mbi lĂ«vizjen e emailit nĂ« 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: removedPër çdo pyetje lidhur me Zextras Suite, mund të kontaktoni përfaqësuesen e kompanisë «Zextras», Ekaterina Triandafiliidi në e-mail katerina@zextras.com
Burimi: habr.com
