Het registreren van alle voorkomende gebeurtenissen is een van de belangrijkste functies van elk bedrijfssysteem. Met logboeken kunt u opkomende problemen oplossen, de werking van informatiesystemen controleren en ook informatiebeveiligingsincidenten onderzoeken. Zimbra OSE houdt ook gedetailleerde logboeken bij van de werking ervan. Ze omvatten alle gegevens, van serverprestaties tot het verzenden en ontvangen van e-mails door gebruikers. Het lezen van de door Zimbra OSE gegenereerde logs is echter een nogal niet-triviale taak. In dit artikel vertellen we u aan de hand van een specifiek voorbeeld hoe u Zimbra OSE-logboeken kunt lezen en hoe u deze gecentraliseerd kunt maken.
Zimbra OSE slaat alle lokale logbestanden op in de map /opt/zimbra/log, en logbestanden zijn ook te vinden in het bestand /var/log/zimbra.log. De belangrijkste hiervan is mailbox.log. Het registreert alle acties die plaatsvinden op de mailserver. Deze omvatten de verzending van e-mails, gebruikersauthenticatiegegevens, mislukte inlogpogingen en andere. Vermeldingen in mailbox.log zijn een tekstreeks die het tijdstip bevat waarop de gebeurtenis plaatsvond, het niveau van de gebeurtenis, het threadnummer waarin de gebeurtenis plaatsvond, de gebruikersnaam en het IP-adres, evenals een tekstbeschrijving van de gebeurtenis .
Het logniveau geeft de mate van invloed van de gebeurtenis op de werking van de server aan. Standaard zijn er 4 gebeurtenisniveaus: INFO, WARN, ERROR en FATAL. Laten we alle niveaus bekijken in oplopende volgorde van ernst.
- INFO - Evenementen op dit niveau zijn meestal bedoeld om te informeren over de voortgang van Zimbra OSE. Berichten op dit niveau omvatten rapporten over het aanmaken of verwijderen van een mailbox, enzovoort.
- WARN - gebeurtenissen van dit niveau informeren over situaties die potentieel gevaarlijk zijn, maar hebben geen invloed op de werking van de server. Het WARN-niveau markeert bijvoorbeeld een bericht over een mislukte inlogpoging van een gebruiker.
- ERROR - dit gebeurtenisniveau in het logboek informeert over het optreden van een fout die lokaal van aard is en de werking van de server niet verstoort. Dit niveau kan een fout signaleren waarbij de indexgegevens van een individuele gebruiker beschadigd zijn geraakt.
- FATAAL - dit niveau duidt op fouten waardoor de server niet normaal kan blijven functioneren. Het FATAL-niveau is bijvoorbeeld voor een record dat aangeeft dat er geen verbinding kan worden gemaakt met het DBMS.
Het logbestand van de mailserver wordt elke dag bijgewerkt. De nieuwste versie van het bestand heeft altijd de naam Mailbox.log, terwijl logs voor een bepaalde datum een datum in de naam hebben en in het archief staan. Bijvoorbeeld mailbox.log.2020-09-29.tar.gz. Dit maakt het veel eenvoudiger om een back-up van activiteitenlogboeken te maken en door logboeken te zoeken.
Voor het gemak van de systeembeheerder bevat de map /opt/zimbra/log/ andere logbestanden. Ze bevatten alleen vermeldingen die betrekking hebben op specifieke Zimbra OSE-elementen. Audit.log bevat bijvoorbeeld alleen records over gebruikersauthenticatie, clamd.log bevat gegevens over de werking van de antivirus, enzovoort. Een uitstekende methode om een Zimbra OSE-server tegen indringers te beschermen is trouwens , die gewoon werkt op basis van audit.log. Het is ook een goede gewoonte om een cron-taak toe te voegen om de opdracht uit te voeren grep -ir „ongeldig wachtwoord“ /opt/zimbra/log/audit.logom dagelijkse informatie over mislukte aanmeldingen te ontvangen.
Een voorbeeld van hoe audit.log een tweemaal verkeerd ingevoerd wachtwoord en een succesvolle inlogpoging laat zien.
Logboeken in Zimbra OSE kunnen uiterst nuttig zijn bij het identificeren van de oorzaken van verschillende kritieke fouten. Op het moment dat er een kritieke fout optreedt, heeft de beheerder doorgaans geen tijd om de logs te lezen. Het is vereist om de server zo snel mogelijk te herstellen. Later, wanneer de server echter een back-up maakt en veel logboeken genereert, kan het moeilijk zijn om de vereiste vermelding in een groot bestand te vinden. Om snel een foutrecord te vinden, volstaat het om het tijdstip te kennen waarop de server opnieuw is opgestart en een vermelding in de logboeken te vinden die dateert van dat moment. De vorige invoer is een registratie van de fout die is opgetreden. U kunt de foutmelding ook vinden door te zoeken op het trefwoord FATAL.
Met Zimbra OSE-logboeken kunt u ook niet-kritieke fouten identificeren. Als u bijvoorbeeld handleruitzonderingen wilt vinden, kunt u zoeken naar handleruitzondering. Vaak gaan fouten die door handlers worden gegenereerd gepaard met een stacktrace waarin wordt uitgelegd wat de uitzondering heeft veroorzaakt. In het geval van fouten bij het bezorgen van e-mail, moet u uw zoekopdracht beginnen met het trefwoord LmtpServer, en om te zoeken naar fouten die verband houden met de POP- of IMAP-protocollen, kunt u de trefwoorden ImapServer en Pop3Server gebruiken.
Logboeken kunnen ook helpen bij het onderzoeken van informatiebeveiligingsincidenten. Laten we eens naar een specifiek voorbeeld kijken. Op 20 september stuurde een van de medewerkers een met een virus geïnfecteerde brief naar een cliënt. Als gevolg hiervan werden de gegevens op de computer van de klant gecodeerd. De medewerker zweert echter dat hij niets heeft gestuurd. Als onderdeel van het onderzoek naar het incident vraagt de bedrijfsbeveiligingsdienst bij de systeembeheerder de logbestanden van de mailserver voor 20 september op die verband houden met de onderzochte gebruiker. Dankzij de tijdstempel vindt de systeembeheerder het benodigde logbestand, haalt de benodigde informatie eruit en draagt deze over aan beveiligingsspecialisten. Die kijken er op hun beurt doorheen en ontdekken dat het IP-adres van waaruit deze brief is verzonden overeenkomt met het IP-adres van de computer van de gebruiker. Camerabeelden bevestigen dat de werknemer op zijn werkplek was toen de brief werd verzonden. Deze gegevens waren voldoende om hem te beschuldigen van het overtreden van informatiebeveiligingsregels en hem te ontslaan.
Een voorbeeld van het extraheren van records over een van de accounts uit het Mailbox.log-logboek naar een afzonderlijk bestand
Alles wordt veel ingewikkelder als het gaat om de infrastructuur met meerdere servers. Omdat logboeken lokaal worden verzameld, is het werken ermee in een infrastructuur met meerdere servers erg lastig en daarom is het nodig om het verzamelen van logboeken te centraliseren. Dit kan worden gedaan door een host in te stellen die logbestanden verzamelt. Er is geen specifieke noodzaak om een speciale host aan de infrastructuur toe te voegen. Elke mailserver kan fungeren als knooppunt voor het verzamelen van logbestanden. In ons geval is dit het knooppunt Mailstore01.
Op deze server moeten we de onderstaande opdrachten invoeren:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vBewerk het /etc/sysconfig/rsyslog bestand en stel de SYSLOGD_OPTIONS=”-r -c 2″ in
Bewerk /etc/rsyslog.conf en verwijder het commentaar op de volgende regels:
$ModLoad imudp
$UDPServerRun 514
Voer de volgende opdrachten 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/zmupdateauthkeysJe kunt controleren of alles werkt met het commando zmprov gacf | grep zimbraLogHostnaam. Na het uitvoeren van de opdracht moet de naam van de host die de logbestanden verzamelt, worden weergegeven. Om dit te wijzigen, moet u de opdracht zmprov mcf zimbraLogHostname mailstore01.company.ru invoeren.
Op alle andere infrastructuurservers (LDAP, MTA en andere mailstores) voert u de opdracht zmprov gacf |grep zimbraLogHostname uit om de naam te zien van de host waarnaar de logs worden verzonden. Om dit te wijzigen, kunt u ook de opdracht zmprov mcf zimbraLogHostname mailstore01.company.ru invoeren
U moet ook op elke server de volgende opdrachten invoeren:
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 restartHierna worden alle logs opgeslagen op de door u opgegeven server, waar ze gemakkelijk kunnen worden bekeken. Bovendien wordt in de Zimbra OSE-beheerdersconsole op het scherm met informatie over de status van servers de actieve Logger-service alleen weergegeven voor de mailstore01-server.
Een andere hoofdpijn voor een beheerder kan het bijhouden van een specifieke e-mail zijn. Omdat e-mails in Zimbra OSE verschillende gebeurtenissen tegelijk doorlopen: scannen door antivirus, antispam, enzovoort, voordat ze worden geaccepteerd of verzonden, kan het voor de beheerder behoorlijk lastig zijn om te achterhalen in welk stadium de e-mail niet aankomt als de e-mail wordt geaccepteerd of verzonden. het was verloren.
Om dit probleem op te lossen, kunt u een speciaal script gebruiken, dat is ontwikkeld door informatiebeveiligingsspecialist Viktor Dukhovny en aanbevolen voor gebruik door Postfix-ontwikkelaars. Dit script voegt vermeldingen uit logboeken voor een specifiek proces samen en stelt u hierdoor in staat snel alle vermeldingen weer te geven die verband houden met het verzenden van een bepaalde brief op basis van de identificatie ervan. Het werk is getest op alle versies van Zimbra OSE, vanaf 8.7. Hier is 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 u het in een bestand opslaan verzamelen.pl, maak het uitvoerbaar en voer vervolgens het bestand uit, specificeer het logbestand en gebruik pgrep om de identificatie-informatie te extraheren van de brief die u zoekt collate.pl /var/log/zimbra.log | pgrep '[e-mail beveiligd]. Het resultaat is een opeenvolgende uitvoer van regels met informatie over de beweging van de letter op de server.
# 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: removedVoor alle vragen met betrekking tot Zextras Suite kunt u per e-mail contact opnemen met de vertegenwoordiger van Zextras Ekaterina Triandafilidi [e-mail beveiligd]
Bron: www.habr.com