Vedo subito 3 bandiere rosse:
-
il primo è che usi WHM, che è una cattiva idea (proprio come il suo piccolo amico cPanel e i suoi colleghi Plesk, Kloxo, ecc) - Non sarei sorpreso se ci fossero vulnerabilità estreme in queste pile di spazzatura che consentirebbe l'accesso a livello di root al server senza compromettere alcun account utente.
-
il secondo è che usi FTP ... nel 2015. Oltre a essere un protocollo orribile e rotto sin dall'inizio, è anche completamente insicuro e qualsiasi utente malintenzionato che ascolta il traffico di qualsiasi cliente può ottenere la sua password. Dovresti usare SFTP che è incorporato in OpenSSH, quindi lo hai già.
-
infine, nonostante questo compromesso, stai ancora cercando di risolvere questo incubo anche se l'unica cosa giusta da fare è nuotare l'orbita, reinstallare una buona distro su di esso senza alcun tipo di pannello web.
Ora, per una risposta adeguata a ciò che questo codice fa - dopo avervi detto qualcosa di molto carino e amichevole, prova a uccidere qualsiasi versione già in esecuzione di se stesso, si avvia sotto il nome "ktnread", sperando di ingannare qualsiasi amministratori di sistema inesperti per scambiarlo con il vero, legittimo thread del kernel "kthreadd".
Potresti davvero dare un'occhiata a ciò che è il suo kthread, sono abbastanza sicuro che si tratti di una storia di orrore Perl rubata per anni, progettata per connettersi a un server IRC e attendere ordini per i DoS in modo che i bambini che li gestiscono può sembrare importante e potente, molto probabilmente per compensare ciò che realmente sono nella vita reale.
Per rispondere alla tua domanda finale, sfortunatamente è impossibile impedire completamente che ciò accada, ma puoi almeno limitare il danno:
-
blocca le connessioni in uscita dai server / contenitori / processi PHP e consenti loro caso per caso se l'applicazione ne ha veramente bisogno - puoi usare IPtables per questo. Anche in caso di compromissione, impedirà al loro malware di attaccare altri host dal proprio server o di inviare spam. Gli script kiddies si arrenderanno completamente perché il loro malware rubato non riesce a connettersi al proprio server IRC e non sono abbastanza intelligenti da modificarlo per prendere gli ordini dal server HTTP già in esecuzione (monitorando le richieste in entrata sull'accesso log).
-
blocca i processi PHP nel proprio chroot o contenitore LXC con il minimo che devono eseguire - sarà molto più difficile per la vita bassa implementare con successo il malware rubato in Perl se non c'è /bin/perl . Non è a prova di proiettile in quanto potrebbero semplicemente caricare il proprio binario Perl ma sarebbe comunque di aiuto e almeno scoraggiare alcuni di essi.
-
mantieni aggiornate le webapp e i loro plugin, poiché sono il principale punto di accesso per gli aggressori. Trovano spesso una vulnerabilità di caricamento dei file che consente loro di caricare tutto il loro carico utile e infine uno script PHP con exec("./payload") in esso che può essere eseguito semplicemente colpendo il suo URL.
-
esegue script PHP basati su una whitelist, invece di eseguire ciecamente qualsiasi cosa che finisca con .php . Anche se ci sono vulnerabilità di caricamento dei file, ciò non significa compromissione immediata del server perché non è possibile ottenere il payload perché il suo percorso non è autorizzato nella whitelist (e la maggior parte delle vulnerabilità di caricamento dei file non ti danno il lusso di anche specificando il percorso di destinazione, per sovrascrivere un file autorizzato).
-
impediscono al processo PHP di scrivere dove non dovrebbe - anche bloccare o almeno rallentare gli aggressori perché la vulnerabilità di caricamento dei file che hanno trovato consente loro solo di caricarsi in una directory non standard dove l'utente PHP può scriviamo.
-
infine, a seconda di cosa sei (host web, azienda standard, ecc.), dovresti chiederti se puoi fidarti dei tuoi utenti. Se sei un'azienda, la risposta è probabilmente sì, ma assicurati di avere delle buone norme per le password (usa le chiavi, laddove possibile, le chiavi SSH per SFTP, ad esempio), e alla fine limitando gli accessi solo alla rete della tua azienda. Se sei un host web, la risposta è decisamente no e dovresti pensare a far rispettare la verifica manuale per i nuovi clienti (il controllo di base delle informazioni fornite - se l'indirizzo o il telefono è reale o se si richiede l'ID) può essere un buon deterrente per le attività dannose.
In conclusione, non puoi mai essere sicuro al 100%, specialmente in un ambiente di hosting condiviso. Presto o tardi, nonostante tutti questi consigli sulla sicurezza, il tuo server sarà compromesso da root e dovrai nuotare e reinstallare, e in base alle tue leggi / ai dati ospitati su di essi potresti dover informare i tuoi clienti hanno violato i loro dati. Se i dati sono qualcosa di più prezioso dei blog di base, ti suggerisco di utilizzare VM separate o server bare metal per eseguire il codice effettivo (PHP, ecc.).