Scopri come viene utilizzato il mio server per gli attacchi DDOS

Potrebbe essere che qualcuno stia effettivamente usando la tua istanza tramite rootkit o attraverso alcuni script PHP dannosi. Il tuo sistema è stato compromesso ora. Nuke dall'orbita e ripristina da uno stato di fiducia (backup).

Assicurati di mantenere aggiornato il tuo server e usa lunghi e complessi hash delle password. Disabilitare l'accesso root (solo consentire l'accesso per chiave, ad esempio). Installare un HIDS (sistema di rilevamento delle intrusioni basato sull'host) e un rootkit. OSSEC è una buona scelta su Linux.

Probabilmente il tuo server è stato compromesso da una vulnerabilità del web e è stato caricato uno script php che interagisce con gli ordini dell'utente malintenzionato.

Dovresti seguire questa procedura per assicurarti di non essere hackerato di nuovo:

1. Controlla i log del server e identifica il comportamento degli utenti malintenzionati e la tua vulnerabilità.
2. Cerca di trovare lo script php dannoso nel tuo server, per fare questo scarica tutti i tuoi file localmente e confrontali con un vecchio backup. Dovrebbe mostrarti il file modificato / nuovo.
3. Salva lo script dannoso, che contiene il Comand & Controlla l'indirizzo IP, quindi puoi inviarlo alla polizia.
4. Ripristina il sito Web da zero, non utilizzare il backup recente o gli script riutilizzati dal sito compromesso. Gli aggressori potrebbero inserire una backdoor e tu aprirai di nuovo la porta.

La cosa più importante è identificare in che modo hanno compromesso il tuo sito, se lo ripristini con la stessa vulnerabilità il bot dell'aggressore eseguirà nuovamente la scansione del tuo sito e avrai lo stesso problema.

Inoltre, mantieni aggiornati i servizi, utilizza password lunghe e complesse, ecc ...

Saluti.

Vorrei provare a stabilire l'estensione della penetrazione. Potrebbe essere limitato ad alcuni tipi di script sul tuo sito che sono stati in grado di abusare per creare un attacco DDOS. Non è così, potrebbe essere limitato a uno script che sono stati in grado di caricare e che esegue azioni sbagliate.

Se hai una buona configurazione nota e puoi determinare che non sono sfuggiti ai limiti dei tuoi motori di scripting (e hai configurato i tuoi motori di scripting in modo sicuro in modo che non potessero modificare il sistema stesso), allora dovresti essere ok per ripristinare una buona configurazione nota di tutto ciò a cui i motori di scripting hanno accesso.

Se non puoi dire con certezza che i tuoi motori di scripting siano configurati in modo sicuro o se sembra che abbiano effettivamente ottenuto l'accesso diretto alla scatola al di fuori del motore di scripting, allora non ci sono misure per contenere ciò che potrebbero avere nascosto e dovresti bombardarlo dall'orbita come suggerito in precedenza.

Il trucco è che non vuoi lasciare alcuna possibilità di una re-infezione che è altamente probabile se hanno accesso a basso livello dal momento che rende facile lasciare dietro cose apparentemente innocue che permetteranno la reinfezione più facilmente.

Sfruttare un punto debole in un'applicazione locale, magari accoppiato con un exroit del kernel root è il modo più probabile. Andrebbe qualcosa di simile.

1) Hacker sfrutta un punto debole in un'applicazione PHP che consente loro di creare file di proprietà del server web e quindi di eseguire quel codice.

2) Il loro codice dannoso scaricherà uno script che consente un accesso più semplice all'esecuzione dei comandi. Il download di uno script perl su / dev / shm usando wget è abbastanza comune.

3) Lo script perl si collegherebbe a un server remoto per formare un tunnel, o potrebbe accettare connessioni in entrata, in modo che i comandi arbitrari possano essere eseguiti più facilmente.

4) Il codice sorgente C per un root exploit verrebbe installato, compilato ed eseguito.

5) Se l'utente avesse successo, ora avrebbe i privilegi di root. A questo punto, il firewall potrebbe essere disabilitato, la configurazione predefinita di iptables cambiata e backdoors come un ssh modificato potrebbe essere installato per consentire l'accesso nonostante le impostazioni di hosts.allow e simili.

Questo fa solo scalfire la superficie, ma ci sono strumenti che possono aiutare con il rilevamento delle intrusioni e le misure che è possibile adottare per rafforzare la configurazione, come impedire le connessioni in uscita a IP arbitrari sul firewall (iptables piuttosto che il firewall esterno di EC2), non avendo un compilatore C nel solito posto o niente e spostando strumenti come wget, anche se una sceneggiatura potrebbe ottenere lo stesso risultato, ma è solo una seccatura per l'hacker. Mantenere un registro dei processi in esecuzione frequentemente (ogni 5 minuti o meno) può essere di aiuto nell'analisi post mortem come i registri web. È molto probabile che un hacker crei file o directory in / dev / shm o / tmp e un'utilità che sta monitorando le voci inattese potrebbe rilevare le intrusioni in anticipo. Bloccando il server per consentire l'accesso solo a se stessi, si dovrebbero trovare elementi inattesi, in particolare in / dev / shm (dove di solito non c'è nulla) non sarebbe eccessivo.

La distribuzione degli aggiornamenti del kernel è strongmente consigliata in quanto vi sono stati molti exploit di escalation di privilegi in Linux.