Die Protokollierung aller Ereignisse ist eine der wichtigsten Funktionen eines jeden Unternehmenssystems. Logs helfen dabei, auftretende Probleme zu lösen, die Leistung von Informationssystemen zu auditieren und Vorfälle im Bereich der Informationssicherheit zu untersuchen. Zimbra OSE führt ebenfalls detaillierte Protokolle über seine Aktivitäten. Diese enthalten alle Daten, von der Serverleistung bis hin zum Versand und Empfang von E-Mails durch die Nutzer. Allerdings ist das Lesen der von Zimbra OSE generierten Protokolle eine ziemlich anspruchsvolle Aufgabe. In diesem Artikel zeigen wir Ihnen anhand eines konkreten Beispiels, wie Sie die Protokolle von Zimbra OSE lesen können und wie Sie diese zentralisieren können.
Alle lokalen Zimbra OSE-Protokolle werden im Ordner /opt/zimbra/log gespeichert, zudem können die Protokolle in der Datei /var/log/zimbra.log gefunden werden. Das wichtigste davon ist mailbox.log. Es protokolliert alle Vorgänge, die auf dem Mailserver stattfinden. Dazu gehören der Versand von E-Mails, Authentifizierungsdaten der Benutzer, fehlgeschlagene Anmeldeversuche und weitere Aktivitäten. Die Einträge in mailbox.log bestehen aus einer Textzeile, die die Uhrzeit des Ereignisses, den Schweregrad, die Thread-Nummer, in der das Ereignis stattfand, den Benutzernamen und die IP-Adresse des Benutzers sowie eine textliche Beschreibung des Ereignisses enthält.
Der Protokollevel gibt an, wie stark das Ereignis die Funktion des Servers beeinflusst. Standardmäßig werden 4 Ereignislevels verwendet: INFO, WARN, ERROR und FATAL. Lassen Sie uns die Levels in aufsteigender Reihenfolge ihrer Schwere betrachten.
- INFO – Ereignisse auf diesem Level dienen in der Regel dazu, über den Verlauf der Zimbra OSE-Arbeiten zu informieren. Zu den Meldungen auf diesem Level gehören Berichte über die Erstellung oder Löschung von Postfächern und Ähnliches.
- WARN — Ereignisse dieser Stufe informieren über Situationen, die potenziell gefährlich sind, aber die Serverleistung nicht beeinträchtigen. Eine WARN-Stufe könnte beispielsweise eine fehlgeschlagene Anmeldeversuch eines Benutzers kennzeichnen.
- ERROR — Diese Ereignisstufe im Log informiert über einen Fehler, der lokal ist und die Serverleistung nicht beeinträchtigt. Ein solcher Fehler könnte beispielsweise darauf hinweisen, dass die Indexdaten eines bestimmten Benutzers beschädigt wurden.
- FATAL — Mit diesem Level werden Fehler markiert, die den Server daran hindern, normal weiterzuarbeiten. Ein FATAL-Level könnte beispielsweise auf einen Fehler hinweisen, bei dem keine Verbindung zur Datenbank hergestellt werden kann.
Die Protokolldatei des Mailservers wird täglich aktualisiert. Die aktuelle Version der Datei trägt immer den Namen Mailbox.log, während die Protokolle für bestimmte Tage das Datum im Namen haben und archiviert werden. Zum Beispiel mailbox.log.2020-09-29.tar.gz. Dies erleichtert die Sicherung der Aktivitätenprotokolle und die Suche in den Logs erheblich.
Für die Bequemlichkeit des Systemadministrators befinden sich im Ordner /opt/zimbra/log/ auch weitere Protokolle. Darin sind nur die Einträge enthalten, die spezifisch für bestimmte Elemente von Zimbra OSE sind. Zum Beispiel enthält die audit.log ausschließlich Einträge zur Benutzerauthentifizierung, während die clamd.log Informationen über die Funktionalität des Antivirenprogramms enthält und so weiter. Übrigens ist eine hervorragende Methode, um den Zimbra OSE-Server vor Angreifern zu schützen, , das auf der audit.log basiert. Eine gute Praxis ist auch das Hinzufügen einer Cron-Job für die Ausführung des Befehls grep -ir „invalid password“ /opt/zimbra/log/audit.log, um täglich Informationen über fehlgeschlagene Anmeldeversuche zu erhalten.
Ein Beispiel, wie im Protokoll audit.log zweimal ein falsches Passwort und ein erfolgreicher Anmeldeversuch angezeigt werden.
Die Protokolle in Zimbra OSE sind äußerst hilfreich, um die Ursachen verschiedener kritischer Ausfälle zu ermitteln. In dem Moment, in dem ein kritischer Fehler auftritt, bleibt dem Administrator oft keine Zeit, die Protokolle zu lesen. Es muss so schnell wie möglich sichergestellt werden, dass der Server wieder läuft. Später, wenn der Server wieder betriebsbereit ist und zahlreiche Protokolle generiert, kann es schwierig sein, den benötigten Eintrag in einer großen Datei zu finden. Um schnell den Fehlerprotokolleintrag zu finden, genügt es, den Zeitpunkt zu kennen, an dem der Server neu gestartet wurde, und einen entsprechenden Eintrag im Protokoll zu suchen, der zu diesem Zeitpunkt datiert ist. Der vorhergehende Eintrag stellt den registrierten Fehler dar. Außerdem kann die Fehlermeldung auch durch eine Suche mit dem Schlüsselwort FATAL gefunden werden.
Die Zimbra OSE-Protokolle ermöglichen ebenfalls die Identifizierung von weniger kritischen Fehlern. Um beispielsweise Handler-Ausnahmen zu finden, kann man nach dem Begriff handler exception suchen. Häufig sind die Fehler, die von den Handlern erzeugt werden, mit einem Stack-Trace verbunden, der erklärt, was die Ursache der Ausnahme war. Bei Zustellungsfehlern sollte man mit dem Schlüsselbegriff LmtpServer beginnen, und zur Suche nach Fehlern im Zusammenhang mit den Protokollen POP oder IMAP empfiehlt es sich, die Schlüsselworte ImapServer und Pop3Server zu verwenden.
Logs können auch bei der Untersuchung von Sicherheitsvorfällen hilfreich sein. Betrachten wir ein konkretes Beispiel. Am 20. September hat ein Mitarbeiter eine mit einem Virus infizierte E-Mail an einen Kunden gesendet. Infolgedessen wurden die Daten auf dem Computer des Kunden verschlüsselt. Der Mitarbeiter schwört jedoch, dass er nichts gesendet hat. Im Rahmen der Vorfalluntersuchung bittet die Sicherheitsabteilung des Unternehmens den Systemadministrator um die Protokolle des Mailservers vom 20. September, die mit dem betroffenen Benutzer in Verbindung stehen. Dank des Zeitstempels findet der Systemadministrator die erforderlichen Logdateien, extrahiert die relevanten Informationen und übergibt sie an die Sicherheitskräfte. Diese prüfen die Daten und stellen fest, dass die IP-Adresse, von der die E-Mail gesendet wurde, dem Computer des Benutzers entspricht. die IP-Adresse gebunden sind Videoaufzeichnungen bestätigten, dass der Mitarbeiter zum Zeitpunkt des Sendens der E-Mail an seinem Arbeitsplatz war. Diese Informationen waren ausreichend, um ihn wegen Verstoßes gegen die Informationssicherheitsrichtlinien zu beschuldigen und ihn zu entlassen.
Beispiel zum Extrahieren von Protokolleinträgen eines der Konten aus der Mailbox.log in eine separate Datei
Alles wird deutlich komplizierter, wenn es um eine Multi-Server-Infrastruktur geht. Da die Protokolle lokal gesammelt werden, ist die Arbeit mit ihnen in einer Multi-Server-Umgebung sehr umständlich, wodurch die Notwendigkeit zur Zentralisierung der Protokollsammlung entsteht. Dies kann durch die Konfiguration eines Hosts zur Protokollsammlung erreicht werden. Es besteht keine besondere Notwendigkeit, einen dedizierten Host in die Infrastruktur einzufügen. Jeder Mailserver kann als Knoten zur Protokollsammlung fungieren. In unserem Fall wird dies der Knoten Mailstore01 sein.
Auf diesem Server müssen wir die folgenden Befehle eingeben:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vBearbeiten Sie die Datei /etc/sysconfig/rsyslog und setzen Sie den Parameter SYSLOGD_OPTIONS=”-r -c 2“
Bearbeiten Sie /etc/rsyslog.conf und entfernen Sie den Kommentar von den folgenden Zeilen:
$ModLoad imudp
$UDPServerRun 514
Geben Sie die folgenden Befehle ein:
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/zmupdateauthkeysÜberprüfen Sie, ob alles funktioniert, indem Sie den Befehl zmprov gacf | grep zimbraLogHostname ausführen. Nach der Ausführung des Befehls sollte der Hostname angezeigt werden, der die Logs sammelt. Um ihn zu ändern, geben Sie den Befehl zmprov mcf zimbraLogHostname mailstore01.company.ru ein.
Führen Sie auf allen anderen Servern der Infrastruktur (LDAP, MTA und weiteren E-Mail-Speichern) den Befehl zmprov gacf | grep zimbraLogHostname aus, um den Hostnamen zu sehen, an den die Logs gesendet werden. Um ihn zu ändern, können Sie ebenfalls den Befehl zmprov mcf zimbraLogHostname mailstore01.company.ru eingeben.
Außerdem müssen auf jedem Server die folgenden Befehle eingegeben werden:
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 restartNach dieser Durchführung werden alle Logs auf dem von Ihnen angegebenen Server aufgezeichnet, wo sie bequem eingesehen werden können. Auch in der Administratorkonsole von Zimbra OSE wird der gestartete Logger-Dienst nur beim Server mailstore01 angezeigt.
Eine weitere Herausforderung für Administratoren kann das Nachverfolgen einer bestimmten E-Mail sein. Da E-Mails in Zimbra OSE mehrere verschiedene Ereignisse durchlaufen – wie Virenprüfung, Spamfilterung und mehr – bevor sie akzeptiert oder gesendet werden, kann es für Administratoren problematisch sein herauszufinden, an welchem Punkt die E-Mail verloren gegangen ist, falls sie nicht ankommt.
Um dieses Problem zu lösen, kann ein spezielles Skript verwendet werden, das von dem Informationssicherheitsexperten Viktor Duchovny entwickelt und von den Entwicklern von Postfix empfohlen wurde. Dieses Skript konsolidiert Einträge aus den Logs zu einem bestimmten Prozess und ermöglicht es so, schnell alle Aufzeichnungen anzuzeigen, die mit dem Versand einer bestimmten E-Mail basierend auf ihrer Identifikationsnummer verbunden sind. Seine Funktionalität wurde in allen Versionen von Zimbra OSE ab 8.7 getestet. Hier ist der Text des Skripts.
#! /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";
}Das Skript ist in Perl geschrieben und muss für den Start in eine Datei gespeichert werden. collate.pl, machen Sie es ausführbar und starten Sie dann die Datei unter Angabe der Protokolldatei und verwenden Sie pgrep, um die Identifikationsinformationen der gesuchten Nachricht zu extrahieren. collate.pl /var/log/zimbra.log | pgrep ‘’. Das Ergebnis wird eine aufeinanderfolgende Ausgabe von Zeilen sein, die Informationen über die Bewegung der Nachricht auf dem Server enthalten.
# 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: removedBei Fragen zu Zextras Suite können Sie sich an die Unternehmensvertreterin von «Zextras», Ekaterina Triandafiliidi, unter der E-Mail-Adresse katerina@zextras.com wenden.
Quelle: habr.com
