Como analizar logs? Como obter informações sobre a rede?
Um administrador de sistemas costuma ter mais trabalho do que braços e mais coisas para lembrar do que cérebro para guardá-las; é por isso que existem os logs. Os arquivos de log são pequenos documentos de texto que são atualizados por scripts, de acordo com a vontade do administrador de sistemas. Existem logs para as mais diversas funções, desde login de usuários em máquinas locais – incluindo tentativas de login sem sucesso –, até logs de acesso a arquivos ou serviços distribuídos por servidores.
Do ponto de vista dos usuários, o log costuma ser a derradeira ferramenta de adestramento – ou melhor, coação – que o administrador de sistema pode apresentar contra suas incursões fora da rede ou da Web, ou suas pretensões de fazer o que quiser.
Os usuários costumam resolver esse problema, como já vimos, contestando os logs administrativos e alegando que eles podem ser alterados manualmente para prejudica-los – apesar de essa defesa, na maioria das vezes, não ser levada em consideração.
Logs remotos
A maioria dos aplicativos de rede gera logs, que podem ser armazenados tanto no servidor em que o aplicativo é rodado quanto em máquinas preparadas especialmente para armazenar logs (os servidores de logs). Alguns aplicativos ainda trazem a opção de envio de arquivos de log ao e-mail do administrador ou a um FTP escolhido para esse fim. O ideal é que o administrador tenha os logs sempre à mão, mesmo que ele não esteja na empresa – o problema é que nem todos os serviços e softwares disponibilizam logs online. Isto pode ser resolvido de várias maneiras, dentre as quais:
a) Criar manualmente um serviço de FTP com senhas, armazenando nele os logs.
b)Criar um diretório escondido, compartilhado para a Web, e utilizar nele todos os diretórios.
Ambas as soluções, na verdade, são muito parecidas e perigosas. Criar um diretório compartilhado na Web, mesmo que encoberto por diversas “camadas” de diretório, pode funcionar para esconder seus arquivos por um curto período de tempo, mas não como solução-padrão. Por mais que os logs pareçam suficientemente ocultos, sistemas de busca como o Google são capazes de devassar servidores, buscando por caminhos de diretório inteiros.
Fazendo a busca digitando inurl:”/admin/logs” na barra de buscas do Google, encontraremos diversos servidores – na maioria servidores Web Apache – desprotegidos ou mal configurados, com muitos logs para serem observados. Para ter certeza de que estamos falando de um servidor Apache, observe se o caminho completo é /www/admin/los. O caminho /wwwroot/logs ou qualquer um contido no diretório /wwwroot diz respeito a servidores Windows rodando o IIS (Internet Information Service).
Visível e vulnerável
Ao mesmo tempo, servidores FTP contendo arquivos de logs, mesmo que protegidos por senha, podem ser visíveis via Google. Ao fazer uma consulta utilizando o parâmetro inurl:”/ftp/log”, o Google retorna uma infinidade de links contendo esses diretórios. Ao tentar acessá-los, em muitos deles não é possível entrar: sinal de que o administrador colocou permissões de arquivos nos logs ou inseriu uma senha.
Esse último recurso é facilmente contornável: os crackers costumam “reverter” o endereço do log, procurando o endereço que corresponde somente ao FTP.
Um exemplo: ao acessar o link http://www.test.com/test/servidores/headers/ ws_ftp.log, o acesso é imediatamente recusado com a exibição de uma mensagem. Mas, abrindo uma nova janela do browser, reverte-se o endereço do link. Apesar de ser um endereço de página Web (www), ele é escrito substituindo o www por FTP. No caso, teríamos ftp://ftp.test.com.
Se o FTP não está configurado para receber logins anônimos diretos – a modalidade de logins na qual a tela para inserção da senha nem aparece – ou indiretos – quando basta digitar anonymous em usuário e manter a senha em branco – o cracker terá de inserir um nome de usuário cadastrado no sistema de FTP e senha.
Para conseguir acesso a todos os arquivos do FTP – incluindo logs – o cracker costuma utilizar as contas administrativas, que dão poder ilimitado para seu possuidor.
Vale até tentar acesso utilizando senhas mal configuradas, esquecidas pelo administrador ou dono do FTP (que nem sempre são a mesma pessoa). Apesar de serem vulnerabilidades antigas e muito exploradas, conhecidas por todos que passaram, no mínimo, por cursos de webmasters, encontrar portas abertas digitando
o formato (login/senha) admin/admin, administrador/administrador, ftp/ftp ou ftp/ “senha em branco” é mais comum do que se imagina.
Quando isso não é possível, o jeito é utilizar técnicas mais agressivas e burras, como os sistemas de brute force. Agressivas porque programas deste tipo para o Windows, como o Brute Force AT2 (http://www.hoobie.net/brutus/brutus-aet2.zip), acompanhados de um arquivo combo (arquivo de texto que contém milhares de especificações para login e senha que serão lidas pelo software) são capazes de fazer mais de 3000 tentativas de login em uma hora. E isso, utilizando máquinas antigas como 486 e uma conexão de 56 kbps (o equivalente a uma linha telefônica comum).
Burras porque, se você não obtiver sucesso, acabará deixando um log com todas as tentativas de acesso feitas por seu número de IP, que poderá ser facilmente rastreado pelo administrador usando o comando traceroute (presente em diversos sistemas operacionais baseados em UNIX) até chegar ao seu provedor e, se você possui IP fixo (que não muda a cada reconexão à Internet), até sua conta de acesso.
Aliás, essa é uma das coisas que a maioria dos crackers e script kiddies aprendem ao invadir um servidor com o sistema de login e conseguir privilégios de administrador: apagar, por via das dúvidas, os arquivos de log. Isso é muito simples de fazer, bastando acessar a linha de comando e programar o seguinte bash: #! /bin/bash
cd /var/log (diretório de armazenamento padrão dos logs em sistemas baseados em UNIX)
for l in ‘ls -p|grep ‘/”; do
-n >$l &>/dev/null
echo Zerando arquivo $l…
done
echo Limpeza dos arquivos de log concluída!
Um bom administrador de sistemas, no entanto, nunca deixaria o /var/log, sozinho, ser repositório de todos os logs do sistema. Pode-se, por exemplo, copiar todos os logs para um outro diretório: # cp –a /var/log (diretório de destino)
Uma esperteza a mais seria enviar o arquivo para um diretório de destino em outra máquina da rede: # cp –a /var/log /192.168.0.1/(diretório de destino)
E uma esperteza MUITO maior seria apagar os arquivos originais depois de copiá-los para um repositório de logs: # cp –af /var/log /192.168.0.1/(diretório de destino)