Quali autorizzazioni devono avere i file/le cartelle del mio sito Web su un server Web Linux?

Soluzione 1:

Quando decidi quali autorizzazioni utilizzare, devi sapere esattamente chi sono i tuoi utenti e di cosa hanno bisogno. Un server web interagisce con due tipi di utenti.

Autenticato gli utenti dispongono di un account utente sul server e possono disporre di privilegi specifici. Questo di solito include amministratori di sistema, sviluppatori e account di servizio. Di solito apportano modifiche al sistema utilizzando SSH o SFTP.

Anonimo gli utenti sono i visitatori del tuo sito web. Sebbene non dispongano delle autorizzazioni per accedere direttamente ai file, possono richiedere una pagina Web e il server Web agisce per loro conto. È possibile limitare l'accesso di utenti anonimi prestando attenzione alle autorizzazioni del processo del server Web. Su molte distribuzioni Linux, Apache viene eseguito come www-data utente ma può essere diverso. Usa ps aux | grep httpd o ps aux | grep apache per vedere quale utente Apache sta usando sul tuo sistema.

Note sui permessi Linux

Linux e altri sistemi conformi a POSIX utilizzano le tradizionali autorizzazioni unix. C'è un eccellente articolo su Wikipedia sui permessi del filesystem quindi non ripeterò tutto qui. Ma ci sono alcune cose di cui dovresti essere a conoscenza.

Il bit di esecuzione
Gli script interpretati (ad es. Ruby, PHP) funzionano bene senza il permesso di esecuzione. Solo i file binari e gli script di shell richiedono il bit di esecuzione. Per attraversare (entrare) in una directory, è necessario disporre dell'autorizzazione di esecuzione su quella directory. Il server web ha bisogno di questa autorizzazione per elencare una directory o servire qualsiasi file al suo interno.

Autorizzazioni predefinite per i nuovi file
Quando viene creato un file, normalmente eredita l'id di gruppo di chi lo ha creato. Ma a volte vuoi che i nuovi file ereditino l'id di gruppo della cartella in cui sono stati creati, quindi dovresti abilitare il bit SGID sulla cartella principale.

I valori di autorizzazione predefiniti dipendono dal tuo umask. L'umask sottrae i permessi dai file appena creati, quindi il valore comune di 022 risulta in file creati con 755. Quando si collabora con un gruppo, è utile cambiare l'umask in 002 in modo che i file creati possano essere modificati dai membri del gruppo. E se vuoi personalizzare i permessi dei file caricati, devi cambiare umask per apache o eseguire chmod dopo che il file è stato caricato.

Il problema con 777

Quando fai chmod 777 il tuo sito web, non hai alcuna sicurezza. Qualsiasi utente del sistema può modificare o eliminare qualsiasi file nel tuo sito web. Ma più seriamente, ricorda che il server Web agisce per conto dei visitatori del tuo sito Web e ora il server Web è in grado di modificare gli stessi file che sta eseguendo. Se sono presenti vulnerabilità di programmazione nel tuo sito Web, possono essere sfruttate per deturpare il tuo sito Web, inserire attacchi di phishing o rubare informazioni dal tuo server senza che tu lo sappia.

Inoltre, se il tuo server funziona su una porta ben nota (che dovrebbe impedire agli utenti non root di generare servizi di ascolto accessibili da tutto il mondo), significa che il tuo server deve essere avviato da root (sebbene qualsiasi server sano cadrà immediatamente a un account meno privilegiato una volta che la porta è collegata). In altre parole, se stai eseguendo un server web in cui l'eseguibile principale fa parte del controllo della versione (ad esempio un'app CGI), lasciando i suoi permessi (o, se è per questo, i permessi della directory che lo contiene, poiché l'utente potrebbe rinominare l'eseguibile) in 777 consente qualsiasi utente per eseguire qualsiasi eseguibile come root.

Definisci i requisiti

• Gli sviluppatori hanno bisogno dell'accesso in lettura/scrittura ai file per poter aggiornare il sito web
• Gli sviluppatori hanno bisogno di leggere/scrivere/eseguire nelle directory in modo che possano navigare
• Apache ha bisogno dell'accesso in lettura ai file e agli script interpretati
• Apache ha bisogno dell'accesso in lettura/esecuzione alle directory servibili
• Apache ha bisogno dell'accesso in lettura/scrittura/esecuzione alle directory per i contenuti caricati

Mantenuto da un singolo utente

Se solo un utente è responsabile della manutenzione del sito, impostalo come proprietario dell'utente nella directory del sito Web e concedi all'utente autorizzazioni rwx complete. Apache ha ancora bisogno dell'accesso in modo che possa servire i file, quindi imposta www-data come proprietario del gruppo e concedi al gruppo le autorizzazioni r-x.

Nel tuo caso, Eve, il cui nome utente potrebbe essere eve , è l'unico utente che gestisce contoso.com :

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Se disponi di cartelle che devono essere scrivibili da Apache, puoi semplicemente modificare i valori di autorizzazione per il proprietario del gruppo in modo che www-data abbia accesso in scrittura.

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

Il vantaggio di questa configurazione è che diventa più difficile (ma non impossibile*) per gli altri utenti del sistema curiosare, dato che solo i proprietari di utenti e gruppi possono navigare nella directory del tuo sito web. Questo è utile se hai dati segreti nei tuoi file di configurazione. Fai attenzione al tuo umask! Se crei un nuovo file qui, i valori di autorizzazione saranno probabilmente predefiniti a 755. Puoi eseguire umask 027 in modo che il valore predefinito dei nuovi file sia 640 (rw- r-- --- ).

Mantenuto da un gruppo di utenti

Se più di un utente è responsabile della manutenzione del sito, sarà necessario creare un gruppo da utilizzare per l'assegnazione delle autorizzazioni. È buona norma creare un gruppo separato per ogni sito Web e denominare il gruppo dopo quel sito Web.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

Nell'esempio precedente, abbiamo utilizzato il proprietario del gruppo per concedere privilegi ad Apache, ma ora viene utilizzato per il gruppo di sviluppatori. Poiché l'utente proprietario non ci è più utile, impostarlo a root è un modo semplice per garantire che non vengano trapelati privilegi. Apache ha ancora bisogno dell'accesso, quindi diamo accesso in lettura al resto del mondo.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Se disponi di cartelle che devono essere scrivibili da Apache, puoi impostare Apache come proprietario dell'utente o proprietario del gruppo. In ogni caso, avrà tutto l'accesso di cui ha bisogno. Personalmente, preferisco renderlo proprietario dell'utente in modo che gli sviluppatori possano ancora sfogliare e modificare i contenuti delle cartelle di caricamento.

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Sebbene questo sia un approccio comune, c'è un aspetto negativo. Poiché ogni altro utente del sistema ha gli stessi privilegi sul tuo sito web di Apache, è facile per gli altri utenti navigare nel tuo sito e leggere file che potrebbero contenere dati segreti, come i tuoi file di configurazione.

Puoi avere la tua torta e mangiarla anche tu

Questo può essere ulteriormente migliorato. È perfettamente legale che il proprietario abbia meno privilegi rispetto al gruppo, quindi invece di sprecare l'utente proprietario assegnandolo a root, possiamo rendere Apache il proprietario dell'utente sulle directory e sui file nel tuo sito web. Questa è un'inversione dello scenario del singolo manutentore, ma funziona ugualmente bene.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Se disponi di cartelle che devono essere scrivibili da Apache, puoi semplicemente modificare i valori di autorizzazione per il proprietario dell'utente in modo che www-data abbia accesso in scrittura.

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Una cosa a cui prestare attenzione con questa soluzione è che l'utente proprietario di nuovi file corrisponderà al creatore invece di essere impostato su www-data. Quindi tutti i nuovi file che crei non saranno leggibili da Apache fino a quando non li macinerai.

*Separazione privilegi Apache

Ho accennato in precedenza che è effettivamente possibile per altri utenti curiosare nel tuo sito Web, indipendentemente dal tipo di privilegi che stai utilizzando. Per impostazione predefinita, tutti i processi Apache vengono eseguiti come lo stesso utente www-data, quindi qualsiasi processo Apache può leggere file da tutti gli altri siti Web configurati sullo stesso server e talvolta persino apportare modifiche. Qualsiasi utente che può fare in modo che Apache esegua uno script può ottenere lo stesso accesso che ha Apache stesso.

Per combattere questo problema, ci sono vari approcci per privilegiare la separazione in Apache. Tuttavia, ogni approccio presenta vari svantaggi in termini di prestazioni e sicurezza. A mio parere, qualsiasi sito con requisiti di sicurezza più elevati dovrebbe essere eseguito su un server dedicato anziché utilizzare VirtualHost su un server condiviso.

Considerazioni aggiuntive

Non ne ho parlato prima, ma di solito è una cattiva pratica che gli sviluppatori modifichino direttamente il sito web. Per i siti più grandi, è molto meglio avere una sorta di sistema di rilascio che aggiorna il server web dai contenuti di un sistema di controllo della versione. L'approccio del singolo manutentore è probabilmente l'ideale, ma invece di una persona hai un software automatizzato.

Se il tuo sito Web consente caricamenti che non devono essere forniti, tali caricamenti devono essere archiviati da qualche parte al di fuori della radice Web. Altrimenti, potresti scoprire che le persone stanno scaricando file che dovevano essere segreti. Ad esempio, se consenti agli studenti di inviare i compiti, dovrebbero essere salvati in una directory che non è servita da Apache. Questo è anche un buon approccio per i file di configurazione che contengono segreti.

Per un sito Web con requisiti più complessi, potresti voler esaminare l'uso degli elenchi di controllo degli accessi. Questi consentono un controllo dei privilegi molto più sofisticato.

Se il tuo sito Web ha requisiti complessi, potresti voler scrivere uno script che imposti tutte le autorizzazioni. Testalo accuratamente, quindi tienilo al sicuro. Potrebbe valere il suo peso in oro se ti trovassi a dover ricostruire il tuo sito web per qualche motivo.

Soluzione 2:

Mi chiedo perché così tante persone utilizzino (o raccomandino) l'"altra" (o) parte dei diritti di Linux per controllare cosa può fare Apache (e/o PHP). Impostando questa parte destra su qualcosa di diverso da "0", consenti a tutto il mondo di fare qualcosa sul file/directory.

Il mio approccio è il seguente:

• Creo due utenti separati. Uno per l'accesso SSH/SFTP (se necessario), che sarà proprietario di tutti i file, e uno per l'utente PHP FastCGI (l'utente con cui verrà eseguito il sito Web). Chiamiamo questi utenti rispettivamente bob e bob-www .
• bob avrà pieni diritti (rwx sulle cartelle, rw- su file), in modo che possa leggere e modificare l'intero sito web.
• Il processo PHP FastCGI richiede r-x diritti sulle cartelle e r-- diritti sui file, ad eccezione di cartelle molto specifiche come cache/ o uploads/ , dove è necessaria anche l'autorizzazione di "scrittura". Per dare a PHP FastCGI questa capacità, verrà eseguito come bob-www e bob-www verrà aggiunto al bob creato automaticamente gruppo.
• Ora ci assicuriamo che il proprietario e il gruppo di tutte le directory e i file siano bob bob .
• Manca qualcosa:anche noi usiamo FastCGI, ma Apache ha ancora bisogno dell'accesso in lettura, per contenuti statici, o file .htaccess che cercherà di leggere se AllowOverride è impostato su qualcosa di diverso da None . Per evitare di usare la o parte dei diritti, aggiungo www-data utente al bob gruppo.

Ora:

• Per controllare cosa può fare lo sviluppatore, possiamo giocare con la u parte dei diritti (ma questa la nota sotto).
• Per controllare cosa possono fare Apache e PHP, possiamo giocare con la g parte dei diritti.
• La o part è sempre impostato su 0, quindi nessun altro sul server può leggere o modificare il sito web.
• Non ci sono problemi quando bob l'utente crea nuovi file, poiché apparterrà automaticamente al suo gruppo principale (bob ).

Questo è un riepilogo, ma in questa situazione, bob è autorizzato a SSH. Se non ci dovrebbe essere nessun utente autorizzato a modificare il sito web (ad es. il cliente modifica il sito web solo tramite un pannello di amministrazione CMS e non ha conoscenza di Linux), crea comunque due utenti, ma dai /bin/false come guscio per bob e disabilitarne l'accesso.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Nota : le persone tendono a dimenticare che limitare la u (proprietario) è il più delle volte inutile e insicuro, poiché il proprietario di un file può eseguire il chmod comando, anche i diritti sono 000.

Dimmi se il mio approccio ha qualche problema di sicurezza, perché non ne sono sicuro al 100%, ma è quello che sto usando.

Penso che questa configurazione abbia un problema:quando PHP/Apache crea un nuovo file (ad esempio upload), apparterrà a bob-www:bob e bob sarà solo in grado di leggerlo. Forse setuid sulla directory può risolvere il problema.

Soluzione 3:

Dato il ranking di Google sulla risposta eccellente di cui sopra, penso che ci sia una cosa che dovrebbe essere notata e non riesco a lasciare una nota dopo la risposta.

Continuando con l'esempio, se prevedi di utilizzare www-data come proprietario e dev-fabrikam come gruppo con autorizzazioni 570 sulla directory (o file), è importante notare che Linux ignora setuid , quindi tutti i nuovi file saranno di proprietà dell'utente che li ha creati. Ciò significa che dopo aver creato nuove directory e file dovrai usare qualcosa di simile a:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

In Ubuntu 12.04 per Rackspace OpenStack, ho riscontrato uno strano problema in cui non riuscivo a ottenere le autorizzazioni 570 per funzionare fino a quando non ho riavviato il server, che ha risolto magicamente il problema. Stavo perdendo i capelli a un ritmo crescente per quel problema apparentemente semplice....

Soluzione 4:

Vado con questa configurazione:

1. Tutte le directory tranne quella dei caricamenti impostate sul proprietario root e gruppo root , autorizzazioni per 0755 .
2. Tutti i file impostati sul proprietario root e gruppo root , autorizzazioni a 0644 .
3. Carica la directory impostata sul proprietario root , gruppo www-data , autorizzazioni a 1770 . Lo sticky bit non consente al proprietario del gruppo di rimuovere o rinominare la directory ei file all'interno.
4. All'interno della cartella dei caricamenti una nuova directory con www-data utente e gruppo proprietario e 0700 autorizzazioni per ogni www-data utente che carica i file.
5. Configurazione di Apache:

Nega AllowOverride e Index nella directory degli upload, in modo che Apache non legga .htaccess file e l'utente Apache non può indicizzare il contenuto della cartella dei caricamenti:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.ini configurazione:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Con questa configurazione, il www-data l'utente non sarà in grado di accedere a directory diverse da siteDir/ /tmp e /usr/share/phpmyadmin . Inoltre puoi controllare la dimensione massima del file, la dimensione massima del post e il numero massimo di file da caricare nella stessa richiesta.

Soluzione 5:

Quando hai un utente FTP chiamato "leo" devi caricare i file nella directory web example.com e hai anche bisogno che il tuo utente "apache" sia in grado di creare file uploa/sessioni/file cache nella directory cache, quindi procedi come segue:

Questo comando assegna leo come proprietario e gruppo come apache a example.com, l'utente apache fa parte del gruppo apache quindi erediterà i permessi del gruppo apache

chown -R leo:apache example.com

Un altro comando che assicura il giusto permesso e soddisfa anche i problemi di sicurezza.

chmod -R 2774 example.com

Qui il primo numero 2 è per la directory e assicura che ogni nuovo file creato rimarrà nello stesso gruppo e nelle stesse autorizzazioni del proprietario. 77 è per il proprietario e il gruppo significa che hanno pieno accesso. 4 è per gli altri significa che possono solo leggere attraverso.

quanto segue è utile per comprendere i numeri di autorizzazione

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7