Come analizzare i registri dopo che il sito è stato hackato

Uno dei nostri progetti web è stato hackato. Malefactor ha cambiato alcuni file di template nel progetto e 1 file di base del framework web (è uno dei famosi frammenti di php). Abbiamo trovato tutti i file corrotti da git e li abbiamo restituiti. Adesso devo trovare il punto debole.

Con alta probabilità possiamo dire che non è il rapimento di password di ftp o ssh. Lo specialist di supporto del provider di hosting (dopo l'analisi dei log) ha dichiarato che era il buco di sicurezza nel nostro codice.

Le mie domande:

1) Quali strumenti dovrei usare per esaminare i registri di accesso e di errori di Apache? (Il nostro server distro è Debian).

2) Puoi scrivere suggerimenti di rilevamento delle linee sospette nei registri? Forse esercitazioni o primer di alcuni regexps o tecniche utili?

3) Come separare "il comportmento normale dell'utente" dai sospetti nei registri.

4) C'è qualche modo per prevenire gli attacchi in Apache?

Grazie per l'aiuto.

  • Applicare automaticamente aggiornamenti di protezione per AWS Elastic Beanstalk
  • Qualcuno ha eseguito un confronto oggettivo di Nessus e Skipfish
  • Quanto è sicuro limitare l'accesso al sito tramite IP?
  • Solo Secure SSH Server SSH Server
  • Vista viva dei comandi di shell Linux eseguiti da un altro utente?
  • Come posso scaricare un file eseguibile all'interno della networking aziendale quando è stato bloccato?
  • L'attacco sofisticato del dictionary di Grokking
  • iptables: lo scanner sa se si esegue pacchetti DROP?
  • 5 Solutions collect form web for “Come analizzare i registri dopo che il sito è stato hackato”

    Come HopelessNOOb, mi piacerebbe avere qualche aiuto professionale con questo.

    Quando si sa che un sistema è stato compromesso non si può fare affidamento su alcun dato memorizzato su di esso. Inoltre, se il compromesso era tramite HTTP, probabilmente non ci sono sufficienti informazioni nei registri standard per essere in grado di isolare ciò che è avvenuto. Questo è il motivo per cui le persone che sono seri sulla sicurezza del webserver utilizzeranno qualcosa come mod_security per get registri molto più dettagliati e eseguire un IDS basato su host per individuare compromessi.

    Lo specialist di supporto del provider di hosting (dopo l'analisi dei log) ha dichiarato che era il buco di sicurezza nel nostro codice

    Se lui / lei può fare tale affermazione allora deve sapere già la risposta alla tua domanda – che o la domanda non è giustificata e veramente significa dire che non hanno trovato nulla di sbagliato con la loro roba.

    Il tuo objective dovrebbe essere quello di get il tuo sito online e sicuro. Per rendere sicuro un sito, è necessario colbind tutti i fori, ma per compromettere un sito solo occorre trovare un buco: sai che hai alless un buco nel tuo sito, ma devi risolvere qualsiasi cosa che esiste – bisogno di prendere un approccio molto diverso per la sicurezza del tuo sito. Anche voi possiamo identificare e risolvere la vulnerabilità che è stata sfruttata questa volta, le prove dimostrano che non hai i processi e le competenze in atto per avere alcuna fiducia che questo sia un incidente isolato.

    Hai una buona risposta da JennyD, ma suggerirei un approccio diverso.

    Noleggiare un esperto.

    Ci sono esperti in materia di sicurezza che effettivamente fanno questo per vivere e faranno un lavoro molto migliore e molto più veloce per determinare come sei stato attaccato e where sei ancora vulnerabile. Controlla il mercato della sicurezza locale e sarò sorpreso se non riesci a trovare un prezzo decente per un servizio di consulenza per analizzare i registri per te, oltre a eseguire alless una scansione di penetrazione e vulnerabilità di base sul tuo sistema ). Otterrai un quadro molto più completo di quello che devi fare per assicurarvi, e sarai in grado di tornare a trascorrere il tuo tempo nelle tue aree di competenza.

    1) Potete dare un'occhiata a questi collegamenti per alcuni software per aiutarti, anche se non ho usato la maggior parte di loro. Ma dato che hai i timestamp sui file modificati, cominciate a guardare i file di registro per quelle date e tempo. Grep per il nome del file di uno dei file modificati; che dovrebbe darti l'indirizzo IP del fattore malfattore, e quindi puoi iniziare a catturare per questo.

    2 e 3) La prima cosa che devi fare è scoprire cosa è normale per il tuo sito. Un modo per farlo è quello di avere uno strumento di analisi standard, come ad esempio awstat, passare quotidianamente i tuoi registri. Il tuo problema principale sembra essere che non sai cosa è normale per il tuo sito, quindi non hai modo di sapere cosa è anormale.

    4) Ci sono modi per prevenire alcuni attacchi, anche se naturalmente si tratta di una corsa agli armamenti. Ma solo rimuovendo gli exploit più comuni, farai molto less probabilità che tu sia il bersaglio di un attacco random. È necessario assicurarsi che l'installazione disponga delle ultime patch di protezione per il proprio sistema operativo, per apache e per php. Dovresti anche dare un'occhiata a mod_security , che consente di registrare l'attività sospetta e, ad esempio, richiedere che un client invii intestazioni come User-Agent, che molti strumenti crack non lo fanno.

    Inoltre, ti consiglierei di considerare l'invio dei tuoi registri, in particolare i registri degli errori e tutti i registri di mod_security, ad un altro server, se ansible, in modo che anche se qualcuno riesce a entrare nel tuo server non sarà in grado di modificare i file di registro hide le loro tracce.

    Oltre alla guida qui, questi argomenti sono discussi in dettaglio oltre allo scambio di stack di sicurezza. Leggete la domanda sull'erogazione di Apache: https://security.stackexchange.com/questions/77/485

    Potresti voler verificare LORG – https://github.com/jensvoid/lorg – uno strumento PHP-CLI (GPL) progettato per il forenscis post-attacco di accesso_logs di Apache. Utilizza diversi methods (basati su firme, statistiche, basati sull'apprendimento) per individuare gli attacchi contro le applicazioni web nei file di registro HTTPD.

    Tenta di raggruppare le attività sospette in sessioni e applica tecniche di individuazione del robot (in genere, un aggressore può eseguire una scansione automatizzata e tornare più tardi per verificare manualmente ciò che ha trovato). Inoltre, utilizza geomapping e DNSBL-lookups per vedere se gli attacchi sono provenienti da un determinato paese o botnet.

    Successivamente è ansible scegliere diversi meccanismi per determinare se un attacco è riuscito: ripetizioni attive e corrispondenza per le firme, codici di risposta HTTP o outlyingness nelle size delle risposte (il field inviato byte).

    Ovviamente, se i file di registro sono stati modificati o eliminati, le cose potrebbero diventare difficili (LORG ha la possibilità di eseguire un semplice controllo tamper per trovare windows di tempo straordinarie senza alcuna attività, ma questo non ti aiuterà davvero).

    Per quanto riguarda la prevenzione degli attacchi, vorrei andare con mod_security (se il tuo provider di servizi lo consente).

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.