Logning af alle forekommende hændelser er en af de vigtigste funktioner i ethvert virksomhedssystem. Logs giver dig mulighed for at løse nye problemer, revidere driften af informationssystemer og også undersøge informationssikkerhedshændelser. Zimbra OSE fører også detaljerede logfiler over driften. De inkluderer alle data fra serverydeevne til afsendelse og modtagelse af e-mails fra brugere. At læse logfilerne genereret af Zimbra OSE er dog en ret ikke-triviel opgave. I denne artikel, ved hjælp af et specifikt eksempel, vil vi fortælle dig, hvordan du læser Zimbra OSE-logfiler, samt hvordan du gør dem centraliserede.
Zimbra OSE gemmer alle lokale logfiler i mappen /opt/zimbra/log, og logfiler kan også findes i filen /var/log/zimbra.log. Den vigtigste af disse er mailbox.log. Den registrerer alle de handlinger, der sker på mailserveren. Disse omfatter transmission af e-mails, brugergodkendelsesdata, mislykkede loginforsøg og andre. Indtastninger i mailbox.log er en tekststreng, der indeholder det tidspunkt, hvor hændelsen fandt sted, hændelsens niveau, trådnummeret, hvor hændelsen fandt sted, brugernavn og IP-adresse samt en tekstbeskrivelse af hændelsen .
Logniveauet angiver graden af hændelsens indflydelse på serverens drift. Som standard er der 4 hændelsesniveauer: INFO, WARN, ERROR og FATAL. Lad os se på alle niveauer i stigende rækkefølge efter sværhedsgrad.
- INFO - Begivenheder på dette niveau er normalt beregnet til at informere om Zimbra OSE's fremskridt. Beskeder på dette niveau inkluderer rapporter om oprettelse eller sletning af en postkasse og så videre.
- ADVARSEL - begivenheder på dette niveau informerer om situationer, der er potentielt farlige, men som ikke påvirker driften af serveren. For eksempel markerer WARN-niveauet en meddelelse om et mislykket brugerloginforsøg.
- FEJL - dette hændelsesniveau i loggen informerer om forekomsten af en fejl, der er af lokal karakter og ikke forstyrrer serverens drift. Dette niveau kan markere en fejl, hvor en individuel brugers indeksdata er blevet beskadiget.
- FATAL - dette niveau angiver fejl, som skyldes, at serveren ikke kan fortsætte med at fungere normalt. F.eks. vil FATAL-niveauet være for en post, der indikerer manglende evne til at oprette forbindelse til DBMS.
Mailserverens logfil opdateres hver dag. Den seneste version af filen har altid navnet Mailbox.log, mens logfiler for en bestemt dato har en dato i navnet og er indeholdt i arkivet. For eksempel mailbox.log.2020-09-29.tar.gz. Dette gør det meget nemmere at sikkerhedskopiere aktivitetslogfiler og søge gennem logfiler.
For nemheds skyld for systemadministratoren indeholder mappen /opt/zimbra/log/ andre logfiler. De inkluderer kun poster, der vedrører specifikke Zimbra OSE-elementer. For eksempel indeholder audit.log kun registreringer om brugergodkendelse, clamd.log indeholder data om driften af antivirus, og så videre. Det er i øvrigt en fremragende metode til at beskytte en Zimbra OSE-server mod ubudne gæster , som bare fungerer baseret på audit.log. Det er også en god praksis at tilføje en cron-opgave for at udføre kommandoen grep -ir „ugyldig adgangskode“ /opt/zimbra/log/audit.logat modtage daglige login-fejloplysninger.
Et eksempel på hvordan audit.log viser en adgangskode indtastet to gange forkert og et vellykket loginforsøg.
Logfiler i Zimbra OSE kan være yderst nyttige til at identificere årsagerne til forskellige kritiske fejl. I det øjeblik, hvor der opstår en kritisk fejl, har administratoren normalt ikke tid til at læse loggene. Det er nødvendigt at gendanne serveren så hurtigt som muligt. Men senere, når serveren er sikkerhedskopieret og genererer en masse logfiler, kan det være svært at finde den nødvendige post i en stor fil. For hurtigt at finde en fejlrecord er det nok at kende tidspunktet, hvor serveren blev genstartet, og finde en post i logfilerne fra dette tidspunkt. Den forrige indtastning vil være en registrering af den fejl, der opstod. Du kan også finde fejlmeddelelsen ved at søge på søgeordet FATAL.
Zimbra OSE-logfiler giver dig også mulighed for at identificere ikke-kritiske fejl. For at finde handlerundtagelser kan du f.eks. søge efter handlerundtagelse. Ofte er fejl genereret af handlere ledsaget af en staksporing, der forklarer, hvad der forårsagede undtagelsen. I tilfælde af fejl med postlevering, bør du starte din søgning med nøgleordet LmtpServer, og for at søge efter fejl relateret til POP- eller IMAP-protokollerne, kan du bruge søgeordene ImapServer og Pop3Server.
Logfiler kan også hjælpe, når der skal undersøges hændelser med informationssikkerhed. Lad os se på et specifikt eksempel. Den 20. september sendte en af medarbejderne et virusinficeret brev til en klient. Som et resultat blev dataene på klientens computer krypteret. Medarbejderen sværger dog, at han ikke har sendt noget. Som en del af efterforskningen af hændelsen anmoder virksomhedens sikkerhedstjeneste fra systemadministratoren om mailserverlogfilerne for den 20. september, der er knyttet til den bruger, der undersøges. Takket være tidsstemplet finder systemadministratoren den nødvendige logfil, udtrækker de nødvendige oplysninger og overfører dem til sikkerhedsspecialister. De ser igen igennem det og finder ud af, at IP-adressen, hvorfra dette brev blev sendt, svarer til IP-adressen på brugerens computer. CCTV-optagelser bekræftede, at medarbejderen var på sin arbejdsplads, da brevet blev sendt. Disse data var nok til at beskylde ham for at overtræde reglerne for informationssikkerhed og fyre ham.
Et eksempel på udtræk af poster om en af konti fra Mailbox.log log ind i en separat fil
Alt bliver meget mere kompliceret, når det kommer til multi-server infrastruktur. Da logfiler indsamles lokalt, er det meget ubelejligt at arbejde med dem i en multi-server-infrastruktur, og derfor er der behov for at centralisere indsamlingen af logfiler. Dette kan gøres ved at oprette en vært til at indsamle logfiler. Der er ikke noget særligt behov for at tilføje en dedikeret vært til infrastrukturen. Enhver mailserver kan fungere som en node til indsamling af logfiler. I vores tilfælde vil dette være Mailstore01-knuden.
På denne server skal vi indtaste nedenstående kommandoer:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vRediger filen /etc/sysconfig/rsyslog, og indstil SYSLOGD_OPTIONS=”-r -c 2″
Rediger /etc/rsyslog.conf, og fjern kommentarer til følgende linjer:
$ModLoad imudp
$UDPServerRun 514
Indtast følgende kommandoer:
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/zmupdateauthkeysDu kan kontrollere, at alt fungerer ved hjælp af kommandoen zmprov gacf | grep zimbraLogHostname. Efter udførelse af kommandoen skal navnet på værten, der indsamler logfiler, vises. For at ændre det skal du indtaste kommandoen zmprov mcf zimbraLogHostname mailstore01.company.ru.
På alle andre infrastrukturservere (LDAP, MTA og andre mailbutikker) skal du køre kommandoen zmprov gacf |grep zimbraLogHostname for at se navnet på værten, som logfilerne sendes til. For at ændre det kan du også indtaste kommandoen zmprov mcf zimbraLogHostname mailstore01.company.ru
Du skal også indtaste følgende kommandoer på hver 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 restartHerefter vil alle logfiler blive registreret på den server, du har angivet, hvor de nemt kan ses. Også i Zimbra OSE-administratorkonsollen, på skærmen med information om status for servere, vil den kørende Logger-tjeneste kun blive vist for mailstore01-serveren.
En anden hovedpine for en administrator kan være at holde styr på en bestemt e-mail. Da e-mails i Zimbra OSE gennemgår flere forskellige begivenheder på én gang: scanning med antivirus, antispam og så videre, før de accepteres eller sendes, for administratoren, hvis e-mailen ikke ankommer, kan det være ret problematisk at spore på hvilket tidspunkt det var tabt.
For at løse dette problem kan du bruge et specielt script, som er udviklet af informationssikkerhedsspecialist Viktor Dukhovny og anbefalet til brug af Postfix-udviklere. Dette script sammenkæder indgange fra logfiler for en specifik proces og giver dig på grund af dette mulighed for hurtigt at få vist alle poster, der er forbundet med at sende et bestemt brev baseret på dets identifikator. Dens arbejde er blevet testet på alle versioner af Zimbra OSE, startende fra 8.7. Her er teksten til manuskriptet.
#! /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";
}Scriptet er skrevet i Perl, og for at køre det skal du gemme det i en fil collate.pl, gør det eksekverbart, og kør derefter filen, der specificerer logfilen og brug pgrep til at udtrække identifikationsoplysningerne for det bogstav, du leder efter collate.pl /var/log/zimbra.log | pgrep '[e-mail beskyttet]>'. Resultatet vil være et sekventielt output af linjer, der indeholder information om bevægelsen af bogstavet på serveren.
# 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: removedFor alle spørgsmål relateret til Zextras Suite, kan du kontakte repræsentanten for Zextras Ekaterina Triandafilidi via e-mail [e-mail beskyttet]
Kilde: www.habr.com