Domanda:
Soluzione di hosting resistente agli hack per non profit?
user249493
2016-03-09 08:49:15 UTC
view on stackexchange narkive permalink

(Sebbene le risposte e i commenti in Come posso trattare con un server compromesso? sono utili, la mia domanda riguarda più la prevenzione dell'hacking quando non ho il controllo totale (o molto) sul server. Ho accesso SSH ma non privilegi di root. Non riesco a vedere o modificare nulla oltre al mio account utente.)

Mi offro come volontario per un'organizzazione senza scopo di lucro, mantenendo il loro sito web per loro. Siamo stati su una piattaforma di hosting condiviso a basso budget (Bluehost) da diversi anni. Il sito è stato costruito su Wordpress e ho fatto del mio meglio per mantenere aggiornati il ​​core WP e tutti i plugin.

Ma siamo stati violati più volte. A volte era dannoso (deturpando la home page) mentre altre volte era invisibile (ho scoperto file nascosti che sembravano semplicemente consentire a qualcuno di entrare e curiosare).

Mi sono completamente sbarazzato di WP, ricostruendo il sito su Bootstrap. Ho rimosso tutti i file dal server, ho eseguito più scansioni antivirus sulla versione locale del nuovo sito, ho cercato qualsiasi cosa sospetta, quindi ho caricato i file sul server. Ero quasi sicuro al 100% che questa nuova base di codice fosse "pulita".

Ma nel giro di pochi giorni, ho scoperto (confrontando il server con la mia versione locale) un index.php compromesso (un po 'preg-replace 'codice è stato inserito prima della prima riga) e ha trovato un file "logo-small.png" in una sottodirectory che non era realmente un file immagine. Era un grosso pezzo di PHP offuscato che sembrava destinato a cose sgradevoli (ho de-offuscato e visualizzato il codice).

Sapevo che gli host condivisi, spesso con centinaia di siti, potevano essere vulnerabili. A questo punto, diffido totalmente del server su cui ci troviamo. Ma quando ho chiesto a Bluehost se saremmo stati più sicuri su un VPS o su un server dedicato (pensando che sarebbe stato più difficile entrare nella nostra "sandbox"), hanno detto che non avrebbe fatto davvero la differenza.

Quindi sono in imbarazzo. L'organizzazione no profit che aiuto ha un budget limitato. Ma non voglio nemmeno continuare a spendere decine o centinaia di ore per monitorare e riparare il sito. Non so se gli hacker stanno entrando tramite il file system o una porta aperta che non dovrebbe essere aperta.

Esiste una soluzione conveniente che fornisce un "indurimento" molto migliore?

I server Web per piccoli siti non richiedono un sacco di hardware. Qualcuno dei tuoi membri ha un vecchio PC che non usa mai e che è disposto a donare? Installa Ubuntu su di esso e inizia a eseguire nginx o Apache su di esso e quindi non devi fidarti di nessun altro. Per un sito Web più piccolo con un budget limitato, ma anche qualcuno che è attento alla sicurezza e lavora per mantenere il server, questa è probabilmente la soluzione migliore. Se questo è un tipo di sito più grande di quel tipo, ignora questo commento.
Possibile duplicato di [Come gestisco un server compromesso?] (Http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server)
Fino a quando non imparerai di più sulla sicurezza del server, sarai violato. Nessuna soluzione server è a prova di hacker a priori, è necessario comprendere e implementare tutti i passaggi elencati nei tutorial di hardening e nelle guide sulla sicurezza. In breve: la sicurezza inizia nella tua testa, non in un server di terze parti.
@DeerHunter: Questo presuppone che abbia il controllo del server web. Se si tratta di hosting condiviso (come accennato) sei sfortunato.
Non sembra un duplicato di [Come gestisco un server compromesso?] (Http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server) per me. L'OP di questa domanda sta cercando di capire la sicurezza delle diverse opzioni di hosting, non come correggere una violazione del server.
Per interesse, la cosa `preg-replace` [sembra essere abbastanza comune] (http://security.stackexchange.com/questions/114919/found-suspicious-obfuscated-php-file-is-this-a-hack -tentativo-sul-mio-sito)
La generazione di siti statici è sicuramente la strada da percorrere, * soprattutto * se puoi utilizzare un provider di hosting in cui sei co-localizzato solo con altri clienti solo hosting statico (quindi nessuno seduto accanto a te sulla stessa macchina esegue codice potenzialmente vulnerabile o). Vedere https://www.staticgen.com/ per un elenco di opzioni popolari relative a: strumenti per la generazione di siti open source.
@Oasiscircle Ciò richiede quindi all'hoster di avere un caricamento abbastanza veloce che sarebbe disposto a condividere con il sito. L'esecuzione di un server viola anche praticamente i termini di servizio di tutti gli ISP per Internet dei clienti (potresti farla franca a seconda dell'ISP).
Una possibilità è che il problema non provenga dall'hosting ma dal tuo computer. Alcuni virus possono rubare le tue credenziali FTP e caricare file sul tuo hosting. Hai cambiato le password ogni volta che il sito web è stato * violato *?
Raccomanderò [Jekyll] (https://jekyllrb.com/), un ** generatore di siti statici **, se stai servendo solo pagine statiche (suona come te). Hai detto di aver riscritto il sito usando Bootstrap, quindi immagino che tu non sia un po 'nuovo nella programmazione. Jekyll è incredibilmente semplice e in realtà non è molto codificato a meno che tu non voglia fare cose fantasiose. Fondamentalmente scrivi solo pagine web in Markdown (come Stack Exchange) e genera un sito. Può anche essere ospitato gratuitamente su [Github Pages] (https://jekyllrb.com/docs/github-pages/). Potrebbe valere la pena esaminarlo se hai un'ora!
L'efficienza dei costi dipende dal budget. Se sei grande come la Croce Rossa o alcune denominazioni di chiese, allora una soluzione di cloud privato virtuale potrebbe funzionare per te. Se sei una piccola organizzazione no profit, l'hosting di Google potrebbe essere sufficiente.
Hai cambiato le password dell'account dopo la prima compromissione?
A meno che tu non sappia cosa stai facendo, VPS è ** molto più difficile ** da proteggere rispetto all'hosting condiviso competente.Un VPS ti offre molta più libertà di configurare il tuo server e molti più modi per commettere errori.Non so di un BlueHost, ma un host condiviso configurato da un amministratore di sistema competente non sarebbe più sicuro di un VPS poiché configurerebbero i propri server in modo tale che la compromissione di un sito non influenzi altri siti sullo stesso host.
Nove risposte:
WoJ
2016-03-09 13:33:23 UTC
view on stackexchange narkive permalink

Se l'unica cosa che esponi a Internet sono pagine web non interattive e non hai bisogno di eseguire componenti lato server, puoi ridurre sostanzialmente i rischi utilizzando un sito web statico.

Ti resta quindi il motore web stesso e in parte estendere il sistema operativo sottostante. Apache o nginx non sono semplici da rafforzare, quindi potresti dare un'occhiata a Cherokee o publicfile.

Puoi fare un ulteriore passo avanti ospitando il tuo file statici su un ambiente esistente che li accetta ( Github Pages per esempio) o spostati su un sito che crei con blocchi come Google Sites (che sono gratuiti per non -profit).

Puoi persino utilizzare AWS S3 per l'hosting di siti statici e non dovrai più preoccuparti di proteggere il server. Supportano persino l'utilizzo dei tuoi domini: http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
Jeroen
2016-03-09 11:04:40 UTC
view on stackexchange narkive permalink

Il problema con l'hosting condiviso è che:

  1. Dipendi dal fatto che tutti i siti web mantengano aggiornato il loro codice. Potrebbe essere possibile che un altro account venga compromesso consentendo a un utente malintenzionato di accedere alla tua parte del server web. Esistono diversi modi per farlo, soprattutto se è installato un pannello di controllo come Direct Admin.

  2. Quando io, come hacker, acquisto spazio web sullo stesso server tu su potrei semplicemente (nel tuo caso) caricare una shell web PHP e (possibilmente) accedere a tutti i siti web che si trovano su quel server. Ciò è possibile anche se i permessi dei file sono impostati correttamente.

La soluzione è non utilizzare l'hosting web condiviso.

Ti suggerisco di acquistare un VPS. Un buon VPS (6 GB di RAM - dischi SSD) può essere acquistato per $ 7 al mese. Potrei darti il ​​link se vuoi, ma non voglio pubblicizzarlo qui. In questo modo hai più controllo su ciò che sta accadendo.

"caricare una shell web PHP e (possibilmente) accedere a tutti i siti web che si trovano su quel server" è davvero così facile accedere a tutti gli altri siti web sullo stesso server? Immagino che per funzionare ci debba essere un errore di configurazione del server per consentire una cosa del genere?
So che con Direct Admin (out of the box) funziona. Ma ci sono altri modi per enumerare home directory / nomi di dominio validi quando si ha una shell sul server quando queste autorizzazioni sono un po 'più rigide.
Esistono opzioni di hosting condiviso in cui puoi avere il tuo sito ospitato su un cluster in cui nessun account utente sullo stesso sistema avrà a disposizione funzionalità non statiche, sollevando alcune delle tue preoccupazioni.
So che non vuoi pubblicizzarlo, ma a quale VPS ti riferisci? "Un buon VPS (6 GB di RAM - dischi SSD) può essere acquistato per $ 7 al mese."
Google "VPS Dime" e lo troverai.
"Potrei semplicemente (nel tuo caso) caricare una shell web PHP e (possibilmente) accedere a tutti i siti web che si trovano su quel server. Questo è anche possibile se i permessi dei file sono impostati correttamente" - quindi stai dicendo che le jail sono intrinsecamente danneggiate o semplicemente che alcuni hosting provider non li usano o li configurano male (c'è molto da configurare male? mi sembra semplice)? Non tenevo il passo con gli exploit allo stato dell'arte, ma pensavo che funzionassero come pubblicizzato, a parte possibili bug in alcune implementazioni che non possono mai essere esclusi.
Sebbene molti host stiano ora escogitando modi per prevenirlo per il motivo menzionato da Jeroen, di solito è facile come fare in modo che uno script PHP riceva il contenuto di ../ Se configurato male, questo restituirebbe un elenco di directory di altri clienti. Quindi supponiamo che se un cliente avesse la directory di billysautoshop.com potrei semplicemente creare uno script di caricamento PHP sul mio account che carica index.php su ../billysautoshop.com E a volte potresti farlo per avere pieno accesso alla radice del server. Probabilmente non è il caso del suo attuale ospite, ma immagino che molti host meno conosciuti / inesperti siano ancora interessati.
Quanto sopra è noto anche come attacco di attraversamento di directory.
Le installazioni standard out of the box di Direct Admin non vengono arrestate (almeno qualche anno fa). Quelli che avevano alcuni problemi di autorizzazione, ho creato uno script che leggesse / etc / passwd per ottenere tutti i nomi utente (/ home / $ username) e il file / etc / bind / domains (o qualunque cosa fosse). Utilizzando un ciclo ho cercato se fosse possibile leggere /home/$user/$domain/public_html/index.php. In questo modo è stato possibile enumerare tutti i percorsi validi su un sistema. Utilizzando una web shell potevo leggere tutti i file config.php e in cambio avevo accesso a tutti i database (legalmente ovviamente)
Tim Seed
2016-03-09 21:38:38 UTC
view on stackexchange narkive permalink

Passa a un sistema di pagine statiche. Anch'io avevo WordPress, ma dopo essere stato hackerato 2 volte dal "Free Syrian Army" (nel tentativo di promuovere la loro situazione ...) mi sono stufato di Wordpress e ho usato Nikola .

Semplice e facile - Pagine Web statiche .... nessun account / porte / vulnerabilità SQL ecc.

Ce ne sono altri (Forks dello stesso) - cerca anche Pelican.

Esercito siriano libero o esercito elettronico siriano? Mai sentito parlare della FSA di hackerare un sito ..
@StackOverflowed In realtà era il Fronte popolare giudeo ...
@Mason Penso che intendi il Fronte popolare della Giudea ... [non quegli altri mascalzoni] (https://www.youtube.com/watch?v=vPyiUePXuGQ).
-1
Vegard
2016-03-09 16:29:55 UTC
view on stackexchange narkive permalink

Digital Ocean offre macchine virtuali dedicate a partire da $ 5 / mese. Ciò sarebbe paragonabile a un server dedicato in termini di confronto tra la soluzione e il VPS.

Il problema più comunemente sarà la tua soluzione software utilizzata nella distribuzione effettiva dei contenuti, tuttavia. Rafforzare i file di configurazione della suite scelta non è banale a meno che tu non abbia esperienza con quel genere di cose.

La protezione avanzata del server come argomento generale è enorme, ma se hai individuato un particolare insieme di programmi che desideri utilizzare, Google e ServerFault.SE avranno molto probabilmente molti suggerimenti su come bloccarli .

O come suggerisce WoJ, puoi utilizzare una soluzione di hosting più precostruita.

Digital Ocean è fantastico!È semplicissimo da configurare e se sei uno studente ricevi un coupon da $ 50: D
tylerl
2016-03-11 08:14:11 UTC
view on stackexchange narkive permalink

Di regola, non è l ' host che viene violato, è il tuo sito. Se disponi di un sito sicuro, un semplice VPS può mantenerti al sicuro.

Supponendo che non sia necessario che i tuoi contenuti rispondano in modo diverso ai diversi visitatori, un generatore di sito statico lavorerà per te. In genere sono un po 'come wordpress in quanto scrivi il tuo contenuto personalizzato e viene trasformato in un sito a tema, ma è diverso in quanto il generatore vive sul tuo computer (non sul server web) e l'unica cosa sul server è HTML statico.

Quindi non c'è niente da hackerare. Non è vivo. Il server non può fare nulla. È solo contenuto.

Se vuoi metterlo sul tuo VPS, puoi ottenerne uno a Linode o Digital Ocean, o se ti senti coraggioso, AWS o Google Compute. Il server di livello più basso in tutti questi luoghi è di circa $ 5 / mese, che è sufficiente per le tue esigenze.

Puoi persino ospitare un sito di questo tipo su Github Pages senza alcun costo .

Finn Årup Nielsen
2016-03-10 16:35:06 UTC
view on stackexchange narkive permalink

Se hai già esperienza con Wordpress, perché non utilizzare semplicemente il cloud wordpress.com. Si spera che si occupino dell'amministrazione del sistema, inclusa la sicurezza. Hai solo bisogno di mantenere la password al sicuro ed esportare / eseguire il backup dei tuoi post regolarmente. Ovviamente sei in balia dell'azienda, - il mio blog una volta è stato bloccato, ma sono riuscito a convincerlo ad aprirlo di nuovo. Inoltre, forse non tutti i plugin di cui hai bisogno potrebbero essere presenti. Potrebbero esserci anche problemi di privacy, il problema del nome di dominio della tua organizzazione non profit e gli annunci che wordpress.com potrebbe inserire nella tua home page.

Tim X
2016-03-11 07:26:51 UTC
view on stackexchange narkive permalink

Ci sono molti buoni consigli nelle risposte. Tuttavia, forse il consiglio più importante è quello di utilizzare solo una società di hosting con una buona reputazione. Non basare la tua decisione sui costi e scegli un sito economico basato esclusivamente su tali criteri.

La realtà è che la gestione di una società di hosting comporta notevoli costi di manutenzione. Per ottenere un profitto sufficiente, è necessario effettuare tagli da qualche parte. Sfortunatamente, questi tagli vengono spesso applicati ai processi di gestione del rischio perché non esiste un'evidente relazione 1 a 1 tra spese e entrate. Il risultato è che la sicurezza spesso soffre.

Le organizzazioni più grandi in cui il recupero è visto come un aspetto importante della loro redditività probabilmente spenderanno di più in queste aree. Hanno anche il vantaggio di poter trarre vantaggio dalle economie di scala. Se non sei nella posizione di gestire da solo i rischi per la sicurezza, devi fare affidamento sulla tua società di hosting.

Diverse risposte suggeriscono di utilizzare un sito statico piuttosto che wordpress. Un sito statico può aiutare, ma ovviamente, se il server è compromesso, fa poca differenza. Tuttavia, framework dinamici mal gestiti che non vengono aggiornati saranno sempre più rischiosi di un sito statico data la stessa sicurezza di hosting.

Wordpress è una soluzione ad alto rischio. È attivamente mirato e ci sono una serie di punti deboli nel sistema di plugin. Anche se mantieni aggiornati i plugin, non ci sono garanzie. Solo questa settimana c'è stato un report di un plugin popolare che ha dei buchi di sicurezza significativi che sono stati deliberatamente aggiunti dal nuovo manutentore del plugin (questo è un problema comune con le architetture dei plugin - i plugin di Chrome soffrono dello stesso problema. Cerchi alcuni Funzionalità. Sei attento alla sicurezza, quindi controlli i riferimenti, la reputazione e i rapporti degli utenti per un plug-in. Tutto sembra a posto e lo sviluppatore ha una buona reputazione, quindi lo installi. Successivamente, lo sviluppatore va avanti: vendendo il plug-in o ad un altro che potrebbe non essere così etico. Non esiste alcun meccanismo per avvisarti di questa modifica. Il nuovo proprietario emette problemi e l'aggiornamento contiene un codice dannoso. Tu applichi l'aggiornamento (o forse l'aggiornamento viene applicato automaticamente). game over ).

Se non puoi utilizzare solo un sito statico, forse prendi in considerazione l'utilizzo di qualcosa di diverso da wordpress che non sia così attivamente mirato. questo non sarà conveniente in quanto probabilmente significherà imparare un nuovo framework, ma potrebbe fornire una protezione aggiuntiva.

L'altra cosa da considerare seriamente, soprattutto se semplicemente non c'è abbastanza budget, è vendere la tua reputazione web per le organizzazioni non profit. C'è un costo associato alla presenza sul web. Se il no profit non può permettersi il costo di un sito sufficientemente sicuro, deve accettare il rischio di essere violato o ridimensionare la propria presenza sul web a qualcosa che è disposto a finanziare. In generale, ci sono poche soluzioni di sicurezza `` economiche '': ottieni quello per cui paghi (puoi pagare più del dovuto, specialmente con alcuni commercianti di olio di serpente attirati dal redditizio spazio di sicurezza, ma se fai la tua ricerca, cerca buone referenze / arbitri, ricordate che non esiste un pranzo gratis e se sembra troppo bello per essere vero, probabilmente non lo è, blah blah blah, generalmente starete bene).

Ángel
2016-07-03 04:21:43 UTC
view on stackexchange narkive permalink

Prima di tutto, devo notare che non sono d'accordo con la premessa di essere vulnerabile solo per essere su un host condiviso. Se il tuo account di hosting condiviso è stato compromesso da un altro utente, è perché:

  • La società di hosting non ha isolato correttamente gli utenti
  • L'utente ha fatto qualcosa di stupido (come con 777 file)

Con un VPS, l'isolamento è fornito da un livello diverso, che è più difficile da superare. E ancora di più con un server dedicato. Quindi, non sono d'accordo con la risposta che Bluehost ti ha dato.

Tuttavia , se il compromesso ha avuto origine dal tuo account (ad es. Un plugin wordpress vulnerabile), allora non avrà certamente importanza il opzione di hosting che utilizzi.

Certamente, il tuo file logo-small.png sembra come se fosse stato caricato tramite la tua applicazione.

Per quanto riguarda il rilevamento di compromessi, ti consiglio di mantenere il file in versione È facile creare uno script che sincronizzi il tuo sito web e si impegni ad es. un repository git.

Questo serve come backup ed evidenzia anche molto chiaramente le differenze quando i file vengono modificati.

Diverse risposte promuovono l'uso di file statici. Se i file non cambiano in remoto, e supponendo che tu sia l'unico a cambiare le pagine web (o che siano cambiate sullo stesso computer "master") un semplice rsync -avz --delete website / the-server : tornerebbe alla versione "pulita", in caso di compromissione del genere. Puoi anche sincronizzare automaticamente in questo modo "per ogni evenienza", anche se se il sito web è in qualche modo vulnerabile, il ripristino automatico dal backup, sebbene efficiente in termini di tempo, non è una vera soluzione.

Neil Robertson
2016-03-11 17:30:48 UTC
view on stackexchange narkive permalink

Sicurezza del personal computer

Secondo il modulo di commento AL, la vulnerabilità potrebbe non avere nulla a che fare con il tuo sito web o l'hosting, ma più a fare con le password rubate da un computer dell'amministratore di un sito Web compromesso o simile o forse l'autore dell'attacco ha il controllo su un account amministrativo che non è stato reimpostato dopo la pulizia iniziale.

Abbandono di WordPress rispetto all'aggiornamento a un host migliore

Allontanarsi da WordPress può aiutare, ma trovare un host con migliori pratiche di sicurezza può essere una soluzione più efficace.

Mi occupo di circa 50 siti web costruito con un CMS simile a WordPress e sono molto coscienzioso nell'applicazione regolare degli aggiornamenti. I siti su host di buona qualità (ad esempio SiteGround) raramente vengono violati. SiteGround aggiorna regolarmente il firewall delle applicazioni web per bloccare i più comuni WordPress, Joomla e altre vulnerabilità, anche se dovresti comunque aggiornare prontamente il tuo CMS e qualsiasi componente aggiuntivo di terze parti non appena vengono rilasciati gli aggiornamenti.

Hosting condiviso vs VPS

Passare a un VPS può ridurre il rischio di contaminazione da altri account sullo stesso server, ma la sicurezza di un VPS si basa sulle capacità della persona o delle persone che lo mantengono, solo come l'hosting condiviso.

Un account di hosting condiviso su un server ben mantenuto ha meno probabilità di essere violato rispetto a un VPS gestito male.

Precauzioni di sicurezza di buon senso

Qualunque cosa tu faccia, nulla sul Web è mai sicuro al 100%. Puoi ridurre al minimo il rischio di perdita di dati eseguendo backup regolari, copiando i backup fuori sede e testando regolarmente i backup.

Ulteriori informazioni su altre precauzioni di sicurezza basate sul buon senso come:

  • applicare regolarmente gli aggiornamenti
  • mantenere la versione PHP aggiornata,
  • scegliere software solo da sviluppatori affermati e affidabili
  • minimizzare il numero di componenti aggiuntivi ove possibile
  • ridurre al minimo il numero di account amministrativi
  • implementare un firewall per applicazioni web per proteggere il sito web e / o abilitare una rete di distribuzione dei contenuti (CDN) che include un firewall per applicazioni web

In conclusione

Direi che la soluzione più conveniente nel tuo caso in cui hai un cliente attento al budget è una soluzione di hosting condiviso con un fornitore di hosting di buona qualità.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...