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 prejudicá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)