Opzioni di hosting
Le opzioni di hosting per un sito Web sono generalmente una delle seguenti:
- server dedicato
- server privato virtuale (VPS)
- hosting condiviso
Con un server dedicato, solo un sito è ospitato su un computer fisico e la configurazione è sicura come il computer stesso.
Con un VPS, il software viene eseguito sullo stesso computer fisico delle macchine virtuali di altri utenti. Tuttavia, è funzionalmente equivalente a un server dedicato. Ancora più importante, un VPS ha la privacy e la sicurezza di un server dedicato.
Con l'hosting condiviso, il tuo sito Web risiede in un file system condiviso con altri utenti. Questo, sfortunatamente, lo rende meno sicuro rispetto a quando è in esecuzione su un server o VPS dedicato. Il resto di questo articolo discute della sicurezza di un WCMS nell'ambiente di hosting condiviso.
Ambiente
Un ambiente di hosting condiviso può essere considerato costituito da un server Web, un file system, un file di impostazioni, un database e alcuni utenti.
Negli esempi seguenti, si presume che l'account del proprietario sia "tom" e che il file delle impostazioni (contenente le credenziali del database) sia denominato "settings.php".
Il processo del server Web può essere eseguito con le autorizzazioni utente dell'account proprietario "tom" o con le autorizzazioni di gruppo del gruppo "www", a seconda della configurazione.
Inoltre, si presuppone un ambiente Gnu / Linux o Unix standard e si presume che il lettore comprenda il sistema di controllo degli accessi Unix con autorizzazioni di lettura (r), scrittura (w) ed esecuzione / access directory separate (x) separate in tre blocchi (utente, gruppo, altro).
Prima di continuare a discutere di impostazioni specifiche, può essere utile elencare le condizioni che vogliamo soddisfare:
- Affinché un sito Web sia operativo, il server Web deve avere accesso in lettura a tutti i file che compongono il sito e accedere alla directory per accedere a tutte le directory che compongono il sito.
- Per un funzionamento sicuro, il server Web non deve avere accesso in scrittura a nessuno dei file che gestisce.
- Per un funzionamento sicuro, uno script Web eseguito da un utente non autorizzato non deve avere accesso in lettura ai file di proprietà di un altro utente.
- Per consentire al proprietario di lavorare sul proprio sito utilizzando l'interfaccia della riga di comando, l'utente deve avere accesso in lettura e scrittura ai propri file.
- Per proteggere i file da accessi da parte di altri utenti che utilizzano la CLI, il blocco "altro" dovrebbe avere alcun permessi impostati.
Sfortunatamente, su un host condiviso, puoi avere solo 4 su 5. Non so in alcun modo che puoi soddisfare tutte e cinque le condizioni su un host condiviso.
Per quanto ne so, i provider host condivisi utilizzano due diverse configurazioni. Entrambi sono discussi di seguito, insieme alle autorizzazioni da utilizzare per proteggere al meglio file e directory e quali condizioni la configurazione non riesce a soddisfare.
Config 1: il server Web è in esecuzione come proprietario
Questa è AFAIK la configurazione più utilizzata. Il web server è in esecuzione come proprietario dei file. Ciò significa che un utente non autorizzato non può utilizzare il suo utente del server Web per eseguire uno script per leggere i file di un altro utente. Questo tipo di configurazione protegge anche gli utenti l'uno dall'altro nella CLI.
Tuttavia, significa anche che non possiamo avere autorizzazioni separate per il proprietario e il server web. Per soddisfare la condizione 2 con questo tipo di installazione, è necessario limitare le autorizzazioni di scrittura per il proprietario al fine di impedire l'accesso in scrittura per il server Web a tutto tranne che alla directory di caricamento.
permessi:
Directories: 500 r-x --- --- tom.tom
Files: 400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.: 700 rwx --- --- tom.tom
Sfortunatamente, ciò significa che la condizione 4 non può essere soddisfatta. Vale a dire che il sito non può essere gestito tramite la CLI. Il proprietario sarà costretto a utilizzare una sorta di dashboard basato sul Web per accedere al sito (la mia raccomandazione è che il proprietario conserva una copia su alcuni server di gestione temporanea in cui ha accesso senza restrizioni e rispecchia le modifiche apportate sul server di gestione temporanea all'host condiviso ).
Config 2: il server Web è in esecuzione come membro del gruppo www
Questa configurazione viene utilizzata da alcuni provider (IMHO) meno professionali di una soluzione host condivisa. Il server Web è in esecuzione come membro del gruppo www e viene fornito l'accesso in lettura richiesto tramite il blocco di gruppo:
permessi:
Directories: 750 rwx r-x --- tom.www
Files: 640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.: 770 rwx rwx --- tom.www
Queste impostazioni hanno il vantaggio di fornire al proprietario pieno accesso ai suoi file tramite l'interfaccia della riga di comando e limitano il server Web alla sola lettura.
Tuttavia, non riesce anche a soddisfare la condizione 3. Cioè consente a un utente canaglia sull'host condiviso (o un hacker che, come compromesso il sito di un altro utente che condivide l'host) di eseguire uno script per leggere qualsiasi file che può essere letto dal server web. Questo dà allo script canaglia l'accesso al file settings.php con le credenziali del database, il che rende banale assumere completamente il sito.
La mia raccomandazione è di evitare questo tipo di configurazione.
Addendum: quanto è pericoloso utilizzare un host condiviso?
Certamente non metterei nulla di sensibile, come numeri di carta di credito o cartelle cliniche, su un host condiviso. Ma l'hosting condiviso è economico e c'è un'attrazione in questo. Uso l'hosting condiviso per molti dei miei siti. Non sono ancora stato violato, ma so che esiste il rischio e sono pronto per il giorno in cui succede. Se sono stato violato, eliminerò semplicemente tutto sull'host condiviso e reinstallerò il sito da una copia mirror che conservo su un server di gestione temporanea sicuro.
Con "config 2", il problema principale è rappresentato dagli altri . Se qualche altro sito Web con cui condividi l'host viene compromesso, anche il tuo sito Web è pranzo. Fare in modo che la sicurezza dipenda da un'altra parte che non si conosce e su cui non si ha alcun controllo non è una buona idea. Questo è il motivo per cui la mia raccomandazione è quella di evitare accordi di hosting di tipo "config 2".
Con "config 1", tu solo controlli la sicurezza del tuo sito web. Questo è meglio (in particolare se sai cosa stai facendo). Ma non è infallibile. Nessuno è perfetto, e se vai su e il tuo sito è compromesso, l'attaccante avrà accesso a tutti i file memorizzati su quell'host che ti appartiene. In altre parole, per ridurre al minimo il danno quando vieni violato, non tenere nulla su quell'host che causi danni se qualcun altro accede ad esso. In particolare, non conservare la tua email su quell'host condiviso. Di solito ci sono tonnellate di dati sensibili nell'e-mail, quindi non li vuoi vicino a un server web che esegue come "tu".
E se la tua applicazione web sta gestendo dati sensibili, assicurati che il tuo budget consenta un host dedicato o un VPS.
Puoi anche consultare questa guida su come proteggere le autorizzazioni e la proprietà dei file su Drupal.org.