Logning af alle hændelser er en af de vigtigste funktioner i ethvert virksomheds system. Logs muliggør problemløsning, revision af it-systemers drift samt undersøgelse af informationssikkerhedshændelser. Zimbra OSE fører også detaljerede logs over sit arbejde. Disse indeholder alle data fra serverens ydeevne til sending og modtagelse af e-mails af brugerne. At læse logs genereret af Zimbra OSE kan dog være en temmelig udfordrende opgave. I denne artikel vil vi med et konkret eksempel vise, hvordan man læser logs fra Zimbra OSE, samt hvordan man gør dem centraliserede.
Alle lokale logs for Zimbra OSE gemmes i mappen /opt/zimbra/log, og logs kan også findes i filen /var/log/zimbra.log. Den mest vigtige af dem er mailbox.log. Denne log dokumenterer alle handlinger, der finder sted på mailserveren. Blandt dem er overførsel af e-mails, data om brugergodkendelse, mislykkede login-forsøg og andre. Posterne i mailbox.log er tekstlinjer, der indeholder tidspunktet for hændelsen, hændelsesniveauet, trådens nummer, hvor hændelsen fandt sted, brugernavnet og dennes ip-adresse samt en tekstbeskrivelse af hændelsen.
Logniveauet angiver hændelsens indflydelse på serverens drift. Som standard anvendes der 4 niveauer for hændelser: INFO, WARN, ERROR og FATAL. Lad os gennemgå alle niveauer i rækkefølge efter alvorlighed.
- INFO — hændelser på dette niveau har til formål at informere om driften af Zimbra OSE. Blandt meddelelserne på dette niveau findes rapporter om oprettelse eller sletning af en postkasse osv.
- WARN — hændelser på dette niveau informerer om situationer, der er potentielt farlige, men som ikke påvirker serverens drift. En situation kan f.eks. klassificeres som WARN ved en mislykket login-forsøg fra en bruger.
- ERROR — dette hændelsesniveau i loggen informerer om forekomsten af en fejl, der er lokal og ikke hindrer serverens drift. En sådan fejl kan f.eks. være, at indeksdataene for en bestemt bruger er blevet beskadiget.
- FATAL — dette niveau markerer fejl, der forhindrer serveren i at fungere korrekt. For eksempel vil en post om umuligheden af at oprette forbindelse til databasen have niveauet FATAL.
Filen med logfiler fra mailserveren opdateres dagligt. Den nyeste version af filen hedder altid Mailbox.log, mens logfilerne for bestemte datoer indeholder datoen i navnet og findes i arkivet. For eksempel mailbox.log.2020-09-29.tar.gz. Dette gør det betydeligt nemmere at sikkerhedskopiere aktivitetslogger og søge i logfilerne.
For at gøre det lettere for systemadministratoren indeholder mappen /opt/zimbra/log/ andre logfiler. Disse inkluderer kun de optegnelser, der vedrører specifikke elementer i Zimbra OSE. For eksempel indeholder audit.log udelukkende optegnelser om brugerautentifikation, clamd.log indeholder oplysninger om antivirusets funktion osv. For øvrigt er en fremragende metode til at beskytte Zimbra OSE-serveren mod angreb , som i øvrigt fungerer på baggrund af audit.log. En god praksis er også at tilføje en cron-opgave til at udføre kommandoen grep -ir "invalid password" /opt/zimbra/log/audit.log, for dagligt at modtage information om tilfælde af mislykkede loginforsøg.
Et eksempel på, hvordan to gange forkert indtastede adgangskoder og et vellykket loginforsøg vises i audit.log.
Logfilerne i Zimbra OSE kan være yderst nyttige ved at afdække årsagerne til forskellige kritiske fejl. I det øjeblik en kritisk fejl opstår, har administratoren som regel ikke tid til at læse loggene. Der skal hurtigt genoprettes serverens funktion. Men senere, når serveren er genoprettet og genererer en masse logfiler, kan det være vanskeligt at finde den nødvendige post i den store fil. For hurtigt at finde fejlinformationen er det tilstrækkeligt at vide, hvornår serveren blev genstartet, og finde loggen, der er dateret til det tidspunkt. Den foregående post vil være posteringen om den opståede fejl. Det er også muligt at finde fejlmeddelelsen ved at søge efter nøgleordet FATAL.
Zimbra OSE-logger kan også afsløre ikke-kritiske fejl. For eksempel, for at finde fejl i en behandler, kan man søge efter sætningen handler exception. Fejl, som genereres af behandlere, ledsages ofte af en stakspor, der forklarer, hvad der forårsagede undtagelsen. I tilfælde af fejl med levering af e-mail bør man starte søgningen med nøgleordet LmtpServer, mens man for at finde fejl relateret til POP- eller IMAP-protokoller kan bruge nøgleordene ImapServer og Pop3Server.
Loggerne kan også hjælpe i efterforskningen af informationssikkerhedshændelser. Lad os se på et konkret eksempel. Den 20. september sendte en af medarbejderne en virus-inficeret e-mail til en klient. Som følge heraf blev dataene på klientens computer krypteret. Men medarbejderen sværger, at han ikke har sendt noget. I forbindelse med efterforskningen af hændelsen anmoder virksomhedens sikkerhedstjeneste systemadministratoren om at få loggerne fra mailserveren for den 20. september, relateret til den bruger, der er under efterforskning. Takket være tidsstemplet finder systemadministratoren den nødvendige logfil, udtrækker den ønskede information og giver den til sikkerhedsteamet. De ser det igennem og opdager, at IP-adressen, der blev brugt til at sende denne e-mail, svarer til IP-adressen brugerens computer. Optagelser fra overvågningskameraer bekræftede, at medarbejderen var på sin arbejdsplads under afsendelsen af e-mailen. Disse oplysninger var tilstrækkelige til at anklage ham for at overtræde informationssikkerhedsreglerne og fyre ham.
Eksempel på at udtrække optegnelser om en af brugerkonti fra Mailbox.log til en separat fil
Situationen bliver betydeligt mere kompliceret, når det drejer sig om en multi-server infrastruktur. Da loggerne indsamles lokalt, er det meget besværligt at arbejde med dem i en multi-server infrastruktur, og derfor opstår behovet for centralisering af logindsamlingen. Dette kan gøres ved at konfigurere en vært til logindsamling. Der er ingen særlig nødvendighed for at tilføje en dedikeret vært til infrastrukturen. Enhver mailserver kan fungere som en node til logindsamling. I vores tilfælde vil det være noden Mailstore01.
På denne server skal vi indtaste de nedenstående kommandoer:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vRediger filen /etc/sysconfig/rsyslog, og sæt parameteren SYSLOGD_OPTIONS=”-r -c 2″
Rediger /etc/rsyslog.conf og fjern kommentaren fra 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, om alt fungerer, ved at bruge kommandoen zmprov gacf | grep zimbraLogHostname. Efter udførelsen af kommandoen skal navnet på værtmaskinen, der samler loggene, vises. For at ændre det skal du indtaste kommandoen zmprov mcf zimbraLogHostname mailstore01.company.ru.
På alle andre servere i infrastrukturen (LDAP, MTA og andre e-mail lagre) skal du udføre kommandoen zmprov gacf |grep zimbraLogHostname for at se navnet på værten, hvor loggene sendes. For at ændre det kan du også indtaste kommandoen zmprov mcf zimbraLogHostname mailstore01.company.ru
Også på hver server skal du indtaste følgende kommandoer:
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 restartEfter dette vil alle logs blive gemt på den server, du har angivet, hvor de nemt kan ses. Også i Zimbra OSE-administratorens konsol vil den aktive Logger-tjeneste kun blive vist på serveren mailstore01.
En anden hovedpine for administratoren kan være at spore en bestemt e-mail. Da e-mails i Zimbra OSE gennemgår flere forskellige hændelser: antivirus- og antispamkontroller, før de accepteres eller sendes, kan det for administratoren være temmelig problematisk at spore, på hvilket trin den ikke kom igennem.
For at løse dette problem kan man bruge et specialskrevet script, som er udviklet af sikkerhedseksperten Viktor Dukhovniy, og som anbefales af Postfix-udviklere. Dette script concatenates poster fra logfilerne for en given proces og gør det muligt hurtigt at vise alle poster relateret til afsendelsen af en bestemt e-mail baseret på dens identifikation. Dets funktionalitet er testet på alle versioner af Zimbra OSE, startende fra 8.7. Her er teksten til scriptet.
#! /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 det gemmes i en fil collate.pl, gøres eksekverbart og derefter køres filen med angivelse af logfilen og ved hjælp af pgrep at udtrække identifikationsoplysningerne for den ønskede e-mail collate.pl /var/log/zimbra.log | pgrep ‘’. Resultatet vil være en sekventiel udskrift af linjer, der indeholder oplysninger om bevægelsen af e-mailen på serveren.
# 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: removedHvis du har spørgsmål vedrørende Zextras Suite, kan du kontakte virksomhedens repræsentant "Zextras", Ekaterina Triandafiliidi, på e-mail katerina@zextras.com
Kilde: habr.com
