Come fai a sapere che il tuo server è stato compromesso?

AGGIORNAMENTO

Vorrei controllare quanto segue:

1. Log. Se hai accesso come root, dovresti controllare cose come history che ti daranno la cronologia dei comandi e i file di registro in /var/logs .

2. Baseline. Se si dispone di una linea di base come hash di file con cui lavorare per i file di applicazione e di sistema, ciò sarà di grande aiuto. Puoi anche utilizzare i backup per confrontare uno stato precedente. Se si utilizza un backup per confrontare i file, utilizzare un po 'più vecchio, se possibile. Il sito potrebbe essere stato compromesso un po 'prima ed è solo ora che il reindirizzamento è stato attivato.

3. Controlla tutti gli include. I file potrebbero non essere sul tuo server. Possono essere inclusi script come <script src=”http://baddomain.com/s.js” /> o iframe tag di tipo. Inoltre, non escludere immagini, PDF di Flash (SWF), file video. È un trucco abbastanza comune incorporare collegamenti a file di un diverso tipo di contenuto. Ti suggerisco di controllarli a mano, in particolare all'inizio e alla fine di un file. Il file potrebbe essere completamente un link / html / javascript o potrebbe essere un file di immagine legittimo con un link in coda alla fine del file.

4. Verifica date, dimensioni e permessi di file insoliti, ad es. 777.

5. Controlla i lavori cron per lavori insoliti. Qualcuno che sta compromettendo un sistema lascerà spesso la porta di servizio per rientrare ancora e ancora. Cron è un modo molto popolare per farlo se sono riusciti ad arrivare così lontano.

6. Verifica l'assenza di file, potresti non essere in grado di accedere ai registri, ma l'assenza di essi è ugualmente un segnale informatico che qualcuno ha ripulito da solo.

7. Utilizza i motori di ricerca. Non sorprende che i motori di ricerca siano bravi a trovare tutto. Utilizza le direttive come site: ad es. site:yoursitehere.com baddomain.com vedi se ottieni qualche hit.

8. Spesso un link o un reindirizzamento verrà offuscato per cui un lungo codice javascript con variabili a lettera singola dovrebbe essere analizzato attentamente.

9. Effettua un'acquisizione di pacchetti con uno strumento come Wireshark o tcpdump da una workstation sicura al sito. Salvalo in un file e cerca nel file una parte dell'URL.

10. Controlla i record del database che possono essere interrogati o aggiornati. Il link potrebbe essere iniettato nel database non in PHP.

11. Non escludere la workstation del cliente. Utilizzare uno scanner antivirus online gratuito, se necessario. Controlla anche nslookup e guarda a cosa risolve. Controlla le estensioni del browser, cancella la cache e controlla i file hosts .

Per ripulirlo (se sei compromesso) devi davvero tornare al bare metal e reinstallare. È doloroso ma è davvero l'unico modo per essere sicuro di averne preso tutto.

Per prevenirlo in futuro dovresti fare quanto segue (anche se potresti già farne alcuni):

1. Indurisci i server, incluso l'utilizzo dei consigli dei fornitori su configurazioni sicure, utilizzando software aggiornato. Applica rigorosi controlli di sicurezza quali autorizzazioni, criteri per le password. Vedi anche consulenza per host condivisi di permessi per cartelle e file .

2. Implementare procedure di controllo della qualità come test su ambienti a bassa sicurezza, revisione del codice e test.

3. Verifica la vulnerabilità della tua applicazione web / sito web da un tester certificato professionista almeno una volta. Cerca tester CE-Council, ISO 27001 e PCI certificati. link

4. Controlla OWASP www.owasp.org e link per le risorse di sicurezza delle applicazioni Web.

5. Utilizzare gli strumenti di Intrusion Prevention System (IPS). Tuttavia, a seconda del tuo provider di hosting potresti avere delle limitazioni su cosa puoi usare. Gli strumenti IPS basati su host dovrebbero essere ok se hai una macchina virtuale dedicata.

Spero che questo aiuti. Altrimenti potresti fornire ulteriori informazioni sui sistemi che stai utilizzando?

Come ha detto @Dgarcia, un metodo rapido consiste nell'utilizzare qualcosa come Tripwire o altri strumenti che monitorano i file o gli hash dei file per verificare le modifiche. Questo funziona per identificare server compromessi da molti tipi di attacco.

1. Potrebbe non funzionare per quelli in cui è stato installato un rootkit che contrasta questo processo.
2. Non funzionerà per i server che sono caduti preda di un compromesso solo memoria o che non tocchi i file che stai monitorando.

Per 1, l'unica opzione è una ricostruzione ex novo

Per 2, l'opzione migliore è una ricostruzione da zero, poiché qualsiasi compromissione potrebbe implementare backdoor che interromperà qualsiasi cosa tu cerchi di correggere, ma altri passi potrebbero essere utili:

• controlla le versioni del tuo server web e php e usale per cercare in un elenco di consulenti per exploit conosciuti - questo ti aiuterà a identificare le aree che potrebbero essere state compromesse. Poi
• controlla il codice dell'applicazione web
• controlla le configurazioni del tuo webserver
• controlla la macchina del cliente (per file hosts, DNS ecc.) in quanto potrebbe effettivamente essere il problema

Questa è una domanda difficile a cui rispondere perché è così ampia. Ci sono due categorie di "hack" nel mio libro: minori e seri. Classificherei un rootkit nella categoria seria e il tuo attacco di script medio è minore. Mentre con attacchi minori puoi ripulirli, non puoi essere sicuro al 100% di averli rimossi o chiuso tutti gli accessi per ripetere l'attacco ma puoi essere sicuro al 99% analizzando l'attacco per fattori chiave come " Questa persona era un buon programmatore? " e "Qual era l'intento della persona?" I rootkit sono affari cattivi. La rimozione di un rootkit richiede una cancellazione completa e il ripristino. Rilevarne uno da remoto è quasi impossibile: devi avere accesso fisico alla macchina e un disco di avvio in mano per essere certi.

Ancora più importante è la prevenzione. Il detto "un'oncia di prevenzione vale un chilo di cura" è completamente vero in questo contesto. Installa un software che ti consente di monitorare vari aspetti del sistema e invia rapporti giornalieri o anche orari. Tripwire è stato menzionato, ma ci sono anche altri strumenti. Consiglio di utilizzare un paio di strumenti diversi: quelli nostrani sono più difficili da individuare e non sono difficili da scrivere. Vuoi costruire una solida difesa e limitare l'accesso al sistema. Non lasciare che chiunque nel mondo abbia accesso alla porta SSH (almeno limitarlo per indirizzo IP / piccolo intervallo di IP). Attaccare un firewall dedicato davanti a ciascun server in modo da avere un ulteriore livello di protezione. Non vuoi lasciare che la scatola stessa sia l'unica linea di difesa. Gestisci solo i dati critici con il server su SSH / SSL, quindi tutto è crittografato e privo di sguardi indiscreti. Non gestire mai i tuoi server da reti WiFi aperte.

Molti siti utilizzano MySQL o un database simile. Rilevare elementi come attacchi XSS o altri dati non autorizzati in un database non è facile perché ci sono problemi dipendenti dallo schema. Non ho visto nessuna soluzione per questo problema, ma non dubiterei che esistano.

Un metodo veloce è quello di avere l'md5 di tutti i file che sai essere sani. Se sospetti che il tuo sito si stia comportando male o come un'ispezione regolare, puoi eseguire il controllo dei file. Se uno qualsiasi di md5 non corrisponde, puoi diffare i file e esaminare le modifiche.

Ovviamente questo non funziona con i file dinamici: registri, database dump, ecc. Se non riesci a tenere traccia delle modifiche.

Esistono, naturalmente, più metodi (ispezioni registri ...) e prevenzioni, ma questo è un modo facile e veloce.