ProHoster > Blog > Administration > Wie man mit Zimbra OSE-Logs arbeitet

Wie man mit Zimbra OSE-Logs arbeitet

Das Protokollieren aller Ereignisse ist eine der wichtigsten Funktionen jedes Unternehmenssystems. Protokolle helfen, auftretende Probleme zu lösen, Audits der Informationssysteme durchzufĂŒhren und SicherheitsvorfĂ€lle zu untersuchen. Zimbra OSE fĂŒhrt ebenfalls detaillierte Protokolle seiner AktivitĂ€ten. Diese enthalten alle Daten von der Serverleistung bis zum Senden und Empfangen von E-Mails durch die Benutzer. Das Lesen der von Zimbra OSE generierten Protokolle ist jedoch eine ziemlich anspruchsvolle Aufgabe. In diesem Artikel zeigen wir Ihnen am konkreten Beispiel, wie Sie die Protokolle von Zimbra OSE lesen und sie zentralisieren können.

Wie man mit Zimbra OSE-Logs arbeitet
Alle lokalen Protokolle von Zimbra OSE werden im Verzeichnis /opt/zimbra/log gespeichert. DarĂŒber hinaus sind die Protokolle in der Datei /var/log/zimbra.log zu finden. Das wichtigste davon ist mailbox.log. Dort werden alle Aktionen erfasst, die auf dem Mailserver stattfinden. Dazu gehören der Versand von Mails, Daten zur Benutzeranmeldung, fehlgeschlagene Anmeldeversuche und andere. Eintragungen im mailbox.log bestehen aus einer Textzeile, die die Zeit des Ereignisses, den Ereignislevel, die Thread-Nummer, in deren Rahmen das Ereignis stattfand, den Benutzernamen und die IP-Adresse sowie eine textliche Beschreibung des Ereignisses enthĂ€lt.

Wie man mit Zimbra OSE-Logs arbeitet

Das Protokollevel zeigt den Grad der Auswirkung eines Ereignisses auf die Serverbetrieb an. StandardmĂ€ĂŸig werden vier Ereignislevel verwendet: INFO, WARN, ERROR und FATAL. Lassen Sie uns diese Levels in aufsteigender Reihenfolge ihrer Schwere betrachten.

  • INFO — Ereignisse auf diesem Level sollen in der Regel ĂŒber den Fortgang von Zimbra OSE informieren. Unter den Nachrichten dieses Levels finden sich Berichte ĂŒber die Erstellung oder Löschung von PostfĂ€chern und vieles mehr.
  • WARN — Ereignisse dieses Levels informieren ĂŒber potenziell gefĂ€hrliche Situationen, die jedoch keine Auswirkungen auf den Betrieb des Servers haben. Ein Beispiel fĂŒr eine WARN-Stufe wĂ€re eine Meldung ĂŒber einen fehlgeschlagenen Anmeldeversuch eines Benutzers.
  • ERROR — dieses Ereignislevel im Protokoll informiert ĂŒber das Auftreten eines Fehlers, der lokal ist und den Betrieb des Servers nicht beeintrĂ€chtigt. So könnte beispielsweise ein Fehler angezeigt werden, bei dem die Indexdaten eines einzelnen Benutzers beschĂ€digt sind.
  • FATAL — auf diesem Level werden Fehler markiert, aufgrund derer der Server nicht normal weiterarbeiten kann. Ein Beispiel wĂ€re eine FATAL-Meldung ĂŒber die Unmöglichkeit, sich mit der Datenbank zu verbinden.

Die Datei mit den Protokollen des Mailservers wird tĂ€glich aktualisiert. Die aktuelle Version der Datei trĂ€gt immer den Namen Mailbox.log, wĂ€hrend Protokolle fĂŒr ein bestimmtes Datum im Namen enthalten sind und in einem Archiv gespeichert werden. Zum Beispiel mailbox.log.2020-09-29.tar.gz. Dadurch wird die Sicherung der Protokolldateien und die Suche in den Protokollen erheblich erleichtert.

Zur Erleichterung des Systemadministrators befinden sich im Ordner /opt/zimbra/log/ auch weitere Protokolle. Diese enthalten nur die EintrĂ€ge, die sich auf bestimmte Elemente von Zimbra OSE beziehen. Zum Beispiel enthĂ€lt die audit.log ausschließlich EintrĂ€ge ĂŒber die Benutzerauthentifizierung, in der clamd.log stehen Daten ĂŒber die Funktionsweise des Antivirenprogramms und so weiter. Übrigens ist eine hervorragende Methode, den Zimbra OSE-Server vor Angreifern zu schĂŒtzen, den Server mit Fail2Ban zu sichern, was genau auf der Grundlage von audit.log funktioniert. Auch eine gute Praxis ist es, eine Cron-Aufgabe hinzuzufĂŒgen, um den Befehl auszufĂŒhren, grep -ir „invalid password“ /opt/zimbra/log/audit.log, um tĂ€glich Informationen ĂŒber fehlgeschlagene Anmeldeversuche zu erhalten.

Wie man mit Zimbra OSE-Logs arbeitet
Ein Beispiel dafĂŒr, wie im Protokoll audit.log ein zweimal falsches Passwort und ein erfolgreicher Anmeldeversuch angezeigt werden.

Die Protokolle in Zimbra OSE können Ă€ußerst hilfreich sein, um die Ursachen verschiedener kritischer 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 Server so schnell wie möglich wieder zum Laufen zu bringen. SpĂ€ter, wenn der Server wieder lĂ€uft und eine Vielzahl von Protokollen generiert, kann es schwierig sein, den benötigten Eintrag in der großen Datei zu finden. Um den Fehler schnell zu finden, genĂŒgt es, die Zeit zu kennen, zu der der Server neu gestartet wurde, und in den Protokollen nach einem Eintrag zu suchen, der auf diesen Zeitpunkt datiert ist. Der vorhergehende Eintrag wird der Eintrag ĂŒber den aufgetretenen Fehler sein. Außerdem kann die Fehlermeldung auch durch die Suche nach dem SchlĂŒsselwort FATAL gefunden werden.

Die Zimbra OSE Protokolle ermöglichen es auch, nicht kritische Fehler zu identifizieren. Um beispielsweise Ausnahmen im Handler zu finden, kann man nach dem Begriff handler exception suchen. Oft werden Fehler, die von den Handlers generiert werden, von einem Stack-Trace begleitet, der erklĂ€rt, was die Ursache der Ausnahme war. Im Falle von Zustellfehlern sollte die Suche mit dem SchlĂŒsselwort LmtpServer beginnen, wĂ€hrend fĂŒr Fehler, die mit den Protokollen POP oder IMAP zusammenhĂ€ngen, die Begriffe ImapServer und Pop3Server verwendet werden können.

Die Protokolle können auch bei der Untersuchung von InformationssicherheitsvorfĂ€llen hilfreich sein. Betrachten wir ein konkretes Beispiel. Am 20. September hat einer der Mitarbeiter eine mit einem Virus infizierte E-Mail an einen Kunden gesendet. Infolgedessen wurden die Daten auf dem Computer des Kunden verschlĂŒsselt. Doch der Mitarbeiter beteuert, dass er nichts gesendet hat. Im Rahmen der Untersuchung des Vorfalls fordert die Sicherheitsabteilung des Unternehmens die Protokolle des Mailservers vom 20. September an, die mit dem Benutzer verbunden sind, dessen Untersuchung stattfindet. Dank des Zeitstempels findet der Systemadministrator die benötigte Protokolldatei, extrahiert die relevanten Informationen und ĂŒbergibt sie den SicherheitskrĂ€ften. Diese wiederum sichten die Informationen und stellen fest, dass die IP-Adresse, von der diese E-Mail gesendet wurde, ĂŒbereinstimmt IP-Adresse mit dem Computer des Benutzers. Die Aufzeichnungen der Überwachungskameras bestĂ€tigten, dass der Mitarbeiter wĂ€hrend des Sendens der E-Mail an seinem Arbeitsplatz war. Diese Informationen reichten aus, um ihn wegen Verletzung der Informationssicherheitsvorschriften zu beschuldigen und ihn zu entlassen. 

Wie man mit Zimbra OSE-Logs arbeitet
Beispiel fĂŒr das Extrahieren von EintrĂ€gen eines der Benutzerkonten aus dem Log Mailbox.log in eine separate Datei

Es wird deutlich komplizierter, wenn es um eine Multiserver-Infrastruktur geht. Da die Protokolle lokal gesammelt werden, ist es sehr umstĂ€ndlich, mit ihnen in einer Multiserver-Infrastruktur zu arbeiten, weshalb die Zentralisierung der Protokollsammlung erforderlich wird. Dies kann durch die Konfiguration eines Hosts zur Protokollsammlung geschehen. Es besteht keine besondere Notwendigkeit, einen dedizierten Host in die Infrastruktur hinzuzufĂŒgen. Jeder Mailserver kann als Knoten zur Protokollsammlung dienen. In unserem Fall wird das 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 -v

Bearbeiten Sie die Datei /etc/sysconfig/rsyslog und setzen Sie den Parameter 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

ÜberprĂŒfen Sie, ob alles funktioniert, mit dem Befehl zmprov gacf | grep zimbraLogHostname. Nach AusfĂŒhrung des Befehls sollte der Hostname angezeigt werden, der die Protokolle 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 anderen E-Mail-Speichern) den Befehl zmprov gacf | grep zimbraLogHostname aus, um den Hostnamen zu sehen, an den die Protokolle gesendet werden. Um ihn zu Ă€ndern, kann ebenfalls der Befehl zmprov mcf zimbraLogHostname mailstore01.company.ru eingegeben werden.

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 restart

Nachdem dies erfolgt ist, werden alle Protokolle auf dem von Ihnen angegebenen Server aufgezeichnet, wo sie bequem eingesehen werden können. Außerdem wird im Administrator-Dashboard von Zimbra OSE auf dem Statusbildschirm der laufende Logger-Dienst nur auf dem Server mailstore01 angezeigt.

Wie man mit Zimbra OSE-Logs arbeitet

Ein weiteres Problem fĂŒr den Administrator kann die Nachverfolgung einer bestimmten E-Mail sein. Da E-Mails in Zimbra OSE mehrere verschiedene Ereignisse durchlaufen: VirenprĂŒfung, Spamfilterung und so weiter, bevor sie empfangen oder gesendet werden, kann es fĂŒr den Administrator, falls eine E-Mail nicht ankommt, recht schwierig sein nachzuvollziehen, an welchem Punkt sie verloren gegangen ist.

Um dieses Problem zu lösen, kann ein spezielles Skript verwendet werden, das von dem Sicherheitsexperten Viktor Duchovny entwickelt wurde und fĂŒr die Verwendung durch Postfix-Entwickler empfohlen wird. Dieses Skript verkettet EintrĂ€ge aus Protokollen nach einem bestimmten Prozess und ermöglicht es so, alle EintrĂ€ge schnell anzuzeigen, die mit dem Versand eines bestimmten Briefes basierend auf seiner Identifikationsnummer verbunden sind. Seine FunktionalitĂ€t wurde in 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 muss zur AusfĂŒhrung in einer Datei gespeichert werden. collate.pl, es ausfĂŒhrbar gemacht werden, und dann muss die Datei mit Angabe der Protokolldatei gestartet werden, wĂ€hrend mit pgrep die Identifikationsinformationen des gesuchten Briefes extrahiert werden. collate.pl /var/log/zimbra.log | pgrep ''. Das Ergebnis ist eine sequenzielle Ausgabe von Zeilen, die Informationen ĂŒber den Briefverkehr 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 zu Zextras Suite können Sie sich an die Vertreterin der Firma „Zextras“, Ekaterina Triandafilidi, per E-Mail unter katerina@zextras.com wenden.

Quelle: habr.com

60GB SSD 8Gb DDR4