Regjistrimi i tĂ« gjitha ngjarjeve qĂ« ndodhin Ă«shtĂ« njĂ« nga funksionet mĂ« tĂ« rĂ«ndĂ«sishme tĂ« çdo sistemi korporativ. Log-et ndihmojnĂ« nĂ« zgjidhjen e problemeve qĂ« shfaqen, nĂ« kryerjen e auditimit tĂ« sistemeve tĂ« informacionit, si edhe nĂ« hetimin e incidenteve tĂ« sigurisĂ« sĂ« informacionit. Edhe Zimbra OSE mban log-e tĂ« detajuara tĂ« funksionimit tĂ« saj. NĂ« to pĂ«rfshihen tĂ« gjitha tĂ« dhĂ«nat, nga performanca e serverit deri te dĂ«rgimi dhe marrja e email-eve nga pĂ«rdoruesit. MegjithatĂ«, leximi i log-eve tĂ« gjeneruara nga Zimbra OSE Ă«shtĂ« njĂ« detyrĂ« jo fort e thjeshtĂ«. NĂ« kĂ«tĂ« artikull, me njĂ« shembull konkret, do tâju tregojmĂ« si tĂ« lexoni log-et e Zimbra OSE, si edhe si tâi centralizoni ato.
Të gjitha log-et lokale Zimbra OSE i ruan në dosjen /opt/zimbra/log; gjithashtu log-et mund të gjenden në skedarin /var/log/zimbra.log. Më i rëndësishmi prej tyre është mailbox.log. Në të regjistrohen të gjitha veprimet që ndodhin në serverin e postës. Midis tyre janë transmetimi i email-eve, të dhënat e autentikimit të përdoruesve, përpjekjet e dështuara për hyrje dhe të tjera. Regjistrimet në mailbox.log paraqiten si një rresht teksti, ku përfshihet koha kur ka ndodhur ngjarja, niveli i ngjarjes, numri i thread-it brenda të cilit ka ndodhur ngjarja, emri i përdoruesit dhe adresa e tij IP, si edhe përshkrimi tekstual i ngjarjes.
Niveli i log-ut tregon shkallĂ«n e ndikimit qĂ« ka ngjarja nĂ« funksionimin e serverit. Si parazgjedhje pĂ«rdoren 4 nivele ngjarjesh: INFO, WARN, ERROR dhe FATAL. Le tâi shqyrtojmĂ« tĂ« gjitha nivelet sipas rritjes sĂ« seriozitetit tĂ« tyre.
- INFO â ngjarjet nĂ« kĂ«tĂ« nivel zakonisht shĂ«rbejnĂ« pĂ«r tĂ« informuar mbi ecurinĂ« e punĂ«s sĂ« Zimbra OSE. NdĂ«r mesazhet e kĂ«tij niveli janĂ« raportet pĂ«r krijimin ose fshirjen e njĂ« kutie postare, e kĂ«shtu me radhĂ«.
- WARN â ngjarjet e kĂ«tij niveli informojnĂ« pĂ«r situata qĂ« janĂ« potencialisht tĂ« rrezikshme, por qĂ« nuk ndikojnĂ« nĂ« funksionimin e serverit. Me nivelin WARN, pĂ«r shembull, shĂ«nohet njĂ« mesazh pĂ«r njĂ« pĂ«rpjekje tĂ« pasuksesshme hyrjeje nga njĂ« pĂ«rdorues.
- ERROR â ky nivel ngjarjeje nĂ« log tregon se ka ndodhur njĂ« gabim me karakter lokal, i cili nuk e pengon funksionimin e serverit. Me kĂ«tĂ« nivel mund tĂ« shĂ«nohet, pĂ«r shembull, njĂ« gabim nĂ« tĂ« cilin tĂ« dhĂ«nat e indeksit tĂ« njĂ« pĂ«rdoruesi tĂ« veçantĂ« rezultojnĂ« tĂ« dĂ«mtuara.
- FATAL â ky nivel shĂ«non gabime pĂ«r shkak tĂ« tĂ« cilave serveri nuk mund tĂ« vazhdojĂ« tĂ« punojĂ« normalisht. PĂ«r shembull, niveli FATAL pĂ«rdoret pĂ«r njĂ« regjistrim kur nuk Ă«shtĂ« e mundur tĂ« lidhet me DBMS.
Skedari i logeve të serverit të postës përditësohet çdo ditë. Versioni më i ri i skedarit gjithmonë ka emrin Mailbox.log, ndërsa loget për një datë të caktuar kanë datën në emër dhe ruhen në arkiv. Për shembull, mailbox.log.2020-09-29.tar.gz. Kjo e thjeshton ndjeshëm ruajtjen rezervë të regjistrave të veprimeve dhe kërkimin nëpër loge.
PĂ«r lehtĂ«si tĂ« administratorit tĂ« sistemit, nĂ« dosjen /opt/zimbra/log/ gjenden edhe loge tĂ« tjera. Ato pĂ«rfshijnĂ« vetĂ«m regjistrimet qĂ« lidhen me elemente tĂ« caktuara tĂ« Zimbra OSE. PĂ«r shembull, audit.log pĂ«rmban vetĂ«m regjistrime pĂ«r autentikimin e pĂ«rdoruesve, clamd.log pĂ«rmban tĂ« dhĂ«na mbi funksionimin e antivirusit, e kĂ«shtu me radhĂ«. MeqĂ« ra fjala, njĂ« metodĂ« shumĂ« e mirĂ« pĂ«r mbrojtjen e serverit Zimbra OSE nga keqbĂ«rĂ«sit Ă«shtĂ« , e cila funksionon pikĂ«risht mbi bazĂ«n e audit.log. NjĂ« praktikĂ« tjetĂ«r e mirĂ« Ă«shtĂ« shtimi i njĂ« detyre cron pĂ«r ekzekutimin e komandĂ«s grep -ir âinvalid passwordâ /opt/zimbra/log/audit.log, nĂ« mĂ«nyrĂ« qĂ« tĂ« merrni çdo ditĂ« informacion pĂ«r rastet e pĂ«rpjekjeve tĂ« pasuksesshme pĂ«r hyrje.
Shembull se si në logun audit.log shfaqen një fjalëkalim i futur gabim dy herë dhe një përpjekje e suksesshme hyrjeje
Loget në Zimbra OSE mund të jenë jashtëzakonisht të dobishme për të përcaktuar shkaqet e dështimeve të ndryshme kritike. Në momentin kur ndodh një gabim kritik, administratori zakonisht nuk ka kohë të lexojë loget. Duhet të rikthehet sa më shpejt funksionimi i serverit. Megjithatë, më pas, kur serveri punon sërish dhe gjeneron shumë loge, 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 kohën kur serveri u rinis dhe të gjeni në loge regjistrimin me atë orë. Regjistrimi paraprirës do të jetë pikërisht ai i gabimit që ka ndodhur. Mesazhi i gabimit mund të gjendet gjithashtu duke kërkuar sipas fjalës kyçe FATAL.
Gjithashtu, log-et e Zimbra OSE lejojnë të identifikohen edhe dështime jokritike. Për shembull, për të gjetur përjashtime të handler-it, mund të kërkoni sipas frazës handler exception. Shpesh, gabimet që gjenerohen nga handler-ët shoqërohen me stack trace, ku shpjegohet shkaku i përjashtimit. Në rast të gabimeve me dorëzimin e postës, kërkimi duhet të nisë me fjalën kyçe LmtpServer, ndërsa për të gjetur gabime që lidhen me protokollet POP ose IMAP mund të përdoren fjalët kyçe ImapServer dhe Pop3Server.
Log-et mund tĂ« ndihmojnĂ« edhe gjatĂ« hetimit tĂ« incidenteve tĂ« sigurisĂ« sĂ« informacionit. Le tĂ« shqyrtojmĂ« njĂ« shembull konkret. MĂ« 20 shtator, njĂ« nga punonjĂ«sit i dĂ«rgoi njĂ« klienti njĂ« email tĂ« infektuar me virus. Si rezultat, tĂ« dhĂ«nat nĂ« kompjuterin e klientit u enkriptuan. MegjithatĂ«, punonjĂ«si betohet se nuk ka dĂ«rguar asgjĂ«. NĂ« kuadĂ«r tĂ« hetimit tĂ« incidentit, shĂ«rbimi i sigurisĂ« sĂ« ndĂ«rmarrjes i kĂ«rkon administratorit tĂ« sistemit log-et e serverit tĂ« postĂ«s pĂ«r datĂ«n 20 shtator, tĂ« lidhura me pĂ«rdoruesin ndaj tĂ« cilit po zhvillohet hetimi. FalĂ« vulĂ«s kohore, administratori i sistemit gjen skedarin e duhur tĂ« log-eve, nxjerr informacionin e nevojshĂ«m dhe ua dorĂ«zon specialistĂ«ve tĂ« sigurisĂ«. KĂ«ta tĂ« fundit, nga ana e tyre, i shqyrtojnĂ« dhe zbulojnĂ« se adresa IP nga e cila Ă«shtĂ« dĂ«rguar ky email pĂ«rputhet me adresĂ« IP kompjuterin e pĂ«rdoruesit. Regjistrimet e kamerave tĂ« mbikĂ«qyrjes konfirmuan se punonjĂ«si nĂ« momentin e dĂ«rgimit tĂ« emailit ndodhej nĂ« vendin e tij tĂ« punĂ«s. KĂ«to tĂ« dhĂ«na mjaftuan pĂ«r ta akuzuar pĂ«r shkelje tĂ« rregullave tĂ« sigurisĂ« sĂ« informacionit dhe pĂ«r ta pushuar nga puna.Â
Shembull i nxjerrjes së regjistrimeve për një nga llogaritë nga log-u Mailbox.log në një skedar të veçantë
Gjithçka ndërlikohet ndjeshëm kur bëhet fjalë për infrastrukturë me shumë serverë. Meqenëse log-et mblidhen lokalisht, puna me to në kushte të një infrastrukture multiserver është shumë e papërshtatshme, prandaj lind nevoja për centralizimin e mbledhjes së log-eve. Kjo mund të bëhet duke konfiguruar një host për mbledhjen e log-eve. Nuk ka ndonjë nevojë të veçantë për të shtuar në infrastrukturë një host të dedikuar. Si nyje për mbledhjen e log-eve mund të përdoret çdo server poste. Në rastin tonë, ky do të jetë nyja Mailstore01.
Në këtë server duhet të fusim komandat e mëposhtme:
sudo su â zimbraÂ
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vRedaktoni skedarin /etc/sysconfig/rsyslog dhe vendosni parametrin SYSLOGD_OPTIONS=â-r -c 2âł
Redaktoni /etc/rsyslog.conf dhe hiqni komentin nga rreshtat e mëposhtëm:
$ModLoad imudp
$UDPServerRun 514
Shkruani 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/zmupdateauthkeysMund të kontrolloni që gjithçka funksionon me komandën zmprov gacf | grep zimbraLogHostname. Pas ekzekutimit të komandës duhet të shfaqet emri i hostit që kryen grumbullimin e logeve. Për ta ndryshuar atë, duhet të ekzekutoni komandën zmprov mcf zimbraLogHostname mailstore01.company.ru.
Në të gjithë serverët e tjerë të infrastrukturës (LDAP, MTA dhe serverë të tjerë të ruajtjes së postës), ekzekutoni komandën zmprov gacf |grep zimbraLogHostname për të parë emrin e hostit ku dërgohen loget. Për ta ndryshuar, mund të përdorni gjithashtu komandën zmprov mcf zimbraLogHostname mailstore01.company.ru
Gjithashtu, në çdo server duhet të ekzekutoni 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 pĂ«rcaktuar, ku mund tâi shikoni me lehtĂ«si. Gjithashtu, nĂ« konsolĂ«n e administratorit tĂ« Zimbra OSE, nĂ« ekranin me informacion pĂ«r gjendjen e serverĂ«ve, shĂ«rbimi Logger i nisur do tĂ« shfaqet vetĂ«m te serveri mailstore01.
Një tjetër sfidë për administratorin mund të jetë gjurmimi i një mesazhi të caktuar emaili. Meqenëse email-et në Zimbra OSE kalojnë menjëherë nëpër disa procese të ndryshme, si kontrolli antivirus, antispam e kështu me radhë, përpara se të pranohen ose të dërgohen, për administratorin mund të jetë mjaft e vështirë të përcaktojë në cilën fazë është humbur mesazhi në rast se ai nuk mbërrin.
Për të zgjidhur këtë problem, mund të përdorni një skript të posaçëm të zhvilluar nga eksperti i sigurisë së informacionit Viktor Dukhovny dhe të rekomanduar për përdorim nga zhvilluesit e Postfix. Ky skript bashkon regjistrimet nga log-et sipas një procesi të caktuar dhe në këtë mënyrë mundëson shfaqjen e shpejtë të të gjitha regjistrimeve që lidhen me dërgimin e një emaili të caktuar, bazuar në identifikuesin e tij. Funksionimi i tij është testuar në të gjitha versionet e Zimbra OSE, duke filluar nga 8.7. Më poshtë po japim 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 nĂ« skedarin collate.pl, tâi jepni tĂ« drejta ekzekutimi dhe mĂ« pas ta nisni skedarin duke specifikuar skedarin e log-ut dhe, me ndihmĂ«n e pgrep, tĂ« nxirrni informacionin identifikues tĂ« emailit qĂ« kĂ«rkoni collate.pl /var/log/zimbra.log | pgrep ââ. Si rezultat, do tĂ« merrni njĂ« paraqitje tĂ« njĂ«pasnjĂ«shme tĂ« rreshtave qĂ« pĂ«rmbajnĂ« informacion 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 të gjitha pyetjet që lidhen me Zextras Suite mund të kontaktoni Përfaqësuesin e kompanisë "Zextras", Ekaterina Triandafiliidi në email katerina@zextras.com
Burimi: habr.com
