Descobrindo como um servidor invadido foi invadido

Eu estava navegando pelo site e encontrei esta pergunta: Meu servidor foi invadido por EMERGENCY . Basicamente, a pergunta diz: Meu servidor foi hackeado. O que devo fazer?

A melhor resposta é excelente, mas levantou algumas questões em minha mente. Uma das etapas sugeridas é:

Examine os sistemas 'atacados' para entender como os ataques conseguiram comprometer sua segurança. Faça todos os esforços para descobrir de onde os ataques "vieram", para que você entenda quais problemas você tem e precisa resolver para tornar seu sistema seguro no futuro.

Eu não fiz nenhum trabalho de administrador do sistema, então não tenho idéia de como começar a fazer isso. Qual seria o primeiro passo? Eu sei que você poderia procurar nos arquivos de log do servidor, mas como invasor, a primeira coisa que eu faria seria apagá-los. Como você "entenderia" como os ataques foram bem-sucedidos?

Começarei dizendo isso, se você NÃO TEM ARQUIVOS DE LOG , existe uma chance razoavelmente boa de que você NUNCA entenderá onde ou como o ataque foi bem-sucedido. Mesmo com arquivos de log completos e adequados, pode ser extremamente difícil entender completamente quem, o quê, onde, quando, por que e como.

Assim, sabendo o quão importante os arquivos de log são, você começa a entender o quão seguro você tem para mantê-los. É por isso que as empresas investem e devem investir em Gerenciamento de Informações de Segurança e Eventos ou SIEM, abreviado.

Em poucas palavras, correlacionar todos os seus arquivos de log em eventos específicos (com base no tempo ou não) pode ser uma tarefa extremamente assustadora. Basta dar uma olhada nos syslogs do firewall no modo de depuração, se você não acredita em mim. E isso é apenas de um aparelho! Um processo SIEM coloca esses arquivos de log em uma série de eventos lógicos, o que facilita a compreensão do que aconteceu.

Para começar a entender melhor como, é útil estudar metodologias de penetração .

Também é útil saber como um vírus é escrito. Ou como escrever um rootkit .

Também pode ser extremamente benéfico configurar e estudar um honeypot .

Também ajuda a ter um analisador de log e se tornar proficiente com ele.

É útil reunir uma linha de base para sua rede e sistemas. O que é tráfego "normal" na sua situação versus tráfego "anormal"?

O CERT tem um excelente guia sobre o que fazer depois que o computador foi invadido, principalmente (que se refere diretamente à sua pergunta específica) na seção "Analisar a intrusão":

• Procure modificações feitas no software do sistema e nos arquivos de configuração
• Procure modificações nos dados
• Procure ferramentas e dados deixados para trás pelo invasor
• Revisar arquivos de log
• Procure sinais de um sniffer de rede
• Verifique outros sistemas na sua rede
• Verifique se há sistemas envolvidos ou afetados em sites remotos

Existem muitas perguntas semelhantes às suas que foram feitas no SF:

1. Como fazer um post-mortem de um hack de servidor
2. Itens estranhos no arquivo hosts e no Netstat
3. isso é uma tentativa de invasão?
4. Como posso aprender Linux do ponto de vista de hackers ou segurança

Este pode ser um processo extremamente complicado e envolvido. A maioria das pessoas, inclusive eu, contrataria um consultor se ele se envolvesse mais do que aquilo que meus equipamentos SIEM poderiam montar.

E, aparentemente, se você quiser entender TOTALMENTE como seus sistemas foram invadidos, terá que passar anos estudando-os e desistir de mulheres.

A resposta para isso pode ser de um milhão de quilômetros de largura e altura, e retirar o que aconteceu com um servidor invadido pode ser quase uma forma de arte tanto quanto qualquer outra coisa, então, novamente, darei pontos de partida e exemplos em vez de um conjunto definitivo de etapas a seguir.

Uma coisa a ter em mente é que, depois de enfrentar uma invasão, você pode auditar seu código, a administração / configuração e os procedimentos do sistema com o conhecimento de que definitivamente há uma fraqueza lá. Isso ajuda a motivar mais do que procurar uma fraqueza teórica que pode ou não estar presente. Muitas vezes, as pessoas colocam coisas online, sabendo que o código poderia ter sido auditado um pouco mais, se tivéssemos tempo; ou o sistema travou um pouco mais firmemente, se não fosse tão inconveniente; ou procedimentos tornados um pouco mais rígidos, se não fosse um incômodo para o chefe lembrar senhas longas. Todos sabemos onde estão nossos pontos fracos mais prováveis, então comece com eles.

Em um mundo ideal, você terá logs armazenados em um servidor syslog diferente (espero que não seja comprometido) , não apenas dos servidores, mas também de firewalls, roteadores etc. que também registrem tráfego. Também existem ferramentas como o Nessus disponíveis que podem analisar um sistema e procurar pontos fracos.

Para software / framworks de terceiros, geralmente há guias de práticas recomendadas que você pode usar para auditar sua implantação ou prestar mais atenção às notícias de segurança e agendas de patches e descobrir alguns buracos que podem ter sido usados.

Por fim, a maioria das invasões deixa um terreno baldio ... se você tiver tempo e paciência para encontrá-lo. As intrusões ou invasões de crianças com script "Dirija por" usando kits de ferramentas de hackers tendem a se concentrar em pontos fracos comuns e podem deixar um padrão que o direciona na direção certa. A coisa mais difícil de analisar pode ser uma intrusão direcionada manual (por exemplo, alguém não queria invadir "um" site, mas sim invadir "seu" site especificamente), e essas são, obviamente, as coisas mais importantes a serem entendidas.

Para alguém que realmente não sabe por onde começar (ou mesmo para pessoas experientes que têm outras funções), o primeiro passo é provavelmente contratar alguém com boa experiência nas etapas acima. Outra vantagem dessa abordagem é que eles analisarão sua configuração sem noções preconcebidas ou interesse pessoal nas respostas.

"Eu sei que você poderia procurar nos arquivos de log do servidor, mas como atacante, a primeira coisa que eu faria seria apagá-los."

Dependendo do tipo de comprometimento, o invasor pode não ter privilégios altos o suficiente no servidor comprometido para poder apagar logs. Também é uma prática recomendada manter os logs do servidor fora da caixa de correio em outro servidor, para evitar violações (exportadas automaticamente em determinados intervalos).

Além dos logs comprometidos do servidor, ainda existem logs de rede (firewall, roteador etc.), bem como logs de autenticação do serviço de diretório, se houver um (Active Directory, RADIUS, ect)

Portanto, analisar os logs ainda é uma das melhores coisas que podem ser feitas.

Ao lidar com uma caixa comprometida, peneirar logs é sempre uma das minhas principais formas de reunir o que aconteceu.

-Josh