Server root hackerato via httpd - conseguenze e prevenzione futura

Question

Server root hackerato via httpd - conseguenze e prevenzione futura

#1 da (4 voti)

4

Da prima della metà del 2014, il mio root server è stato preso di mira dagli hacker e recentemente hanno ottenuto un accesso limitato. Ho disabilitato tutti i servizi una volta capito che il server è stato compromesso e ho iniziato a indagare. Secondo i registri, era circa una settimana dopo l'intrusione avvenuta con successo.

Ero solito ospitare un sito web per un amico basato sul CMS di Joomla. Durante le indagini mi sono reso conto che il sito Web era severamente obsoleto e praticamente abbandonato. Dato che il suo dominio e il suo sito erano l'obiettivo principale, sospetto che gli aggressori abbiano sfruttato bug noti o difetti di sicurezza nel software per caricare i propri script, principalmente per inviare email di spam.

Ho appena appreso che un grosso problema è in effetti, che tutti i siti web hanno lo stesso utente. Una volta che gli hacker hanno avuto accesso, potevano eseguire comandi sul lato server con questo utente (che è "www-data").

Non mi dispiacerebbe se questo avrebbe solo influenzato il sito del mio amico, ma sfortunatamente hanno creato uno script in uno degli altri domini (che fino a quella data mostrava solo un index.html vuoto). Il file è una variante della shell remota PHP chiamata WSO ed è la ragione principale per cui chiedo aiuto. Prima di pulire e reinstallare il mio server di root, voglio assicurarmi che questo non accada di nuovo e vorrei fare queste domande:

Apparentemente l'hacker è riuscito a installare uno script php oltre i confini del dominio obsoleto / non funzionante. Come ha fatto a farlo? Non dovrebbe nginx o php5-fpm avere un qualche tipo di meccanismo per impedire agli script php di accedere a directory al di fuori della root del dominio corrente?
So che alcuni CMS come Joomla ti chiedono se vuoi usare la funzione php mail () o un server SMTP. Come posso impedire rigorosamente a php di inviare email per posta () e consentire solo smtp autenticato?
È possibile incapsulare completamente il sito web del mio amico, in modo che una volta che un hacker riesce a iniettare qualche script, non lo aiuterà ad accedere a nessun altro sito Web, per non parlare del file system del server?
Qual è il modo ISP di limitare gli script dei clienti e il comportamento di invio di e-mail? La velocità di trasmissione delle e-mail è abbastanza buona?

php cms webserver hardening

posta 08frak 15.02.2015 - 02:49

fonte

1 risposta

Leggi altre domande sui tag php cms webserver hardening

Si sta utilizzando un servizio VPN gratuito e anonimo sicuro? [chiuso] Devo cancellare una macchina nuova e un HDD?

score 4 · Accepted Answer

L'utente malintenzionato ha avuto accesso a tutti gli altri virtualhosts (quelli che chiami "domini") perché vengono eseguiti tutti sotto l'utente www-data , una volta che ha ottenuto i privilegi di questo utente, può accedere a tutti gli altri domini.

Per mitigarlo puoi usare mod_privileges su Apache per eseguire ogni virtualhost con un altro utente account e fare in modo che ogni virtualhost utilizzi un diverso pool PHP-FPM che viene eseguito anche con lo stesso utente diverso. Se un utente malintenzionato riesce a ottenere l'accesso alla shell sotto il proprio account virtualhost e tenta di ls della directory virtualhost di qualcun altro, riceverà solo un errore Autorizzazione negata (a meno che "qualcun altro" abbia eseguito chmod -R 777 nel suo elenco, ma poi merita di essere compromesso.

Anche la direttiva open_basedir di PHP può essere d'aiuto, ma non è a prova di proiettile e proteggerà solo dalla lettura dei file utilizzando le solite funzioni di I / O dei file di PHP, ma non eseguendo i comandi di shell.

How can I strictly prevent php from sending emails by mail()

PHP ha una direttiva di configurazione per disabilitare determinate funzioni, quindi come soluzione stupida è possibile utilizzarla, ma non proteggerà dall'utilizzo di socket non elaborati per connettersi a un server di posta e scaricare lo spam lì. La soluzione migliore è bloccare le connessioni in uscita sulla porta 25. L'SMTP autenticato può utilizzare la porta di invio (587) in modo che gli utenti legittimi possano ancora utilizzare il server del proprio provider di posta o il server fornito dall'utente, ma non saranno in grado di eseguire la scansione per i relè aperti sulla porta 25 e prova a inviare il loro spam.

Is it possible to completely encapsulate the website of my friend

È possibile inserire ciascun server in una prigione chroot e in esecuzione su una porta diversa e avere davanti a sé un server Web leggero che funge da proxy per reindirizzare le connessioni dalla porta HTTP (s) standard al corretto server basato su chroot sul nome di dominio. Puoi andare ancora oltre usando LXC (contenitori) o intere macchine virtuali / server fisici per questo, a seconda dei tuoi requisiti di sicurezza.

What is the ISP way of restricting customers' scripts and email sending behavior?

Alcuni (cattivi) ISP bloccano la porta 25 su qualsiasi cosa tranne i propri server (da dove possono tracciare l'utente anche se non si autentica perché sanno a quale IP appartiene chi), alcuni permettono di usare liberamente la porta e presumo di chiudere il tuo account solo se ricevono troppi reclami sullo spam dal tuo IP.

Dalla lettura dei termini e delle condizioni di OVH (un popolare ISP francese) sembrano monitorare il traffico SMTP in uscita e passare tutti i principali attraverso il loro filtro basato su Spamassasin, e se troppe mail sono considerate spam bloccano la tua porta 25.