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:
[global] netbios name = fileserver01 server string = File Server workgroup = empresa security = user map to guest = bad user socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=16384 SO_SNDBUF=16384 interfaces = lo bond0 hosts allow = 127. 10.10.20. bind interfaces only = yes log level = 0 passdb backend = tdbsam log file = /var/log/samba/log.%m max log size = 1024 load printers = no printing = bsd printcap name = /dev/null getwd cache = yes [public] comment = Compartilhamento de uso colaborativo path = /data browseable = yes read only = no guest ok = yes vfs objects = full_audit # Auditoria full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir full_audit:prefix = %u|%I|%S full_audit:failure = none full_audit:facility = LOCAL1 full_audit:priority = DEBUG
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:
smbd_audit: joao.ferreira|192.168.0.140|public|opendir|ok|Datafiles/0001/bkp/dataFile0001a.dat
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 é:
*.info ……… /var/log/messages
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:
# File Server Audit
local1.debug -/var/log/samba/audit.log
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:
service syslog reload
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:
/var/log/samba/audit.log { dayly rotate 32 minsize 2M notifempty missingok sharedscripts copytruncate compress delaycompress postrotate /bin/kill -HUP `cat /var/run/smbd.pid /var/run/nmbd.pid 2> /dev/null` 2> /dev/null || true endscript }
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:
/var/log/samba/*.log
Altere para:
/var/log/samba/[b-z]*.log
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
