Servidor Debian Lenny comprometido - sem sinal de ponto de intrusão?

Question

Eu tenho um servidor, ele está desatualizado com o Debian Lenny, e sim, eu sei que provavelmente é metade do problema. Também possui o PHPMyAdmin e o ProFTPd. Mais uma vez, eu entendi, todos os sinais ruins.

Mas, para minha vida, não consigo descobrir como esse usuário está fazendo login e adicionando arquivos e executando comandos.

Eles podem iniciar screen sessions e digitar coisas como nano file.sh e, em seguida, criar um script e ./file.sh para executá-lo. Isso significa que eles têm acesso SSH? Eu não entendo.

Eu verifico todos os meus arquivos de log, e nada em qualquer lugar mostra uma autenticação bem-sucedida. Eu verifico users , who , last , todo pequeno comando que eu possa digitar - nada mostra qualquer sinal de alguém estar logado.

De vez em quando, noto que eles criam novos diretórios e o proprietário é 500 ou 1XXX , mas essas contas não aparecem quando eu as procuro.

Existe algo que eu possa fazer para descobrir que o wtf está acontecendo? Vamos limpar o servidor, não me entenda mal, mas gostaria de saber o que aconteceu exatamente para que eu possa evitar esse tipo de problema no futuro.

Eu não quero nenhuma recomendação em relação a "não use phpmyadmin, antigas distribuições não suportadas, ftp, etc.", em nosso novo servidor não teremos nada inseguro, e usaremos chaves de autenticação SSH com senha, etc.

Eu só quero saber um pouco sobre como posso saber quando o usuário está logado e de onde ele fez login. É verdade que provavelmente não estou dando informações suficientes, mas talvez algo clica em alguém? Obrigado.

    

Answer 1

A maioria das invasões de script e manuais faz:

• limpe entradas de log e rastreamentos semelhantes da invasão
• instale um rootkit, que permite a entrada no sistema fora dos programas do servidor padrão
• substituir os programas padrão (como ps, netstat, ls, etc.) por versões manipuladas que ocultam qualquer atividade do rootkit mencionado acima (ou seja, o ps não mostrará o processo de execução do rootkit)

Às vezes, esses ataques são defeituosos e deixam rastros para trás. Mas em qualquer caso: você não pode confiar em nenhuma ferramenta de diagnóstico que você tenha no sistema.

Se você quiser brincar um pouco e aprender, poderá:

1. Instale e execute o 'rkhunter' [*] por exemplo, que verifica rootkits conhecidos, mas você não pode confiar na saída sem:

   • ter executado pelo menos uma vez antes do arrombamento acontecer
   • esperando que o atacante tenha ignorado uma instalação do rkhunter no sistema (não manipulou o rkhunter em si)

2. Inicialize a partir de um CD de recuperação / USB

   • Monte os discos do sistema e examine os binários do sistema de recuperação
   • comparando md5sums de binários com a versão de estoque.
   • carrega o sistema em uma VM e inspeciona o tráfego de rede

tl; dr: É quase impossível descobrir o vetor de ataque em um sistema tão aberto. De um jeito ou de outro:

Por favor, seja responsável e tire o sistema da Internet o mais rápido possível e configure-o a partir do zero.

[*] ou outros sistemas IDS, existem muitos.

    

Answer 2

Mesmo que o novo sistema operacional do servidor esteja endurecido ao máximo, e você use o software atualizado mais recente e não tenha mais serviços de texto simples; eles podem ter obtido acesso no servidor antigo por meio do aplicativo da Web em execução no servidor - por exemplo, uma injeção de SQL ou vulnerabilidade de upload de arquivo. Assim, você pode se tornar proprietário novamente se implantar o mesmo aplicativo no novo servidor.

Então, eu realmente recomendo a revisão de código (embora eu também recomende 'e') realizar um teste de penetração de aplicativos da web usando alguém que faz esse tipo de teste profissionalmente / oferece uma recompensa de bugs para a comunidade fazer isso para voce. E que você realiza correções, varreduras de vulnerabilidades e testes de caneta regularmente - pelo menos uma vez por ano ou em software, dependendo, é claro, de quanto você valoriza o serviço que o servidor / aplicativo fornece a você.

PS enquanto seu servidor estiver off-line, considere tirar sua imagem e executar a autópsia contra a imagem para gerar uma linha de tempo para o hack (s) - concentre os IDs dos usuários que você viu 500, 1xxx. Eu suspeito que você achará útil saber como a perícia é feita, especialmente se você for alvo de novo. Embora, como apontado em respostas anteriores, o hack possa ter coberto seus rastros e alterado bibliotecas de chaves e executáveis para deixar uma linha de tempo falsa. Mais uma vez você pode MD5sum os executáveis e bibliotecas na imagem e comparar com as versões originais para descobrir se eles se preocuparam em cobrir suas faixas.

    

Answer 3

Vamos ficar paranóicos! Primeiro de tudo, desligue este linux e use o comando dd para fazer uma cópia completa dos discos.

O sistema está diretamente conectado à internet? Se não, que bom, você pode começar a cheirar o tráfego, para que possamos determinar algumas coisas úteis. Se a resposta for sim, tente colocar alguma máquina entre ela e a internet. Por que não farejar diretamente dentro da máquina? Com um rootkit seria possível tornar-se invisível ao sniffing, e nossos esforços serão uma perda de tempo.

É altamente recomendável que você extraia todas as suas informações, códigos, bancos de dados e analise manualmente tudo para garantir que não haja backdoors nele.

Reconstrua uma máquina similar, com a mesma versão de cada lib, e então escaneie todo o sistema, calculando o hash de tudo, use SHA1 ou SHA2, com o MD5 podemos ter colisões facilmente calculadas, somos paranóicos, lembre-se disso! Compare as duas listas, além disso, tente detectar qualquer parâmetro incomum no grub / lilo, qualquer carregamento de módulo estranho.

Verifique também os usuários e as chaves ssh. Verifique se há bugs no código-fonte, por exemplo, ele pode executar o código como apache e deixar um backdoor para escalar privilégios para o usuário root.

Todas as verificações devem ser feitas usando as imagens do disco, em um ambiente offline.

Voltando à sua sessão de sniffing, tente detectar qualquer tráfego incomum. Se sua máquina foi comprometida, possivelmente ela será usada para algo ilegal, como DDoSing ou ser um pivô para outro ataque.

Depois de detectar de onde o invasor se conecta (aposto que ele usa o TOR) e como ele se conecta, você pode começar a rastreá-lo. Determine se é um script automatizado ou um usuário real que está controlando seu servidor. Você pode fazer o download e alterar o bash / sh / zsh ou qual shell seu invasor está usando para salvar os logs, mesmo que o usuário não ajuste a variável. Faça o mesmo com o SSH, altere o código para criar em outro lugar, um log com processos iniciados e logins. Se ele se conectar usando um backdoor (Isso é o que é mais provável), tente determinar como ele funciona e determine para que ele está usando seus sistemas.

Por que isso? Porque se ele está fazendo algo ilegal, mais cedo ou mais tarde alguém o localizará e o achará no caminho. A melhor maneira de evitar problemas sérios é obter evidências do que está acontecendo e, depois disso, tentar fechar esse ambiente e conseguir um bom advogado.