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.
Gli utenti autenticati 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. Solitamente apportano modifiche al sistema utilizzando SSH o SFTP.
Gli utenti anonimi 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 degli utenti anonimi facendo attenzione alle autorizzazioni del processo del server Web. Su molte distribuzioni Linux, Apache viene eseguito come www-datautente ma può essere diverso. Usa ps aux | grep httpdo ps aux | grep apacheper vedere quale utente Apache sta usando sul tuo sistema.
Note sui permessi di Linux
Linux e altri sistemi conformi a POSIX utilizzano le autorizzazioni unix tradizionali. C'è un eccellente articolo su Wikipedia sulle autorizzazioni del filesystem, quindi non ripeterò tutto qui. Ma ci sono alcune cose di cui dovresti essere consapevole.
Il bit di esecuzione Gli
script interpretati (ad es. Ruby, PHP) funzionano bene senza il permesso di esecuzione. Solo i binari e gli script di shell richiedono il bit di esecuzione. Per attraversare (entrare) 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 tutti i file al suo interno.
Autorizzazioni predefinite per i nuovi file
Quando viene creato, un file eredita normalmente l'ID di gruppo di chiunque lo abbia creato. Ma a volte vuoi che i nuovi file ereditino l'id di gruppo della cartella in cui vengono creati, quindi abiliterai il bit SGID sulla cartella principale.
I valori di autorizzazione predefiniti dipendono dal tuo umask. Umask sottrae le autorizzazioni dai file appena creati, quindi il valore comune di 022 determina la creazione di file con 755. Quando si collabora con un gruppo, è utile cambiare umask in 002 in modo che i file creati possano essere modificati dai membri del gruppo. E se si desidera personalizzare le autorizzazioni dei file caricati, è necessario modificare umask per apache o eseguire chmod dopo che il file è stato caricato.
Il problema con 777
Quando sei sul chmod 777tuo sito web, non hai alcuna sicurezza. Qualsiasi utente sul 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 ci sono vulnerabilità di programmazione nel tuo sito Web, possono essere sfruttate per sfigurare il tuo sito Web, inserire attacchi di phishing o rubare informazioni dal tuo server senza che tu lo sappia.
Inoltre, se il tuo server gira su una porta ben nota (che dovrebbe impedire agli utenti non root di generare servizi di ascolto accessibili in tutto il mondo), ciò 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 è vincolata). In altre parole, se stai eseguendo un server web in cui l'eseguibile principale fa parte del controllo versione (ad esempio un'app CGI), lasciando le sue autorizzazioni (o, in tal caso, le autorizzazioni della directory contenente, poiché l'utente potrebbe rinominare l'eseguibile) a 777 consente a qualsiasi utente di eseguire qualsiasi eseguibile come root.
Definire 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 su directory per poter navigare
- Apache necessita dell'accesso in lettura ai file e agli script interpretati
- Apache necessita dell'accesso in lettura / esecuzione a directory gestibili
- Apache necessita dell'accesso in lettura / scrittura / esecuzione alle directory per il contenuto caricato
Gestito 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 tutte le autorizzazioni rwx. Apache ha ancora bisogno dell'accesso per poter servire i file, quindi imposta www-data come proprietario del gruppo e dai al gruppo le autorizzazioni rx.
Nel tuo caso, Eva, il cui nome utente potrebbe essere eve, è l'unico utente che mantiene 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 hai 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, poiché solo i proprietari di utenti e gruppi possono navigare nella directory del tuo sito web. Ciò è utile se si hanno dati segreti nei file di configurazione. Fai attenzione alla tua umask! Se si crea un nuovo file qui, i valori di autorizzazione saranno probabilmente impostati su 755. È possibile eseguire in umask 027modo che i nuovi file siano impostati su 640 ( rw- r-- ---).
Gestito da un gruppo di utenti
Se più di un utente è responsabile della manutenzione del sito, sarà necessario creare un gruppo da utilizzare per assegnare le autorizzazioni. È buona norma creare un gruppo separato per ciascun sito Web e denominare il gruppo come tale sito Web.
groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob
Nell'esempio precedente, abbiamo usato il proprietario del gruppo per dare privilegi ad Apache, ma ora viene usato per il gruppo di sviluppatori. Dato che il proprietario dell'utente non ci è più utile, impostarlo su root è un modo semplice per garantire che non vi siano privilegi. Apache ha ancora bisogno di 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 hai cartelle che devono essere scrivibili da Apache, puoi impostare Apache come proprietario dell'utente o proprietario del gruppo. Ad ogni modo, avrà tutto l'accesso di cui ha bisogno. Personalmente, preferisco renderlo il proprietario dell'utente in modo che gli sviluppatori possano comunque navigare e modificare il contenuto 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. Dal momento che ogni altro utente sul sistema ha gli stessi privilegi sul tuo sito Web di Apache, è facile per gli altri utenti navigare nel tuo sito e leggere file che possono contenere dati segreti, come i file di configurazione.
Puoi avere la tua torta e mangiarla anche tu
Questo può essere ulteriormente migliorato. È perfettamente legale per il proprietario avere meno privilegi rispetto al gruppo, quindi invece di sprecare il proprietario dell'utente assegnandolo a root, possiamo rendere Apache il proprietario dell'utente nelle directory e nei file del 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 hai 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 finché non li chown.
* Separazione dei privilegi di Apache
Ho accennato in precedenza che è effettivamente possibile che altri utenti curiosino 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 in grado di far eseguire ad Apache uno script può ottenere lo stesso accesso di cui dispone 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 avviso, qualsiasi sito con requisiti di sicurezza più elevati dovrebbe essere eseguito su un server dedicato anziché utilizzare VirtualHosts su un server condiviso.
Ulteriori considerazioni
Non ne ho parlato prima, ma di solito è una cattiva pratica avere sviluppatori che modificano direttamente il sito web. Per i siti più grandi, è molto meglio avere un qualche tipo di sistema di rilascio che aggiorna il server web dal contenuto di un sistema di controllo della versione. L'approccio del manutentore singolo è probabilmente l'ideale, ma al posto di una persona hai un software automatizzato.
Se il tuo sito Web consente caricamenti che non devono essere pubblicati, tali caricamenti devono essere archiviati in un luogo esterno alla radice Web. Altrimenti, potresti scoprire che le persone stanno scaricando file che erano destinati a essere segreti. Ad esempio, se si consente agli studenti di inviare compiti, questi devono 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, è possibile esaminare l'utilizzo degli elenchi di controllo di accesso . Ciò consente un controllo molto più sofisticato dei privilegi.
Se il tuo sito Web ha requisiti complessi, potresti voler scrivere uno script che configuri tutte le autorizzazioni. Provalo accuratamente, quindi tienilo al sicuro. Potrebbe valere la pena il suo peso in oro se mai ti ritrovassi a dover ricostruire il tuo sito Web per qualche motivo.