Tous les journaux locaux sont stockés par Zimbra OSE dans le dossier / opt / zimbra / log, et les journaux peuvent également être trouvés dans le fichier /var/log/zimbra.log. Le plus important d'entre eux est mailbox.log. Il enregistre toutes les actions qui ont lieu sur le serveur de messagerie. Parmi eux, il y a la transmission de lettres, des données sur l'authentification des utilisateurs, des tentatives de connexion infructueuses et d'autres. Les entrées dans mailbox.log sont une chaîne de texte qui contient l'heure à laquelle l'événement s'est produit, le niveau de l'événement, le numéro du flux dans lequel l'événement s'est produit, le nom d'utilisateur et son adresse IP, ainsi que la description textuelle de l'événement.
Le niveau de journalisation indique le degré auquel l'événement affecte le serveur. Par défaut, 4 niveaux d'événements sont utilisés: INFO, WARN, ERROR et FATAL. Analysons tous les niveaux par ordre de gravité croissante.
- INFO — Zimbra OSE.
- WARN — , , . WARN .
- ERROR — , . , .
- FATAL — , - . FATAL .
Le fichier journal du serveur de messagerie est mis à jour quotidiennement. La dernière version du fichier porte toujours le nom Mailbox.log, tandis que les journaux pour une certaine date ont une date dans le nom et sont contenus dans l'archive. Par exemple mailbox.log.2020-09-29.tar.gz. Cela simplifie considérablement la sauvegarde des journaux d'action et la recherche dans les journaux.
Pour la commodité de l'administrateur système, le dossier / opt / zimbra / log / contient d'autres journaux. Ils incluent uniquement les entrées qui se rapportent à des éléments Zimbra OSE spécifiques. Par exemple, audit.log contient uniquement des entrées sur l'authentification des utilisateurs, clamd.log contient des données sur le fonctionnement de l'antivirus, etc. À propos, une excellente méthode pour protéger le serveur Zimbra OSE des intrus consiste à protéger le serveur à l'aide de Fail2Ban.qui fonctionne simplement basé sur audit.log. Il est également recommandé d'ajouter une tâche cron pour exécuter la commande grep -ir "invalid password" /opt/zimbra/log/audit.log afin de recevoir des informations quotidiennes sur les tentatives de connexion infructueuses.
Un exemple de la façon dont deux fois le mot de passe incorrect et la tentative de connexion réussie sont affichés dans audit.log
Les journaux dans Zimbra OSE peuvent être extrêmement utiles pour déterminer les causes de diverses défaillances critiques. Au moment où une erreur critique se produit, l'administrateur n'a généralement pas le temps de lire les journaux. Il est nécessaire de restaurer le fonctionnement du serveur dès que possible. Cependant, plus tard, lorsque le serveur s'exécute à nouveau et génère de nombreux journaux, il peut être difficile de trouver l'entrée requise dans un fichier volumineux. Afin de trouver rapidement un enregistrement d'erreur, il suffit de connaître l'heure à laquelle le serveur a été redémarré et de trouver une entrée dans les journaux datés à cette heure. L'enregistrement précédent sera l'enregistrement de l'erreur qui s'est produite. Vous pouvez également trouver le message d'erreur en recherchant le mot-clé FATAL.
En outre, les journaux Zimbra OSE vous permettent d'identifier les pannes non critiques. Par exemple, pour rechercher des exceptions de gestionnaire, vous pouvez rechercher une exception de gestionnaire. Souvent, les erreurs générées par les gestionnaires sont accompagnées d'une trace de pile, ce qui explique la cause de l'exception. En cas d'erreurs lors de la remise du courrier, vous devez commencer votre recherche avec le mot-clé LmtpServer, et pour rechercher des erreurs liées aux protocoles POP ou IMAP, vous pouvez utiliser les mots-clés ImapServer et Pop3Server.
En outre, les journaux peuvent aider à enquêter sur les incidents de sécurité des informations. Prenons un exemple spécifique. Le 20 septembre, l'un des employés a envoyé une lettre infectée par un virus au client. En conséquence, les données sur l'ordinateur du client ont été cryptées. Cependant, l'employé jure qu'il n'a rien envoyé. Dans le cadre d'une enquête sur les incidents, le service de sécurité d'entreprise demande à l'administrateur système les journaux du serveur de messagerie du 20 septembre associés à l'utilisateur faisant l'objet de l'enquête. Grâce à l'horodatage, l'administrateur système trouve le fichier nécessaire avec les journaux, extrait les informations nécessaires et les transfère au personnel de sécurité. Ceux-ci, à leur tour, le parcourent et constatent que l'adresse IP à partir de laquelle cette lettre a été envoyée correspond à l'adresse IP de l'ordinateur de l'utilisateur.Des images de vidéosurveillance ont confirmé que l'employé se trouvait sur son lieu de travail lorsque la lettre a été envoyée. Ces données étaient suffisantes pour l'accuser d'avoir enfreint les règles de sécurité de l'information et le renvoyer.
Un exemple d'extraction d'enregistrements sur l'un des comptes de Mailbox.log dans un fichier séparé
Tout devient beaucoup plus compliqué lorsqu'il s'agit d'infrastructure multi-serveurs. Étant donné que les journaux sont collectés localement, il est très peu pratique de travailler avec eux dans une infrastructure multi-serveurs et il est donc nécessaire de centraliser la collecte des journaux. Cela peut être fait en configurant l'hôte pour la collecte des journaux. Il n'est pas particulièrement nécessaire d'ajouter un hôte dédié à l'infrastructure. Tout serveur de messagerie peut servir de nœud pour la collecte des journaux. Dans notre cas, ce sera le nœud Mailstore01.
Sur ce serveur, nous devons entrer les commandes suivantes:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vModifiez le fichier / etc / sysconfig / rsyslog et définissez SYSLOGD_OPTIONS = ”- r -c 2 ″
Modifiez /etc/rsyslog.conf et décommentez les lignes suivantes:
$ ModLoad imudp
$ UDPServerRun 514
Entrez les commandes suivantes:
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/zmupdateauthkeysVous pouvez vérifier que tout fonctionne avec la commande zmprov gacf | grep zimbraLogHostname. Après avoir exécuté la commande, le nom de l'hôte qui collecte les journaux doit être affiché. Pour le modifier, vous devez entrer la commande zmprov mcf zimbraLogHostname mailstore01.company.ru.
Sur tous les autres serveurs d'infrastructure (LDAP, MTA et autres stockages de courrier), exécutez la commande zmprov gacf | grep zimbraLogHostname pour voir le nom de l'hôte vers lequel les journaux vont. Pour le modifier, vous pouvez également entrer la commande zmprov mcf zimbraLogHostname mailstore01.company.ru
De plus, sur chaque serveur, entrez les commandes suivantes:
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 restartAprès cela, tous les journaux seront enregistrés sur le serveur que vous avez spécifié, où ils peuvent être consultés facilement. Également dans la console d'administration de Zimbra OSE sur l'écran avec des informations sur l'état des serveurs, le service Logger en cours d'exécution sera affiché uniquement sur le serveur mailstore01.
Un autre casse-tête pour un administrateur peut être le suivi d'un e-mail spécifique. Étant donné que les e-mails dans Zimbra OSE passent par plusieurs événements différents à la fois: vérification par antivirus, anti-spam, etc., avant d'être reçus ou envoyés, pour l'administrateur, si un e-mail n'arrive pas, il peut être assez problématique de retracer à quel stade il a été perdu ...
Pour résoudre ce problème, vous pouvez utiliser un script spécial, qui a été développé par le spécialiste de la sécurité de l'information Viktor Dukhovny et qui est recommandé aux développeurs de Postfix. Ce script concatène les enregistrements des journaux pour un processus spécifique et, de ce fait, vous permet d'afficher rapidement tous les enregistrements associés à l'envoi d'une lettre particulière en fonction de son identifiant. Son travail a été testé sur toutes les versions de Zimbra OSE, à partir de la 8.7. Voici le texte du 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";
}Le script est écrit en Perl et pour l'exécuter, vous devez l'enregistrer dans le fichier collate.pl , le rendre exécutable, puis exécuter le fichier en spécifiant le fichier journal et en utilisant pgrep pour mettre en évidence les informations d'identification de la lettre requise collate.pl /var/log/zimbra.log | pgrep '<20200929164500 \ .user @ mail \ .company \ .ru>' . Le résultat sera une sortie séquentielle de lignes contenant des informations sur le mouvement de la lettre sur le serveur.
# 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: removedPour toutes questions relatives à Zextras Suite, vous pouvez contacter le Représentant de la société Zextras Ekaterina Triandafilidi par e-mail katerina@zextras.com