La journalisation de tous les événements qui se produisent est l'une des fonctions les plus importantes de tout système d'entreprise. Les journaux permettent de résoudre les problèmes qui surviennent, de réaliser des audits du fonctionnement des systèmes d'information, ainsi que d'enquêter sur des incidents de sécurité informatique. Zimbra OSE tient également des journaux détaillés de son fonctionnement. Ces journaux contiennent toutes les données allant de la performance du serveur à l'envoi et à la réception de courriels par les utilisateurs. Cependant, la lecture des journaux générés par Zimbra OSE est une tâche plutôt complexe. Dans cet article, nous vous expliquerons comment lire les journaux de Zimbra OSE à travers un exemple concret, ainsi que comment les centraliser.
Tous les journaux locaux de Zimbra OSE sont stockés 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 celles-ci, la transmission de courriers, les données d'authentification des utilisateurs, les tentatives de connexion échouées, et d'autres. Les enregistrements dans mailbox.log se présentent sous forme de chaîne de texte contenant l'heure à laquelle l'événement s'est produit, le niveau de l'événement, le numéro du thread dans lequel l'événement a eu lieu, le nom de l'utilisateur et son adresse IP, ainsi que la description textuelle de l'événement.
Le niveau du journal indique le degré d'impact de l'événement sur le fonctionnement du serveur. Par défaut, quatre niveaux d'événements sont utilisés : INFO, WARN, ERROR et FATAL. Examinons tous les niveaux par ordre croissant de gravité.
- INFO — les événements à ce niveau visent généralement à informer sur le déroulement du travail de Zimbra OSE. Parmi les messages de ce niveau figurent des rapports sur la création ou la suppression de boîtes aux lettres, etc.
- WARN — les événements de ce niveau informent sur des situations potentiellement dangereuses, mais qui n'affectent pas le fonctionnement du serveur. Le niveau WARN, par exemple, est utilisé pour marquer un message sur une tentative de connexion échouée d'un utilisateur.
- ERROR — ce niveau d'événement dans le journal informe de l'apparition d'une erreur qui est de nature locale et n'empêche pas le fonctionnement du serveur. Une erreur de ce niveau pourrait être marquée lorsque les données d'index d'un utilisateur particulier sont corrompues.
- FATAL — ce niveau marque les erreurs qui empêchent le serveur de fonctionner normalement. Par exemple, un enregistrement de niveau FATAL apparaîtrait pour indiquer une impossibilité de se connecter à la base de données.
Le fichier de logs du serveur mail est mis à jour chaque jour. La version récente du fichier porte toujours le nom Mailbox.log, tandis que les logs pour une certaine date contiennent la date dans leur nom et sont archivés. Par exemple mailbox.log.2020-09-29.tar.gz. Cela facilite grandement la sauvegarde des journaux d'activités et la recherche dans les logs.
Pour le confort de l'administrateur système, le dossier /opt/zimbra/log/ contient d'autres logs. Ceux-ci ne comprennent que les entrées qui se rapportent à des éléments spécifiques de Zimbra OSE. Par exemple, audit.log contient uniquement des enregistrements d'authentification des utilisateurs, clamd.log fournit des informations sur le fonctionnement de l'antivirus, et ainsi de suite. D'ailleurs, une excellente méthode de protection du serveur Zimbra OSE contre les intrus est , qui fonctionne justement sur la base d'audit.log. De plus, il est bon de programmer une tâche cron pour exécuter la commande grep -ir "invalid password" /opt/zimbra/log/audit.log, afin de recevoir quotidiennement des informations sur les tentatives de connexion échouées.
Voici un exemple de la manière dont le log audit.log affiche une saisie incorrecte de mot de passe à deux reprises et une tentative de connexion réussie.
Les logs dans Zimbra OSE peuvent être extrêmement utiles pour déterminer les causes de divers échecs critiques. Lorsque l'erreur critique se produit, l'administrateur n'a généralement pas le temps de lire les logs. Il est nécessaire de rétablir le fonctionnement du serveur aussi rapidement que possible. Cependant, plus tard, lorsque le serveur fonctionne à nouveau et génère de nombreux logs, retrouver l'enregistrement désiré dans un gros fichier peut être difficile. Pour trouver rapidement l'enregistrement d'une erreur, il suffit de connaître le moment où le serveur a été redémarré et de chercher dans les logs l'enregistrement daté à cette heure. L'enregistrement précédent sera celui de l'erreur survenue. Il est également possible de trouver un message d'erreur en recherchant le mot-clé FATAL.
Les journaux de Zimbra OSE permettent également d'identifier les défaillances non critiques. Par exemple, pour rechercher des exceptions de gestionnaire, vous pouvez effectuer une recherche avec le terme handler exception. Souvent, les erreurs générées par les gestionnaires sont accompagnées d'une trace de pile, indiquant la cause de l'exception. En cas d'erreurs de livraison de courrier, il est recommandé de commencer la recherche avec le mot clé LmtpServer, tandis que pour les erreurs liées aux protocoles POP ou IMAP, vous pouvez utiliser les mots clés ImapServer et Pop3Server.
Les journaux peuvent également aider lors d'enquêtes sur des incidents de sécurité informatique. Considérons un exemple concret. Le 20 septembre, l'un des employés a envoyé un e-mail infecté par un virus à un client. Par conséquent, les données sur l'ordinateur du client ont été chiffrées. Cependant, l'employé jure qu'il n'a rien envoyé. Dans le cadre de l'enquête sur l'incident, le service de sécurité de l'entreprise demande à l'administrateur système les journaux du serveur de messagerie pour le 20 septembre, liés à l'utilisateur concerné par l'enquête. Grâce à l'horodatage, l'administrateur système retrouve le fichier journal approprié, extrait les informations nécessaires et les transmet à la sécurité. Ces derniers, à leur tour, examinent les données et découvrent que l'adresse IP depuis laquelle cet e-mail a été envoyé correspond une adresse IP à l'ordinateur de l'utilisateur. Les enregistrements des caméras de surveillance ont confirmé que l'employé était à son poste lors de l'envoi de l'e-mail. Ces données ont suffi pour l'accuser de violation des règles de sécurité de l'information et pour le licencier.
Exemple d'extraction des enregistrements d'un des comptes à partir du journal Mailbox.log dans un fichier séparé
Tout se complique considérablement lorsque l'on parle d'une infrastructure multi-serveurs. Étant donné que les journaux sont collectés localement, il est très difficile de travailler avec eux dans une infrastructure multi-serveurs, ce qui rend nécessaire la centralisation de la collecte des journaux. Cela peut être réalisé en configurant un hôte pour la collecte des journaux. Il n'est pas particulièrement nécessaire d'ajouter un hôte dédié à l'infrastructure. N'importe quel 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 l'option SYSLOGD_OPTIONS=”-r -c 2″
Éditez /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 logs doit s'afficher. Pour le modifier, il est nécessaire d'entrer la commande zmprov mcf zimbraLogHostname mailstore01.company.ru.
Sur tous les autres serveurs de l'infrastructure (LDAP, MTA et autres stockages de messagerie), exécutez la commande zmprov gacf | grep zimbraLogHostname pour voir le nom de l'hôte vers lequel les logs sont envoyés. Pour le modifier, vous pouvez également entrer la commande zmprov mcf zimbraLogHostname mailstore01.company.ru.
De plus, il est nécessaire d'entrer les commandes suivantes sur chaque serveur :
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 logs seront enregistrés sur le serveur que vous avez spécifié, où ils pourront être consultés facilement. De plus, dans la console d'administration Zimbra OSE, l'état du service Logger sera affiché uniquement sur le serveur mailstore01.
Une autre source de tracas pour l'administrateur peut être le suivi d'un message électronique particulier. Étant donné que les e-mails dans Zimbra OSE passent par plusieurs événements différents : vérification antivirus, antispam, etc., avant d'être acceptés ou envoyés, il peut être très problématique pour l'administrateur de savoir à quel stade un e-mail a été perdu s'il ne parvient pas.
Pour résoudre ce problème, vous pouvez utiliser un script spécial développé par le spécialiste en sécurité de l'information Victor Dukhovniy, recommandé à l'usage des développeurs de Postfix. Ce script concatène les entrées des journaux par un processus donné, permettant ainsi d'afficher rapidement toutes les entrées liées à l'envoi d'un courrier spécifique basé sur son identifiant. Son fonctionnement a été testé sur toutes les versions de Zimbra OSE à partir de 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 le faire fonctionner, vous devez l'enregistrer dans un fichier collate.pl, le rendre exécutable, puis exécuter le fichier en spécifiant le fichier des journaux et en utilisant pgrep pour extraire les informations d'identification de l'e-mail recherché. collate.pl /var/log/zimbra.log | pgrep ''. Le résultat sera une sortie séquentielle des lignes contenant des informations sur le traitement de l'e-mail 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 toute question concernant Zextras Suite, vous pouvez contacter la représentante de la société « Zextras », Ekaterina Triandaphilidi, par e-mail à katerina@zextras.com.
Source : habr.com
