A gravação de todos os eventos que ocorrem é uma das funções mais importantes de qualquer sistema corporativo. Os logs permitem resolver problemas, auditar o funcionamento dos sistemas de informação e investigar incidentes de segurança da informação. O Zimbra OSE também mantém logs detalhados de seu funcionamento. Eles incluem todos os dados, desde o desempenho do servidor até o envio e recebimento de emails pelos usuários. No entanto, a leitura dos logs gerados pelo Zimbra OSE é uma tarefa bastante complexa. Neste artigo, vamos mostrar um exemplo específico de como ler os logs do Zimbra OSE e como centralizá-los.
Todos os logs locais do Zimbra OSE são armazenados na pasta /opt/zimbra/log, e os logs também podem ser encontrados no arquivo /var/log/zimbra.log. O mais importante deles é o mailbox.log, que registra todas as ações que ocorrem no servidor de e-mail. Entre elas, a transmissão de emails, dados sobre a autenticação dos usuários, tentativas de login malsucedidas e outros. As entradas no mailbox.log consistem em uma linha 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 seu endereço IP, além de uma descrição textual do evento.
O nível do log indica o grau de impacto do evento no funcionamento do servidor. Por padrão, são usados 4 níveis de eventos: INFO, WARN, ERROR e FATAL. Vamos analisar todos os níveis em ordem crescente de gravidade.
- INFO — os eventos neste nível geralmente servem para informar sobre o andamento do Zimbra OSE. Entre as mensagens deste nível estão os relatórios sobre a criação ou exclusão de uma caixa de correio, e assim por diante.
- WARN — os eventos deste nível informam sobre situações que são potencialmente perigosas, mas que não afetam o funcionamento do servidor. O nível WARN, por exemplo, é usado para marcar mensagens sobre tentativas de login malsucedidas de usuários.
- ERROR — esse nível de evento no log informa sobre a ocorrência de um erro que é local e não impede o funcionamento do servidor. Um erro que pode ser marcado com esse nível é o em que os dados índice de um usuário específico foram corrompidos.
- FATAL — esse nível marca erros que impedem que o servidor continue a funcionar normalmente. Por exemplo, o nível FATAL estará presente em um registro sobre a impossibilidade de conectar-se ao SGBD.
O arquivo de logs do servidor de e-mail é atualizado diariamente. A versão mais recente do arquivo tem sempre o nome Mailbox.log, enquanto os logs de um período específico têm a data no nome e estão contidos em um arquivo compactado. Por exemplo, mailbox.log.2020-09-29.tar.gz. Isso simplifica significativamente a criação de backups dos logs de ações e a busca nos logs.
Para conveniência do administrador de sistemas, a pasta /opt/zimbra/log/ contém outros logs. Eles incluem apenas os registros que se referem a elementos específicos do Zimbra OSE. Por exemplo, no audit.log estão exclusivamente os registros de autenticação de usuários, no clamd.log as informações sobre o funcionamento do antivírus e assim por diante. A propósito, um excelente método de proteção do servidor Zimbra OSE contra invasores é , que funciona com base no audit.log. Além disso, é uma boa prática adicionar uma tarefa cron para executar o comando grep -ir "invalid password" /opt/zimbra/log/audit.log, para receber diariamente informações sobre tentativas de login mal-sucedidas.
Exemplo de como no log audit.log aparecem duas tentativas de senha incorreta e uma tentativa de login bem-sucedida.
Os logs no Zimbra OSE podem ser extremamente úteis para descobrir as 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 a operação do servidor o mais rápido possível. Contudo, depois, quando o servidor está funcionando novamente e gerando muitos logs, encontrar o registro necessário em um grande arquivo pode ser complicado. Para localizar rapidamente o registro sobre o erro, basta saber o horário em que o servidor foi reiniciado e procurar nos logs a entrada datada nesse horário. O registro anterior será a entrada sobre o erro ocorrido. Também é possível encontrar mensagens de erro usando a busca pela palavra-chave FATAL.
Os logs do Zimbra OSE também permitem identificar falhas não críticas. Por exemplo, para encontrar exceções do manipulador, pode-se realizar uma busca pela frase handler exception. Frequentemente, os erros gerados pelos manipuladores vêm acompanhados de rastreamentos de pilha, que explicam a causa da exceção. No caso de erros relacionados à entrega de e-mails, é aconselhável começar a busca pela palavra-chave LmtpServer, enquanto para procurar erros relacionados aos protocolos POP ou IMAP, pode-se usar as palavras-chave ImapServer e Pop3Server.
Os logs também podem ajudar na investigação de incidentes de segurança da informação. Vamos considerar um exemplo específico. Em 20 de setembro, um dos funcionários enviou um e-mail infectado por vírus a um cliente. Como resultado, os dados no computador do cliente foram criptografados. No entanto, o funcionário jura que não enviou nada. No curso da investigação do incidente, o serviço de segurança da empresa solicita ao administrador de sistemas os logs do servidor de e-mail de 20 de setembro, relacionados ao usuário em investigação. Graças ao carimbo de data/hora, o administrador de sistemas encontra o arquivo com os logs, extrai as informações necessárias e as entrega à equipe de segurança. Esta, por sua vez, revisa os dados e descobre que o endereço IP de onde o e-mail foi enviado corresponde endereço IP ao computador do usuário. As gravações das câmeras de vigilância confirmaram que o funcionário estava em seu local de trabalho no momento do envio do e-mail. Essas informações foram suficientes para acusá-lo de violar as normas de segurança da informação e demiti-lo.
Exemplo de extração de registros de uma das contas do log Mailbox.log para um arquivo separado
Tudo se complica significativamente no momento em que se trata de uma infraestrutura de múltiplos servidores. Como os logs são coletados localmente, trabalhar com eles em uma infraestrutura de múltiplos servidores é bastante inconveniente, o que traz a necessidade de centralizar a coleta dos logs. Isso pode ser feito configurando um host para coleta de logs. Não há necessidade especial de adicionar um host dedicado à infraestrutura. Qualquer servidor de e-mail pode ser usado como um nó para coleta de logs. No nosso caso, esse será o nó Mailstore01.
Nesse servidor, precisamos inserir os comandos listados abaixo:
sudo su – zimbra
zmcontrol parar
sair
sudo /opt/zimbra/libexec/zmfixperms -e -vEdite o arquivo /etc/sysconfig/rsyslog e configure o parâmetro SYSLOGD_OPTIONS=”-r -c 2″
Edite /etc/rsyslog.conf e descomente as seguintes linhas:
$ModLoad imudp
$UDPServerRun 514
Digite os seguintes comandos:
sudo /etc/init.d/rsyslog parar
sudo /etc/init.d/rsyslog iniciar
sudo su – zimbra
zmcontrol iniciar
sair
sudo /opt/zimbra/libexec/zmloggerinit
sudo /opt/zimbra/bin/zmsshkeygen
sudo /opt/zimbra/bin/zmupdateauthkeysVerifique se tudo está funcionando com o comando zmprov gacf | grep zimbraLogHostname. Após a execução, o nome do host que coleta os logs deve ser exibido. Para alterá-lo, insira o comando zmprov mcf zimbraLogHostname mailstore01.company.ru.
Em todos os outros servidores da infraestrutura (LDAP, MTA e outros repositórios de emails), execute o comando zmprov gacf |grep zimbraLogHostname para ver o nome do host para onde os logs estão sendo enviados. Para alterá-lo, insira também o comando zmprov mcf zimbraLogHostname mailstore01.company.ru.
Além disso, em cada servidor, é necessário inserir os seguintes comandos:
sudo su - zimbra
/opt/zimbra/bin/zmsshkeygen
/opt/zimbra/bin/zmupdateauthkeys
sair
sudo /opt/zimbra/libexec/zmsyslogsetup
sudo serviço rsyslog reiniciar
sudo su - zimbra
zmcontrol reiniciarDepois disso, todos os logs serão gravados no servidor que você especificou, onde poderão ser visualizados de forma conveniente. Além disso, no console do administrador do Zimbra OSE, na tela com informações sobre o estado dos servidores, o serviço Logger será exibido apenas no servidor mailstore01.
Outra dor de cabeça para o administrador pode ser o rastreamento de um determinado e-mail. Como os e-mails no Zimbra OSE passam por vários eventos, como verificação de vírus, antispam, etc., antes de serem aceitos ou enviados, pode ser bastante problemático para o administrador acompanhar em que etapa um e-mail foi perdido.
Para resolver este problema, pode-se utilizar um script especial desenvolvido pelo especialista em segurança da informação Viktor Dukhoyny e recomendado para uso pelos desenvolvedores do Postfix. Este script concatena registros de logs de um determinado processo e, assim, permite exibir rapidamente todos os registros relacionados ao envio de um determinado e-mail com base em seu identificador. Seu funcionamento foi testado em todas as versões do Zimbra OSE, a partir da 8.7. Apresentamos 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, é necessário salvá-lo em um arquivo collate.pl, torná-lo executável e, em seguida, executar o arquivo indicando o arquivo de logs e, com o auxílio do pgrep, obter a informação de identificação do e-mail desejado. collate.pl /var/log/zimbra.log | pgrep ‘’. O resultado será uma saída sequencial de linhas que contêm informações sobre o tráfego do e-mail no servidor.
# 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: removedPara qualquer questão relacionada ao Zextras Suite, você pode entrar em contato com a representante da empresa «Zextras», Ekaterina Triandafiliadi, pelo e-mail katerina@zextras.com
Fonte: habr.com
