Risposte:
Prima di tutto, tieni presente che qualsiasi capacità di scripting in Apache (php, cgi, ruby, ...) è il potenziale equivalente di un account di shell con privilegi dell'utente che esegue lo script.
Se il server è condiviso con più utenti, potresti pensare di usare suexec (- o ITK MPM - Suggerito da David Schmitt ) in modo che non tutti gli script vengano eseguiti come lo stesso utente apache.
Virtualizza o chroot apache, in modo che qualsiasi compromesso sia almeno in qualche modo contenuto in un ulteriore livello di sicurezza. Tieni presente che quando chroot apache, la manutenzione potrebbe diventare più difficile, poiché finirai per spostare le librerie nella prigione ecc. Se sei su FreeBSD puoi invece usare una prigione, che è molto più facile da mantenere, poiché puoi semplicemente installare apache dalle porte ed esegui portaudit al suo interno, senza doversi preoccupare delle dipendenze della libreria e dello spostamento manuale dei file, che diventa sempre un brutto pasticcio. Con le jail BSD puoi semplicemente continuare a utilizzare il sistema di gestione dei pacchetti (porte). (Su GNU / Linux puoi anche usare VServer per la virtualizzazione. - Suggerito da David Schmitt )
(ovviamente) Resta al passo con aggiornamenti e patch, non solo per Apache, ma anche PHP, ruby, perl, ecc ... non fidarti solo del tuo sistema operativo per darti tutti gli aggiornamenti. Alcune distro sono estremamente lente con le loro patch. Limitare il più possibile il tempo di esposizione alle vulnerabilità di 0 giorni. Attaccare il milw0rm avanzamento nel tuo lettore RSS, iscriviti ai insecure.org mailing list, ecc ... Non solo lo aiuterà a conoscere le vulnerabilità prima che il sistema operativo ottiene intorno al rilascio di una patch, potrete anche conoscere le vulnerabilità in alcuni php applicazioni cms per esempio, che potrebbero non essere nemmeno gestite o patchate dal tuo sistema operativo.
Usa qualcosa come tripwire / aide, audit o mtree (su BSD) per tenere traccia delle modifiche sul tuo filesystem. Questo è davvero importante. Ti invieremo periodicamente le modifiche, esaminandole manualmente, ogni giorno. Se qualche file cambia e non dovrebbe cambiare, scopri perché. Se qualche javascript dannoso viene in qualche modo inserito nelle tue pagine con qualsiasi metodo, lo prenderai in questo modo. Questo non solo salva il tuo server, ma anche i tuoi utenti, poiché le tue pagine web possono essere abusate per infettare i tuoi visitatori. (Questa è una tattica molto comune, gli aggressori spesso non si preoccupano nemmeno del tuo server, vogliono solo infettare il maggior numero possibile di visitatori fino a quando non vengono scoperti. Questi aggressori non si preoccupano nemmeno di nascondere le loro tracce di solito. È molto importante cogliere un compromesso come questo il più velocemente possibile.)
Usare cose come la suhosin per proteggere il php aiuta. Ma impara anche a capirlo, modifica la configurazione dei parametri previsti della tua applicazione.
L'uso di una patch del kernel come PaX può aiutarti a proteggerti da molte vulnerabilità di buffer overflow. Anche se il tuo software è vulnerabile. (Questo non ti rende invulnerabile, è solo un altro livello minore.)
Non essere troppo fiducioso quando si utilizza uno strumento di sicurezza. Comprendi gli strumenti che usi e usa il buon senso. Leggi, impara, tieniti il più possibile.
Prendi in considerazione l'utilizzo del controllo di accesso obbligatorio (ad esempio: SELinux ). Ti consente di specificare, per ogni applicazione, cosa è permesso fare, in modo molto dettagliato. A quali file è consentito l'accesso. Ciò che il kernel chiama è autorizzato a fare, ecc. Questo è un processo molto complicato e richiede molta comprensione. Alcune distro forniscono politiche SELinux preconfigurate per i loro pacchetti (es. Gentoo ). Questo suggerimento è in qualche modo una contraddizione con quello qui sotto, ma comunque valido.
Mantieni le cose semplici. Una complessa strategia di sicurezza potrebbe funzionare contro di te.
In Apache, imposta regole predefinite molto restrittive (Opzioni Nessuno, Nega da tutto, ecc ...) e sovrascrivi secondo necessità per VirtualHosts specifici.
Nega l'accesso a tutti i dotfile (che coprono anche immediatamente i file .htaccess)
Usa sempre https ovunque ci sia un qualche tipo di autenticazione password.
Il firewall dovrebbe essere una politica di rifiuto per impostazione predefinita. Crea alcune regole specifiche nel tuo firewall per registrare il traffico specifico.
Imposta gli script di analisi dei log per scansionare i tuoi log alla ricerca di anomalie. (la suite preludio IDS può farlo, ma onestamente, ti consiglio di creare i tuoi script nel tempo, poiché ti aiuteranno a capire meglio i tuoi strumenti e le tue regole.)
Chiedi al server di inviarti rapporti giornalieri sugli ultimi utenti che hanno effettuato l'accesso, connessioni attive, larghezza di banda utilizzata, ecc ...
Avere una cron scan per binari di suid, file scrivibili in tutto il mondo e cose del genere, e inviarle per posta.
Per tutte le cose che hai impostato che ti vengono spedite, dovresti creare un elenco di eccezioni nel tempo. (cartelle su cui ignorare le modifiche al filesystem, 777 file da consentire, file binari suid da consentire). È importante ricevere notifiche solo su cose che non dovrebbero accadere. Se ricevi una mail ogni giorno con cose banali, inizierai a ignorarle e diventeranno inutili.
Avere una buona strategia di backup ridondante a strati solidi. E non dare per scontato che fare un'immagine o una copia di tutto funzioni. Ad esempio, se MySQL è nel mezzo della scrittura su una tabella durante il backup, i file binari MySQL potrebbero essere danneggiati quando si ripristina il backup. Quindi avrai bisogno di un cron che mysqldump sia i tuoi database in cima a immagini regolari o tarball notturni o controllo della versione o qualsiasi altra cosa tu abbia impostato. Pensa alla tua strategia di backup. Voglio dire, davvero pensarci.
Non fare affidamento su elenchi come questo per motivi di sicurezza :) Davvero! Ne troverai molti su Internet, vai a leggerli tutti, ricercare ogni suggerimento e usare il buon senso e l'esperienza per prendere una decisione. Alla fine, esperienza e buon senso sono le uniche cose che ti salveranno. Non elenchi, né strumenti. Leggi, ma non limitarti a copiare senza capire.
Raccomando la lista di controllo della sicurezza di Linux , da SAN. Lo uso, oltre ad altre procedure interne. L'elenco di controllo potrebbe essere un po 'obsoleto, ma molti dei punti chiave sono veri.
Ci saranno sempre innumerevoli autorizzazioni per il controllo, innumerevoli liste di controllo, scoperta senza fine di nuovi bug / vulnerabilità. Sicurezza Non penso che sia qualcosa che accendi o spegni, è qualcosa che fai costantemente.
Dato l '"inevitabile fallimento" del software, SELinux aiuta a sollevare alcune preoccupazioni (di nuovo nessun proiettile d'argento per la sicurezza). supponendo che un'applicazione dello spazio utente sia compromessa, la corretta politica SELinux impedirà che agisca secondo i suoi consueti privilegi (cioè se SELinux fosse disabilitato o permissivo). Ciò ovviamente richiederà il monitoraggio dei log di controllo, l'analisi dei criteri installati e la modifica laddove necessario per consentire il funzionamento delle applicazioni.
Non dire che la politica di default non sarebbe d'aiuto, ma personalmente mi piace sapere cosa consente.