Como localizar o ponto de entrada de uma pessoa não autorizada em um servidor

2

Estamos executando um servidor dedicado interno com centenas de sites. Alguns desses sites eram muito inseguros e a caixa não era gerenciada muito bem. Alguém entrou, bagunçou um monte de coisas e está nos importunando, desfigurando alguns dos sites, pedindo dinheiro, etc.

Fizemos muitas correções, mas ainda há algum tipo de backdoor através do qual ele pode entrar. Encontramos e excluímos alguns arquivos que eram uma espécie de painel de controle do hacker, mas como o arquivo era chamado apenas de contactUs.php, é impossível saber que todas as instâncias desses tipos de arquivos foram removidas.

Eu percebo que este é um assunto muito amplo e uma pergunta que pode ser difícil de responder, mas que passos você tomaria para descobrir como essa pessoa está entrando no sistema?

É uma máquina do Fedora que executa principalmente sites PHP.

    
por stef 20.12.2009 / 21:10

2 respostas

11

Honestamente, se você está administrando um negócio, eu não tentaria estudar o invasor, apenas os bloquearia e seguiria em frente. Não vale a pena o tempo, o incômodo e a frustração de entrar em uma batalha de inteligência com alguém assim. Algumas ideias para se livrar delas:

  • Reinstale a caixa, do zero, usando uma mídia em boas condições.
  • Antes de começar a colocar sites, verifique se ele está completamente atualizado e atualizado. Se você estiver executando uma versão desatualizada do Fedora (uma que não esteja recebendo ativamente atualizações de segurança), atualize para a versão mais recente (ou use algo com suporte de segurança adequado).
  • Não execute scripts PHP via mod_php , porque é uma brincadeira de criança explorar os inevitáveis problemas de permissões resultantes de ter que dar ao servidor da Web acesso de gravação a várias partes do sistema. Use suexec ou suphp.
  • Execute scripts PHP como um usuário separado da "conta FTP" principal (ou equivalente), portanto, se você tiver um usuário example (para o site example.com ), execute seu conteúdo dinâmico em um usuário chamado example-cgi (ou equivalente). Em seguida, conceda somente o acesso de gravação do usuário example-cgi às partes da árvore do sistema de arquivos que as requerem. (Isso requer modificar a verificação de permissões do suexec, mas vale a pena). Desta forma, o invasor não pode executar scripts que modifiquem o código PHP do site, e eles têm que trabalhar muito mais para injetar um exploit.
  • Procure e destrua todos os arquivos graváveis do mundo de maneira proativa e em andamento.
  • Restringir conexões FTP e SSH de locais conhecidos, em vez de permitir que toda a Internet se conecte.
  • Aplique senhas strongs usando algo como o módulo cracklib do PAM - ou, melhor ainda, livre-se totalmente do FTP e exija o uso de chaves SSH para entrar na máquina.

Provavelmente uma pilha de outras coisas que não consigo pensar no momento, mas isso vai mantê-lo por um tempo.

    
por 20.12.2009 / 22:38
3

Algumas ideias:

Se você puder obter evidências dos arquivos que ele alterou, provavelmente poderá obter um registro de data e hora que você poderia correlacionar com algum log no próprio servidor ou uma caixa intermediária (o firewall, aproximadamente). Se esse cara limpar a si mesmo, tiver logs duplicados ou configurar o log remoto na caixa onde ele se conecta - dessa forma ele não poderá apagar a evidência. A correlação cruzada vai ser complicada para dizer o mínimo, especialmente com a sua carga.

Além disso, use rkhunter, chkrootkit e OSSEC e veja o que aparece. Ou monte um honeypot e veja se ele dá uma mordida:)

    
por 20.12.2009 / 21:20

Tags