O registro de todos os eventos ocorridos é uma das funções mais importantes de qualquer sistema corporativo. Os logs permitem resolver problemas emergentes, auditar o funcionamento dos sistemas de informação e também investigar incidentes de segurança da informação. O Zimbra OSE também mantém registros detalhados de sua operação. Eles incluem todos os dados, desde o desempenho do servidor até o envio e recebimento de e-mails pelos usuários. No entanto, ler os logs gerados pelo Zimbra OSE não é uma tarefa trivial. Neste artigo, usando um exemplo específico, mostraremos como ler os logs do Zimbra OSE, bem como centralizá-los.
O Zimbra OSE armazena todos os logs locais na pasta /opt/zimbra/log, e os logs também podem ser encontrados no arquivo /var/log/zimbra.log. O mais importante deles é mailbox.log. Ele registra todas as ações que ocorrem no servidor de email. Isso inclui a transmissão de e-mails, dados de autenticação do usuário, tentativas de login malsucedidas e outros. As entradas em mailbox.log são uma sequência de texto que contém a hora em que o evento ocorreu, o nível do evento, o número do thread em que o evento ocorreu, o nome do usuário e o endereço IP, bem como uma descrição de texto do evento .
O nível de log indica o grau de influência do evento na operação do servidor. Por padrão existem 4 níveis de evento: INFO, WARN, ERROR e FATAL. Vejamos todos os níveis em ordem crescente de gravidade.
- INFO - Eventos neste nível geralmente têm como objetivo informar sobre o progresso do Zimbra OSE. As mensagens neste nível incluem relatórios sobre a criação ou exclusão de uma caixa de correio e assim por diante.
- AVISO - eventos deste nível informam sobre situações potencialmente perigosas, mas não afetam o funcionamento do servidor. Por exemplo, o nível WARN marca uma mensagem sobre uma tentativa malsucedida de login do usuário.
- ERRO - este nível de evento no log informa sobre a ocorrência de um erro de natureza local e não interfere no funcionamento do servidor. Este nível pode sinalizar um erro no qual os dados do índice de um usuário individual foram corrompidos.
- FATAL - este nível indica erros devido aos quais o servidor não consegue continuar a operar normalmente. Por exemplo, o nível FATAL será para um registro que indica a incapacidade de conexão ao SGBD.
O arquivo de log do servidor de e-mail é atualizado todos os dias. A versão mais recente do arquivo sempre tem o nome Mailbox.log, enquanto os logs de uma determinada data têm uma data no nome e estão contidos no arquivo. Por exemplo mailbox.log.2020-09-29.tar.gz. Isso torna muito mais fácil fazer backup de logs de atividades e pesquisar logs.
Para conveniência do administrador do sistema, a pasta /opt/zimbra/log/ contém outros logs. Eles incluem apenas entradas relacionadas a elementos específicos do Zimbra OSE. Por exemplo, audit.log contém apenas registros sobre autenticação do usuário, clamd.log contém dados sobre a operação do antivírus e assim por diante. A propósito, um excelente método para proteger um servidor Zimbra OSE contra intrusos é , que funciona apenas com base em audit.log. Também é uma boa prática adicionar uma tarefa cron para executar o comando grep -ir “senha inválida” /opt/zimbra/log/audit.logpara receber informações diárias sobre falhas de login.
Um exemplo de como audit.log mostra uma senha digitada incorretamente duas vezes e uma tentativa de login bem-sucedida.
Os logs no Zimbra OSE podem ser extremamente úteis na identificação das causas de várias falhas críticas. No momento em que ocorre um erro crítico, o administrador geralmente não tem tempo para ler os logs. É necessário restaurar o servidor o mais rápido possível. No entanto, posteriormente, quando o servidor estiver em backup e gerando muitos logs, pode ser difícil encontrar a entrada necessária em um arquivo grande. Para encontrar rapidamente um registro de erro, basta saber a hora em que o servidor foi reiniciado e encontrar nos logs uma entrada que data dessa hora. A entrada anterior será um registro do erro ocorrido. Você também pode encontrar a mensagem de erro pesquisando a palavra-chave FATAL.
Os logs do Zimbra OSE também permitem identificar falhas não críticas. Por exemplo, para localizar exceções do manipulador, você pode procurar por exceção do manipulador. Freqüentemente, os erros gerados pelos manipuladores são acompanhados por um rastreamento de pilha que explica o que causou a exceção. Em caso de erros na entrega de correio, você deve iniciar sua pesquisa com a palavra-chave LmtpServer, e para pesquisar erros relacionados aos protocolos POP ou IMAP, você pode usar as palavras-chave ImapServer e Pop3Server.
Os logs também podem ajudar na investigação de incidentes de segurança da informação. Vejamos um exemplo específico. No dia 20 de setembro, um dos funcionários enviou uma carta infectada pelo vírus a um cliente. Como resultado, os dados no computador do cliente foram criptografados. Porém, o funcionário jura que não enviou nada. Como parte da investigação do incidente, o serviço de segurança empresarial solicita ao administrador do sistema os logs do servidor de e-mail de 20 de setembro associados ao usuário que está sendo investigado. Graças ao carimbo de data/hora, o administrador do sistema encontra o arquivo de log necessário, extrai as informações necessárias e as transfere para especialistas em segurança. Estes, por sua vez, examinam-no e descobrem que o endereço IP de onde esta carta foi enviada corresponde ao endereço IP do computador do usuário. Imagens de CCTV confirmaram que o funcionário estava em seu local de trabalho quando a carta foi enviada. Esses dados foram suficientes para acusá-lo de violar regras de segurança da informação e demiti-lo.
Um exemplo de extração de registros sobre uma das contas do log Mailbox.log em um arquivo separado
Tudo fica muito mais complicado quando se trata de infraestrutura multiservidor. Como os logs são coletados localmente, trabalhar com eles em uma infraestrutura multiservidor é muito inconveniente e, portanto, há necessidade de centralizar a coleta de logs. Isso pode ser feito configurando um host para coletar logs. Não há necessidade específica de adicionar um host dedicado à infraestrutura. Qualquer servidor de e-mail pode atuar como um nó para coletar logs. No nosso caso, este será o nó Mailstore01.
Neste servidor, precisamos inserir os comandos abaixo:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vEdite o arquivo /etc/sysconfig/rsyslog e defina SYSLOGD_OPTIONS=”-r -c 2″
Edite /etc/rsyslog.conf e remova o comentário das seguintes linhas:
$ModLoad imudp
$UDPServerRun 514
Digite os seguintes comandos:
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/zmupdateauthkeysVocê pode verificar se tudo está funcionando usando o comando zmprov gacf | grep zimbraLogHostname. Após executar o comando, deverá ser exibido o nome do host que coleta os logs. Para alterá-lo, você deve inserir o comando zmprov mcf zimbraLogHostname mailstore01.company.ru.
Em todos os outros servidores de infraestrutura (LDAP, MTA e outros armazenamentos de correio), execute o comando zmprov gacf |grep zimbraLogHostname para ver o nome do host para o qual os logs são enviados. Para alterá-lo, você também pode inserir o comando zmprov mcf zimbraLogHostname mailstore01.company.ru
Você também deve inserir os seguintes comandos em cada servidor:
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 restartDepois disso, todos os logs serão gravados no servidor que você especificou, onde poderão ser visualizados convenientemente. Além disso, no console do administrador do Zimbra OSE, na tela com informações sobre o status dos servidores, o serviço Logger em execução será exibido apenas para o servidor mailstore01.
Outra dor de cabeça para um administrador pode ser acompanhar um e-mail específico. Como os e-mails no Zimbra OSE passam por vários eventos diferentes ao mesmo tempo: verificação por antivírus, antispam e assim por diante, antes de serem aceitos ou enviados, para o administrador, se o e-mail não chegar, pode ser bastante problemático rastrear em que estágio foi perdido.
Para resolver esse problema, você pode usar um script especial, desenvolvido pelo especialista em segurança da informação Viktor Dukhovny e recomendado para uso pelos desenvolvedores do Postfix. Este script concatena entradas de logs para um processo específico e, por isso, permite exibir rapidamente todas as entradas associadas ao envio de uma determinada carta com base em seu identificador. Seu funcionamento foi testado em todas as versões do Zimbra OSE, a partir de 8.7. Aqui está o texto do 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";
}O script é escrito em Perl e para executá-lo você precisa salvá-lo em um arquivo collate.pl, torne-o executável e execute o arquivo especificando o arquivo de log e usando pgrep para extrair as informações de identificação da carta que você está procurando collate.pl /var/log/zimbra.log | pgrep'[email protegido]> '. O resultado será uma saída sequencial de linhas contendo informações sobre a movimentação da carta no servidor.
# 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: removedPara todas as perguntas relacionadas ao Zextras Suite, você pode entrar em contato com o representante da Zextras Ekaterina Triandafilidi por e-mail [email protegido]
Fonte: habr.com