Questa è una domanda canonica sulla protezione di uno stack LAMP

Quali sono le linee guida assolute per proteggere un server LAMP?

La risposta di David è una buona base per i principi generali della protezione del server. Come ha indicato David, questa è una domanda enorme. Le tecniche specifiche che prendi potrebbero dipendere fortemente dal tuo ambiente e da come verrà utilizzato il tuo server. Attenzione, questo può richiedere molto lavoro in un ambiente di test per essere realizzato e fatto bene. Seguito da molto lavoro per l'integrazione nel proprio ambiente di produzione e, soprattutto, nel processo aziendale.

In primo luogo, tuttavia, controlla se la tua organizzazione ha delle politiche di protezione, poiché potrebbero essere le più direttamente pertinenti. In caso contrario, a seconda del ruolo, questo potrebbe essere un ottimo momento per costruirli. Consiglierei anche di affrontare ciascun componente separatamente dal basso verso l'alto.

L
Ci sono molte buone guide disponibili per aiutarti. Questo elenco può aiutarti o meno a seconda della tua distribuzione.

• Center for Internet Security Benchmarks - Distribuzione specifica per i principali gusti
• CentOS Hardening HowTo - Segue da vicino la guida CIS RHEL5, ma è molto più facile da leggere
• NIST SP800-123 - Guida alla sicurezza generale del server
• Schede informative sulla tempra dell'NSA - Non aggiornate di recente come CIS, ma ancora applicabili
• Tiger - Software di controllo della sicurezza del sistema live

A
Apache può essere divertente da proteggere. Trovo più facile rafforzare il sistema operativo e mantenere l'usabilità rispetto ad Apache o PHP.

• Apache Server Hardening - Questa domanda sul sito gemello di IT Security contiene molte buone informazioni.
• Benchmark per Center for Internet Security - Ancora una volta, benchmark Apache.
• Suggerimenti per la sicurezza di Apache - Direttamente dal progetto Apache, sembra che copra le basi
• Elenco di controllo per l' indurimento della DISA - Elenco di controllo dei ragazzi del DoD Information Assurance

The M

• Center for Internet Security Benchmarks - Ancora una volta, ma per i benchmark MySQL
• Indurimento MySQL OWASP
• Linee guida generali sulla sicurezza - Elenco di controllo di base dagli sviluppatori del progetto

La P
Questo si scontra a fondo con l'idea di Secure Programming Practices, che è una disciplina a sé stante. SANS e OWASP hanno una quantità ridicola di informazioni sull'argomento, quindi non proverò a replicarle qui. Mi concentrerò sulla configurazione di runtime e lascerò i tuoi sviluppatori preoccuparsi del resto. A volte la 'P' in LAMP si riferisce a Perl, ma di solito PHP. Sto assumendo quest'ultimo.

• Protezione avanzata PHP - Alcune discussioni minori, anche sul sito IT Security SE.
• Progetto PHP indurito - Progetto principale che produce Suhosin , un tentativo di correggere l'applicazione PHP per proiettare contro determinati tipi di attacchi.
• Indurimento del PHP con Suhosin - Un breve HowTo specifico per Suhosin
• Protezione di PHP da php.ini - Discussione breve ma non negativa su alcune delle opzioni di runtime legate alla sicurezza

Hai fatto una domanda che è, francamente, degna di alcuni libri sull'argomento. Ma ci sono alcune linee guida di base generali che funzionano bene:

1. Tieniti aggiornato. Ciò significa che il sistema operativo, tutti i servizi e, soprattutto, tutte le webapp in esecuzione.
2. Disabilita i servizi non necessari, limita quelli necessari all'esposizione minima (se non ti connetti in remoto a MySQL, quindi non lo ascolti su TCP) ed esegui un firewall basato su host. (Se è rigorosamente LAMP, dovresti essere bravo con 80 e 443, ma forse anche SSH per l'amministrazione.))
3. Usa password complesse. Meglio ancora, se si utilizza SSH, utilizzare solo l'autenticazione basata su chiave.
4. Assicurati di non accedere come root. Accedi come utenti e usa su & sudo.
5. Anche se non rende le cose più sicure, dovresti eseguire strumenti come logwatch in modo da essere consapevole di ciò che sta accadendo sul tuo server.

Spero che ti aiuti a iniziare.

Ecco una buona lista di controllo con cui mi piace iniziare.

Firewall

• Un buon approccio è quello di non consentire a nessun traffico di iniziare, quindi aprire solo ciò di cui hai bisogno , quando ne hai bisogno. Ciò comporta l'apertura delle porte / ips minimi per far funzionare le cose e minimizzare l'esposizione.
• Per un server LAMP potrebbe essere necessario solo aprire le porte per http / https per il mondo e ssh per gli amministratori di sistema.
• Assicurati che cose come il traffico ipv6 sia bloccato se non lo usi
• AWS fornisce gruppi di sicurezza, Linux ha iptables e molti pacchetti tra cui scegliere.

SSH e utenti

• Nessuna password per l'accesso ssh (utilizzare la chiave privata)
• Non consentire a root di ssh (gli utenti appropriati dovrebbero ssh in, quindi su o sudo)
• Usa sudo per gli utenti in modo che i comandi vengano registrati
• Registra tentativi di accesso non autorizzati (e considera il software per bloccare / vietare gli utenti che tentano di accedere al tuo server troppe volte, come fail2ban)
• ssh su una porta non standard (questo può essere utile per assicurarti di non avere poca frutta in sospeso e tenere lontano molto del fastidioso traffico, ma non farà molto per la sicurezza, in particolare da solo)
• blocca ssh solo sull'intervallo ip di cui hai bisogno (un ampio intervallo è meglio di nessun intervallo)

Banca dati

• Disinfetta i dati dell'utente
• Parametrizzare le query
• Prendi in considerazione l'astrazione del DB sulla sua stessa macchina. Questa separazione può rendere più difficile per un utente malintenzionato accedere allo stack Web e viceversa.
• Come ogni altro software aggiornato è importante.
• Un utente per ogni scopo . Quando si creano utenti, iniziare senza privilegi e aggiungere solo quelli di cui hanno bisogno per preformare il loro ruolo. Avere utenti separati per applicazioni diverse (o talvolta parti distinte di applicazioni) contribuirà a ridurre i vantaggi di un utente malintenzionato qualora compromettano un account. Fai anche attenzione con privilegi speciali come GRANT che non dovrebbero essere assegnati alla leggera.
• Avere una politica per cambiare periodicamente le password è una buona idea. Se sei preoccupato per la quantità di sforzo richiesto, ricorda che meno frequente è meglio che mai.
• Comprendi la crittografia della password. Password salt . Non usare md5!

Software

• Mantieni aggiornato il software (sistema operativo, server Web, linguaggio di scripting, CMS). Molte persone là fuori cercheranno vulnerabilità note nelle versioni precedenti (senza patch)
• Rimuovere qualsiasi software non necessario (idealmente non mantenere il pacchetto richiesto per compilare il software sui server di produzione, è meglio pre-compilare il software e renderlo disponibile come pacchetto per le macchine di produzione)
• Assicurati che le autorizzazioni per i file siano bloccate (specialmente per cose come caricamenti di utenti e file di configurazione)
• Area di amministrazione protetta da password per CMS a livello di server Web (l' autenticazione http può trovarsi di fronte a un CMS vulnerabile e aiutare a bloccare l'accesso, che è un buon modo per prevenire gli attacchi)
• Usa SSL per l'area di amministrazione e altri dati sensibili
• Automatizza la gestione dei tuoi server e della tua infrastruttura (qualcosa come Puppet, Chef o SaltStack. Se usi anche AWS CloudFormation). Questo ti aiuterà a sistemare le cose su molti server e a ridurre gli scenari come correggere le autorizzazioni sul server A ma dimenticarti di farlo sul server B
• Ove possibile, non dare via la versione particolare del tuo CMS, PHP o WebServer. Mentre oscurare queste informazioni non è sicurezza, ci sono molte persone là fuori che cercano particolari versioni di software diversi e minore è la quantità di informazioni che dai liberamente e più un hacker deve lavorare. Questo è un buon modo per assicurarti di non essere uno dei frutti a bassa pendenza. Naturalmente questo non farà nulla a qualcuno che vuole spendere un po 'più di sforzo per entrare
• Limitare le persone che hanno accesso al server

Aggiungendo ciò che David suggerisce, più modulare è la tua installazione, con ciò intendo limitare l'accesso a determinati utenti / gruppi creati appositamente per un'attività e limitarne l'ambito, più sicuro è il tuo stack LAMP: un esempio di questo è avere un utente Apache per file / cartelle Apache con autorizzazioni impostate di conseguenza e non in alcun gruppo che può accedere a file / cartelle di sistema critici. Un utente che può accedere alle tabelle MySql associate ai tuoi siti Web che intendi pubblicare e solo a tali tabelle. Inoltre, puoi limitare il loro accesso per fornire la quantità minima di accesso da una chiamata PHP. Inoltre, assicurati che il nome utente MySQL utilizzato / esposto attraverso il file PHP non sia lo stesso nome utente o password utilizzata per un altro utente.

Cosa significa: se l'utente apache o l'utente MySql sono compromessi, non possono fare alcun danno al di fuori dell'ambito delle cartelle a cui apache ha accesso (nel caso dell'utente apache) e all'esterno della tabella ( s) / database (s) (nel caso dell'utente per il database MySQL).

Se in qualche modo l'utente di MySQL dovesse essere compromesso, non potrebbe, ad esempio, accedere al database e eliminare tutti i database da MySQL e rovinare tutti i tuoi dati. POTREBBERO in alcune circostanze essere in grado di eliminare le tabelle o inserire informazioni in alcune tabelle in un database isolato, motivo per cui è importante concedere l'accesso alle tabelle solo dove è assolutamente necessario e concedere solo le autorizzazioni necessarie ... se non si ' Non è necessario disporre dei privilegi di eliminazione delle tabelle o dei privilegi di aggiornamento, quindi non assegnarli a quell'utente.

Inoltre, se per qualche motivo il nome utente e la password dell'account amministrativo vengono rilevati per MySQL, se si utilizza un nome utente diverso rispetto a qualsiasi nome utente sul sistema, devono prima violare la sicurezza del sistema prima di accedere al database per danneggiare. Lo stesso vale per l'utente apache e l'accesso ai file.

Esempio di tempo! Ho intenzione di fare un esempio di sistema per semplificare l'idea.

supponiamo che tu abbia utenti sul tuo sistema (root dovrebbe essere disabilitato per sicurezza attraverso qualcosa come umod -l o passwd -l, ecc.): john, barney, terence e lisa.

potresti creare un utente in MySQL con il nome di bigbird (assicurati di usare una password con hash). Bigbird ha solo privilegi selezionati e privilegi di aggiornamento, ma non rilascia o crea, e certamente no . Inoltre, si crea un altro utente MySQL amministrativo con il nome garfield per lavorare sul database MySQL e si elimina l'utente root dal database MySQL in modo che non possa essere compreso. garfield è stato concesso . privilegi su MySQL (in effetti, si tratta solo di rinominare root).

ora crei un gruppo apache o un utente e lo chiameremo apweb2. Appweb2 non è un membro di altri gruppi e tutti i file / cartelle per apache sono memorizzati in / home / apweb2 /. Ogni host virtuale avrebbe la propria sottocartella e ciascuno di questi host avrebbe la radice del documento impostata su quella sottocartella. I collegamenti simbolici sarebbero disabilitati per non fornire accidentalmente l'accesso al resto del sistema.

Inoltre, puoi limitare l'accesso ssh solo a determinati utenti (o ad alcuni gruppi, mi piace inserirli nel gruppo ssh e renderlo l'unica cosa in grado di usare ssh).

Inoltre, puoi scegliere quali utenti hanno i privilegi di sudo per limitare ulteriormente le cose. Un altro passo che puoi fare è fare in modo che tutti gli utenti ssh non siano in grado di sudo, potresti creare utenti speciali che possono usare sudo che non possono usare ssh, quindi una volta che hai effettuato l'accesso, devi accedere a un altro utente per avere accesso a sudo.

Quindi, modularizzando ogni segmento, se ne viene compromesso uno, l'intero stack non verrà compromesso e sarà possibile rimediare al problema 1 invece di ricominciare tutto da capo.

Ho trovato questo documento di SANS.org davvero utile http://www.sans.org/score/checklists/linuxchecklist.pdf

Al momento, non trascurare la virtualizzazione dei container, vale a dire Docker, systemd-nspawn e i meccanismi di virtualizzazione dei container su cui sono costruiti (spazi dei nomi, cgroups). L'uso della virtualizzazione del contenitore consente di isolare i processi, ad esempio se uno dei servizi è compromesso, un utente malintenzionato non otterrà l'accesso ad altri servizi.

Nel caso di LAMP, è possibile utilizzare, ad esempio, quattro contenitori Docker con server SSH, Apache, MySQL, PHP-FPM / Python / Perl / ecc.