it-swarm.dev

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

Di recente ho aiutato un client a cui era stato hackerato il server. Gli hacker hanno aggiunto un po 'PHP nell'intestazione della home page che reindirizza l'utente a un sito Web porno - ma solo se provenivano da Google. Ciò ha reso leggermente più difficile per il client individuare. vedrebbe bene il sito Web. Solo i nuovi visitatori del sito Web di Google verrebbero indirizzati al sito porno.

Ieri sera è accaduto qualcosa di simile a un altro cliente. Ho pensato che fosse un trucco simile, ma quando ho controllato la base di codice non sono riuscito a trovare alcun codice dannoso. Il suo chrome reindirizza dal sito Web dei client a www(dot)pc-site(dot)com. Non riesco a replicare questo comportamento. Immagino sia possibile che il codice dannoso venga aggiunto e rimosso. Quindi ho bisogno di un modo più completo per capire se il server è stato violato.

Solo 2 sviluppatori hanno accesso a questo server dedicato (e alla società di hosting Rackspace). Il server è Red Hat Linux.

Quali sono i passaggi che devo seguire per scoprire se il server è stato violato?

45
Boz

[~ ~ #] aggiornato [~ ~ #]

Vorrei controllare quanto segue:

  1. Registri. 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 hai una linea di base come hash di file con cui lavorare per file di applicazioni e di sistema, questo ti aiuterà molto. È inoltre possibile utilizzare i backup per confrontare uno stato precedente. Se si utilizza un backup per confrontare i file, se possibile, utilizzare uno leggermente più vecchio. Il sito potrebbe essere stato compromesso da un po 'di tempo ed è solo ora che il reindirizzamento è stato attivato.

  3. Controlla eventuali include. I file potrebbero non essere sul tuo server. Possono essere script inclusi 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 diverso tipo di contenuto. Suggerirei di ispezionarli a mano in particolare all'inizio e alla fine di un file. Il file può essere completamente un collegamento/html/javascript o può essere un file di immagine legittimo con un collegamento alla fine del file.

  4. Verifica la presenza di date, dimensioni e autorizzazioni di file insolite, ad es. 777.

  5. Controlla i lavori cron per lavori insoliti. Qualcuno che compromette un sistema spesso lascia una porta sul retro per rientrare ancora e ancora. Cron è un modo molto popolare per farlo se sono riusciti ad arrivare così lontano.

  6. Controlla l'assenza di file, potresti non essere in grado di accedere ai registri, ma l'assenza di questi è anche un segnale di coda che qualcuno ha ripulito dopo se stesso.

  7. Usa i motori di ricerca. I motori di ricerca non sorprendono nel trovare tutto. Usa direttive come site: per esempio. site:yoursitehere.com baddomain.com vedi se riscontri dei risultati.

  8. Spesso viene offuscato un collegamento o un reindirizzamento, pertanto è necessario analizzare attentamente il codice javascript con variabili a lettera singola.

  9. Esegui 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. Controllare i record del database che possono essere interrogati o aggiornati. Il collegamento potrebbe essere inserito nel database e non nel PHP.

  11. Non escludere la workstation del client. Utilizzare uno scanner antivirus online gratuito, se necessario. Controlla anche nslookup e vedi cosa si risolve. Controlla le estensioni del browser, svuota la cache e controlla hosts file.

Per ripulirlo (se si è compromessi) è davvero necessario tornare a bare metal e reinstallare. È doloroso ma è davvero l'unico modo per essere sicuri di avere tutto.

Per prevenirlo in futuro dovresti fare quanto segue (anche se potresti già aver fatto alcuni di questi):

  1. Indurire i server, incluso l'utilizzo dei consigli del fornitore su configurazioni sicure, utilizzando software aggiornato. Applicare uno stretto controllo di sicurezza come autorizzazioni, criteri password. Vedi anche consiglio dell'host condiviso con permesso di cartella e file .

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

  3. Far testare la vulnerabilità dell'applicazione Web/del sito Web da un tester certificato professionista almeno una volta. Cerca tester certificati CE-Council, ISO 27001 e PCI. http://www.eccouncil.org/certification/licensed_penetration_tester.aspx

  4. Controlla OWASP www.owasp.org e http://phpsec.org/projects/guide/2.html per le risorse di sicurezza delle applicazioni web.

  5. Utilizzare gli strumenti IPS (Intrusion Prevention System). Tuttavia, a seconda del provider di hosting, potresti avere delle limitazioni su ciò che puoi utilizzare. Host based IPS dovrebbero essere ok se si dispone di una macchina virtuale dedicata.

Spero che aiuti. Altrimenti forse potresti fornire maggiori informazioni sui sistemi in esecuzione?

45
Bernie White

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

  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 in preda a un compromesso della sola memoria o che non tocca i file che si stanno monitorando.

Per 1, l'unica opzione è una ricostruzione da zero

Per 2, la tua migliore opzione è una ricostruzione da zero, poiché qualsiasi compromesso potrebbe implementare backdoor che spezzerebbero qualsiasi cosa tu cerchi di risolvere, ma altri passaggi potrebbero essere utili:

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

Questa è una domanda difficile a cui rispondere perché è così ampia. Nel mio libro ci sono due categorie di "hack": minore e serio. Classificherei un rootkit nella categoria grave e il tuo attacco di iniezione di script medio come 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'intenzione della persona?" I rootkit sono cattivi affari. La rimozione di un rootkit richiede una cancellazione e un ripristino completi. Rilevarne uno da remoto è quasi impossibile: devi essere certo di avere accesso fisico alla macchina e un disco di avvio in mano.

Ancora più importante è la prevenzione. Il motto "un'oncia di prevenzione vale un chilo di cura" è del tutto vero in questo contesto. Installa un software che ti consenta di monitorare vari aspetti del sistema e di inviare rapporti giornalieri o anche orari. È stato menzionato Tripwire, ma ci sono anche altri strumenti là fuori. Consiglio di utilizzare un paio di strumenti diversi: quelli locali sono più difficili da individuare e non difficili da creare. Volete costruire una solida difesa e limitare l'accesso al sistema. Non lasciare che nessuno al mondo abbia accesso alla porta SSH (almeno limitalo per indirizzo IP/intervallo ridotto di IP). Attacca un firewall dedicato davanti a ciascun server in modo che vi sia un ulteriore livello di protezione. Non vuoi lasciare che la scatola stessa sia l'unica linea di difesa. Gestisci i dati critici solo con il server su SSH/SSL in modo che tutto sia 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 cose come attacchi XSS o altri dati non autorizzati in un database non è facile perché ci sono problemi dipendenti dallo schema. Non ho visto alcuna soluzione per questo problema, ma non dubiterei che esistano.

6
Linders

Un metodo veloce è avere il md5 di tutti i file che conosci sono integri. Se sospetti che il tuo sito si stia comportando male o come ispezione regolare puoi fare il controllo dei file. Se una qualsiasi delle md5 non corrisponde, è possibile differenziare i file e esaminare le modifiche.

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

Esistono, ovviamente, molteplici metodi (ispeziona i log ...) e le prevenzione, ma questo è un modo semplice e veloce.

2
dgarcia