A instância do Amazon EC2 possivelmente comprometida

3

Eu tenho uma instância do EC2 que pode ter sido comprometida. A instância responde muito lentamente desde a semana passada e recentemente eu verifiquei o httpd access_logs e eles estão em excesso de 11Gigs, apesar de abrir a instância do EC2 apenas no mês passado. O access_log de hoje está crescendo. O arquivo de log está cheio de sites que não têm nada a ver com o site em que estou trabalhando.

Um punhado de pessoas tinha acesso ssh, mas eu o revoguei. Ainda assim, os arquivos de log crescem.

Acabamos de receber alguns e-mails da Amazon sobre "abuso" e descobri que houve um salto na atividade de correspondência. Estranhamente, eu nunca configurei o serviço de email nesta instância, mas o firewall foi configurado para permitir o acesso smtp (entre outras coisas), mesmo que eu tenha configurado apenas o acesso à porta 80 e algumas portas 22.

Eu não sou muito de um servidor e não conheço nenhum.

Eu mudei minhas senhas da Amazon e criei novos códigos de acesso. Mudou as portas para ssh para diferentes.

Eu realmente aprecio qualquer conselho sobre este assunto. Obrigado.

// ******** *EDITAR ********* /

Agora acredito que isso foi o resultado de ter meu servidor usado como proxy. De acordo com estas diretrizes link , consegui conter uma grande a maioria do tráfego falso indo para o site, embora as solicitações ainda estejam se acumulando nos access_logs. Confirmei ao tentar usar o meu servidor como proxy e isso força os usuários ao site diretamente - do jeito que eu acho que deveria - em vez de dizer, yahoo.com.

Eu não sei se essa foi a solução, mas até agora parece estar dando certo - até agora.
Ainda assim, as respostas postadas abriram meus olhos. Se alguém tem mais a dizer, eu ficaria feliz em ouvir. Muito obrigado!

    
por sandrum 18.04.2011 / 06:01

3 respostas

2

Procure nas páginas que você atende, procure por algo parecido com links com spam ou explore o código que foi inserido em seu servidor. Sua melhor aposta é comparar seus arquivos estáticos com um backup e ver se alguma coisa foi alterada.

Feche a porta 25 no firewall, se você não estiver usando.

Você pode usar ferramentas como o rkhunter:

link

e chkrootkit:

link

para tentar detectar ferramentas que os hackers usam para manter o controle sobre o sistema.

Use uma ferramenta como o Nexpose para encontrar vulnerabilidades em seu aplicativo da Web e no SO e siga as recomendações deles sobre a correção dessas vulnerabilidades:

link

    
por 18.04.2011 / 06:51
0

Pode haver uma das duas maneiras em que o servidor está sendo violado ou invadido. Primeiro através de uma exploração de software e segundo através da rota da aplicação web. Primeiro, eu verifico se há explorações de software e, em seguida, verifique o aplicativo da Web.

Possíveis problemas. Em nenhuma ordem particular

  1. Você tem alguma correspondência / formulário que usa a entrada do usuário para enviar e-mails e não possui autenticação / autorização envolvida.
  2. Configuração incorreta ou aplicativos não protegidos. Coisas como phpMyadmin sem senha ou em aplicativos de desenvolvimento expostos de maneira insegura.
  3. Verifique os logs de acesso e obtenha uma lista de arquivos que foram acessados. Se eles são seus arquivos, eu verificaria as falhas de segurança neles.
  4. Verifique seu backup válido conhecido com os arquivos atuais presentes em seu servidor da web. Se você não usou nenhuma diretrizes de codificação segura , pode haver um problema com o Shell Remoto etc.

Se você não estiver usando o bloco de endereçamento smtp no firewall para conter o dano.

    
por 18.04.2011 / 06:21
0

Se as solicitações ainda estiverem chegando, altere o endereço IP elástico. Freqüentemente os proxies públicos são referenciados pelo endereço IP, isso deve parar o tráfego restante.

Vale a pena conferir qualquer endereço IP atribuído a você ao pesquisá-lo quando você o obtiver. Eu tinha uma que estava listada como proxy, então só tenho outra.

    
por 18.04.2011 / 22:14