Como encontrar vazamento de segurança após uma invasão de skynet?

Question

Alguns dias atrás, o servidor de um amigo teve uma invasão. O ataque instalou um novo daemon SSH que permite a entrada de qualquer conta válida, sem fornecer uma senha válida. Após o login, cada conta recebeu automaticamente permissões de root e o servidor cumprimentou da seguinte forma:

O ataque também removeu as entradas do syslog que mostraram a intrusão (nós descobrimos isso com o log do syslog) e alterou o caminho do local do pacote Debian em /etc/apt/sources.list .

O servidor é executado sob o Debian Etch e não estava atualizado durante o ataque: o Apache / PHP não tinha todas as atualizações de segurança instaladas. Achamos que a intrusão poderia ter acontecido por causa dessas atualizações ausentes, mas na verdade não temos certeza. Durante o dia antes do ataque, instalamos o Wordpress 3.0.1; mas não sabemos se a instalação do Wordpress foi ou não um abridor de portas.

Existe alguma maneira de descobrir qual vazamento de segurança no servidor permitiu a invasão?

    

Answer 1

Depois que um invasor ganha raiz, muitas vezes é difícil dizer como ele entrou porque pode modificar o sistema, incluindo os registros. A menos que você tenha logs sendo transferidos para outro sistema pela rede, você pode estar sem sorte - especialmente porque você mencionou os logs sendo modificados.

Obviamente, a lição aprendida é que você precisa manter-se atualizado sobre patches. Nós aplicamos patches normalmente em um dia deles sendo liberados através do yum / apt-get.

Observe que um ataque contra o PHP, o Apache ou o Wordpress provavelmente teria dado apenas privilégios de servidor da web ao invasor. Mas parece da sua descrição que eles definitivamente tiveram raiz. Então, se eles conseguissem entrar em um aplicativo da Web, havia outro comprometimento para permitir que eles passassem do Apache para o root. Mas também estou me perguntando se eles entraram por meio de uma senha de root fraca no SSH, etc ...

No entanto, saber o método para atacá-lo provavelmente não permitirá que você o limpe. A máquina está comprometida muito seriamente neste ponto, a partir de sua descrição, e sua melhor opção é instalar um novo sistema operacional a partir do zero e configurar o sistema novamente. Examine todos os dados e softwares trazidos da caixa antiga. É MUITO difícil consertar uma caixa comprometida.

De qualquer forma, para responder à sua pergunta sobre se há alguma maneira de descobrir, aqui estão alguns lugares comuns para procurar o que aconteceu:

• / var / log / syslog ou / var / log / messages - procure quando o ataque pode ter ocorrido, possivelmente por falhas no log ou atividade que você não consegue explicar.
• Outros registros talvez não tenham apagado como / var / log / security
• .bash_history de várias contas, incluindo raiz e o servidor da web. Isso pode fornecer os comandos que eles executaram ou informações sobre o que foi feito.
• Procure processos em execução que você não reconhece ou processos que você reconhece que podem estar sendo executados a partir de diretórios ou nomes incomuns. Olhe para / proc / $ PID e / proc / $ PID / fd dos vários IDs de processo ($ PID) dos processos que você vê em execução.
• Talvez o "último" diga alguma coisa, mas eles provavelmente acabaram com isso.
• O rkhunter pode ajudar a informar o que está comprometido no sistema e ajudar a encontrar onde você pode procurar mais informações.
• Os logs do Apache podem mostrar alguma indicação de atividade incomum, mas geralmente é difícil filtrar os ataques que você obtém o tempo todo daquele que realmente quebrou o sistema.

Grande parte deste trabalho é uma correlação cruzada séria entre diferentes arquivos de log para descobrir o que é interessante e o que é apenas ruído.

Fazer esse tipo de investigação não é um trabalho rápido. É provável que demore 4 ou mais horas, especialmente se for a primeira vez que você faz uma.

    

Answer 2

Você provavelmente está sem sorte, a menos que tenha algum tipo de registro remoto.

Eu acho que é melhor descrever isso como "lição aprendida", reinstalar o sistema a partir do zero (sério, não pule esse passo!), e então manter o novo sistema corrigido.

Na minha experiência, é muito melhor ter atualizações automáticas e correr o risco de ter que limpar depois de um patch automatizado ruim do que fazer atualizações manualmente e arriscar ficar para trás e isso acontecer. No primeiro caso, no caso muito raro de um patch de fornecedor / distro, normalmente você pode consertar as coisas com poucos minutos de trabalho na pior das hipóteses. Com um comprometimento do sistema, é uma reconstrução completa e muito tempo perdido.