2009-08-20 10 views
5

Esistono misure di sicurezza speciali da adottare quando si distribuisce un sito Drupal su un server di produzione?hardening drupal per un'implementazione dal vivo

Ad esempio: posso immaginare che è necessario rimuovere install.php dalla directory principale. Ci sono altre azioni?

O c'è forse un modulo a disposizione, che controlla il sito per "prontezza mondo"

risposta

0

Si dovrebbe anche rimuovere l'impostazione del Registro Tema ricostruzione.

Ricompila il registro dei temi su ogni pageload, quindi rende il tuo sito molto lento.

+0

Questa impostazione è disattivata per impostazione predefinita. – ceejayoz

+1

Non correlato all'indurimento. –

1

Oltre agli altri suggerimenti, rimuovere anche update.php.

Mi piacerebbe anche (ri) spostare/script dal Webroot

E 'una cosa minore, ma si potrebbe rimuovere i file di testo nella directory principale della distribuzione, che trapelare il numero di versione. Ad esempio CHANGELOG.txt, ecc.

Non ricordo con quale cron.php si protegge da flood-calling. Si consiglia di verificare se vale la pena limitare l'accesso solo locale o da riga di comando.

Assicurarsi che i file .inc vengano elaborati da PHP.

+1

Non abbiamo mai ritenuto necessario rimuovere update.php - è vietato l'utilizzo da parte di chiunque tranne l'utente amministratore 0, e se un hacker ha accesso a questo, beh, sei nei guai. Non è necessario spostare o rimuovere alcun file durante l'installazione di drupal e il problema è che quando si aggiorna Drupal alla prossima versione di sicurezza, si può finire con i file in due punti, con la confusione e errori che potrebbero causare. –

+0

La domanda riguardava la sicurezza, non la facilità di installazione. Un approccio a più livelli alla sicurezza è sempre una buona idea. Quanto lontano tenga dipende da te. Hai certamente ragione nel dire che devi riesaminare il set di file su ogni aggiornamento. Ma ci sono alcuni buoni motivi per lasciare file eseguibili che non è necessario aggirarsi nel webroot. Si tratta di limitare la superficie di attacco, se una vulnerabilità sconosciuta dovesse essere introdotta in un'applicazione (forse diversa). – Cheekysoft

+0

+1 per la partecipazione a problemi minori come la perdita di versione e la nozione di sicurezza a più livelli. – Omniwombat

5

Il rapporto di stato su http://your-site/admin/reports/status indica se qualcosa non va bene.

Nella pagina di amministrazione delle prestazioni è possibile attivare varie impostazioni di memorizzazione nella cache, ma testare il sito con esse attivate prima della distribuzione.

C'è un book by greggles per la protezione drupal, che può valere la pena dare un'occhiata.

+0

Sì, questo. Assicurati che la password dell'amministratore sia un po 'gobblygook, non qualcosa che la gente ricorderà, e suggerisci al cliente di non usarla a meno che non sia assolutamente necessario. Assicurarsi inoltre che le impostazioni del database siano tali da consentire solo le connessioni localhost e avere anche una password casuale simile per quella connessione. –

1

tutto questo le risposte farvi smettere di pensare dopo l'installazione è fatto - ma il software ha una storia e dopo l'installazione di Drupal si dispone di un bambino più da guardare - in drupal's caso orologio molto da vicino! Ciò significa che DEVI abbonarti alla mailing list di sicurezza drupal e leggere tutte le mail che arrivano da lì: preparati a ricevere molte e-mail. È positivo che il team di drupal stia fornendo queste informazioni velocemente, ma è triste che ci siano davvero troppe di queste mail, che potrebbero essere correlate allo stile di programmazione della drupal. preparatevi ad alzarvi più di una volta nel cuore della notte per aggiornare la vostra installazione drupal perché alcuni sviluppatori di estensioni non hanno mai capito, perché l'input dal web deve essere disinfettato (sì, questo tipo di problemi di sicurezza si verificano ancora nel mondo drupal .) Quindi "indurire" significa "tenere il passo con gli aggiornamenti", nel caso delle drupali questi vengono abbastanza spesso. Pensa a questo se hai molti siti e vuoi distribuirli su più server: i deploymemts automatici ti aiuteranno a risparmiare un sacco di tempo.

2

Idealmente hai testato il codice per le insicurezze prima della distribuzione, ma la configurazione può spesso mancare.C'è un modo per analizzare il vostro sito Drupal per errori di configurazione che avrebbe portato alla vulnerabilità http://drupal.org/project/security_review

di riesame sulla sicurezza rende i seguenti controlli:

  • permessi sicuro su file di sistema
  • PHP nei commenti o nodi
  • Sia segnalazione degli errori è
  • Formati di input non sicuri
  • Se i file privati ​​sono attivi e se la directory dei file è esterna a webroot
  • estensioni di upload ammessi
  • autorizzazioni di amministratore concessi agli utenti non attendibili
Problemi correlati