ProxyPass è più sicuro di hosting diretto del sito PHP?

Dipenderà dal tuo modello di minaccia, "sicuro contro cosa "?

La maggior parte delle vulnerabilità delle applicazioni (lato PHP) non sono correlate al server Web o all'architettura; saranno causati da richieste HTTP perfettamente normali e legali che sono illegali o non pianificate, a livello di applicazione PHP. Per esempio. il classico

GET /...login.php?user=' OR 1=1;&pass=

Contro questo ampio spettro di possibili attacchi, c'è poco che il modulo Apache o NginX possano fare per te, e nessun vero motivo per scegliere l'uno sull'altro.

Poi c'è la possibilità di attaccare direttamente il server HTTP . Non è molto probabile (anche se può succedere) che una richiesta forgiata contro cui Apache è vulnerabile possa passare NginX indenne, tanto meno essere riformattato in letalità ad Apache da NginX stesso. Possiamo quindi ragionevolmente presumere che nella struttura di NginX + fastcgi, NginX sia l'unico punto vulnerabile a tali attacchi.

Quindi penso che NginX dovrebbe fornire un ulteriore livello di sicurezza, se eseguito su una macchina propria , con monitoraggio appropriato e privilegi ridotti (di cui NginX avrebbe bisogno di molto meno di PHP) .

Quindi, attaccando il sistema, NginX sarebbe stato sovvertito e si sarebbe schiantato (o si sarebbe altrimenti tradito), e avrebbe fermato l'attacco; o lasciando la scatola NginX compromessa e completamente aperta all'attaccante.

In quest'ultimo caso non sei peggio che con PHP direttamente esposto, per quanto riguarda la tua applicazione; in entrambi i casi non c'è nulla tra te e una casella controllata da un attaccante (solo ora sta operando da una scatola sconosciuta, e c'è una leggera consolazione lì).

Per quanto riguarda il resto del mondo, ora le cose sono possibili (e potresti essere ritenuto responsabile per loro) che non erano precedenti: ad esempio, lo scopo dell'attaccante non avrebbe potuto compromettere la tua applicazione, ma solo per ottenere un punto d'appoggio sulla macchina NginX per operare come zombi o zampa di gatto contro qualcos'altro. In questo scenario hai effettivamente aumentato la superficie di attacco: un utente malintenzionato alla ricerca di NginX vulnerabili non avrebbe avuto motivo di attaccare un'installazione PHP.

Se NginX viene eseguito sulla stessa macchina dell'applicazione PHP, il rischio complessivo aumenta. Su una macchina separata, direi che il rischio ... cambia , sia per tipo che per livello.

Se difeso in modo appropriato, può diminuire; e puoi trarre alcuni benefici dall'essere in grado di destreggiarsi con diversi fastcgis con impostazioni diverse o con macchine diverse per distribuire il carico con facilità. Se non monitora e mantieni anche la confezione di NginX, ad esempio se non aumenti la superficie di manutenzione e il costo, il rischio potrebbe aumentare nuovamente.

Quindi, a cosa serve tutto questo, non è tanto una questione di NginX rispetto a un modulo di Apache, ma di quale distribuzione di NginX (e manutenzione) contro quale distribuzione di Apache (e manutenzione ) .

A parità di tutti gli altri (vale a dire lo stesso livello di costi e sforzi, su Apache da solo o condivisi tra PHP e NginX), preferirei mantenere le cose semplici e il mio attacco di superficie piccolo, e vai con il modulo Apache. Se pensi che potresti trarre vantaggio dal bilanciamento del carico in futuro e sei disposto a sostenere i costi aggiuntivi, NginX sarebbe una scelta adatta ora.

nginx è giovane e finora ha avuto un track record di sicurezza terribile . È più probabile che nginx subisca ancora un'altra vulnerabilità critica rispetto a un HTTPD più stagionato come Apache o IIS (gasp!).