Die Protokollierung aller auftretenden Ereignisse ist eine der wichtigsten Funktionen eines jeden Unternehmenssystems. Mithilfe von Protokollen können Sie aufkommende Probleme lösen, den Betrieb von Informationssystemen überprüfen und auch Vorfälle im Bereich der Informationssicherheit untersuchen. Zimbra OSE führt außerdem detaillierte Protokolle seines Betriebs. Sie umfassen alle Daten von der Serverleistung bis zum Senden und Empfangen von E-Mails durch Benutzer. Das Lesen der von Zimbra OSE generierten Protokolle ist jedoch keine triviale Aufgabe. In diesem Artikel erklären wir Ihnen anhand eines konkreten Beispiels, wie Sie Zimbra OSE-Protokolle lesen und zentralisieren.
Zimbra OSE speichert alle lokalen Protokolle im Ordner /opt/zimbra/log, und Protokolle sind auch in der Datei /var/log/zimbra.log zu finden. Das wichtigste davon ist mailbox.log. Es zeichnet alle Aktionen auf, die auf dem Mailserver stattfinden. Dazu gehören die Übertragung von E-Mails, Benutzerauthentifizierungsdaten, fehlgeschlagene Anmeldeversuche und andere. Einträge in mailbox.log sind eine Textzeichenfolge, die den Zeitpunkt, zu dem das Ereignis aufgetreten ist, die Ebene des Ereignisses, die Thread-Nummer, in der das Ereignis aufgetreten ist, den Benutzernamen und die IP-Adresse sowie eine Textbeschreibung des Ereignisses enthält .
Die Protokollebene gibt den Grad des Einflusses des Ereignisses auf den Serverbetrieb an. Standardmäßig gibt es 4 Ereignisstufen: INFO, WARN, ERROR und FATAL. Schauen wir uns alle Ebenen in aufsteigender Reihenfolge ihres Schweregrads an.
- INFO – Veranstaltungen auf dieser Ebene sollen normalerweise über den Fortschritt von Zimbra OSE informieren. Zu den Nachrichten auf dieser Ebene gehören Berichte über die Erstellung oder Löschung eines Postfachs usw.
- WARN – Ereignisse dieser Stufe informieren über potenziell gefährliche Situationen, haben jedoch keinen Einfluss auf den Betrieb des Servers. Beispielsweise markiert die Stufe WARN eine Meldung über einen fehlgeschlagenen Anmeldeversuch eines Benutzers.
- FEHLER – diese Ereignisebene im Protokoll informiert über das Auftreten eines Fehlers, der lokaler Natur ist und den Betrieb des Servers nicht beeinträchtigt. Diese Ebene kann einen Fehler kennzeichnen, bei dem die Indexdaten eines einzelnen Benutzers beschädigt wurden.
- FATAL – diese Stufe weist auf Fehler hin, aufgrund derer der Server nicht normal weiterarbeiten kann. Die Stufe FATAL gilt beispielsweise für einen Datensatz, der angibt, dass keine Verbindung zum DBMS hergestellt werden kann.
Die Protokolldatei des Mailservers wird täglich aktualisiert. Die neueste Version der Datei hat immer den Namen Mailbox.log, während Protokolle für ein bestimmtes Datum ein Datum im Namen haben und im Archiv enthalten sind. Zum Beispiel mailbox.log.2020-09-29.tar.gz. Dies erleichtert das Sichern von Aktivitätsprotokollen und das Durchsuchen von Protokollen erheblich.
Zur Vereinfachung für den Systemadministrator enthält der Ordner /opt/zimbra/log/ weitere Protokolle. Sie umfassen nur Einträge, die sich auf bestimmte Zimbra OSE-Elemente beziehen. Audit.log enthält beispielsweise nur Datensätze zur Benutzerauthentifizierung, clamd.log enthält Daten zum Betrieb des Antivirenprogramms usw. Eine hervorragende Methode zum Schutz eines Zimbra OSE-Servers vor Eindringlingen ist übrigens , was nur basierend auf audit.log funktioniert. Es empfiehlt sich auch, einen Cron-Task hinzuzufügen, um den Befehl auszuführen grep -ir „ungültiges Passwort“ /opt/zimbra/log/audit.logum täglich Informationen zu Anmeldefehlern zu erhalten.
Ein Beispiel dafür, wie audit.log ein zweimal falsch eingegebenes Passwort und einen erfolgreichen Anmeldeversuch anzeigt.
Protokolle in Zimbra OSE können äußerst nützlich sein, um die Ursachen verschiedener kritischer Fehler zu identifizieren. In dem Moment, in dem ein kritischer Fehler auftritt, hat der Administrator normalerweise keine Zeit, die Protokolle zu lesen. Es ist erforderlich, den Server so schnell wie möglich wiederherzustellen. Später, wenn der Server jedoch hochgefahren ist und viele Protokolle generiert, kann es schwierig sein, den erforderlichen Eintrag in einer großen Datei zu finden. Um einen Fehlereintrag schnell zu finden, reicht es aus, den Zeitpunkt des Neustarts des Servers zu kennen und in den Protokollen einen Eintrag aus diesem Zeitpunkt zu finden. Der vorherige Eintrag ist eine Aufzeichnung des aufgetretenen Fehlers. Sie können die Fehlermeldung auch finden, indem Sie nach dem Schlüsselwort FATAL suchen.
Mit Zimbra OSE-Protokollen können Sie auch unkritische Fehler identifizieren. Um beispielsweise Handler-Ausnahmen zu finden, können Sie nach Handler-Ausnahmen suchen. Häufig werden von Handlern generierte Fehler von einem Stack-Trace begleitet, der erklärt, was die Ausnahme verursacht hat. Bei Fehlern bei der E-Mail-Zustellung sollten Sie Ihre Suche mit dem Schlüsselwort LmtpServer beginnen. Um nach Fehlern im Zusammenhang mit den POP- oder IMAP-Protokollen zu suchen, können Sie die Schlüsselwörter ImapServer und Pop3Server verwenden.
Protokolle können auch bei der Untersuchung von Informationssicherheitsvorfällen hilfreich sein. Schauen wir uns ein konkretes Beispiel an. Am 20. September schickte einer der Mitarbeiter einen mit Viren infizierten Brief an einen Kunden. Dadurch wurden die Daten auf dem Computer des Kunden verschlüsselt. Der Mitarbeiter schwört jedoch, dass er nichts geschickt hat. Im Rahmen der Untersuchung des Vorfalls fordert der Sicherheitsdienst des Unternehmens vom Systemadministrator die Mailserverprotokolle für den 20. September an, die mit dem untersuchten Benutzer verknüpft sind. Dank des Zeitstempels findet der Systemadministrator die erforderliche Protokolldatei, extrahiert die erforderlichen Informationen und übermittelt sie an Sicherheitsspezialisten. Diese wiederum durchsuchen es und stellen fest, dass die IP-Adresse, von der dieser Brief gesendet wurde, mit der IP-Adresse des Computers des Benutzers übereinstimmt. CCTV-Aufnahmen bestätigten, dass sich der Mitarbeiter zum Zeitpunkt der Absendung des Briefes an seinem Arbeitsplatz befand. Diese Daten reichten aus, um ihn des Verstoßes gegen die Regeln der Informationssicherheit zu beschuldigen und ihn zu entlassen.
Ein Beispiel für das Extrahieren von Datensätzen zu einem der Konten aus dem Mailbox.log-Protokoll in eine separate Datei
Bei einer Multi-Server-Infrastruktur wird alles deutlich komplizierter. Da Protokolle lokal gesammelt werden, ist die Arbeit mit ihnen in einer Infrastruktur mit mehreren Servern sehr umständlich und daher besteht die Notwendigkeit, die Protokollsammlung zu zentralisieren. Dies kann durch die Einrichtung eines Hosts zum Sammeln von Protokollen erfolgen. Es besteht keine besondere Notwendigkeit, der Infrastruktur einen dedizierten Host hinzuzufügen. Jeder Mailserver kann als Knotenpunkt zum Sammeln von Protokollen fungieren. In unserem Fall ist dies der Knoten Mailstore01.
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 legen Sie SYSLOGD_OPTIONS=“-r -c 2“ fest.
Bearbeiten Sie /etc/rsyslog.conf und kommentieren Sie die folgenden Zeilen aus:
$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/zmupdateauthkeysMit dem Befehl zmprov gacf | können Sie überprüfen, ob alles funktioniert grep zimbraLogHostname. Nach der Ausführung des Befehls sollte der Name des Hosts angezeigt werden, der Protokolle sammelt. Um es zu ändern, müssen Sie den Befehl zmprov mcf zimbraLogHostname mailstore01.company.ru eingeben.
Führen Sie auf allen anderen Infrastrukturservern (LDAP, MTA und anderen Mailspeichern) den Befehl zmprov gacf |grep zimbraLogHostname aus, um den Namen des Hosts anzuzeigen, an den die Protokolle gesendet werden. Um es zu ändern, können Sie auch den Befehl zmprov mcf zimbraLogHostname mailstore01.company.ru eingeben
Sie müssen außerdem auf jedem Server die folgenden Befehle eingeben:
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 restartAnschließend werden alle Protokolle auf dem von Ihnen angegebenen Server aufgezeichnet und können dort bequem eingesehen werden. Außerdem wird in der Zimbra OSE-Administratorkonsole auf dem Bildschirm mit Informationen zum Status der Server der laufende Logger-Dienst nur für den Server mailstore01 angezeigt.
Ein weiteres Problem für einen Administrator kann es sein, den Überblick über eine bestimmte E-Mail zu behalten. Da E-Mails in Zimbra OSE mehrere verschiedene Ereignisse gleichzeitig durchlaufen: Scannen durch Antiviren-, Antispam- und so weiter, bevor sie akzeptiert oder gesendet werden, kann es für den Administrator, wenn die E-Mail nicht ankommt, ziemlich problematisch sein, nachzuverfolgen, in welchem Stadium es war verloren.
Um dieses Problem zu lösen, können Sie ein spezielles Skript verwenden, das vom Informationssicherheitsspezialisten Viktor Dukhovny entwickelt und für die Verwendung durch Postfix-Entwickler empfohlen wurde. Dieses Skript verkettet Einträge aus Protokollen für einen bestimmten Vorgang und ermöglicht Ihnen dadurch eine schnelle Anzeige aller Einträge, die mit dem Versenden eines bestimmten Briefes anhand seiner Kennung verbunden sind. Seine Funktion wurde auf allen Versionen von Zimbra OSE getestet, beginnend mit 8.7. 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 um es auszuführen, müssen Sie es in einer Datei speichern collate.pl, machen Sie es ausführbar und führen Sie dann die Datei aus, geben Sie die Protokolldatei an und verwenden Sie pgrep, um die Identifikationsinformationen des gesuchten Briefes zu extrahieren collate.pl /var/log/zimbra.log | pgrep '[E-Mail geschützt] >'. Das Ergebnis ist eine sequentielle Ausgabe von Zeilen mit Informationen über die Bewegung des Briefes auf dem 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: removedBei allen Fragen im Zusammenhang mit der Zextras Suite können Sie sich per E-Mail an die Vertreterin von Zextras Ekaterina Triandafilidi wenden [E-Mail geschützt]
Source: habr.com