Apache, suexec, PHP, suPHP

Mentre sono abbastanza a mio agio come utente Linux , il mio Admin-fu Linux è un po 'debole. Quindi, sono qui alla ricerca di una guida con un server CentOS che sto per costruire.

Devo configurare un server Web Apache2 per alcuni dei nostri clienti. Voglio che il contenuto Web di ogni client sia nella loro home directory ( USERDIRin apache.conf, giusto?) Per i siti HTML statici. Voglio che Apache funzioni come client ( suexec?). Alcune delle loro cose saranno app PHP e ho l'impressione che vorrò guardare suphpanche allora.

Quindi in pratica voglio sembrare una versione ridotta di una società di web hosting condivisa. Considerando quanto comuni quelli sono ho pensato di trovare facilmente un bel corrente how-to guida su come impostare questo tutto in su, ma finora non ho avuto molto poca fortuna. Sospetto che le mie parole di ricerca siano disattivate.

Quindi le domande (sentiti libero di rispondere a una o tutte):

1. Qualcuno ha alcuni collegamenti solidi alle guide attuali / moderne che mi aiuterebbero a impostare tutto questo? No, il sito di documentazione di Apache non è una guida ;-)
2. Dal momento che ho un mix di siti statici e app PHP, voglio / ho bisogno di installare sia suexec che suphp? In tal caso, ciò introduce delle sfide di cui dovrei essere consapevole?
3. Dovrei guardare altre opzioni invece di suexec e suphp?

Ho intenzione di dare agli utenti finali SSH, SFTP o SCP l'accesso alle loro cose (se ciò influisce su qualcosa).

Grazie in anticipo per il vostro aiuto.

[Modifica] Avrei dovuto menzionarlo prima: un obiettivo chiave della mia ricerca per emulare un provider di hosting condiviso relativo ai permessi e alla proprietà dei file. Mi piacerebbe davvero evitare di insegnare agli utenti la necessità di cambiare tali cose solo per vedere le loro aggiunte / modifiche.

L'uso di suexec e suphp impone un tipo di separazione dei privilegi diverso da quello predefinito.

L'impostazione predefinita è separare l'autorizzazione dell'utente dal server Web. Cioè, l'utente possiede i file e deve concedere al server Web l'autorizzazione per visualizzarli e modificarli.

Il modello suexec / suphp è che il server web (durante l'esecuzione di script) viene eseguito con l'account dell'utente, quindi il sito Web ha il permesso di fare tutto ciò che l'utente ha il permesso di fare. In una certa misura, questo elimina la separazione tra l'utente e il server web, ma in cambio applica una separazione DIVERSA: cioè tra il sito Web di un utente e il sito Web di un altro utente nella stessa casella.

Per impostazione predefinita, PHP viene sempre eseguito con l'account utente di Apache, quindi gli script PHP di un sito Web possono accedere a tutti i file che gli script PHP di un altro sito possono fare. Pertanto, se un account sul server viene violato, l'infezione può diffondersi agli altri. SuPHP lo impedisce.

Né suexec né suphp influenzeranno il modo in cui apache serve contenuto statico . Tutte le vecchie regole si applicano ancora. Invece, suexec e suphp cambiano l'account con cui verranno eseguiti CGI e PHP (rispettivamente). Suexec fa eseguire l'eseguibile CGI con l'account del proprietario, mentre SuPHP esegue gli script PHP con l'account del proprietario.

Suexec e SuPHP non sono necessariamente migliori . Sono solo diversi . Non impediranno che un sito Web venga violato (e probabilmente potrebbe rendere più facile l'hacking del sito ), ma impediranno a un compromesso su un sito di diffondersi a tutti gli altri. Per l'amministratore del sito, questo isolamento è probabilmente più importante, motivo per cui alcuni sistemi di hosting condiviso rendono suexec e suphp l'impostazione predefinita.

Un "gotcha" estremamente comune è che SuPHP controlla la proprietà e le autorizzazioni di uno script prima che venga eseguito e restituirà un errore 500 se le autorizzazioni non sono appropriate.

In particolare:

• Il proprietario e il gruppo del file devono corrispondere al proprietario del sito Web (come impostazione nella configurazione di Apache)
• Il file non deve essere scrivibile dal mondo
• La directory padre non deve essere scrivibile in tutto il mondo