Meu servidor linux foi invadido. Como descubro como e quando foi feito?

Question

Eu tenho um servidor doméstico executando uma distribuição Ubuntu desktop. Eu encontrei isso no meu crontab

* * * * * /home/username/ /.access.log/y2kupdate >/dev/null 2>&1

e quando procuramos nesse diretório (o espaço após o nome de usuário / é um nome de diretório) eu encontrei muitos scripts que obviamente estão fazendo algo que eles não deveriam.

Antes de limpar o computador e reinstalar o material, gostaria de descobrir o que causou a violação de segurança e quando isso foi feito. Então eu não abro o mesmo buraco novamente.

Quais arquivos de log devo procurar? Os únicos servidores que eu sei que estão rodando no computador são o sshd e o lighttpd.

O que devo fazer para detectar se coisas assim acontecem novamente?

    

Answer 1

Primeiro, verifique se o computador está desconectado de qualquer rede.
Em segundo lugar, certifique-se de obter todos os dados importantes das unidades antes de inicializar o sistema operacional hackeado novamente.

Comece verificando os carimbos de hora nos arquivos em questão. Muitas vezes eles são precisos.
Faça referência cruzada àqueles com o registro httpd e o log de autenticação, se não tiverem sido apagados. Se um outro o outro foi apagado, você pode apostar que era o meio de entrada. Se eles ainda estiverem intactos, você poderá coletar mais informações sobre como eles chegaram do log.

Se eles estão todos apagados, você está muito ferrado. Provavelmente, levaria mais tempo para descobrir o que aconteceu do que vale a pena.

Você mencionou que esses dois serviços estavam em execução; havia um bom firewall para evitar que todo o restante fosse acessado? Você permitiu o SSH na porta 22; é seu login razoavelmente fácil de adivinhar; você permitiu logins de senha; você tinha algum tipo de limitação de taxa real para logins de senha? Você tem algum software adicional instalado com o lighttpd? perl; php; cgi; um CMS ou similar? Você estava executando uma versão atualizada de todo o software? você assina notificações de segurança para todo o software que você executa e avalia cuidadosamente todas as notificações para ver se elas se aplicam ao software que você executa / expõe ao público?

    

Answer 2

Este é um tipo de tópico em si mesmo; você pode pesquisar no google forux for Linux para mais informações. Basicamente, você teria que primeiro fazer uma imagem de suas unidades para análise off-line, depois limpar o computador e instalá-lo a partir de uma placa limpa.

E lembre-se de todos os incidentes. Qualquer pessoa que usasse o computador poderia ter suas senhas comprometidas. Mude as senhas, mantenha-as off-line, etc. até chegar em uma "sala limpa" (VM isolada).

Caso contrário, há muitos logs de verificação (que podem ser falsificados) e verificação de seus aplicativos (scripts php? Bancos de dados? Atualizados para as correções mais recentes? outros usuários que fornecem senhas?)

Não há, literalmente, uma maneira fácil de responder à sua pergunta, já que você precisaria fazer um trabalho forense no servidor e verificar se há falhas. Você pode usar algumas ferramentas automatizadas, mas lembre-se de que, se o invasor tiver privativas de raiz, você não poderá mais confiar nos binários do sistema e não poderá confiar nos registros.

Quanto a ataques futuros, dependendo de quão seguro você deseja, você pode começar redirecionando seus logs para um sistema que é usado apenas para salvar os logs do sistema. Nenhum outro acesso, para reduzir a pegada de ataque.

Você também executaria um software de soma de verificação no seu sistema, como o Tripwire, para verificar a integridade de seus arquivos.

E, claro, mantenha-se atualizado com as atualizações e execute o software de verificação que verifica os rootkits.

Mais uma vez, a segurança não é uma coisa de lance-a-chave. Pode ser uma especialidade em si também. A segurança em camadas pode ser tão rígida quanto a verificação de hosts / IPs que não pertencem à sua rede, criptografando todo o acesso ao sistema, enviando logs diários das alterações encontradas em seu sistema e configurando um honeypot em sua rede para procurar por atividades estranhas (por que meu servidor está tentando se conectar à porta 25 no honeypot)?

Primeiramente, se você deseja verificar a atividade, obtenha a imagem do disco e reinstale o software do servidor. Do princípio. Os binários do servidor não são mais confiáveis.

EDIT - algumas outras coisas que me ocorrem desde que você está executando o SSH - instale o denyhosts. Ele pode ser configurado para que ataques automatizados contra seu sistema no SSHD sejam bloqueados após um número X de tentativas. Ele também pode ser configurado para atualizar de outros servidores denyhost em uma "nuvem" para compartilhar IPs bloqueados para ajudar a minimizar ataques automatizados. Você também pode mover a porta que está escutando; muitas pessoas apontam que é apenas segurança através da obscuridade, mas dado o número de varreduras de bots, isso reduz significativamente as tentativas aleatórias de invasão.