Técnicas forenses para identificação da invasão e do invasor em sistemas Unix/Linux através do SSH (parte 2)

Veremos neste artigo uma pequena contribuição sobre algumas das ferramentas e sua utilização na perícia forense em sistemas UNIX/Linux para comprovação da autoria de ataques e/ou invasão através do serviço de Secure Shell - SSH.

[ Hits: 64.833 ]

Por: Matuzalém Guimarães em 03/01/2009


Indícios da invasão



Segundo Murilo; Steding-Jessen (2001), basicamente os ataques a sistemas computacionais seguem uma seqüência padrão, o que permite que sejam implantadas barreiras de proteção visando inibir ou dificultar a ação do atacante.

Murilo; Steding-Jessen (2001) enfatizam que o ciclo de ataque é iniciado com a varredura do sistema em busca de alguma vulnerabilidade a ser explorada com o intuito de obter acesso ao sistema. Uma vez invadido o sistema, o atacante busca meios de não ser detectado e a garantia da continuidade, para isso são utilizadas normalmente ferramentas de backdoors. A figura 1 mostra um ciclo básico das ações de um atacante.

Figura 1 - Ciclo básico de uma invasão / fonte: Steding-Jessen (2001)
Ainda segundo os autores, o uso de ferramentas de rootkit é normalmente usado pelo invasor a fim de não ser identificado e garantir seu acesso através da instalação de backdoors no sistema atacado.

Ainda segundo os autores, os rootkits são essencialmente coleções dessas ferramentas, utilizadas por invasores após o comprometimento de um sistema. Em conjunto, costumam incluir executáveis para monitorar o teclado (keyloggers), registrar tráfego de rede (sniffers), permitir acesso irrestrito ao sistema mesmo sem uma conta válida e, principalmente, esconder tudo que foi feito.

Segundo Borchardt (2002), os rootkits que usam módulos de kernel são conhecidos por rootkit de LKM (loadable kernel modules), estes são carregados dinamicamente no kernel, alterando assim a sua funcionalidade original, sem a necessidade de uma reinicialização. Outras implementações de rootkits funcionam alterando comandos do sistema para esconder informações referentes à presença do atacante, como conexões de rede, arquivos, processos etc.

Ainda segundo o autor, a detecção de rootkits de LKM torna-se difícil, pois os comandos do sistema não são alterados, sendo que o kernel do sistema continuará a responder às requisições de forma normal, ocultando assim a presença do atacante.

Nemeth; Snyder; Seebass; Hein (2001) afirmam que algumas ferramentas automatizadas podem auxiliar na tarefa de identificação de alterações no sistema após uma falha de segurança, o uso da ferramenta tripwire. Segundo os autores esta ferramenta monitora as permissões e realiza cheksum de arquivos de sistemas importantes para que seja possível detectar arquivos que foram substituídos, corrompidos ou manipulados.

O tripwire verifica arquivos em comparação com um bando de dados que registra suas características e checksums no momento em que o banco de dados foi criado. Ele trabalha com uso da ferramenta diff para diferenciar o sistema de arquivos em relação a essa base de referência.

Murilo; Steding-Jessen (2001) esclarecem que além dos processos, conexões de rede também podem revelar pistas de uma invasão, tais como o endereço IP usado pelo atacante para se conectar ao sistema. Um dos comandos usados em sistemas Unix que permite listar todos os sockets IP locais e o protocolo utilizado é o netstat. Além deste outros comandos como o whois e o traceroute podem revelar mais informações sobre endereços IP, essas informações dificilmente podem ser corroboradas pelo atacante.

Os autores ainda afirmam que com o uso do comando dmesg poderá ser revelada uma interface de rede trabalhando em modo promíscuo o que vem a revelar uma possível captura de dados na rede.

Uma técnica simples, mas efetiva, é analisar o próprio arquivo binário de algum programa suspeito, com a finalidade de encontrar caracteres imprimíveis no arquivo. Os autores enfatizam que utilizando o comando strings com o argumento "-a" mais o "binário". Caso algum programa suspeito se conecte a um serviço, pode ser possível encontrar a senha no código do programa, porém, se faz necessária certa expertise para diferir entre informações pertinentes nos caracteres listados na saída exibida do programa.

    Próxima página

Páginas do artigo
   1. Indícios da invasão
   2. Ferramentas para coleta de dados
   3. Análise dos dados
   4. Identificação do invasor
   5. Referências
Outros artigos deste autor

Monitoramento de redes com o Zenoss

Segurança da Informação na Internet

NFS rápido e direto usando Slackware 12

Instalando Free Pascal Compiler no Ubuntu

Estatísticas para todos

Leitura recomendada

Debian Squeeze - Instalando VirtualBox com acesso WEB via phpVirtualBox

SmoothWall - Linux para gateway

Armazenamento de senhas no Linux

Cliente "automágico" Linux logando no domínio NT/Samba

Instalando a nova versão do HLBR - IPS invisível

  
Comentários
[1] Comentário enviado por brevleq em 05/01/2009 - 14:47h

Muito bom!!

[2] Comentário enviado por y2h4ck em 06/01/2009 - 09:20h

Não sei se você percebeu mas eu seu texto você cai em contradição no seguinte ponto:

- Você mostra que uma das fases que um possível atacante efetuaria é de Cobrir os Rastros. Obviamente os logs seriam o primeiro alvo deste atacante.
- Em seguida no capitulo "Identificando o Invasor" você se vale dos logs para identificar o invasor.

Acredito que no seu caso, ou seja, caso de uma análise forense, os logs seriam algo não confiável. Não concorda? :)


[]s

Anderson

[3] Comentário enviado por matux em 06/01/2009 - 13:34h

Olá Anderson,

Obrigado pela leitura e atenção dispensada.
Toda crítica ou elogio sempre será bem-vinda.
Com relação à sua observação tem um outro ponto de vista, seria o seguinte:
1. Os autores que citei afirmam e demonstram o ciclo básico de um ataque. Uma das fases seria "cobrir seus rastros" ou seja, apagar os logs que permitam identificá-lo.

Minha opinião: alguns trabalhos que já realizei e em conversas com outros colegas da área de segurança, bem como em revistas especializadas fica claro que nem sempre os logs são alterados de forma a não permitir a identificação do atacante.

2. Os logs são de fato uma das melhores e mais simples formas de identificação de ações dentro de um sistema. Conseqüentemente de que forma poderíamos identificar uma invasão por SSH se para isto não fossem utilizado a análise dos Logs de acesso.

3. Sabemos que nada é 100% seguro e nem mesmo a perícia forense poderá contar com evidências que permitam a identificação do atacante de forma inequívoca. Os ataques se mostram cada vez mais sofisticados e complexos. Mas ainda sim para a grande maioria dos casos em que podemos contar com os logs servindo de base para a investigação, creio que é sem sombra de dúvidas uma das melhores formas.

Obrigado por sua contribuição e parabéns pelos seus artigos.
Um forte abraço!

[4] Comentário enviado por edipo.magrelo em 08/01/2009 - 11:25h

Ótimo artigo amigo.
Para quem quer saber mais da computação forense recomendo a leitura

[5] Comentário enviado por eisen em 21/05/2009 - 09:34h

Muito bom mesmo, rápido e direto.
Parabéns.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts