Gestori PHP e memorizzazione nella cache

Se non stai eseguendo una cache di opcode, allora stai già dosando te stesso, soprattutto se stai usando Drupal! È un buon modello di business se noleggi l'hardware del server!

Ci sono alcuni casi limite in cui il funzionamento di suPHP ha senso dal punto di vista della sicurezza (ma il numero di questi è enormemente ridotto dal supporto di php-fpm dei pool per utente) - ma questo non è uno di questi. (se si stesse utilizzando php-fpm, potrebbe valere la pena di prendere in considerazione un utente dedicato per gestire il percorso di caricamento del file).

La migliore protezione contro un attacco DOS sta avendo la capacità di affrontarlo. La seconda opzione migliore è quella di poter profilare l'attacco e iniettare facilmente una specifica gestione / blocco.

and removed write privileges for any directory/file except where image uploads, etc may occur.

Questo non è abbastanza da solo - devi anche disabilitare l'analisi PHP (e, preferibilmente qualsiasi accesso diretto al web server) alla directory degli upload.

Controllare il tuo server tramite WHM non è una buona idea se sei preoccupato per la sicurezza.

Riguardo all'attacco precedente ... questa è una domanda separata, e non ci sono quasi abbastanza informazioni per azzardare un'ipotesi - anche se tali informazioni fossero disponibili, probabilmente è al di là della portata di una risposta qui. È piuttosto improbabile che la configurazione di PHP provochi i symptpoms che descrivi ("Ricordo che un amministratore non vede le pagine protette da privilegi di amministratore") - è più probabile che si tratti di un difetto / problema di codice altrove nello stack.

Potresti non essere in grado di utilizzare il caching opcode (come APC), ma non c'è nulla che dica che non puoi usare la funzionalità di caching di Drupal per risolvere alcuni dei problemi di prestazioni ( collegamento ). Certo, non è la stessa cosa del caching dell'opcode, ma con suPHP ci sono molti compromessi.

Ricorda, tutto ciò che la tua applicazione invia (incluso Javascript) è aperto a chiunque o qualcosa da leggere. Questo "clic" che descrivi potrebbe essere stato facilmente uno script che chiama qualsiasi cosa la tua richiesta Ajax stava chiamando direttamente.

Inoltre, per favore disabilita l'impostazione php.ini "display_errors" in produzione. Ciò impedisce il normale ritorno del messaggio di errore all'app / script richiedente (eccetto per errori fatali). La maggior parte dei problemi relativi a MySQL, inclusi i problemi di connessione, sono avvisi in modo da non causare problemi. Puoi utilizzare ini_set per modificare questo valore in fase di runtime ( link ).