Il logging di tutti gli eventi in corso è una delle funzioni più importanti di qualsiasi sistema aziendale. I log consentono di risolvere problemi, auditare il funzionamento dei sistemi informatici e investigare incidenti di sicurezza informatica. Anche Zimbra OSE mantiene log dettagliati delle proprie attività. Questi includono dati che vanno dalle prestazioni del server all'invio e alla ricezione di e-mail da parte degli utenti. Tuttavia, leggere i log generati da Zimbra OSE è un compito piuttosto complesso. In questo articolo, attraverso un caso pratico, spiegheremo come leggere i log di Zimbra OSE e come centralizzarli.
Tutti i log locali di Zimbra OSE si trovano nella cartella /opt/zimbra/log; i log possono anche essere trovati nel file /var/log/zimbra.log. Il più importante di questi è mailbox.log. In esso vengono registrate tutte le azioni che si svolgono sul server di posta, tra cui la trasmissione di email, i dati sull'autenticazione degli utenti, i tentativi di accesso non riusciti e altro ancora. Le voci in mailbox.log sono una stringa di testo contenente l'ora in cui si è verificato l'evento, il livello dell'evento, il numero del thread in cui si è verificato l'evento, il nome utente e il suo indirizzo IP, oltre a una descrizione testuale dell'evento.
Il livello del log indica il grado di impatto dell'evento sul funzionamento del server. Per impostazione predefinita, vengono utilizzati 4 livelli di eventi: INFO, WARN, ERROR e FATAL. Esaminiamo tutti i livelli in ordine crescente di gravità.
- INFO — gli eventi a questo livello sono generalmente progettati per informare sul funzionamento di Zimbra OSE. Tra i messaggi di questo livello ci sono i report sulla creazione o la cancellazione di una casella di posta e così via.
- WARN — eventi di questo livello informano su situazioni potenzialmente pericolose, ma che non influiscono sul funzionamento del server. Un messaggio di accesso utente fallito, ad esempio, è contrassegnato come WARN.
- ERROR — questo livello di evento nel log informa di un errore che è di natura locale e non impedisce il funzionamento del server. Un errore di questo tipo potrebbe riguardare dati indicizzati di un singolo utente che risultano danneggiati.
- FATAL — questo livello contrassegna errori che impediscono al server di continuare a funzionare normalmente. Ad esempio, un evento FATAL si riferirebbe a una registrazione di impossibilità di collegamento al DBMS.
Il file di log del server di posta viene aggiornato ogni giorno. La versione più recente del file è sempre nominata Mailbox.log, mentre i log per una determinata data hanno la data nel titolo e sono contenuti in un archivio. Ad esempio mailbox.log.2020-09-29.tar.gz. Questo semplifica notevolmente il backup dei registri delle azioni e la ricerca nei log.
Per comodità dell'amministratore di sistema, nella cartella /opt/zimbra/log/ sono presenti anche altri log. Questi includono solo le registrazioni relative a specifici elementi di Zimbra OSE. Ad esempio, in audit.log sono presenti esclusivamente registrazioni di autenticazione degli utenti, in clamd.log i dati sul funzionamento dell'antivirus e così via. A proposito, un ottimo metodo per proteggere il server Zimbra OSE dagli aggressori è , che funziona proprio sulla base di audit.log. È inoltre buona pratica aggiungere un'attività cron per eseguire il comando grep -ir "invalid password" /opt/zimbra/log/audit.log, per ricevere quotidianamente informazioni sui tentativi di accesso non riusciti.
Esempio di come nel log audit.log siano visualizzati due tentativi di accesso con password errata e un tentativo di accesso riuscito
I log di Zimbra OSE possono essere estremamente utili per identificare le cause di vari guasti critici. Nel momento in cui si verifica un errore critico, l'amministratore di solito non ha tempo per leggere i log. È necessario ripristinare il funzionamento del server il prima possibile. Tuttavia, poi, quando il server è nuovamente operativo e genera un numero elevato di log, trovare la voce giusta in un file di grandi dimensioni può essere complicato. Per individuare rapidamente la registrazione di un errore, è sufficiente conoscere l'orario in cui il server è stato riavviato e cercare nei log una voce datata a quell'orario. La registrazione precedente costituirà la voce dell'errore verificatosi. È anche possibile trovare un messaggio di errore utilizzando la ricerca per la parola chiave FATAL.
I log di Zimbra OSE consentono anche di identificare malfunzionamenti non critici. Ad esempio, per trovare le eccezioni del gestore, è possibile cercare la frase handler exception. Spesso, gli errori generati dai gestori sono accompagnati da un traceback che spiega cosa ha causato l'insorgenza dell'eccezione. In caso di errori di consegna delle e-mail, è consigliabile iniziare la ricerca con la parola chiave LmtpServer, mentre per gli errori legati ai protocolli POP o IMAP si possono utilizzare le parole chiave ImapServer e Pop3Server.
I registri possono anche essere utili nell'indagine sugli incidenti di sicurezza informatica. Consideriamo un caso specifico. Il 20 settembre, uno dei dipendenti ha inviato al cliente un'email infettata da virus. Di conseguenza, i dati sul computer del cliente sono stati criptati. Tuttavia, il dipendente giura di non aver inviato nulla. Nell'ambito dell'indagine, il servizio di sicurezza dell'azienda richiede all'amministratore di sistema i log del server di posta del 20 settembre riguardanti l'utente oggetto dell'inchiesta. Grazie al timestamp, l'amministratore di sistema trova il file con i log necessari, estrae le informazioni richieste e le trasmette alla sicurezza. Questi, a loro volta, le esaminano e scoprono che l'indirizzo IP da cui è stata inviata l'email corrisponde indirizzo IP al computer dell'utente. Le registrazioni delle telecamere di sorveglianza hanno confermato che il dipendente era al suo posto di lavoro durante l'invio dell'email. Questi dati sono stati sufficienti per accusarlo di violazione delle norme di sicurezza informatica e licenziarlo.
Esempio di estrazione delle registrazioni di uno degli account dal log Mailbox.log in un file separato
Tutto si complica notevolmente nel momento in cui si parla di un'infrastruttura multi-server. Poiché i log vengono raccolti localmente, lavorare con essi in condizioni di un'infrastruttura multi-server è molto scomodo e quindi sorge la necessità di centralizzare la raccolta dei log. Questo può essere realizzato configurando un host per la raccolta dei log. Non è necessaria l'aggiunta di un host dedicato all'infrastruttura. Qualsiasi server di posta può fungere da nodo per la raccolta dei log. Nel nostro caso, questo sarà il nodo Mailstore01.
Su questo server dobbiamo immettere i comandi seguenti:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vModifica il file /etc/sysconfig/rsyslog e imposta il parametro SYSLOGD_OPTIONS=”-r -c 2″
Modifica /etc/rsyslog.conf e de-commenta le seguenti righe:
$ModLoad imudp
$UDPServerRun 514
Immetti i seguenti comandi:
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/zmupdateauthkeysVerifica che tutto funzioni utilizzando il comando zmprov gacf | grep zimbraLogHostname. Dopo l'esecuzione del comando verrà visualizzato il nome dell'host che raccoglie i log. Per modificarlo, è necessario inserire il comando zmprov mcf zimbraLogHostname mailstore01.company.ru.
Su tutti gli altri server dell'infrastruttura (LDAP, MTA e altri archivi di posta), esegui il comando zmprov gacf | grep zimbraLogHostname per vedere il nome dell'host a cui vengono inviati i log. Per modificarlo, puoi inserire anche il comando zmprov mcf zimbraLogHostname mailstore01.company.ru.
Inoltre, su ogni server è necessario inserire i seguenti comandi:
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 restartDopo di questo, tutti i log verranno registrati sul server da te indicato, dove potranno essere visualizzati facilmente. Inoltre, nella console di amministrazione Zimbra OSE, nella schermata con le informazioni sullo stato dei server, il servizio Logger verrà visualizzato solo sul server mailstore01.
Un'altra preoccupazione per l'amministratore può essere il tracciamento di un'email specifica. Poiché le email in Zimbra OSE attraversano diversi eventi: la verifica antivirus, il filtro antispam e così via, prima di essere accettate o inviate, per un amministratore può essere piuttosto problematico capire a che punto si è persa un'email qualora non arrivasse.
Per risolvere questo problema, è possibile utilizzare uno script speciale sviluppato dal professionista della sicurezza informatica Viktor Dukhonov e raccomandato dagli sviluppatori di Postfix. Questo script concatena le voci dai log per un processo specifico e consente di visualizzare rapidamente tutte le voci relative all'invio di una determinata email basata sul suo identificatore. La sua funzionalità è stata testata su tutte le versioni di Zimbra OSE, a partire dalla 8.7. Ecco il testo dello 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";
}Lo script è scritto in Perl e per eseguirlo è necessario salvarlo in un file collate.pl, rendilo eseguibile e poi esegui il file specificando il file di log e utilizzando pgrep per estrarre le informazioni identificative dell'email ricercata. collate.pl /var/log/zimbra.log | pgrep ‘’. Il risultato sarà un'uscita sequenziale delle righe contenenti informazioni sul movimento dell'email sul server.
# 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: removedPer qualsiasi domanda relativa a Zextras Suite, puoi contattare il rappresentante dell'azienda «Zextras», Ekaterina Triandafili, via email all'indirizzo katerina@zextras.com.
Fonte: habr.com
