La journalisation de tous les événements survenus est l’une des fonctions les plus importantes de tout système d’entreprise. Les journaux vous permettent de résoudre les problèmes émergents, d'auditer le fonctionnement des systèmes d'information et également d'enquêter sur les incidents de sécurité des informations. Zimbra OSE tient également des journaux détaillés de son fonctionnement. Ils incluent toutes les données depuis les performances du serveur jusqu'à l'envoi et la réception d'e-mails par les utilisateurs. Cependant, lire les logs générés par Zimbra OSE est une tâche plutôt non triviale. Dans cet article, à l'aide d'un exemple précis, nous vous expliquerons comment lire les logs Zimbra OSE, ainsi que comment les centraliser.
Zimbra OSE stocke tous les journaux locaux 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 se produisent sur le serveur de messagerie. Ceux-ci incluent la transmission d’e-mails, les données d’authentification des utilisateurs, les tentatives de connexion infructueuses, etc. 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 de thread dans lequel l'événement s'est produit, le nom d'utilisateur et l'adresse IP, ainsi qu'une description textuelle de l'événement. .
Le niveau de journalisation indique le degré d'influence de l'événement sur le fonctionnement du serveur. Par défaut, il existe 4 niveaux d'événements : INFO, WARN, ERROR et FATAL. Examinons tous les niveaux par ordre croissant de gravité.
- INFO - Les événements à ce niveau sont généralement destinés à informer sur les progrès de Zimbra OSE. Les messages à ce niveau incluent des rapports sur la création ou la suppression d'une boîte aux lettres, etc.
- AVERTIR - les événements de ce niveau informent sur des situations potentiellement dangereuses, mais n'affectent pas le fonctionnement du serveur. Par exemple, le niveau WARN marque un message concernant l'échec d'une tentative de connexion d'un utilisateur.
- ERREUR - ce niveau d'événement dans le journal informe de l'apparition d'une erreur de nature locale et n'interfère pas avec le fonctionnement du serveur. Ce niveau peut signaler une erreur dans laquelle les données d'index d'un utilisateur individuel ont été corrompues.
- FATAL - ce niveau indique des erreurs à cause desquelles le serveur ne peut pas continuer à fonctionner normalement. Par exemple, le niveau FATAL concernera un enregistrement indiquant l'impossibilité de se connecter au SGBD.
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 facilite grandement la sauvegarde des journaux d'activité 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 liées à des éléments spécifiques de Zimbra OSE. Par exemple, audit.log contient uniquement des enregistrements 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 un serveur Zimbra OSE contre les intrus est , qui fonctionne uniquement sur la base d'audit.log. C'est également une bonne pratique d'ajouter une tâche cron pour exécuter la commande grep -ir "mot de passe invalide" /opt/zimbra/log/audit.logpour recevoir des informations quotidiennes sur les échecs de connexion.
Un exemple de la façon dont audit.log affiche un mot de passe saisi deux fois de manière incorrecte et une tentative de connexion réussie.
Les journaux dans Zimbra OSE peuvent être extrêmement utiles pour identifier les causes de diverses pannes 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 serveur dès que possible. Cependant, plus tard, lorsque le serveur est sauvegardé et génère de nombreux journaux, il peut être difficile de trouver l'entrée requise dans un fichier volumineux. Afin de retrouver 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 logs datant de cette heure. L'entrée précédente sera un enregistrement de l'erreur survenue. Vous pouvez également trouver le message d'erreur en recherchant le mot-clé FATAL.
Les journaux Zimbra OSE vous permettent également 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 qui explique la cause de l'exception. En cas d'erreurs de livraison 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.
Les journaux peuvent également être utiles lors des enquêtes sur les incidents de sécurité des informations. Regardons un exemple spécifique. Le 20 septembre, l'un des employés a envoyé une lettre infectée par un virus à un client. En conséquence, les données sur l'ordinateur du client ont été cryptées. Or, 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 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 journal nécessaire, extrait les informations nécessaires et les transmet aux spécialistes de la 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 au moment de l'envoi de la lettre. Ces données étaient suffisantes pour l'accuser de violation des règles de sécurité de l'information et le licencier.
Un exemple d'extraction d'enregistrements sur l'un des comptes du journal 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, travailler avec eux dans une infrastructure multi-serveurs est très peu pratique et il est donc nécessaire de centraliser la collecte des journaux. Cela peut être fait en configurant un hôte pour collecter les 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 collecter les journaux. Dans notre cas, il s'agira du nœud Mailstore01.
Sur ce serveur, nous devons entrer les commandes ci-dessous :
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 en utilisant 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 magasins de messagerie), exécutez la commande zmprov gacf |grep zimbraLogHostname pour voir le nom de l'hôte auquel les journaux sont envoyés. Pour le modifier, vous pouvez également saisir la commande zmprov mcf zimbraLogHostname mailstore01.company.ru
Vous devez également saisir 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 journaux seront enregistrés sur le serveur que vous avez spécifié, où ils pourront être facilement consultés. De plus, dans la console d'administrateur Zimbra OSE, sur l'écran contenant des informations sur l'état des serveurs, le service Logger en cours d'exécution sera affiché uniquement pour le serveur mailstore01.
Un autre casse-tête pour un administrateur peut être le suivi d'un e-mail spécifique. Puisque les emails dans Zimbra OSE passent par plusieurs événements différents à la fois : analyse par antivirus, antispam, etc., avant d'être acceptés ou envoyés, pour l'administrateur, si l'email n'arrive pas, il peut être assez problématique de retracer à quelle étape c'était perdu.
Afin de résoudre ce problème, vous pouvez utiliser un script spécial, développé par le spécialiste de la sécurité de l'information Viktor Dukhovny et recommandé aux développeurs de Postfix. Ce script concatène les entrées des journaux pour un processus spécifique et, de ce fait, vous permet d'afficher rapidement toutes les entrées associées à 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 un fichier assembler.pl, rendez-le exécutable, puis exécutez le fichier en spécifiant le fichier journal et en utilisant pgrep pour extraire les informations d'identification de la lettre que vous recherchez collate.pl /var/log/zimbra.log | pgrep'[email protected]>'. 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 '<[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: removedPour toutes les questions relatives à Zextras Suite, vous pouvez contacter le représentant de Zextras Ekaterina Triandafilidi par e-mail [email protected]
Source: habr.com