Il logging di tutti gli eventi in corso è una delle funzioni più importanti di qualsiasi sistema aziendale. I log consentono di affrontare i problemi emergenti, condurre audit delle operazioni dei sistemi informativi e indagare sugli incidenti di sicurezza informatica. Anche Zimbra OSE tiene dettagliati log del proprio funzionamento. In essi si trovano tutte le informazioni, dalle prestazioni del server all'invio e ricezione di email da parte degli utenti. Tuttavia, leggere i log generati da Zimbra OSE può essere un compito piuttosto complesso. In questo articolo, con un esempio concreto, ti spiegheremo come leggere i log di Zimbra OSE e come centralizzarli.
Tutti i log locali di Zimbra OSE sono conservati nella cartella /opt/zimbra/log, mentre i log possono anche essere trovati nel file /var/log/zimbra.log. Il più importante tra di essi è mailbox.log. Esso registra tutte le azioni che avvengono sul server di posta. Tra queste, la trasmissione di email, i dati sull'autenticazione degli utenti, i tentativi di accesso non riusciti e altro ancora. Le registrazioni in mailbox.log sono rappresentate da una stringa di testo che contiene l'orario 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 di log indica il grado di impatto dell'evento sul funzionamento del server. Per impostazione predefinita, sono utilizzati 4 livelli di eventi: INFO, WARN, ERROR e FATAL. Analizziamo tutti i livelli in ordine crescente di gravità.
- INFO — gli eventi a questo livello di solito informano sull'andamento del lavoro di Zimbra OSE. Tra i messaggi di questo livello ci sono i report sulla creazione o cancellazione di una casella di posta e così via.
- WARN — gli eventi a questo livello informano su situazioni che sono potenzialmente pericolose, ma che non incidono sul funzionamento del server. Un messaggio di tentativo di accesso non riuscito da parte di un utente è, ad esempio, contrassegnato con il livello WARN.
- ERROR — questo livello di evento nel log informa di un errore sorto con carattere locale che non impedisce il funzionamento del server. Un livello di questo tipo può essere utilizzato per segnare un errore nel quale i dati indicizzati di un singolo utente si sono danneggiati.
- FATALE — questo livello indica errori che impediscono al server di continuare a funzionare normalmente. Ad esempio, il livello FATALE si avrà in caso di impossibilità di connettersi al DBMS.
Il file di log del server di posta viene aggiornato ogni giorno. La versione più recente del file porta sempre il nome Mailbox.log, mentre i log di date specifiche contengono la data nel titolo e sono archiviati. 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/ ci sono anche altri log. Questi contengono solo le registrazioni relative a specifici elementi di Zimbra OSE. Ad esempio, in audit.log ci sono esclusivamente registrazioni sull'autenticazione degli utenti, in clamd.log informazioni sul funzionamento dell'antivirus e così via. Inoltre, un ottimo metodo di protezione per il server Zimbra OSE contro i malintenzionati è , che funziona proprio sulla base di audit.log. È anche buona prassi aggiungere un compito cron per eseguire il comando grep -ir "invalid password" /opt/zimbra/log/audit.log, per ricevere quotidianamente informazioni sui tentativi di accesso falliti.
Ecco un esempio di come in audit.log venga registrato un tentativo di accesso con una password errata e un accesso riuscito.
I log in Zimbra OSE possono essere estremamente utili per identificare le cause di vari malfunzionamenti critici. Nel momento in cui si verifica un errore critico, di solito l'amministratore non ha tempo di leggere i log. È necessario ripristinare il funzionamento del server il prima possibile. Tuttavia, poi, quando il server è di nuovo operativo e genera molti log, trovare la registrazione desiderata in un grande file può essere complicato. Per trovare rapidamente la registrazione di un errore, è sufficiente conoscere l'orario in cui il server è stato riavviato e cercare nei log la registrazione con data corrispondente a quell’orario. La registrazione precedente sarà quella dell'errore verificatosi. Si può anche trovare il messaggio di errore cercando la parola chiave FATALE.
I log Zimbra OSE permettono anche di identificare guasti non critici. Ad esempio, per trovare le eccezioni dell'handler, è possibile cercare la frase handler exception. Spesso gli errori generati dagli handler sono accompagnati da una traccia dello stack, che spiega le ragioni dell'eccezione. In caso di errori di consegna della posta, è consigliabile iniziare la ricerca con la parola chiave LmtpServer, mentre per cercare errori relativi ai protocolli POP o IMAP è possibile utilizzare le parole chiave ImapServer e Pop3Server.
I log possono anche essere utili per indagare su incidenti di sicurezza informatica. Consideriamo un caso specifico. Il 20 settembre, uno degli impiegati ha inviato un'email infetta a un cliente. Di conseguenza, i dati sul computer del cliente sono stati crittografati. Tuttavia, l'impiegato giura di non aver inviato nulla. Nell'ambito dell'indagine sull'incidente, il servizio di sicurezza dell'azienda richiede all'amministratore di sistema i log del server di posta per il 20 settembre, relativi all'utente sotto indagine. Grazie al timestamp, l'amministratore di sistema trova il file con i log necessari, estrae le informazioni richieste e le consegna agli agenti di 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 l'impiegato si trovava al suo posto di lavoro mentre inviava l'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 quando si tratta di un'infrastruttura multi-server. Poiché i log vengono raccolti localmente, lavorare con essi in un contesto di infrastruttura multi-server è molto scomodo e quindi sorge la necessità di centralizzare la raccolta dei log. Questo può essere fatto configurando un host per la raccolta dei log. Non è necessaria l'aggiunta di un host dedicato nell'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, è necessario inserire i seguenti comandi:
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 decommenta le seguenti righe:
$ModLoad imudp
$UDPServerRun 514
Inserisci 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/zmupdateauthkeysPuoi verificare che tutto funzioni con il comando zmprov gacf | grep zimbraLogHostname. Dopo aver eseguito il comando, dovrebbe essere visualizzato il nome dell'host che raccoglie i log. Per modificarlo, inserisci 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 vanno i log. Per modificarlo, puoi anche inserire il comando zmprov mcf zimbraLogHostname mailstore01.company.ru
Inoltre, su ciascun 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 questo, tutti i log verranno registrati sul server che hai specificato, dove sarà possibile visualizzarli comodamente. Inoltre, nella console dell'amministratore di Zimbra OSE, nella schermata con le informazioni sullo stato dei server, il servizio Logger in esecuzione verrà visualizzato solo per il server mailstore01.
Un'altra preoccupazione per l'amministratore potrebbe essere il monitoraggio di un'email specifica. Poiché le email in Zimbra OSE passano attraverso vari eventi come la scansione antivirus, anti-spam e altro, prima di essere ricevute o inviate, per l'amministratore, nel caso in cui un'email non arrivi, potrebbe essere piuttosto difficile rintracciare a quale stadio sia andata persa.
Per risolvere questo problema, è possibile utilizzare uno script speciale sviluppato dal esperto di sicurezza informatica Viktor Dukhonny e raccomandato per l'uso dai programmatori Postfix. Questo script concatena le voci dai log per un determinato processo e consente così di visualizzare rapidamente tutte le voci relative all'invio di una specifica email sulla base del suo identificatore. La sua funzionalità è stata testata su tutte le versioni di Zimbra OSE a partire dalla 8.7. Di seguito 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, renderlo eseguibile e poi lanciare il file specificando il file di log e utilizzando pgrep per estrarre le informazioni identificative della email ricercata. collate.pl /var/log/zimbra.log | pgrep ‘’. Il risultato sarà un'uscita sequenziale di righe contenenti informazioni sul movimento della 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 riguardante Zextras Suite, puoi contattare il Rappresentante della compagnia "Zextras", Ekaterina Triandafyllidi all'indirizzo email katerina@zextras.com
Fonte: habr.com
