Quale utente dovrebbe essere in esecuzione apache e PHP? Quali autorizzazioni dovrebbero avere i file / var / www?

Ho appena avviato una casella Ubuntu 11.10 e poi ho eseguito apt-get install apache2 php5l'installazione di apache2 e PHP 5 sulla confezione. Ora funziona come un "web server" e carica "Funziona!" pagina. Ora sto cercando di rafforzare la sicurezza e ho le seguenti domande sui server Web Linux:

1. Chi dovrebbe eseguire Apache?
2. In quale gruppo dovrebbe appartenere questo utente?
3. Quali pacchetti possono far funzionare PHP (e Apache?) Come proprietario dei file? (come su host web condivisi) Devo usare questi pacchetti? Sono facili / fattibili da mantenere su un piccolo sistema?
4. Quali dovrebbero essere le autorizzazioni predefinite per i file e le cartelle pubblicati sul Web con apache in esecuzione www-data? Per apache / php in esecuzione come utente?

Ho eseguito le seguenti operazioni esaminando l'impostazione predefinita:

Struttura del file

Quando cd /faccio un ls -alelenco dei contenuti, vedo /var:

drwxr-xr-x 13 root root  4096 2012-02-04 20:47 var/

Se cdentro vare ls -alvedo:

drwxr-xr-x  2 root root  4096 2012-02-04 20:47 www/

Infine, dentro /var/wwwvedo:

drwxr-xr-x  2 root root 4096 2012-02-04 20:47 ./
drwxr-xr-x 13 root root 4096 2012-02-04 20:47 ../
-rw-r--r--  1 root root  177 2012-02-04 20:47 index.html

Il mio punto chiave è che finora tutti questi file appartengono root:root, i file hanno autorizzazioni di 644 e le directory hanno autorizzazioni di 755.

Autorizzazioni di Apache

Se creo un file come root /var/www/test.phpcon il contenuto:

<?php echo shell_exec('whoami');

e carica quel file in un browser che mi dice www-data, che è lo stesso del /etc/apache2/envvarsfile:

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

Se lo faccio ps aux | grep -i apachevedo quanto segue:

root      1916  1.2 104664  7488 Ss   20:47 /usr/sbin/apache2 -k start
www-data  1920  0.8 105144  5436 S    20:47 /usr/sbin/apache2 -k start
www-data  1921  1.0 105144  6312 S    20:47 /usr/sbin/apache2 -k start
www-data  1922  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start
www-data  1923  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start
www-data  1924  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start
www-data  1925  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start

Quindi, chi sta eseguendo apache? Sembra che forse il primo processo sia come root, forse dallo /etc/init.d/apachescript all'avvio del sistema, e gli altri come www-datagenerati dal primo. È corretto?

Quindi, se digito, groups www-datavedo www-data : www-data- quindi sembra essere solo nel www-datagruppo. Immagino che anche questa sia una pratica standard.

Hosting condiviso e sicurezza

Quindi, se capisco le cose correttamente, se apache è in esecuzione come www-datae voglio che apache sia in grado di leggere una directory, il xbit deve essere impostato per il mondo (altro) gruppo ( o+x), e anche questo deve essere impostato su tutti i genitori directory su tutta la catena ( www, var). E se voglio che Apache sia in grado di leggere da un file, allora il o+rbit deve essere impostato.

Sfortunatamente credo che ciò introduca un buco nella sicurezza per più applicazioni e / o più utenti sulla stessa casella di Linux: tutti i file Web devono essere leggibili in tutto il mondo e quindi sono accessibili anche da altre applicazioni e altri utenti sul sistema. Se un'applicazione installata sul sistema presentava una vulnerabilità di sicurezza che consentiva input utente non convalidati e non elaborati, che veniva quindi eseguito da PHP, un utente malintenzionato remoto poteva quindi sfogliare tutti gli altri file sul sistema Web leggibili a livello mondiale. Allo stesso modo, se la casella aveva più utenti e un utente conosceva il percorso dei file Web di un altro utente, poteva quindi leggere il contenuto del file (e vedere cose sensibili come stringhe di connessione al database, ecc.).

Ho sentito parlare di due pacchetti, suphpe phpsuexecche si occupano di consentire i file degli utenti per essere servito fuori 'come li' su un sistema condiviso. Uno dei vantaggi di questo è che consente alle applicazioni Web (come Wordpress) di creare e modificare file, molto utile per l'aggiunta di temi, plugin e software di aggiornamento. Naturalmente è probabilmente più sicuro fare queste cose manualmente, ma può essere fatto un compromesso forse con uno dei pacchetti sopra menzionati? O forse usando chownper far appartenere il gruppo di directory di wordpress www-datae impostare il bit appiccicoso sul gruppo ( g+s)?

Li ho usati solo come utente finale di una società di web hosting, quindi non conosco i dettagli di essi e se sono persino ragionevoli da installare su un piccolo sistema o se ce ne sono altri misure di sicurezza che dovrei usare invece, ma ho pensato di menzionarle qui in quanto sembrano un modo possibile per affrontare alcune delle mie preoccupazioni.

Torna alle domande

1. Chi dovrebbe eseguire Apache?
2. In quale gruppo dovrebbe appartenere questo utente?
3. Quali pacchetti possono far funzionare PHP (e Apache?) Come proprietario dei file? (come su host web condivisi) Devo usare questi pacchetti? Sono facili / fattibili da mantenere su un piccolo sistema?
4. Quali dovrebbero essere le autorizzazioni predefinite per i file e le cartelle pubblicati sul Web con apache in esecuzione www-data? Per apache / php in esecuzione come utente?

1. non root
2. non root
3. suexec
4. Dipende. 644 per i file e 755 per le cartelle sono valori predefiniti sicuri.

Non modificare la proprietà di nulla in dati www a meno che tu non voglia che php sia in grado di modificare il contenuto di quel file / cartella

Indipendentemente da qualsiasi altra cosa tu faccia: le cartelle necessitano delle autorizzazioni di lettura ed esecuzione per consentire all'utente di trovare i file; i file necessitano delle autorizzazioni di lettura affinché l'utente possa leggerle. Se si verificano errori di autorizzazione quando si cambiano le cose, si è riusciti a rimuovere queste autorizzazioni fondamentalmente richieste.

Se non stai scrivendo alcun file tramite l'applicazione php, puoi lasciare file di tua proprietà: tu. In questa circostanza si applica l'autorizzazione mondiale (xx4 / 5).

Se lasci i file come di tua proprietà: tu con permessi per i file di 644 (file) ciò significherebbe che solo tu puoi modificare i file del sito Web - www-data non sei tu - quindi non puoi modificare i file.

Se vuoi limitare l'accesso ad apache + te e bloccare tutti gli altri accessi chown -R you:www-data *. Con le autorizzazioni per i file di 640 e le autorizzazioni per le cartelle di 750 che è possibile modificare, www-data può leggere, perché Apache legge l'autorizzazione di gruppo (x4 / 5x).

Limitare al minimo i percorsi in cui si consente a apache / php di scrivere - se esiste una directory tmp su cui l'applicazione deve scrivere - consentirle di scrivere solo in quella cartella - e per eventuali posizioni scrivibili, se possibile, assicurarsi che sia al di fuori del document root o prendere provvedimenti per garantire che questo percorso scrivibile non sia accessibile dal web.

Nota che "tu" non dovrebbe essere root. Consentire l'accesso diretto a ssh come root è un indicatore di altri cali di sicurezza (come non impedire l'accesso con password), ma si tratta di una serie di domande a sé.

Quindi, se capisco le cose correttamente, se apache funziona come www-data e voglio che apache sia in grado di leggere una directory, il bit x deve essere impostato per il gruppo world (altro) (o + x), e anche quello deve essere impostato su tutte le directory principali fino alla catena (www, var). E se voglio che apache sia in grado di leggere da un file, è necessario impostare il bit o + r.

Questo non è vero, non è necessario impostare rwxsu "altro". È necessario modificare il proprietario e / o il gruppo della cartella / file particolare che si sta tentando di proteggere. Per esempio:

chown -R cwd:www-data /var/www/cwd.com
chmod 750 /var/www/cwd.com

Ora solo i membri del gruppo www-datapossono leggere /var/www/cwd.com. E solo tu (cwd) puoi scriverci. Se vuoi consentire alle tue applicazioni (tramite Apache) di scrivere / modificare anche i file in quella directory, chmod a 770.

Penso che questo copra tutti i tuoi problemi, non vedo alcun motivo per cambiare l'utente con cui funziona Apache.