Auditoria e Rotacionamento de logs em Servidores de Arquivos Linux

AGRADEÇA AO AUTOR COMPARTILHE!

Este artigo tem por objetivo mostrar a utilização de mecanismos importantes para auditoria e rotacionamento de logs.

Em relação a auditoria, este artigo permitirá aumentar o nível de detalhes registrados para posterior auditoria em um servidor de arquivos utilizando Samba e Red Hat Enterprise Linux 5 (versões posteriores e distribuições diferentes poderão ser utilizadas com poucas adaptações).

A auditoria com excelente nível de detalhes pode ser realizada através do módulo full_audit do Samba, módulo esse que pode ser facilmente carregado devido a arquitetura de sistemas de arquivos virtuais do samba conhecida como VFS (Virtual File System).

Existem outros módulos que permitem aumentar as funcionalidades do Samba como, por exemplo, Lixeira e Antivírus, sendo que atualmente trabalho com as soluções da Kaspersky Labs, e a solução para File Servers (por exemplo) instala um módulo VFS para permitir o scanning de arquivos em compartilhamentos disponibilizados pelo Samba.

Para verificar os módulos disponíveis/instalados no sistema, basta verificar os arquivos (.so) existentes no diretório /usr/lib64/samba/vfs.

No arquivo smb.conf localizado em (/etc/samba) poderíamos criar a seguinte configuração:

As linhas com fonte formatadas em negrito referem-se as entradas necessárias para que o compartilhamento “public” permita a auditoria das opções especificadas acima, operações (full_audit:success) respectivamente para arquivos/diretórios como: abertura de arquivo, abertura de diretório, escrita, exclusão, renomear arquivos/diretórios, criar diretórios e excluir diretórios.

Vale salientar que estas operacões serão registradas somente se as mesmas tiverem status de execução “êxito”, devido o parâmetro success. Entretanto, dependendo do que se desejar auditar, é possível auditar estas e outras operações que não tiveram êxito na execução, por exemplo, alguma ACL de sistema de arquivos impedindo a exclusão do arquivo.

A diretiva prefix é importante para que os dados registrados no log contenham informações que o administrador considera relevantes para a auditoria. No caso acima, poderíamos ter a seguinte entrada no arquivo de log:

No exemplo acima, as informações em negrito indicam o usuário (%u) que realizou a operação, o endereço IP (%I) do usuário e o compartilhamento acesso (%S).

O prefixo será inserido sempre antes dos dados que indicam a operação realizada (opendir), o status da operacão (ok) e o objeto que sofreu a ação (arquivo/diretório – Datafiles/0001/bkp/dataFile0001a.dat)

Na diretiva full_audit:failure: none estamos indicando que não será registrada nenhuma operação (none) que tenha obtido como status de execução alguma falha.

As duas últimas linhas são muito importantes e permitem que os registros de log sejam direcionados ao sistema de logs utilizado no momento, neste caso, SYSLOG.

A penúltima linha (full_audit:facility = LOCAL1) indica que iremos rotular as mensagens de log do Samba (especificamente do módulo VFS full_audit) para que sejam consideradas mensagens que são originadas do recurso de sistema chamado local1.

O Syslog permite filtrar os registros de logs e direcioná-los em arquivos separados de acordo com o recurso no qual o registro foi originado. Existem vários recursos (que podem ser considerados canais) por onde as mensagens/registros são enviados por algum elemento do sistema, por exemplo, um processo de servidor de e-mails, eventos de autenticação no sistema e mensagens originadas do próprio kernel.

Cada serviço/aplicativo pode direcionar suas mensagens para cada um destes canais, de modo que o syslog possa receber estes registros através destes “canais” e direcioná-los a arquivos separados.

Estes “canais” normalmente são referenciados em literatura especializada como facilty levels ou níveis facilitadores.

Ao invés de usar os “canais”/recursos (kernel, user, mail, auth, etc) já definidos e utilizados extensivamente por diversos elementos do sistema, podemos utilizar canais livres de modo a facilitar a filtragem e organização de logs específicos através do syslog.

No caso acima iremos utilizar o recurso/canal chamados local1, mas poderíamos usar outro “canal”/recurso/facility level padronizado/rotulado no Syslog, sendo estes: auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0, local1 até local7

Estes “canais”/recursos/facilty levels foram rotulados durante a especificação do padrão Syslog (padrão para registro de mensagens de computadores) de acordo com a RFC 5424.

Os facility levels local0 até local7 são reservados para uso local pelo administrador, sendo um boa prática utilizá-los em situações onde o log gerado não se enquadra/pode ser classificado dentro dos facility levels expostos acima.

A última linha do arquivo (full_audit:priority = DEBUG) indica o nível de severidade do registro, sendo que, de acordo com a RFC 5424, o padrão Syslog permite classificar a importância do evento a ser registrado utilizando os seguintes rótulos: Emergency (Emerg), Alert (Alert), Critical (crit), Error (err/error), Warning (warn), Notice (notice), Informational (info) e Debug (debug).

Devido estas indicações de severidade do evento é possível direcionar ainda mais as mensagens para arquivos diferentes.

No caso acima poderia utilizar o nível de severidade Info, mas para não precisar alterar a configuração padrão do Syslog que é:

Ou seja, irá registrar qualquer evento vindo de qualquer recurso (*) classificado com nível de severidade Informational no arquivo /var/log/messages, portanto, classificaremos o nível de severidade como Debug (muito utilizada por desenvolvedores ou implementação de políticas de log em período de teste).

A próxima configuração que deverá ser realizada é no arquivo do Syslog (/etc/syslog.conf), inserindo na última linha do arquivo o trecho abaixo:

O uso do hífen ao lado do caminho absoluto irá depender do ambiente, ou seja, da quantidade de memória disponível no servidor bem como o número de acessos e operações em cada arquivo, pois o hífen torna o registro síncrono com o arquivo, entretanto poderá gerar decremento na performance dependendo do número de usuários acessando arquivos e obviamente dependerá da quantidade de arquivos e operações ocorrendo em média, deste modo, se a quantidade de memória é considerável para o ambiente, é possível deixar o registro ocorrer de forma assíncrona (retirando o hífen acima), entretanto, dependendo do ambiente (uso de No-breaks) e da importância destes logs, o uso assíncrono é arriscado, portanto, uma análise considerando estas e outras variáveis é importante.

Após alterar o arquivo, solicite o recarregamento do arquivo de configuração por parte do servico do Syslog:

Para completar a configuração iremos implementar a política de rotacionamento de logs. Rotacionamento de logs é uma tarefa que é realizada pela ferramenta logrotate, e possui grande importância em servidores.

A maioria dos arquivos de log em sistema Unix utilizam formato texto pleno, mas independente disso, dependendo da demanda que usuários e recursos (arquivos/diretórios) acessados, bem como o período em que isto está ocorrendo, estes arquivos de texto irão crescer ao ponto de ocupar centenas a milhares de Megabytes, ao ponto de utilizar todo os espaço disponível para esta finalidade.

O rotacionamento de logs permite que, de acordo com a política empregada, um arquivo possa ser segmentado, bem como seus segmentos mais antigos serem compactados (de modo a reduzir o espaço utilizado).

Dentro de uma política de log, além de considerar o espaço em disco disponível, deve-se observar o período em que deseja-se armazenar estes arquivos. No caso do arquivo audit.log que estamos definindo como ponto para registrar as ações realizadas em cada arquivo/diretório, precisamos definir quantos dias, meses ou anos estes registros estarão disponíveis ou quantos segmentos irão existir do arquivo e que período (diariamente, semanalmente, etc) estes segmentos serão criados.

No caso vamos criar um arquivo de parâmetros que irá criar até 32 segmentos, e parte destes segmentos serão compactados. Já em relação ao período de criação destes segmentos ele será diário, bem como estes arquivos serão segmentos considerando que o segmento mais recente tenha atingido pelo menos 2 Megabytes, para que as entradas mais antigas destes arquivo sejam movidas para outro arquivo de segmento.

Crie um arquivo audit_samba.conf em /etc/logrotate.d com o seguinte conteúdo:

Os elementos mais importantes deste arquivo são:

  • dayly: realiza o rotacionamento/segmentação do arquivo diariamente);
  • rotate 32: irá rotacionar e manter no máximo 32 segmentos (os segmentos mais antigos serão descartados);
  • minsize 2M: somente irá rotacionar que o arquivo de segmento mais recente conter no mínimo 2M, do contrário não será segmento no dia presente;
  • compress: como o próprio nome já diz, os segmentos serão compactados (por padrão utilizando o utilitário gzip, entretanto, este comportamento pode ser alterado com o parâmetro compresscmd);
  • delaycompress: atrasa a compressão para o próximo rotacionamento, ou seja, teremos arquivos de segmento compactados a partir do antepenúltimo segmento mais recente até o segmento mais antigo.

Entretanto, ainda falta alterar um arquivo de políticas do logrotate chamado /etc/logrotate.d/samba.

Este arquivo contém uma política de rotacionamento que será aplicada a todos os arquivos com extensão log existentes em /var/log/samba, entretanto, como temos um arquivo de política já especifico para o arquivo audit_samba.log (que irá expandir muito mais rapidamente que qualquer outro arquivo de logs do samba), vamos adaptar o arquivo de políticas de rotacionamento padrão para não aplicar estas políticas no arquivo audit_samba.log.

Alterar o arquivo /etc/logrotate.d/samba:

Onde existe:

Altere para:

Diferente de outros utilitários do sistema, o logrotate não é executado em background como um servico, ele é executado mediante as políticas de agendamento de tarefas definidas no cron, sendo assim, o utilitário logrotate será executado todos os dias a 4:02 da manhã de arquivo com o arquivo /etc/crontab e existência do arquivo de agendamento em /etc/cron.daily.


Este artigo também foi publicado no meu blog (que está sendo reformulado), onde tenho centenas de artigos que serão disponibilizados novamente, artigos esses antes disponíveis em outro blog que possuia.

waldemardibiazijr.wordpress.com/category/auditoria/

O mesmo artigo artigo foi publico no Pulse do Linkedin: www.linkedin.com/pulse/full-audit-samba-syslog-logrotate-rhel-5-waldemar-dibiazi-junior

AGRADEÇA AO AUTOR COMPARTILHE!

Waldemar Dibiazi Junior

Mais artigos deste autor »

Analista de Infraestrutura de Redes da Prorede Telecom - Ribeirão Preto - SP, trabalhou em dezenas de projetos de virtualização, reestruturação, implantação, bem como, projetos envolvendo clusters fail over, Segregação de Redes, VPNs, Load Balance, File Servers sob Clusters, Monitoramento de Infraestrutura e Nuvens Privadas sob Amazon AWS e Openstack.

Engenheiro de Computação, Pós Graduação em Banco de Dados, MBA em Gestão de Infraestrutura como Serviço, certificado Red Hat RHCSA, RHCE e RHCSA-OSP, estando entre os 20 primeiros certificados da América da Latina na plataforma Openstack da Red Hat.


Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">