Como limpar os registros de auditoria do Zimbra para liberar espaço em disco com segurança

Comece por decidir o que realmente precisa remover.

Um servidor Zimbra com pouco espaço em disco pode tornar a limpeza de logs urgente, mas /opt/zimbra/log/audit.lognão se trata apenas de um registro de diagnóstico descartável. O Zimbra os documenta como trilha de auditoria para eventos de autenticação e atividades administrativas. Isso significa que o melhor método de limpeza depende da necessidade de espaço imediato, de evidências históricas ou de uma solução de retenção a longo prazo.

A opção mais segura é deixar o audit.logarquivo ativo intacto e lidar primeiro com as cópias rotacionadas mais antigas. Se você estiver sujeito a uma política interna de retenção, restrição legal ou requisito de conformidade, arquive esses arquivos em outro sistema de arquivos antes de excluir qualquer coisa. Se o próprio arquivo ativo se tornou anormalmente grande, você pode apagá-lo, mas isso deve ser tratado como uma medida de emergência, pois remove o histórico de auditoria atual e pode introduzir uma pequena condição de corrida se o servidor continuar gravando enquanto você copia o arquivo.

A própria documentação de registro do Zimbra coloca o Log4j audit.logem um diretório /opt/zimbra/loge o descreve como o componente responsável pela rotação de arquivos como ` audit.log.zimbra.log` e `.zimbra.log` mailbox.log. Outros logs do Zimbra podem usar a logrotateconfiguração do sistema operacional, portanto, não assuma que todos os arquivos no diretório `.zimbra.log` seguem o mesmo mecanismo. Consulte a referência oficial de arquivos de log do Zimbra e as notas sobre rotação de logs do Zimbra .

Compare as opções de limpeza antes de agir.

Passo 1: Avalie o problema antes de excluir qualquer coisa.

Primeiro, confirme se os registros de auditoria são realmente os responsáveis ​​pela pressão. Execute os seguintes comandos root:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

O primeiro comando informa o quão cheio /optestá o sistema de arquivos. O segundo mostra o espaço ocupado pelos logs do Zimbra. O terceiro expõe o arquivo de auditoria ativo e quaisquer gerações rotacionadas. Se os arquivos de auditoria representarem apenas uma pequena fração do sistema de arquivos, limpá-los pode não resolver o problema real; arquivos de caixa de correio, backups, bancos de dados ou outras famílias de logs podem estar consumindo espaço.

Anote também a versão instalada antes de alterar o comportamento:

su - zimbra -c 'zmcontrol -v'

Isso é importante porque a documentação do Zimbra abrange várias gerações de produtos, e a sintaxe exata do Log4j, a configuração gerada e as tarefas de limpeza podem variar. Não copie um valor de retenção de um exemplo antigo da wiki e assuma que ele é o seu padrão atual.

Antes de decidir o que remover, verifique o uso do sistema de arquivos, o tamanho total do log do Zimbra e as gerações individuais do log de auditoria.

Passo 2: Verifique como este servidor rotaciona e remove logs.

A documentação do Zimbra apresenta dois mecanismos relevantes: o Log4j para arquivos, incluindo o `.zimbra.log` audit.log, e o `.zimbra.log` do sistema operacional logrotatepara diversos outros logs do Zimbra. A documentação também observa que o próprio crontab do Zimbra pode conter tarefas de manutenção de logs. Em vez de tentar adivinhar, revise a configuração em produção.

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

Se um desses arquivos não contiver a configuração esperada na sua versão, inspecione a configuração de registro (log) correspondente em vez de forçar a utilização de um exemplo antigo. Os arquivos gerados também podem ser sobrescritos após a reinicialização do serviço ou a regeneração da configuração. As notas de registro do Zimbra distinguem especificamente as edições temporárias no arquivo de propriedades gerado das alterações permanentes feitas no .inmodelo correspondente.

Para servidores com um volume de auditoria inesperadamente alto, verifique se o registro adicional foi ativado intencionalmente. As notas de versão do Zimbra 10.0.6 documentam o zimbra_additional_loggingatributo de configuração local, que pode adicionar mais eventos de autenticação com falha ou outros eventos úteis ao audit.logregistro de logs. Não desative o registro de segurança útil apenas para economizar espaço; se o volume for legítimo, uma solução melhor geralmente é a retenção, a compressão ou o armazenamento centralizado de logs. Consulte as notas de versão oficiais do Zimbra 10.0.6 .

Antes de alterar o comportamento de retenção ou rotação, revise o crontab e a configuração do Log4j do servidor.

Etapa 3: Prefira arquivar ou excluir primeiro os registros rotacionados.

Para a maioria dos administradores, os logs de auditoria rotacionados mais antigos são o melhor alvo inicial. Use find-os no modo somente relatório antes de excluir qualquer item. O exemplo a seguir lista os logs de auditoria rotacionados com mais de 30 dias; 30 dias é apenas um limite de exemplo, não um período de retenção prescrito pelo Zimbra:

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

Se esses arquivos não forem mais necessários, exclua apenas os arquivos rotacionados que foram revisados. Se precisar mantê-los, copie-os ou arquive-os em um sistema de arquivos diferente primeiro. Usar outro ponto de montagem é importante quando a partição do Zimbra já está quase cheia, porque criar um arquivo compactado no mesmo sistema de arquivos cheio pode consumir ainda mais espaço temporariamente.

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

Repita o processo para os mesmos nomes de arquivo que você revisou. Verifique o backup antes de remover a origem. Evite padrões genéricos, como rm -f /opt/zimbra/log/audit.log*"; esse padrão também corresponde ao arquivo ativo".

Se você deseja manter registros antigos localmente, mas reduzir o espaço ocupado por eles, comprima apenas os arquivos rotacionados:

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

A utilidade da compressão depende da sua configuração atual de rotação de logs. Algumas implementações já comprimem logs históricos como parte da manutenção. Verifique o que já existe antes de adicionar outra camada de compressão.

As diretrizes de registro histórico do Zimbra também alertam que os registros de auditoria podem conter dados confidenciais. Trate os arquivos com os mesmos controles de acesso que os registros ativos. Consulte as diretrizes oficiais de registro do Zimbra .

Liste primeiro os arquivos antigos rotacionados, copie o histórico necessário para um armazenamento separado e só então remova as gerações revisadas.

Quando o truncamento do arquivo audit.log ativo é justificado

Se arquivos rotacionados não forem o problema e o audit.logpróprio processo ativo estiver consumindo espaço crítico, o truncamento pode liberar espaço imediatamente. É também a opção com a compensação mais clara: o histórico de auditoria atual é destruído assim que o arquivo é truncado.

Um procedimento de emergência mais seguro é interromper brevemente o mailboxd, copiar o arquivo ativo para outro sistema de arquivos, truncar o original no local para que a propriedade e as permissões sejam preservadas e iniciar o mailboxd novamente:

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

Isso introduz tempo de inatividade no serviço de caixa de correio, portanto, não é a escolha certa para todos os ambientes. Copiar o arquivo ativo sem interromper o mailboxd evita o tempo de inatividade, mas cria uma condição de corrida na qual as entradas gravadas após a cópia e antes do truncamento podem ser perdidas. Se a pressão no disco não for severa, a limpeza dos arquivos rotacionados e a correção da retenção são preferíveis.

Não utilize rmo log ativo como primeira resposta. Um processo pode continuar escrevendo em um descritor de arquivo aberto mesmo após a entrada do diretório ser excluída, portanto, o espaço em disco esperado pode não ser recuperado imediatamente. Truncar o inode existente é mais previsível quando uma limpeza de emergência é realmente necessária.

Etapa 4: Verifique a recuperação do disco e o registro contínuo.

Após a limpeza, confirme o resultado em vez de confiar na ausência de erros:

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

Um bom resultado apresenta três sinais: aumento do espaço livre no sistema de arquivos em questão, audit.loga existência de novos eventos e a continuidade da execução dos serviços relevantes do Zimbra. Se dfo sistema de arquivos ainda estiver cheio, mesmo após duuma queda acentuada no espaço disponível, verifique se há arquivos excluídos que ainda estejam abertos devido a processos em execução antes de excluir mais dados.

Verificar o espaço recuperado, a atividade de auditoria recente e a integridade do serviço após a limpeza.

Escolha a solução a longo prazo com base no motivo pelo qual os registros aumentaram.

Se o crescimento for normal, mas a retenção for muito longa

Ajuste o processo de retenção ou poda somente após documentar o período de histórico necessário. Inspecione a configuração existente do crontab do Zimbra e do Log4j e, em seguida, faça a menor alteração apropriada para a versão. Mantenha uma cópia da configuração original e teste se a próxima rotação realmente cria os arquivos esperados.

Se o ruído de autenticação estiver controlando o volume

Investigue a origem dos dados em vez de simplesmente excluí-los mais rapidamente. Tentativas repetidas de login, clientes mal configurados, sondagens de monitoramento ou registros de autenticação intencionalmente expandidos podem aumentar o volume de auditoria. Como isso audit.logé útil para investigações de segurança, reduzir o ruído subjacente geralmente é melhor do que suprimir as evidências.

Caso seja necessário manter meses de histórico de auditoria

Mova ou envie os logs para um armazenamento projetado para retenção. O registro centralizado, o armazenamento de objetos ou um sistema de arquivos de log dedicado separam o histórico de conformidade da capacidade exigida pela plataforma de e-mail. A documentação de arquivos de log do Zimbra discute explicitamente as opções de registro centralizado, incluindo audit.log...

O que não fazer

• Não exclua audit.log*usando um caractere curinga não revisado.
• Não assuma que o Zimbra /etc/logrotate.d/zimbracontrola o log de auditoria ativo em todas as versões; a documentação do Zimbra sobre o Log4j é utilizada como mecanismo de rotação para esse fim audit.log.
• Não compacte ou arquive arquivos no mesmo sistema de arquivos quase cheio, a menos que tenha confirmado que há espaço temporário suficiente.
• Não reduza o período de retenção sem verificar os requisitos organizacionais, legais ou de segurança.
• Não edite permanentemente os arquivos Log4j gerados sem antes verificar se o Zimbra os regenerará a partir de um modelo.

Verificação final

Se os logs antigos rotacionados fossem os principais consumidores de espaço, o resultado desejado seria simples: o log de auditoria ativo permaneceria intacto, os arquivos históricos seriam arquivados ou removidos de acordo com a política aplicada e o sistema de arquivos recuperaria espaço suficiente para operar normalmente. Se o espaço começar a desaparecer imediatamente, pare de considerar a limpeza como a solução e investigue a taxa de gravação, a atividade de autenticação, a configuração de rotação e quaisquer configurações adicionais de registro. Essa distinção — limpeza pontual versus crescimento recorrente — é o que determina se você realmente resolveu o problema.