Análise Forense Computacional de Logs em Sistemas Linux: as testemunhas da rede.

Logs são registros, normalmente armazenados em ficheiros 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 diversos sistemas operativos, como GNU/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 operativo GNU/Linux para demonstrar como o profissional de perícia pode coletar muitas informações a respeito do sistema. Logs no GNU/Linux. O GNU/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 utilizadores que acessaram o sistema operativo:

Exemplo da execução do comando "last", que informa a data e hora dos utilizadores que acessaram o sistema operativo.

Já o comando "lastb", pode listar a última tentativa de login que não obteve êxito. Igualmente, pode-se acessar diretamente o ficheiro responsável por tais registros digitando  

# cat /var/log/btmp

Com "who", é possível verificar os utilizadores 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 utilizador.

Outro dado importante na análise de trojans e rootkits é monitorar quais ficheiros de 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 utilizador.

Posteriormente, podemos filtrar com o comando "lsof -p" somente os ficheiros 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 ficheiros chamados por determinado processo.

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

No GNU/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 Ficheiros 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 = Ficheiro que registra os logs do Servidor de E-mails

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

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 ficheiro "auth.log" em "/etc/log" , tem muito a nos dizer:

Utilizador tenta proceder login no sistema operativo 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 operativo.

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 operativo.

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 utilizadores 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 = Ficheiro de registro de conexões http
• /var/log/squid/cache.log = Hora e data em que o ficheiro 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 GNU/Linux e é considerado o salvador dos administradores de rede, auditores e peritos computacionais. Por meio do mesmo é possível fazer com que o ficheiro de log, retorne, por exemplo, apenas os registros que tragam determinada "string" em sua linha.

OBS: Em programação e em linguagens formais, uma cadeia de caracteres (também conhecida como samblagem ou string) é uma seqüência ordenada de caracteres (símbolos) escolhidos a partir de um conjunto pré-determinado. Em programação, cada símbolo armazenado na memória é representado por um valor numérico. Uma variável declarada com tipo de dado cadeia geralmente armazena um número pré-determinado de caracteres.

No nosso exemplo, podemos varrer o ficheiro "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 contra falsificação, adulteração e acesso não autorizado, por meio de medidas de descentralização e redundância das “testemunhas eletrônicas”.

Fonte: Imaster

Pagina do autor do artigo: Dr. José Milagre

Historia do GNU/Linux:

Historia do Unix:



Fonte: Youtube