Descobrindo como um servidor invadido foi invadido

Question

Eu estava apenas navegando pelo site e encontrei esta pergunta: MEU servidor foi invadido EMERGÊNCIA . Basicamente, a pergunta diz: Meu servidor foi invadido. O que devo fazer?

A melhor resposta é excelente, mas levantou algumas questões em minha mente. Um dos passos sugeridos é:

Examine the 'attacked' systems to understand how the attacks succeeded in compromising your security. Make every effort to find out where the attacks "came from", so that you understand what problems you have and need to address to make your system safe in the future.

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

    

Answer 1

Vou começar dizendo isso, se você tiver SEM ARQUIVOS DE LOG , então há uma boa chance de que você NUNCA entenda 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 como os arquivos de log são importantes, você começa a entender o quanto é seguro mantê-los. É por isso que as empresas fazem e devem investir em Informações de segurança & Gerenciamento de eventos ou SIEM para breve.

Empoucaspalavras,correlacionandotodososseusarquivosdelogemeventosespecíficos(baseadosemtempoounão)podeserumatarefaextremamentedifícil.Apenasdêumaolhadanosseussyslogsdefirewallnomododedepuraçãosevocênãoacreditaemmim.Eissoésódeumaparelho!UmprocessoSIEMcolocaessesarquivosdelogemumasériedeeventoslógicosquetornammaisfácilentenderoqueaconteceu,muitomaisfácildeentender.

Paracomeçaraentendermelhorcomo,éútilestudar metodologias de penetração .

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

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

Também ajuda a ter um log parser e tornar-se proficiente com ele.

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

O

CERT tem um excelente guia sobre o que fazer após o computador ter sido invadido, notavelmente (que pertence diretamente à sua pergunta específica) a seção "Analisar a intrusão":

• Procure por modificações feitas no software do sistema e nos arquivos de configuração
• Procure por modificações nos dados
• Procure ferramentas e dados deixados pelo intruso
• Revisar arquivos de log
• Procure sinais de um sniffer de rede
• Verifique outros sistemas na sua rede
• Verifique os 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 de hosts e no Netstat
3. isso é uma tentativa de hack?
4. Como posso aprender Linux do ponto de vista de hacking ou segurança

Isso pode ser um processo extremamente complicado e complicado. A maioria das pessoas, inclusive eu, contrataria um consultor se ele se envolvesse mais do que os aparelhos SIEM poderiam montar.

E, aparentemente, se você quiser TOTALMENTE entender como seus sistemas foram invadidos, precisará gastar anos estudá-los e desistir mulheres

    

Answer 2

A resposta para um pouquinho pode ter um milhão de milhas de largura e alta, e desfazer o que aconteceu com um servidor hackeado pode ser quase uma forma de arte tanto quanto qualquer outra coisa, então vou dar pontos de partida e exemplos ao invés de um conjunto definitivo de etapas a seguir.

Uma coisa a ter em mente é que, depois de ter enfrentado uma invasão, você pode auditar o seu código, a administração / configuração do sistema e os procedimentos, sabendo que ali há uma fraqueza. Isso ajuda a motivar mais do que procurar por uma fraqueza teórica que pode ou não estar lá. Muitas vezes as pessoas colocam coisas on-line, sabendo que o código poderia ter sido auditado um pouco mais, se tivéssemos tempo; ou o sistema trancou um pouco mais firmemente, se não fosse tão inconveniente; ou procedimentos um pouco mais apertados, se não fosse um incômodo para o chefe se lembrar de senhas longas. Todos nós 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 (não comprometido), não apenas de servidores, mas de quaisquer firewalls, roteadores, etc, que também registram o tráfego. Existem também ferramentas como Nessus disponíveis que podem analisar um sistema e procurar pontos fracos.

Para softwares / framworks de terceiros, geralmente há guias de práticas recomendadas que podem ser usados para auditar sua implantação ou você pode prestar mais atenção às notícias de segurança e às programações de patch e descobrir algumas falhas que podem ter sido usadas.

Por último, a maioria das intrusões deixa um rastro ... se você tiver tempo e paciência para encontrá-lo. "Dirigir por" intrusões de script infantil ou invasões usando kits de ferramentas de hackers tendem a se concentrar em pontos fracos comuns e podem deixar um padrão que aponta você na direção certa. A coisa mais difícil de analisar pode ser uma intrusão manual dirigida (por exemplo, alguém não queria hackear "um" site, mas em vez disso queria hackear "seu" site especificamente), e essas, claro, são as coisas mais importantes para entender.

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

    

Answer 3

"Eu sei que você poderia procurar nos arquivos de log do servidor, mas como um invasor, a primeira coisa que eu faria seria apagar os arquivos de log."

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

Além dos logs do servidor comprometidos, ainda há 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)

Então, observar os registros ainda é uma das melhores coisas que podem ser feitas.

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

-Josh