Visų vykstančių įvykių registravimas yra viena iš svarbiausių bet kurios įmonės sistemos funkcijų. Žurnalai leidžia spręsti iškylančias problemas, audituoti informacinių sistemų veikimą, taip pat tirti informacijos saugumo incidentus. Zimbra OSE taip pat saugo išsamius savo veiklos žurnalus. Jie apima visus duomenis nuo serverio veikimo iki vartotojų el. laiškų siuntimo ir gavimo. Tačiau Zimbra OSE sugeneruotų žurnalų skaitymas yra gana nebanali užduotis. Šiame straipsnyje, naudodami konkretų pavyzdį, pasakysime, kaip skaityti Zimbra OSE žurnalus ir kaip juos centralizuoti.
Zimbra OSE visus vietinius žurnalus saugo /opt/zimbra/log aplanke, o žurnalus taip pat galima rasti /var/log/zimbra.log faile. Svarbiausias iš jų yra mailbox.log. Jis įrašo visus veiksmus, kurie atliekami pašto serveryje. Tai apima el. laiškų, vartotojo autentifikavimo duomenų, nesėkmingų prisijungimo bandymų ir kt. Įrašai mailbox.log yra teksto eilutė, kurioje yra įvykio laikas, įvykio lygis, gijos, kurioje įvyko įvykis, numeris, vartotojo vardas ir IP adresas, taip pat tekstinis įvykio aprašymas .
Žurnalo lygis rodo įvykio įtakos serverio veikimui laipsnį. Pagal numatytuosius nustatymus yra 4 įvykių lygiai: INFO, WARN, ERROR ir FATAL. Pažvelkime į visus lygius didėjančia sunkumo tvarka.
- INFORMACIJA – šio lygio renginiai paprastai skirti informuoti apie Zimbra OSE pažangą. Šio lygio pranešimai apima ataskaitas apie pašto dėžutės sukūrimą ar ištrynimą ir pan.
- ĮSPĖJIMAS – tokio lygio įvykiai informuoja apie situacijas, kurios yra potencialiai pavojingos, tačiau neturi įtakos serverio darbui. Pavyzdžiui, WARN lygis žymi pranešimą apie nepavykusį vartotojo prisijungimo bandymą.
- KLAIDA – šis įvykių lygis žurnale informuoja apie įvykusią klaidą, kuri yra vietinio pobūdžio ir netrukdo serverio darbui. Šis lygis gali pažymėti klaidą, kai sugadinti atskiro vartotojo indekso duomenys.
- FATAL – šis lygis rodo klaidas, dėl kurių serveris negali toliau normaliai veikti. Pavyzdžiui, FATAL lygis bus skirtas įrašui, rodančiam, kad nepavyksta prisijungti prie DBVS.
Pašto serverio žurnalo failas atnaujinamas kiekvieną dieną. Naujausia failo versija visada vadinasi Mailbox.log, o tam tikros datos žurnalų pavadinime yra data ir jie yra archyve. Pavyzdžiui, mailbox.log.2020-09-29.tar.gz. Taip daug lengviau kurti atsargines veiklos žurnalų kopijas ir ieškoti žurnaluose.
Sistemos administratoriaus patogumui aplanke /opt/zimbra/log/ yra kitų žurnalų. Juose yra tik įrašai, susiję su konkrečiais Zimbra OSE elementais. Pavyzdžiui, audit.log yra tik įrašai apie vartotojo autentifikavimą, clamd.log – duomenys apie antivirusinės programos veikimą ir pan. Beje, puikus būdas apsaugoti Zimbra OSE serverį nuo įsibrovėlių , kuris veikia tik remiantis audit.log. Taip pat gera praktika pridėti cron užduotį komandai vykdyti grep -ir „netinkamas slaptažodis“ /opt/zimbra/log/audit.loggauti kasdienę prisijungimo nesėkmės informaciją.
Pavyzdys, kaip audit.log rodo du kartus neteisingai įvestą slaptažodį ir sėkmingą prisijungimo bandymą.
Zimbra OSE žurnalai gali būti labai naudingi nustatant įvairių kritinių gedimų priežastis. Tuo metu, kai įvyksta kritinė klaida, administratorius dažniausiai neturi laiko skaityti žurnalų. Būtina kuo greičiau atkurti serverį. Tačiau vėliau, kai serveris sukuria atsarginę kopiją ir generuoja daug žurnalų, gali būti sunku rasti reikiamą įrašą dideliame faile. Norint greitai rasti klaidos įrašą, pakanka žinoti serverio paleidimo iš naujo laiką ir rasti įrašą žurnaluose nuo to laiko. Ankstesnis įrašas bus įvykusios klaidos įrašas. Klaidos pranešimą taip pat galite rasti ieškodami raktažodžio FATAL.
Zimbra OSE žurnalai taip pat leidžia nustatyti nekritinius gedimus. Pavyzdžiui, norėdami rasti tvarkyklės išimtis, galite ieškoti tvarkyklės išimties. Dažnai tvarkytojų sugeneruotas klaidas lydi dėklo pėdsakas, paaiškinantis, kas sukėlė išimtį. Pašto pristatymo klaidų atveju turėtumėte pradėti paiešką nuo raktažodžio LmtpServer, o norėdami ieškoti klaidų, susijusių su POP arba IMAP protokolais, galite naudoti ImapServer ir Pop3Server raktinius žodžius.
Žurnalai taip pat gali padėti tiriant informacijos saugumo incidentus. Pažvelkime į konkretų pavyzdį. Rugsėjo 20 d. viena iš darbuotojų išsiuntė virusu užkrėstą laišką klientui. Dėl to kliento kompiuteryje esantys duomenys buvo užšifruoti. Tačiau darbuotojas prisiekia nieko neatsiuntė. Vykdydama įvykio tyrimą, įmonės saugos tarnyba sistemos administratoriaus paprašo rugsėjo 20 d. pašto serverio žurnalų, susijusių su tiriamu vartotoju. Laiko žymos dėka sistemos administratorius suranda reikiamą žurnalo failą, ištraukia reikiamą informaciją ir perduoda saugos specialistams. Tie, savo ruožtu, peržiūri jį ir nustato, kad IP adresas, iš kurio buvo išsiųstas šis laiškas, atitinka vartotojo kompiuterio IP adresą. Vaizdo stebėjimo kamera patvirtino, kad darbuotojas, kai buvo išsiųstas laiškas, buvo savo darbo vietoje. Šių duomenų pakako apkaltinti jį informacijos saugumo taisyklių pažeidimu ir atleisti iš darbo.
Vienos paskyrų įrašų ištraukimo iš Mailbox.log žurnalo į atskirą failą pavyzdys
Viskas tampa daug sudėtingiau, kai kalbama apie kelių serverių infrastruktūrą. Kadangi žurnalai renkami lokaliai, dirbti su jais kelių serverių infrastruktūroje yra labai nepatogu, todėl reikia centralizuoti žurnalų rinkimą. Tai galima padaryti nustatant pagrindinį kompiuterį žurnalams rinkti. Nėra jokio ypatingo poreikio pridėti prie infrastruktūros skirto pagrindinio kompiuterio. Bet kuris pašto serveris gali veikti kaip žurnalų rinkimo mazgas. Mūsų atveju tai bus Mailstore01 mazgas.
Šiame serveryje turime įvesti šias komandas:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vRedaguokite /etc/sysconfig/rsyslog failą ir nustatykite SYSLOGD_OPTIONS=”-r -c 2″
Redaguokite /etc/rsyslog.conf ir panaikinkite šių eilučių komentarus:
$ModLoad imudp
$UDPServerRun 514
Įveskite šias komandas:
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/zmupdateauthkeysGalite patikrinti, ar viskas veikia, naudodami komandą zmprov gacf | grep zimbraLogHostname. Įvykdžius komandą, turėtų būti rodomas žurnalus renkančio pagrindinio kompiuterio pavadinimas. Norėdami jį pakeisti, turite įvesti komandą zmprov mcf zimbraLogHostname mailstore01.company.ru.
Visuose kituose infrastruktūros serveriuose (LDAP, MTA ir kitose pašto parduotuvėse) paleiskite komandą zmprov gacf |grep zimbraLogHostname, kad pamatytumėte pagrindinio kompiuterio, kuriam siunčiami žurnalai, pavadinimą. Norėdami jį pakeisti, taip pat galite įvesti komandą zmprov mcf zimbraLogHostname mailstore01.company.ru
Taip pat kiekviename serveryje turite įvesti šias komandas:
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 restartPo to visi žurnalai bus įrašyti į Jūsų nurodytą serverį, kur juos bus patogu peržiūrėti. Be to, Zimbra OSE administratoriaus konsolėje ekrane su informacija apie serverių būseną, veikianti Logger paslauga bus rodoma tik serveriui mailstore01.
Kitas administratoriaus galvos skausmas gali būti konkretaus el. pašto sekimas. Kadangi Zimbra OSE el. laiškai vienu metu vyksta per kelis skirtingus įvykius: nuskaitoma antivirusine, antispam ir tt, prieš priimant ar išsiunčiant, administratoriui, jei el. laiškas negauna, gali būti gana sunku atsekti, kuriame etape. tai buvo prarasta.
Norėdami išspręsti šią problemą, galite naudoti specialų scenarijų, kurį sukūrė informacijos saugos specialistas Viktoras Dukhovny ir rekomendavo naudoti Postfix kūrėjai. Šis scenarijus sujungia įrašus iš konkretaus proceso žurnalų ir dėl to leidžia greitai parodyti visus įrašus, susijusius su konkretaus laiško siuntimu pagal jo identifikatorių. Jo darbas buvo išbandytas visose Zimbra OSE versijose, pradedant nuo 8.7. Čia yra scenarijaus tekstas.
#! /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";
}Scenarijus parašytas Perl ir norint jį paleisti, reikia jį įrašyti į failą sugretinti.pl, padarykite jį vykdomą, tada paleiskite failą, nurodydami žurnalo failą ir naudodami pgrep, kad ištrauktumėte ieškomos raidės identifikavimo informaciją collate.pl /var/log/zimbra.log | pgrep '[apsaugotas el. paštu]>’. Rezultatas bus nuoseklus eilučių, kuriose yra informacija apie raidės judėjimą serveryje, išvestis.
# 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: removedVisais su Zextras Suite susijusiais klausimais galite kreiptis į Zextras atstovę Ekaterina Triandafilidi el. [apsaugotas el. paštu]
Šaltinis: www.habr.com