Aantekening van alle gebeure wat voorkom is een van die belangrikste funksies van enige korporatiewe stelsel. Logs laat jou toe om opkomende probleme op te los, die werking van inligtingstelsels te oudit, en ook inligtingsekuriteitsinsidente te ondersoek. Zimbra OSE hou ook gedetailleerde logboeke van sy werk. Dit sluit alle data in van bedienerwerkverrigting tot die stuur en ontvang van e-posse deur gebruikers. Die lees van die logs wat deur Zimbra OSE gegenereer word, is egter 'n taamlik nie-triviale taak. In hierdie artikel, met behulp van 'n spesifieke voorbeeld, sal ons jou vertel hoe om Zimbra OSE-logboeke te lees, asook hoe om dit gesentraliseer te maak.
Zimbra OSE stoor alle plaaslike logs in die /opt/zimbra/log-lêergids, en logs kan ook in die /var/log/zimbra.log-lêer gevind word. Die belangrikste hiervan is mailbox.log. Dit teken alle aksies aan wat op die posbediener plaasvind. Onder hulle is die oordrag van briewe, gebruikersverifikasiedata, onsuksesvolle aanmeldpogings en ander. Inskrywings in mailbox.log is 'n teksstring wat die tyd bevat waarop die gebeurtenis plaasgevind het, die vlak van die gebeurtenis, die nommer van die stroom waarbinne die gebeurtenis plaasgevind het, die gebruikersnaam en sy ip-adres, en 'n teksbeskrywing van die gebeurtenis.
Die logvlak dui die mate van invloed van die gebeurtenis op die werking van die bediener aan. By verstek word 4 gebeurtenisvlakke gebruik: INLIGTING, WAARSKUWING, FOUT en FATAAL. Kom ons ontleed al die vlakke in stygende volgorde van hul erns.
- INLIGTING - geleenthede op hierdie vlak is gewoonlik ontwerp om in te lig oor die vordering van die Zimbra OSE. Onder die boodskappe van hierdie vlak is verslae oor die skep of verwydering van 'n posbus, ensovoorts.
- WAARSKUW - gebeure van hierdie vlak lig in oor situasies wat potensieel gevaarlik is, maar nie die werking van die bediener beïnvloed nie. Die WAARSKUWING-vlak, byvoorbeeld, merk 'n boodskap oor 'n onsuksesvolle gebruikeraanmeldingspoging.
- FOUT - hierdie gebeurtenisvlak in die logboek lig in oor die voorkoms van 'n fout wat plaaslik van aard is en nie inmeng met die werking van die bediener nie. Hierdie vlak kan 'n fout merk waarin die indeksdata van 'n individuele gebruiker beskadig is.
- FATAAL – Foute wat verhoed dat die bediener voortgaan om normaal te funksioneer, word met hierdie vlak gemerk. Byvoorbeeld, die FATAL-vlak sal in die rekord wees oor die onvermoë om aan die DBBS te koppel.
Die posbedienerloglêer word elke dag opgedateer. Die nuutste weergawe van die lêer word altyd Mailbox.log genoem, terwyl die logboeke vir 'n sekere datum 'n datum in die titel het en in die argief vervat is. Byvoorbeeld mailbox.log.2020-09-29.tar.gz. Dit vergemaklik die rugsteun van aktiwiteitslogboeke en soek deur die logboeke aansienlik.
Vir die gerief van die stelseladministrateur bevat die /opt/zimbra/log/-lêergids ander logs. Dit sluit slegs daardie inskrywings in wat verband hou met spesifieke Zimbra OSE-elemente. Byvoorbeeld, oudit.log bevat slegs inskrywings oor gebruikersverifikasie, clamd.log bevat data oor antivirus-werking, ensovoorts. Terloops, 'n uitstekende metode om die Zimbra OSE-bediener teen indringers te beskerm , wat net werk gebaseer op oudit.log. Dit is ook goeie praktyk om 'n cron-taak by te voeg om die opdrag uit te voer grep -ir "ongeldige wagwoord" /opt/zimbra/log/audit.logom daaglikse inligting oor mislukte aanmeldpogings te ontvang.
'n Voorbeeld van hoe die oudit.log 'n dubbele verkeerde wagwoord en 'n suksesvolle aanmeldpoging toon
Die logs in Zimbra OSE kan uiters nuttig wees om die oorsake van verskeie kritieke mislukkings uit te vind. Op die oomblik wanneer 'n kritieke fout voorkom, is die administrateur gewoonlik nie gereed om die logs te lees nie. Die bediener moet so gou moontlik herstel word. Maar later, wanneer die bediener rugsteun is en baie logs genereer, kan dit moeilik wees om die regte inskrywing in 'n groot lêer te vind. Om vinnig 'n foutinskrywing te vind, is dit genoeg om te weet op watter tydstip die bediener herbegin is en 'n inskrywing te vind in die logboeke wat tot hierdie tyd gedateer is. Die vorige rekord sal die foutrekord wees. Jy kan ook die foutboodskap vind deur na die FATAL-sleutelwoord te soek.
Die Zimbra OSE-logs laat jou ook toe om nie-kritieke mislukkings op te spoor. Byvoorbeeld, om hanteerder-uitsonderings te vind, kan jy soek vir die frase hanteerder-uitsondering. Dikwels word die foute wat deur hanteerders gegenereer word vergesel van 'n stapelspoor wat verduidelik wat die uitsondering veroorsaak het. In die geval van posafleweringsfoute, moet jy jou soektog met die LmtpServer-sleutelwoord begin, en om te soek na foute wat verband hou met die POP- of IMAP-protokolle, kan jy die ImapServer- en Pop3Server-sleutelwoorde gebruik.
Logs kan ook help met die ondersoek van inligtingsekuriteitvoorvalle. Kom ons kyk na 'n spesifieke voorbeeld. Op 20 September het een van die werknemers 'n virus-geïnfekteerde brief aan die kliënt gestuur. Gevolglik is die data op die kliënt se rekenaar geïnkripteer. Die werknemer sweer egter dat hy niks gestuur het nie. As deel van die ondersoek van die voorval, versoek die ondernemingsekuriteitsdiens van die stelseladministrateur die e-posbedienerlogboeke vir 20 September wat verband hou met die gebruiker wat ondersoek word. Danksy die tydstempel vind die stelseladministrateur die regte loglêer, onttrek die nodige inligting en gee dit aan die sekuriteitswagte deur. Hulle bekyk dit op hul beurt en vind dat die IP-adres waarvandaan hierdie brief gestuur is, ooreenstem met die IP-adres van die gebruiker se rekenaar. CCTV-beeldmateriaal het bevestig dat die werknemer by sy werkplek was toe die brief gestuur is. Hierdie data was genoeg om hom daarvan te beskuldig dat hy inligtingsekuriteitsreëls oortree het en hom afgedank het.
'n Voorbeeld van die onttrekking van rekords oor een van die rekeninge vanaf die Mailbox.log log in 'n aparte lêer
Dinge word baie meer ingewikkeld as dit kom by multi-bediener-infrastruktuur. Aangesien die logs plaaslik versamel word, is dit baie ongerieflik om daarmee te werk in 'n multi-bediener infrastruktuur, en daarom word dit nodig om die versameling van logs te sentraliseer. U kan dit doen deur 'n gasheer op te stel vir die versameling van logs. Daar is geen spesiale behoefte om 'n toegewyde gasheer by die infrastruktuur te voeg nie. Enige posbediener kan as 'n gasheer optree vir die versameling van logs. In ons geval sal dit die Mailstore01-knooppunt wees.
Op hierdie bediener moet ons die opdragte hieronder invoer:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vWysig die /etc/sysconfig/rsyslog lêer, en stel die SYSLOGD_OPTIONS="-r -c 2" opsie
Redigeer /etc/rsyslog.conf en verwyder die volgende reëls:
$ModLoad imudp
$UDPServerRun 514
Voer die volgende opdragte in:
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/zmupdateauthkeysJy kan seker maak dat alles werk met behulp van die zmprov gacf | grep zimbraLogHostname. Nadat die opdrag uitgevoer is, moet die naam van die gasheer wat die logs versamel, vertoon word. Om dit te verander, moet jy die opdrag zmprov mcf zimbraLogHostname mailstore01.company.ru invoer.
Op alle ander infrastruktuurbedieners (LDAP, MTA en ander posbergings), voer die zmprov gacf |grep zimbraLogHostname-opdrag uit om die naam van die gasheer te sien waarheen die logs gaan. Om dit te verander, kan jy ook die opdrag zmprov mcf zimbraLogHostname mailstore01.company.ru invoer
Op elke bediener moet u ook die volgende opdragte invoer:
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 restartDaarna sal alle logs aangeteken word op die bediener wat jy gespesifiseer het, waar dit gerieflik bekyk kan word. Ook, in die Zimbra OSE-administrasiekonsole, op die skerm met inligting oor die status van die bedieners, sal die lopende Logger-diens slegs op die mailstore01-bediener vertoon word.
Nog 'n kopseer vir 'n administrateur kan wees om tred te hou met 'n spesifieke e-posboodskap. Aangesien e-posse in Zimbra OSE op een slag deur verskeie verskillende gebeurtenisse gaan: kontroleer deur antivirus, antispam, ensovoorts, voordat dit aanvaar of gestuur word, vir die administrateur, as die e-pos nie bereik nie, kan dit nogal problematies wees om op te spoor in watter stadium dit was verlore.
Om hierdie probleem op te los, kan u 'n spesiale skrif gebruik, wat ontwikkel is deur inligtingsekuriteitspesialis Viktor Dukhovy en aanbeveel word vir gebruik deur Postfix-ontwikkelaars. Hierdie skrif koppel rekords uit die logboeke vir 'n spesifieke proses aaneen en laat jou as gevolg hiervan vinnig alle rekords wat verband hou met die stuur van 'n spesifieke brief vertoon op grond van die identifiseerder daarvan. Die werk daarvan is op alle weergawes van Zimbra OSE getoets, vanaf 8.7. Hier is die teks van die skrif.
#! /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";
}Die skrip is in Perl geskryf en om dit te laat loop moet jy dit in 'n lêer stoor versamel.pl, maak dit uitvoerbaar, hardloop dan die lêer wat die loglêer spesifiseer en gebruik pgrep om die identifikasie-inligting van die e-pos waarna jy soek te onttrek collate.pl /var/log/zimbra.log | pgrep'[e-pos beskerm]>'. Die resultaat sal 'n opeenvolgende uitvoer van reëls wees wat inligting bevat oor die beweging van die letter op die bediener.
# 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: removedVir alle vrae wat verband hou met Zextras Suite, kan jy die verteenwoordiger van Zextras Ekaterina Triandafilidi per e-pos kontak [e-pos beskerm]
Bron: will.com