Como analisar logs depois que o site foi invadido

Question

Um dos nossos projetos da web foi invadido. O Malefactor alterou alguns arquivos de modelo no projeto e um arquivo principal da estrutura da web (é um dos famosos frameworks php). Encontramos todos os arquivos corrompidos pelo git e os revertemos. Então agora eu preciso encontrar o ponto fraco.

Com alta probabilidade, podemos dizer que não é a abdução de senha ftp ou ssh. O especialista de suporte do provedor de hospedagem (após a análise de logs) disse que era a falha de segurança em nosso código.

Minhas perguntas:

1) Quais ferramentas devo usar para revisar o acesso e os logs de erro do Apache? (Nossa distribuição do servidor é Debian).

2) Você pode escrever dicas de detecção de linhas suspeitas em logs? Talvez tutoriais ou iniciadores de algumas expressões ou técnicas úteis?

3) Como separar "comportamento normal do usuário" de suspeito em logs.

4) Existe alguma maneira de prevenir ataques no Apache?

Obrigado pela sua ajuda.

    

Answer 1

Como o HopelessNOOb, recomendo obter ajuda profissional com isso.

Quando você sabe que um sistema foi comprometido, você não pode confiar em nenhum dado armazenado nele. Além disso, se o compromisso foi via HTTP, então provavelmente não há informações suficientes nos logs padrão para poder isolar o que ocorreu. É por isso que as pessoas que levam a sério a segurança do servidor da Web usarão algo como mod_security para obter logs muito mais detalhados e executar um IDS baseado em host para detectar comprometimentos.

The support specialist of hosting provider (after logs analysis) said that it was the security hole in our code

Se ele / ela puder fazer essa afirmação, ele / ela já deve saber a resposta para sua pergunta - isso ou a reivindicação não é fundamentada e eles realmente querem dizer que não encontraram nada de errado em suas coisas.

Seu objetivo deve ser tornar seu site on-line e seguro. Para tornar um site seguro, você precisa conectar todos os buracos - mas, para comprometer um site, você só precisa encontrar um furo: você sabe que tem pelo menos um furo no seu site, mas precisa consertar qualquer que existem - o que significa que você precisa adotar uma abordagem muito diferente para a segurança do seu site. Mesmo que você consiga identificar e corrigir a vulnerabilidade que foi explorada desta vez, a evidência mostra que você não tem os processos e habilidades para ter qualquer tipo de confiança de que este foi um incidente isolado.

    

Answer 2

Você recebeu uma boa resposta de JennyD, mas eu sugiro uma abordagem diferente.

Contrate um especialista.

Existem especialistas em segurança que realmente fazem isso para ganhar a vida e farão um trabalho muito melhor e mais rápido de determinar como você foi hackeado e onde você ainda está vulnerável. Confira o mercado de segurança local, e eu ficaria surpreso se você não puder encontrar um preço decente em serviços de consultoria para analisar os logs para você, assim como executar pelo menos uma varredura básica de penetração e vulnerabilidade em seu sistema (s ). Você terá uma visão muito mais completa do que precisa fazer para se proteger, e poderá voltar a gastar seu tempo em suas áreas de especialização.

    

Answer 3

1) Você pode dar uma olhada em estes links para alguns software para ajudá-lo, embora eu não tenha usado a maioria deles sozinho. Mas, como você tem carimbos de data e hora nos arquivos que foram alterados, comece examinando os arquivos de log dessas datas e horas. Grep para o nome do arquivo de um dos arquivos alterados; Isso deve dar-lhe o endereço IP do malfeitor, e então você pode começar a fazer isso.

2 e 3) A primeira coisa que você precisa fazer é descobrir o que é normal para o seu próprio site. Uma maneira de fazer isso é ter uma ferramenta de análise padrão, como awstat, passar por seus logs diariamente. Seu principal problema agora parece ser que você não sabe o que é normal para o seu site, então você não tem como saber o que é anormal.

4) Existem maneiras de prevenir alguns ataques, embora seja uma corrida armamentista. Mas apenas removendo as explorações mais comuns, você terá menos probabilidade de ser o alvo de um ataque aleatório. Você deve se certificar de que sua instalação possui os últimos patches de segurança para o seu sistema operacional, para o apache e para o php. Você também deve dar uma olhada em mod_security , que permite que você registre atividades suspeitas e, por exemplo, exigir que um cliente envie cabeçalhos como User-Agent, que muitas ferramentas de crack não possuem.

Além disso, aconselho que você considere enviar seus logs, especialmente logs de erros e quaisquer logs mod_security, para outro servidor, se possível, para que, mesmo que alguém consiga entrar no seu servidor, eles não consigam editar o arquivo. arquivos de log para ocultar suas faixas.

    

Answer 4

Além da orientação aqui, esses tópicos são discutidos em profundidade na troca de pilha de segurança. Faça uma leitura da pergunta sobre o endurecimento do Apache: link

    

Answer 5

Você pode querer verificar o LORG - link - uma ferramenta PHP-CLI (GPL) projetada para forenscis pós-ataque de Apache access_logs. Ele usa vários métodos (baseados em assinatura, estatísticas, baseados em aprendizado) para detectar ataques contra aplicativos da Web em arquivos de log HTTPD.

Ele tenta agrupar essas atividades suspeitas em sessões e aplica técnicas de detecção de robôs (normalmente, um invasor pode executar uma verificação automatizada e depois voltar mais tarde para verificar manualmente o que encontrou). Além disso, ele usa geomapping e DNSBL-lookups para ver se os ataques se originam de um determinado país ou botnet.

Depois, você pode escolher vários mecanismos para determinar se um ataque foi bem-sucedido: replays ativos e correspondência para assinaturas, códigos de resposta HTTP ou periferia no tamanho das respostas (o campo de bytes enviados).

Obviamente, se os arquivos de log foram alterados ou apagados, as coisas podem ficar difíceis (o LORG tem a opção de realizar uma simples verificação de adulteração para encontrar janelas de tempo extraordinárias sem atividade, mas isso não ajudará muito). / p>

Quanto à prevenção de ataques, eu usaria o mod_security (se o seu provedor de hospedagem permitir).