Lições tomadas depois do hacking ao meu servidor

Depois do ataque de que o meu servidor foi alvo, estive a informar-me e a estudar soluções e procedimentos recomendados a tomar neste tipo de soluções. Aos interessados, ficam aqui informações que considero bastante úteis.

Alguns documentos de leitura recomendada
cert.pt - Passos para recuperação de um compromisso de segurança: Um pouco desactualizado, mas tem informação que ainda pode ser útil para uma primeira análise. Atenção: alguns dos procedimentos aqui recomendados poderão já não ser adequados actualmente. Por exemplo: desligar o computador da rede pode provocar um ataque "kamikaze" da parte de algumas ferramentas de ataque, que podem despoletar um rm -rf / quando perdem a ligação à rede.

As seguintes ligações também são bastante informativas e nunca são demais de recordar para o público em geral: cert.pt - O que fazer em caso de infecção por vírus informático e cert.pt - Cuidados a ter com Conversas em Instant Messengers, IRCs e Chat On-Line.

Em casos em que haja mais recursos (empresas ou organizações com administradores de sistemas dedicados), o seguinte documento contém recomendações para uma abordagem sistemática a estas situações: cert.pt - Recolha e Armazenamento de Dados de Prova. Aqui reforça-se bem a ideia, a não esquecer, de se fazer sempre a análise forense num sistema isolado. Caso contrário, o computador que faz a análise corre o risco real de ficar também infectado.

Outro documento, bem mais actual e bastante útil: Securing Debian Manual - Chapter 11 - After the compromise (incident response).

Posto isto, resumo aqui algumas ferramentas úteis que recolhi ou que me foram recomendadas por terceiros. Fica aqui o meu agradecimento público àqueles que contribuíram para o enriquecimento desta lista.

Ferramentas de análise forense:

• sleuthkit: Um pacote com várias ferramentas para análise de um sistema comprometido. Permite recolher informação sobre ficheiros apagados, processos em execução, entre outros.
• autopsy: Um interface web para análise forense de imagens de discos.

Ferramentas de prevenção:

• Logwatch: O logwatch, como o próprio nome indica, observa os logs do sistema, e envia todos os dias para o administrador um relatório com um resumo sobre os mesmos. Este relatório inclui a contagem de tentativas e acessos ao servidor, software instalado, estado dos discos e partições, entre outros.
• Tripwire: Mantém um checksum dos programas instalados no sistema. Deve ser configurado assim que o sistema é instalado, quando se tem a certeza de que não houve qualquer intrusão. Depois de um ataque (ou suspeita de ataque), é possível detectar os ficheiros alterados (cujo checksum não corresponde ao guardado anteriormente).
• Limitação de ligações: A lógica destas ferramentas é limitar o número de ligações permitidas para reduzir a frequência (e a eficácia) de ataques por dicionário, como aquele de que fui vítima.
  • Limitar Ligações SSH: colocar uma regra simples na firewall para limitar o número de ligações por minuto provenientes do mesmo endereço IP e destinadas ao porto do servidor SSH. Limitar ligações com frequência acima das 3 por minuto vindas do mesmo IP pode reduzir mais de 70% dos port scans. Esta sugestão é simples e interessante, mas pode tornar-se incómoda para as ocasiões em que eu próprio tenho dificuldades em acertar com as passwords.
  • DenyHosts: O DenyHosts mantém uma listagem das origens de ataques conhecidas, compilada por milhares de utilizadores da ferramenta. É um bom princípio, mas tem dois senãos principais: primeiro, estou a confiar numa listagem criada por desconhecidos, e um ataque coordenado a esta listagem (que não sei se alguma vez aconteceu) pode inviabilizar o acesso à máquina; segundo, só limita as tentativas de acesso ao SSH. Idealmente, gostaria de limitar os acessos a toda a máquina, e não apenas ao servidor SSH na mesma.
  • fail2ban, SSHGuard: Estas duas ferramentas negam as ligações à máquina a todos os que tiverem falhado ao ligar-se à mesma. À semelhança do que acontece quando se falha um login num screensaver, em que o tempo de espera para novas tentativas vai aumentando, estas tornam o intervalo entre tentativas de acesso à máquina cada vez maior. Completarei esta secção quando tiver uma comparação mais detalhada e informada entre as duas.
  • Deixar de usar passwords e permitir apenas chaves públicas reconhecidas: Esta é uma solução eficaz, mas o grande problema surge quando pretendo aceder a partir de uma máquina nova, cuja chave não se encontra no servidor. Fico bloqueado do lado de fora. Adicionalmente, se não forem utilizadas passphrases, faz ainda partir do princípio de que confio plenamente nas máquinas cujas chaves foram ali enviadas, o que pode nem sempre ser verdade.

Todas as ferramentas mencionadas estão disponíveis nos repositórios de qualquer distribuição decente. ;)