Alle lokalen Protokolle werden von Zimbra OSE im Ordner / opt / zimbra / log gespeichert. Protokolle finden Sie auch in der Datei /var/log/zimbra.log. Das wichtigste davon ist mailbox.log. Es zeichnet alle Aktionen auf, die auf dem Mailserver ausgeführt werden. Dazu gehören die Übertragung von Briefen, Daten zur Benutzerauthentifizierung, erfolglose Anmeldeversuche und andere. Die Einträge in mailbox.log sind eine Textzeichenfolge, die den Zeitpunkt des Auftretens des Ereignisses, die Ebene des Ereignisses, die Nummer des Streams, in dem das Ereignis aufgetreten ist, den Benutzernamen und seine IP-Adresse sowie die Textbeschreibung des Ereignisses enthält.
Die Protokollebene gibt an, inwieweit sich das Ereignis auf den Server auswirkt. Standardmäßig werden 4 Ereignisebenen verwendet: INFO, WARN, ERROR und FATAL. Lassen Sie uns alle Ebenen in der Reihenfolge zunehmender Schwere analysieren.
- INFO — Zimbra OSE.
- WARN — , , . WARN .
- ERROR — , . , .
- FATAL — , - . FATAL .
Die Mailserver-Protokolldatei wird täglich aktualisiert. Die neueste Version der Datei heißt immer Mailbox.log, während die 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 vereinfacht das Sichern von Aktionsprotokollen und das Durchsuchen von Protokollen erheblich.
Für den Systemadministrator enthält der Ordner / opt / zimbra / log / andere Protokolle. Sie enthalten nur die Einträge, die sich auf bestimmte Zimbra OSE-Elemente beziehen. Beispielsweise enthält audit.log nur Einträge zur Benutzerauthentifizierung, clamd.log Daten zum Antivirenbetrieb usw. Eine hervorragende Methode zum Schutz des Zimbra OSE-Servers vor Eindringlingen besteht übrigens darin , den Server mit Fail2Ban zu schützenDas funktioniert nur basierend auf audit.log. Es wird auch empfohlen , eine Cron-Task hinzuzufügen, um den Befehl grep -ir "ungültiges Kennwort" /opt/zimbra/log/audit.log auszuführen, damit Sie täglich Informationen über fehlgeschlagene Anmeldeversuche erhalten.
Ein Beispiel dafür, wie ein zweimal falsch eingegebenes Kennwort und ein erfolgreicher Anmeldeversuch in der Datei audit.log angezeigt werden
Protokolle in Zimbra OSE können äußerst nützlich sein, um die Ursachen für verschiedene kritische Fehler zu ermitteln. In dem Moment, in dem ein kritischer Fehler auftritt, hat der Administrator normalerweise keine Zeit, die Protokolle zu lesen. Es ist erforderlich, den Serverbetrieb so schnell wie möglich wiederherzustellen. Wenn der Server jedoch später erneut ausgeführt wird und viele Protokolle generiert, kann es schwierig sein, den erforderlichen Eintrag in einer großen Datei zu finden. Um schnell einen Fehlerdatensatz zu finden, reicht es aus, den Zeitpunkt des Neustarts des Servers zu kennen und einen Eintrag in den zu diesem Zeitpunkt datierten Protokollen zu finden. Der vorherige Datensatz ist der Datensatz des aufgetretenen Fehlers. Sie können die Fehlermeldung auch finden, indem Sie nach dem Schlüsselwort FATAL suchen.
Mit den Zimbra OSE-Protokollen können Sie auch unkritische Fehler identifizieren. Um beispielsweise Handlerausnahmen zu finden, können Sie nach Handlerausnahmen suchen. Von Handlern generierte Fehler werden häufig von einer Stapelverfolgung begleitet, die erklärt, was die Ausnahme verursacht hat. Bei Fehlern bei der E-Mail-Zustellung sollten Sie Ihre Suche mit dem Schlüsselwort LmtpServer starten. 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 Vorfällen im Bereich der Informationssicherheit hilfreich sein. Betrachten wir ein konkretes Beispiel. Am 20. September schickte einer der Mitarbeiter einen mit Viren infizierten Brief an den Kunden. Infolgedessen wurden die Daten auf dem Computer des Clients verschlüsselt. Der Mitarbeiter schwört jedoch, dass er nichts gesendet hat. Im Rahmen einer Vorfalluntersuchung fordert der Sicherheitsdienst des Unternehmens den Systemadministrator auf, die Mailserverprotokolle vom 20. September für den untersuchten Benutzer zu erstellen. Dank des Zeitstempels findet der Systemadministrator die erforderliche Datei mit Protokollen, extrahiert die erforderlichen Informationen und überträgt sie an das Sicherheitspersonal. 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 des Versands 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 über eines der Konten aus dem Mailbox.log in eine separate Datei Bei
der Multi-Server-Infrastruktur wird alles viel komplizierter. Da Protokolle lokal erfasst werden, ist es sehr unpraktisch, mit ihnen in einer Multi-Server-Infrastruktur zu arbeiten, und daher muss die Erfassung von Protokollen zentralisiert werden. Dies kann durch Konfigurieren des Hosts zum Sammeln von Protokollen erfolgen. Es ist nicht besonders erforderlich, der Infrastruktur einen dedizierten Host hinzuzufügen. Jeder Mailserver kann als Knoten zum Sammeln von Protokollen fungieren. In unserem Fall ist dies der Mailstore01-Knoten.
Auf diesem Server müssen wir die folgenden Befehle eingeben:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -v
Bearbeiten Sie die Datei / etc / sysconfig / rsyslog und setzen Sie SYSLOGD_OPTIONS = ”- r -c 2 ″.
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/zmupdateauthkeys
Sie können überprüfen, ob alles mit dem Befehl zmprov gacf | funktioniert grep zimbraLogHostname. Nach dem Ausführen des Befehls sollte der Name des Hosts angezeigt werden, der die Protokolle sammelt. Um dies zu ändern, müssen Sie den Befehl zmprov mcf zimbraLogHostname mailstore01.company.ru eingeben.
Führen Sie auf allen anderen Infrastrukturservern (LDAP, MTA und andere Mail-Speicher) den Befehl zmprov gacf | grep zimbraLogHostname aus, um den Namen des Hosts anzuzeigen, auf den sich die Protokolle beziehen. Um dies zu ändern, können Sie auch den Befehl zmprov mcf zimbraLogHostname mailstore01.company.ru eingeben. Geben Sie
außerdem auf jedem Server die folgenden Befehle ein:
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 restart
Danach werden alle Protokolle auf dem von Ihnen angegebenen Server aufgezeichnet und können bequem angezeigt werden. Auch in der Zimbra OSE-Administratorkonsole auf dem Bildschirm mit Informationen zum Status der Server wird der ausgeführte Logger-Dienst nur auf dem Mailstore01-Server angezeigt.
Ein weiteres Problem für einen Administrator kann das Verfolgen einer bestimmten E-Mail-Nachricht sein. Da E-Mails in Zimbra OSE mehrere verschiedene Ereignisse gleichzeitig durchlaufen: Überprüfung durch Antivirus, Antispam usw., bevor sie empfangen oder gesendet werden, kann es für den Administrator sehr problematisch sein, zu verfolgen, in welchem Stadium sie verloren gegangen ist, wenn eine E-Mail nicht erreicht wird ...
Um dieses Problem zu lösen, können Sie ein spezielles Skript verwenden, das vom Informationssicherheitsspezialisten Viktor Dukhovny entwickelt wurde und von Postfix-Entwicklern empfohlen wird. Dieses Skript verkettet Datensätze aus den Protokollen für einen bestimmten Prozess und ermöglicht es Ihnen daher, alle Datensätze, die mit dem Senden eines bestimmten Briefes verbunden sind, anhand seiner Kennung schnell anzuzeigen. Seine Arbeit wurde auf 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. Um es auszuführen, müssen Sie es in der Datei collate.pl speichern , ausführbar machen und dann die Datei ausführen, in der die Protokolldatei angegeben ist, und mit pgrep die Identifikationsinformationen des erforderlichen Buchstabens collate.pl /var/log/zimbra.log | hervorheben pgrep '<20200929164500 \ .user @ mail \ .company \ .ru>' . Das Ergebnis ist eine sequentielle Ausgabe von Zeilen, die Informationen über die Bewegung des Buchstabens 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: removed
Bei allen Fragen zur Zextras Suite können Sie sich per E-Mail an katerina@zextras.com an die Vertreterin der Zextras-Firma Ekaterina Triandafilidi wenden