Logging van alle gebeurtenissen is een van de meest essentiële functies van elk bedrijfssysteem. Logbestanden helpen bij het oplossen van problemen, het uitvoeren van audits van informatiesystemen en het onderzoeken van incidenten op het gebied van informatiebeveiliging. Zimbra OSE genereert ook gedetailleerde logbestanden van zijn werking. Deze bevatten gegevens van de serverprestaties tot het verzenden en ontvangen van e-mails door gebruikers. Het lezen van de logbestanden die door Zimbra OSE worden gegenereerd, is echter een tamelijk complexe taak. In dit artikel bespreken we aan de hand van een concreet voorbeeld hoe u de logbestanden van Zimbra OSE kunt lezen en hoe u ze kunt centraliseren.
Alle lokale logbestanden van Zimbra OSE worden opgeslagen in de map /opt/zimbra/log; de logbestanden zijn ook te vinden in het bestand /var/log/zimbra.log. Het belangrijkste daarvan is mailbox.log. Hierin worden alle acties die op de mailserver plaatsvinden vastgelegd. Dit omvat het verzenden van e-mails, gegevens over gebruikersauthenticatie, niet-succesvolle inlogpogingen en meer. De vermeldingen in mailbox.log zijn tekstregels die de tijd van het voorval, het niveau van het voorval, het nummer van de thread waarin het voorval zich voordeed, de gebruikersnaam en het IP-adres van de gebruiker, evenals een tekstuele beschrijving van het voorval bevatten.
Het logniveau geeft de mate van invloed van een gebeurtenis op de werking van de server aan. Standaard worden er 4 niveaus van gebeurtenissen gebruikt: INFO, WARN, ERROR en FATAL. Laten we elk niveau in volgorde van ernst bespreken.
- INFO — gebeurtenissen op dit niveau zijn meestal bedoeld om te informeren over de voortgang van Zimbra OSE. Onder de berichten op dit niveau vallen rapporten over het aanmaken of verwijderen van mailboxes, enzovoort.
- WARN — gebeurtenissen op dit niveau geven informatie over situaties die potentieel gevaarlijk zijn, maar geen invloed hebben op de werking van de server. Een WARN-niveau wordt bijvoorbeeld aangegeven bij een melding van een mislukte inlogpoging door een gebruiker.
- ERROR — dit niveau van gebeurtenis in de log informeert over het optreden van een fout die lokaal van aard is en die de werking van de server niet belemmert. Een fout waarbij de indexgegevens van een specifieke gebruiker beschadigd zijn, kan dit niveau hebben.
- FATAL — dit niveau markeert fouten waardoor de server niet normaal kan blijven functioneren. Een FATAL-niveau zou bijvoorbeeld worden toegewezen aan een registratie over het niet kunnen verbinden met de database.
Het logbestand van de e-mailserver wordt dagelijks bijgewerkt. De nieuwste versie van het bestand heeft altijd de naam Mailbox.log, terwijl de logs van een specifieke datum in de naam worden opgenomen en in een archief worden opgeslagen. Bijvoorbeeld mailbox.log.2020-09-29.tar.gz. Dit maakt het aanzienlijk gemakkelijker om de handelingen in de logs te reserveren en erin te zoeken.
Voor het gemak van de systeembeheerder bevat de map /opt/zimbra/log/ ook andere logs. Deze bevatten alleen die berichten die verband houden met specifieke elementen van Zimbra OSE. Bijvoorbeeld, audit.log bevat uitsluitend records van gebruikersauthenticatie, clamd.log bevat gegevens over de werking van de antivirus, enzovoort. Een uitstekende methode om de Zimbra OSE-server tegen kwaadwillenden te beschermen, is , dat precies op basis van audit.log werkt. Ook is het een goede praktijk om een cron-taak toe te voegen die het commando uitvoert grep -ir "invalid password" /opt/zimbra/log/audit.log, om dagelijks informatie te krijgen over mislukte inlogpogingen.
Een voorbeeld van hoe in audit.log twee keer een onjuist ingevoerd wachtwoord en een succesvolle inlogpoging worden weergegeven.
Logs in Zimbra OSE kunnen uiterst nuttig zijn bij het achterhalen van de redenen voor verschillende kritieke storingen. Op het moment dat er een kritieke fout optreedt, is de beheerder meestal niet in de stemming om de logs te lezen. Er is dringend behoefte om de werking van de server zo snel mogelijk te herstellen. Echter, later, wanneer de server weer in werking is en veel logs genereert, kan het moeilijk zijn om de nodige record te vinden in een groot bestand. Om snel de foutmelding te vinden, hoeft men alleen maar te weten op welk tijdstip de server opnieuw is opgestart en de logs te doorzoeken naar een record met die datum. De voorgaande record zal de foutmelding zijn. Ook kan een foutmelding worden gevonden met behulp van een zoekopdracht op het sleutelwoord FATAL.
De Zimbra OSE-logs helpen ook bij het identificeren van niet-kritieke storingen. Bijvoorbeeld, om handler-excepties te vinden, kan men zoeken op de zin handler exception. Vaak worden de fouten die door handlers worden gegenereerd, vergezeld van een stacktrace die uitlegt wat de oorzaak van de exceptie is. In het geval van fouten met e-mailbezorging, dient men te beginnen met het sleutelwoord LmtpServer, en voor het zoeken naar fouten gerelateerd aan de protocollen POP of IMAP kunnen de sleutelwoorden ImapServer en Pop3Server worden gebruikt.
De logs kunnen ook helpen bij het onderzoeken van incidenten in de informatiebeveiliging. Laten we een specifiek voorbeeld bekijken. Op 20 september stuurde een van de medewerkers een e-mail met een virus naar een klant. Hierdoor raakten de gegevens op de computer van de klant versleuteld. De medewerker beweert echter dat hij niets heeft verzonden. Tijdens het onderzoek van het incident vraagt de beveiligingsdienst van het bedrijf de systeemadministrator om de logs van de mailserver van 20 september op te vragen, gerelateerd aan de gebruiker die wordt onderzocht. Dankzij de timestamp vindt de systeemadministrator het benodigde logbestand, haalt de benodigde informatie eruit en geeft deze door aan de beveiligingsfunctionarissen. Zij bekijken dit en ontdekken dat het IP-adres van waaruit deze e-mail is verzonden overeenkomt met het IP-adres de computer van de gebruiker. Beelden van bewakingscamera's bevestigden dat de werknemer tijdens het verzenden van de e-mail op zijn werkplek was. Deze gegevens waren voldoende om hem te beschuldigen van het schenden van de regels voor informatiebeveiliging en om hem te ontslaan.
Voorbeeld van het extraheren van records van een van de accounts uit het logbestand Mailbox.log naar een apart bestand
Het wordt aanzienlijk gecompliceerder wanneer het gaat om een multiservininfrastructuur. Aangezien logs lokaal worden verzameld, is het erg ongebruikelijk om ermee te werken in een multiservininfrastructuur; daarom is er een behoefte aan centralisatie van logverzameling. Dit kan worden bereikt door een host voor logverzameling in te stellen. Er is geen dringende behoefte om een speciale host aan de infrastructuur toe te voegen. Elke e-mailserver kan als node voor logverzameling fungeren. In ons geval zal dat node Mailstore01 zijn.
Op deze server moeten we de onderstaande commando's invoeren:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vBewerk het bestand /etc/sysconfig/rsyslog en stel de parameter SYSLOGD_OPTIONS=”-r -c 2″ in
Bewerk /etc/rsyslog.conf en verwijder de opmerkingen van de volgende regels:
$ModLoad imudp
$UDPServerRun 514
Voer de volgende commando's 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/zmupdateauthkeysControleer of alles werkt met het commando zmprov gacf | grep zimbraLogHostname. Na uitvoering van het commando zou de hostnaam moeten worden weergegeven die de logs verzamelt. Om dit te wijzigen, moet je het commando zmprov mcf zimbraLogHostname mailstore01.company.ru invoeren.
Voer op alle andere servers in de infrastructuur (LDAP, MTA en andere e-mailopslagplaatsen) het commando zmprov gacf | grep zimbraLogHostname uit om de hostnaam te zien waar de logs naartoe gaan. Ook om dit te wijzigen, kan het commando zmprov mcf zimbraLogHostname mailstore01.company.ru worden ingevoerd.
Ook op elke server moeten de volgende commando's worden ingevoerd:
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 worden alle logs geregistreerd op de door jou opgegeven server, waar ze gemakkelijk kunnen worden bekeken. Ook in de Zimbra OSE-beheerdersconsole zal de draaiende Logger-service alleen op server mailstore01 worden weergegeven in het statusoverzicht van de servers.
Een andere uitdaging voor de beheerder kan het volgen van een bepaalde e-mail zijn. Aangezien e-mails in Zimbra OSE verschillende gebeurtenissen ondergaan: antiviruscontrole, antispam, enzovoort, voordat ze worden ontvangen of verzonden, kan het behoorlijk problematisch zijn voor de beheerder om te achterhalen op welk punt de e-mail verloren is gegaan als deze niet aankomt.
Om dit probleem op te lossen, kan een speciaal script worden gebruikt, ontwikkeld door beveiligingsspecialist Viktor Dukhivny en aanbevolen voor gebruik door Postfix-ontwikkelaars. Dit script concateneert logboekvermeldingen van een specifiek proces en stelt zo in staat om snel alle vermeldingen weer te geven die verband houden met de verzending van een bepaalde e-mail op basis van zijn identificatie. Het is getest op alle versies van Zimbra OSE, beginnend vanaf 8.7. Hieronder vindt u de tekst van het script.
#! /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";
}Het script is geschreven in Perl en om het uit te voeren, moet het in een bestand worden opgeslagen. collate.pl, maak het uitvoerbaar en voer vervolgens het bestand uit met de logbestand opgeven en met behulp van pgrep de identificatie-informatie van de gewenste e-mail extraheren. collate.pl /var/log/zimbra.log | pgrep ‘’. Het resultaat zal een opeenvolgende uitvoer zijn van de regels waarin informatie over de status van de e-mail op de server is opgenomen.
# 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: removedVoor vragen over Zextras Suite kunt u contact opnemen met de vertegenwoordiger van het bedrijf 'Zextras', Ekaterina Triandafiliadi, via e-mail katerina@zextras.com
Bron: habr.com
