La registrazione di tutti gli eventi che si verificano è una delle funzioni più importanti di qualsiasi sistema aziendale. I registri consentono di risolvere problemi emergenti, verificare il funzionamento dei sistemi informativi e anche indagare sugli incidenti legati alla sicurezza delle informazioni. Zimbra OSE conserva inoltre registri dettagliati del suo funzionamento. Includono tutti i dati, 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 non banale. In questo articolo, utilizzando un esempio specifico, ti spiegheremo come leggere i registri di Zimbra OSE e come renderli centralizzati.
Zimbra OSE memorizza tutti i registri locali nella cartella /opt/zimbra/log e i registri possono essere trovati anche nel file /var/log/zimbra.log. Il più importante di questi è mailbox.log. Registra tutte le azioni che si verificano sul server di posta. Questi includono la trasmissione di e-mail, dati di autenticazione dell'utente, tentativi di accesso falliti e altri. Le voci in mailbox.log sono una stringa di testo che contiene 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 l'indirizzo IP, nonché una descrizione testuale dell'evento .
Il livello di registro indica il grado di influenza dell'evento sul funzionamento del server. Per impostazione predefinita sono presenti 4 livelli di eventi: INFO, WARN, ERROR e FATAL. Esaminiamo tutti i livelli in ordine crescente di gravità.
- INFO: gli eventi a questo livello hanno solitamente lo scopo di informare sui progressi di Zimbra OSE. I messaggi a questo livello includono report sulla creazione o l'eliminazione di una casella di posta e così via.
- WARN - gli eventi di questo livello informano su situazioni potenzialmente pericolose, ma non influenzano il funzionamento del server. Ad esempio, il livello WARN contrassegna un messaggio relativo a un tentativo di accesso utente non riuscito.
- ERRORE: questo livello di evento nel registro informa del verificarsi di un errore di natura locale e non interferisce con il funzionamento del server. Questo livello può contrassegnare un errore in cui i dati dell'indice di un singolo utente sono stati danneggiati.
- FATAL: questo livello indica errori a causa dei quali il server non può continuare a funzionare normalmente. Ad esempio, il livello FATAL sarà per un record che indica l'impossibilità di connettersi al DBMS.
Il file di registro del server di posta viene aggiornato ogni giorno. L'ultima versione del file ha sempre il nome Mailbox.log, mentre i log per una certa data hanno una data nel nome e sono contenuti nell'archivio. Ad esempio casella di posta.log.2020-09-29.tar.gz. Ciò semplifica notevolmente il backup dei registri delle attività e la ricerca nei registri.
Per comodità dell'amministratore di sistema, la cartella /opt/zimbra/log/ contiene altri log. Includono solo voci relative a specifici elementi Zimbra OSE. Ad esempio, audit.log contiene solo record sull'autenticazione dell'utente, clamd.log contiene dati sul funzionamento dell'antivirus e così via. A proposito, un ottimo metodo per proteggere il server Zimbra OSE dagli intrusi è , che funziona solo in base a audit.log. È anche una buona pratica aggiungere un'attività cron per eseguire il comando grep -ir "password non valida" /opt/zimbra/log/audit.logper ricevere informazioni giornaliere sugli errori di accesso.
Un esempio di come audit.log mostra una password inserita due volte in modo errato e un tentativo di accesso riuscito.
I log in Zimbra OSE possono essere estremamente utili per identificare le cause di vari errori critici. Nel momento in cui si verifica un errore critico, l'amministratore di solito non ha tempo per leggere i registri. È necessario ripristinare il server il prima possibile. Tuttavia, in seguito, quando il server esegue il backup e genera molti registri, può essere difficile trovare la voce richiesta in un file di grandi dimensioni. Per trovare rapidamente una registrazione di errore è sufficiente conoscere l'ora in cui è stato riavviato il server e trovare nei log una voce risalente a quell'ora. La voce precedente sarà una registrazione dell'errore che si è verificato. Puoi anche trovare il messaggio di errore cercando la parola chiave FATAL.
I registri di Zimbra OSE consentono inoltre di identificare gli errori non critici. Ad esempio, per trovare le eccezioni del gestore, puoi cercare eccezione del gestore. Spesso gli errori generati dai gestori sono accompagnati da un'analisi dello stack che spiega cosa ha causato l'eccezione. In caso di errori con la consegna della posta, dovresti iniziare la ricerca con la parola chiave LmtpServer, mentre per cercare errori relativi ai protocolli POP o IMAP puoi utilizzare le parole chiave ImapServer e Pop3Server.
I registri possono anche essere utili durante le indagini sugli incidenti legati alla sicurezza delle informazioni. Diamo un'occhiata a un esempio specifico. Il 20 settembre uno dei dipendenti ha inviato una lettera infetta da virus 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 aziendale richiede all'amministratore di sistema i log del server di posta relativi alla data del 20 settembre associati all'utente indagato. Grazie alla marcatura temporale, l'amministratore di sistema trova il file di registro necessario, estrae le informazioni necessarie e le trasmette agli specialisti della sicurezza. Questi, a loro volta, lo esaminano e scoprono che l'indirizzo IP da cui è stata inviata questa lettera corrisponde all'indirizzo IP del computer dell'utente. Le riprese delle telecamere a circuito chiuso hanno confermato che il dipendente si trovava sul posto di lavoro al momento dell'invio della lettera. Questi dati sono bastati per accusarlo di violazione delle norme sulla sicurezza informatica e licenziarlo.
Un esempio di estrazione dei record relativi a uno degli account dal registro Mailbox.log in un file separato
Tutto diventa molto più complicato quando si parla di infrastrutture multiserver. Poiché i log vengono raccolti localmente, lavorare con essi in un'infrastruttura multi-server è molto scomodo e quindi è necessario centralizzare la raccolta dei log. Questo può essere fatto configurando un host per raccogliere i log. Non è necessario aggiungere 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 inserire i comandi seguenti:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vModifica il file /etc/sysconfig/rsyslog e imposta SYSLOGD_OPTIONS="-r -c 2″
Modifica /etc/rsyslog.conf e decommenta le seguenti righe:
$ModLoad imudp
$UDPServerEsegui 514
Immettere 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 utilizzando il comando zmprov gacf | grep zimbraLogHostname. Dopo aver eseguito il comando, dovrebbe essere 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 anche inserire il comando zmprov mcf zimbraLogHostname mailstore01.company.ru
È inoltre necessario immettere i seguenti comandi su ciascun server:
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 restartSuccessivamente, tutti i registri verranno registrati sul server specificato, dove potranno essere comodamente visualizzati. Inoltre, nella console di amministrazione 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 altro grattacapo per un amministratore può essere tenere traccia di un'e-mail specifica. Poiché le e-mail in Zimbra OSE attraversano diversi eventi contemporaneamente: scansione da parte di antivirus, antispam e così via, prima di essere accettate o inviate, per l'amministratore, se l'e-mail non arriva, può essere piuttosto problematico risalire a quale fase era perduto.
Per risolvere questo problema, è possibile utilizzare uno script speciale, sviluppato dallo specialista della sicurezza informatica Viktor Dukhovny e consigliato per l'uso dagli sviluppatori di Postfix. Questo script concatena le voci dei registri per un processo specifico e, per questo motivo, consente di visualizzare rapidamente tutte le voci associate all'invio di una particolare lettera in base al suo identificatore. Il suo funzionamento è stato testato su tutte le versioni di Zimbra OSE, a partire dalla 8.7. Ecco il testo della sceneggiatura.
#! /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 su un file collate.pl, rendilo eseguibile, quindi esegui il file specificando il file di log e utilizzando pgrep per estrarre le informazioni identificative della lettera che stai cercando collate.pl /var/log/zimbra.log | pgrep '[email protected]>'. Il risultato sarà un output sequenziale di righe contenenti informazioni sul movimento della lettera sul server.
# 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: removedPer tutte le domande relative a Zextras Suite, è possibile contattare il rappresentante di Zextras Ekaterina Triandafilidi via e-mail [email protected]
Fonte: habr.com