Logs são registros, normalmente armazenados em arquivos ASCII ou texto simples, capazes de armazenar o que se passa com sistemas computacionais e serviços de rede. A Correlação de logs de eventos, segurança e auditoria são fundamentais para que se possa reconstruir o que efetivamente ocorreu com um sistema computacional no passado.

Deve-se consignar, entretanto, que antes mesmo da analise dos logs, o perito deve pautar sua conduta pela manutenção da volatilidade, princípio computacional que nos informa, basicamente, que antes da análise de logs armazenados em discos rígidos existem muitas outras coisas mais importantes para se fazer prioritariamente, como o dump da memória e o congelamento do estado da rede e processos.

Importa frizar também que o perito deverá ter a intimidade em coletar dados em sistemas operacionais diversos, como Linux e Windows, e nestes, em aplicações diversas, como Squid ou um Servidor Exchange Server.

No presente artigo, exploramos as ferramentas nativas do sistema operacional Linux para demonstrar como o profissional de perícia pode coletar muitas informações a respeito do sistema.

Logs no Linux

O Linux é recheado de registros, muitos comandos simples nativos podem levantar muitas informações sobre o sistema, por exemplo, o comando last/lastlog, que pode ser utilizado para exibir a listagem dos últimos usuários que logaram no sistema:

Exemplo da execução do comando last, que informa a data e hora dos usuários que logaram no sistema.

Já o comando lastb, pode listar a última tentativa de login que não obteve êxito. Igualmente, pode-se acessar diretamente o arquivo responsável por tais registros digitando # cat /var/log/btmp.

Com who, é possível verificar os usuários logados na máquina. Já com history | more, o perito tem acesso aos registros dos últimos comandos executados na seção atual.

Execução do comando history: Informa últimos comandos digitados pelo usuário.

Outro dado importante na análise de trojans e rootkits é monitorar quais arquivos determinados processos estão chamando. Por vezes, nada melhor que “executar” o trojan para efetivamente ter indícios do que ele realiza. Com o comando ps -aux] é possível identificar os processos atuais executados por um usuário.

Posteriormente, podemos filtrar com o comando lsof -p somente os arquivos chamados pelo processo PID 11306 (e acabamos de detectar a utilização de MSN em ambiente empresarial, normalmente vedado pela Política de Segurança). Em nosso exemplo, ao executarmos o Amsn (Cliente Messenger para Linux) e executar o comando para listagem dos processos, encontramos o seguinte registro nos logs:

Correlação entre arquivos chamados por determinado processo.

Interessante, dependendo do escopo da perícia, correlacionar os arquivos abertos por um determinado usuário, onde podemos utilizar o comando id para identificar o UID (User Identification) do usuário e posteriormente o comando lsof -U UID.

No Linux , por default, a grande maioria dos registros do sistema se encontram em /var/log, dentre os quais vale destacar:

• /var/log/messages = Contém registros de acesso ao sistema e em alguns casos registros do IPTABLES
• /var/log/samba/log.smbd = Contém os logs do Servidor de Arquivos SAMBA
• /var/log/httpd/(access, error ou agent.log) = Logs do Servidor Web Apache
• /var/log/lpr.log = Informações de acesso às impressoras
• /etc/mail/maillog = Arquivo que registra os logs do Servidor de E-mails

Mais fácil, porém, é a analise de /etc/syslog.conf, arquivo de configuração dos logs do Sistema Operacional, que indica onde os arquivos de log estão armazenados. Apenas atenção é necessária, pois este arquivo pode ter sido atacado ou alterado pelo cybercriminoso. Ainda em /etc/passwd é possível verificar se cracker criou algum account não conhecido pelo administrador de rede.

A lógica e o bom senso nos dizem que um criminoso pode ter corrido muitos quilômetros pelo sistema atacado, mas tudo começou pelo primeiro passo, e o primeiro passo é se autenticar como administrador. Em nosso exemplo, o arquivo auth.log em /etc/log , tem muito a nos dizer:

Usuário tenta se logar no sistema como administrador às 18:26:46 porém não consegue. Posteriormente às 19:03:01 obtém acesso ao root, e em menos de 1(um) minuto, se desconecta do sistema.

Já em /etc/log/daemon.log, podemos identificar os logs envolvendo os serviços em geral, desde logs da rede, como por exemplo, requisições de conexão ou de IPs, à identificação de que alguém plugou ou desconectou da máquina um pen-drive ou dispositivo móvel, vejamos:

Daemons registrando todos os serviços e eventos do sistema.

Nos termos da NBR ISO/IE 17799:2005, especificamente em seus itens 9.7.1 e 10.10.0, é de boa prática a todo administrador de segurança a adoção de um proxy cache em uma rede, e por quê? Justamente para que se armazenem registros de atividades dos usuários que tem acesso à rede mundial de computadores, eis que a empresa pode ser responsabilizada judicialmente pelo conteúdo que seus colaboradores acessam. O Squid é o servidor mais utilizado na plataforma livre e ele também deixa rastros:

Primeiramente deve-se analisar /etc/squid/squid.conf, em busca de alterações nos paths padrões de armazenamento dos logs. Os logs do Squid são divididos em:

• /var/log/squid/access.log = Arquivo de registro de conexões http
• /var/log/squid/cache.log = Hora e data em que o arquivo cache foi iniciado
• /var/log/squid/store.log = Registro dos objetos armazenados pelos clientes em consulta a sites (vídeos, conteúdos proibidos, mp3s, imagens, etc.)

Grep: um aliado

O Grep é um binário encontrado na maioria das distribuições Linux e é considerado o salvador dos administradores de rede, auditores e peritos computacionais. Por meio do mesmo é possível fazer com que o arquivo de log, retorne, por exemplo, apenas os registros que tragam determinada sting em sua linha.

No nosso exemplo, podemos varrer o arquivo auth.log em busca de entradas e saídas de um dispositivo de armazenamento supostamente conhecido, que aqui chamamos de “LG”. Utilizamos o comando cat auth.log |grep “LG” e veja o que descobrimos:

Grep: filtramos, ente um \”mar de logs\” somente os registros de conexão de desconexão de determinado dispositivo de armazenamento. No caso um pen drive \”LG\” com número serial identificado.

Conclusões: a importância dos logs

Como verificado, sistemas Unix tem muito a nos contar. Em uma investigação de incidentes eletrônicos, a análise de logs é de extrema importância, eis que se a função do perito é apurar a ocorrência de fatos e identificar a autoria dos mesmos, a função dos logs é servir como “testemunhas eletrônicas”, aptas a depor sobre incidentes e crimes de tecnologia.

Ainda, manter com segurança registros de atividades atende ao item 10.10 da IS0/IEC 17799:2005, que trata da detecção e registro de atividades não autorizadas, além de evitar responsabilização civil e criminal corporativa, a medida em que pode informar a autoria de delito praticado dos computadores da empresa.

Porém não basta registrar, mas nos termos do item 10.10.3 da 17799:2005, proteger logs conta falsificação, adulteração e acesso não autorizado, por meio de medidas de descentralização e redundância das “testemunhas eletrônicas”.

Blog do José Milagre