ataque SSH CentOS Amazon EC2

Question

Eu executei algumas instâncias baseadas no RightsCale CentOS AMI no Amazon EC2. Dois meses atrás, descobri que nossa segurança SSHD está comprometida (adicionei host.allow e host.deny para ssh). Então criei novas instâncias e fiz um ssh baseado em IP que permitia somente nossos IPs através do AWS Firewall (ec2-authorize) e conectava a porta padrão do ssh 22 a alguma outra porta mas dois dias atrás eu descobri que não era capaz de logar no servidor e quando tentei em 22 port o ssh se conectou e achei que o sshd_conf foi alterado e quando tentei editar o sshd_config achei que o root não tinha permissão de gravação no arquivo. Então eu tentei um chmod e ele disse que o acesso era negado para o usuário 'root'. Isto é muito estranho. Eu verifiquei log e histórico seguro e não encontrei nada informativo. Eu tenho PHP, Ruby On Rails, Java, aplicativos Wordpress em execução nesses servidores.

Desta vez, fiz uma verificação do chkrootkit e não encontrei nada. Eu renomeiei a pasta / etc / ssh e reinstalei o openssh através do yum. Eu já havia enfrentado isso em 3 instâncias no CentOS (5.2, 5.4). Eu tenho instâncias no Debian, bem como aquelas que funcionam bem. É um problema do CentOS / Rightscale? Galera, que medidas de segurança devo tomar para evitar isso?

Eu duvido que isso possa ser um hacker interno também, já que permitimos apenas nossos IPs para o ssh.

Por isso estou planejando usar um keylogger que pode registrar todos os toques de tecla de cada usuário e terminais. Você poderia me sugerir alguns dos melhores trajes do keylogget para esse propósito?

Tenho certeza de que é um ataque ssh, mas não sei como eles fizeram isso. O CentOS 5 ainda usa o openssh 4.3, então eu compilei o openssh 5.5 e descobri que eles mudaram os atributos para / usr / bin / ssh e / usr / sbin / sshd. Eu tive que usar o nome do arquivo lsattr o nome do arquivo chattr -ia para remover os atributos e compilar com sucesso o openssh. Agora estou tentando configurar o chroot e configurar o Osiris por precaução.

Por favor, compartilhe seus pensamentos. Também preciso de um keylogger registra todas as teclas digitadas que você sugere?

Obrigado pelo seu apoio.

    

Answer 1

Basicamente, você está ferrado.

Se você fosse realmente explorado, eles poderiam ter adicionado um backdoor no binário SSHD, ou qualquer outro arquivo no sistema ... Já que a fonte está disponível, isso é fácil de fazer, e é extremamente difícil identificar se você não planejou com antecedência.

Se você não tiver o Tripwire ou similar instalado antes que o problema tenha acontecido, você basicamente terá que verificar cada arquivo no sistema em uma instalação de limpeza conhecida.

Mais fácil apenas mover seu aplicativo para um servidor limpo.

A melhor prevenção é um scanner de integridade de arquivos. Basicamente, ele verifica todos os arquivos no sistema e faz um hash dele. Em seguida, periodicamente, ele verifica novamente e notifica você sobre quaisquer alterações. Limpa uma brisa.

Concordo que você provavelmente não foi explorado pelo SSH ... Eu quase nunca vi isso acontecer e, quando isso acontece, geralmente é devido a uma vulnerabilidade não corrigida no daemon. Brute forçando uma senha SSH geralmente é uma causa perdida.

Edit: Eu tenho lido em Osiris esta tarde, e parece muito legal. Ele periodicamente re-scans e envia um e-mail dos arquivos alterados. A versão empresarial do Tripwire oferece checagem em tempo real, mas é claro que você tem que pagar por isso. Existe uma versão de código aberto do Tripwire , que pegou as rédeas do muito mais antigo código fonte aberto, e é bastante sólido também.

    

Answer 2

Antes de mais nada: certifique-se duplamente com qualquer outra pessoa que tenha acesso root / sudo que não tenha reconfigurado isso. Você não quer perseguir um ataque que não aconteceu.

Nota: um cenário de ataque parece improvável. A maioria das pessoas inteligentes o suficiente para comprometer sua máquina não é estúpida o suficiente para mudar coisas tão óbvias quanto a porta SSH está escutando. Por que se incomodar?

Após decidir que sua máquina foi comprometida, considere tudo o que você digitou ou armazenou no servidor de informações públicas. Alterar senhas, chaves SSH, etc.

Em seguida, você precisa determinar o ponto de entrada mais provável. A menos que você tenha algumas senhas ridículas, duvido muito que o SSH tenha sido o compromisso original. Astronomicamente mais provável é que alguém tenha obtido acesso através de uma das suas aplicações Web.

• Isole cada um dos seus aplicativos para sua própria nova instância do EC2. Eles são baratos. Compromissos de segurança podem destruir seu negócio. Isso ajudará você a isolar quaisquer vulnerabilidades em um único aplicativo, que tem o efeito colateral prático de apontar o dedo quando / se ocorrer um ataque.

• Verifique se há vulnerabilidades conhecidas nas suas versões. Ou adote a abordagem shotgun e atualize tudo para sua versão mais recente.

• Se algum dos seus aplicativos estiver sendo executado como root, corrija isso agora.

• Se algum de seus aplicativos estiver sendo executado fora de um chroot, corrija isso agora.

• Crie um servidor syslog central sem servidores externos. Defina cada um dos seus aplicativos para registrar o mais breve possível via syslog para este servidor. Quando / se ocorrer um ataque, você precisará da perícia para determinar de onde veio e como entrou.

• Se você está permitindo o acesso SSH com senha a esses servidores, não o faça. Mude para chaves ssh.

• Considere instalar o Tripwire, o Osiris ou outro monitor de integridade para determinar quando algo de ruim acontece.

Um atacante sofisticado tentará cobrir seus rastros. Se você não tem os monitores e salvaguardas para registrar o que está acontecendo, persegui-lo será um exercício de futilidade. Mantenha seu sistema o mais seguro possível e garanta que qualquer atividade estranha não passe despercebida.

EDITAR

Como você mencionou alguns erros de permissão negada para o root, verifique se root é o único usuário atribuído ao UID 0 (getent passwd 0). Se não, você está definitivamente comprometido.

    

Answer 3

Se quaisquer binários foram alterados, você pode executar "rpm -aV". Isto irá md5 corresponder ao rpm instalado contra o binário no disco (e também verificar permissões e similares). Não é exatamente tripwire - e não vai detectar se qualquer usuário carregado conteúdo mudou, obviamente, mas se alguma coisa foi alterada em / usr ou / bin etc ele deve aparecer.

Ele sinaliza um monte de falsos positivos para coisas em / etc que foram deliberadamente alteradas, portanto, você precisará revisar sua saída depois de executá-la.

    

Answer 4

Você tem certeza de que isso não é o Rightscales "rightscripts" (chef) apenas está pavimentando suas mudanças?

É extremamente improvável que o seu sshd tenha sido comprometido, a menos que você esteja usando senhas de palavra inglesa minúsculas de seis caracteres.