Hosting multi-sito: manca una vulnerabilità importante per proteggere i siti l'uno dall'altro?

EDIT # 2 23 luglio 2015: Alla ricerca di una nuova risposta che identifichi un importante elemento di sicurezza mancante nella configurazione di seguito o che possa dare motivo di credere che tutto sia coperto.

EDIT # 3 29 luglio 2015: Cerco in particolare una possibile configurazione errata come inavvertitamente consentire qualcosa che potrebbe essere sfruttato per aggirare le restrizioni di sicurezza o, peggio ancora, lasciando qualcosa di completamente aperto.

Questa è una configurazione di hosting multi-sito / condivisa e vogliamo usare un'istanza di Apache condivisa (ovvero viene eseguita con un account utente) ma con PHP / CGI in esecuzione come utente di ciascun sito Web per garantire che nessun sito possa accedere ai file di un altro sito e vogliamo assicurati che non manchi nulla (ad es. se non sapessimo della prevenzione degli attacchi symlink).

Ecco cosa ho finora:

• Assicurati che gli script PHP vengano eseguiti come account e gruppo di utenti Linux del sito Web e siano in jail (come l'utilizzo di CageFS) o almeno correttamente limitati utilizzando le autorizzazioni del filesystem Linux.
• Utilizzare suexec per assicurarsi che gli script CGI non possano essere eseguiti come utente Apache.
• Se è necessario il lato server include il supporto (come nei file shtml), utilizzare Options IncludesNOEXECper impedire che CGI possa essere eseguito quando non ci si aspetta (anche se questo non dovrebbe essere un problema se si utilizza suexec).
• Predisporre una protezione dagli attacchi tramite link simbolico in modo che un hacker non possa indurre Apache a pubblicare i file di un altro sito Web come testo normale e divulgare informazioni sfruttabili come le password dei DB.
• Configura AllowOverride/ AllowOverrideListper consentire solo le direttive che un hacker non può sfruttare. Penso che questo sia meno preoccupante se gli articoli di cui sopra sono fatti correttamente.

Andrei con MPM ITK se non fosse così lento e non funzionasse come root, ma in particolare desideriamo usare un Apache condiviso ma assicurarci che sia fatto in modo sicuro.

Ho trovato http://httpd.apache.org/docs/2.4/misc/security_tips.html , ma non era completo su questo argomento.

Se è utile sapere, stiamo pianificando di usare CloudLinux con CageFS e mod_lsapi.

C'è qualcos'altro da assicurarsi o da fare?

MODIFICA 20 luglio 2015: le persone hanno presentato alcune buone soluzioni alternative che sono utili in generale, ma si noti che questa domanda è indirizzata solo alla sicurezza di una configurazione Apache condivisa. Nello specifico c'è qualcosa che non è stato menzionato sopra che potrebbe consentire a un sito di accedere ai file di un altro sito o compromettere in qualche modo altri siti?

Grazie!

Sono completamente d'accordo con gli articoli che hai finora.

Alcuni anni fa eseguivo una tale configurazione multiutente e fondamentalmente ho trovato lo stesso compromesso: mod_php è veloce (in parte perché tutto funziona nello stesso processo) e suexec è lento ma sicuro (perché ogni richiesta genera un nuovo processi). Sono andato con suexec, perché era richiesto l'isolamento dell'utente.

Attualmente c'è una terza opzione che potresti prendere in considerazione: dare ad ogni utente il proprio demone php-fpm. La fattibilità dipende dal numero di utenti, poiché ognuno di essi deve ottenere almeno un processo php-fpm utilizzando il proprio account utente (il daemon utilizza quindi un meccanismo simile a prefork per scalare le richieste, quindi il numero di processi e il loro utilizzo della memoria può essere un fattore limitante). Avrai anche bisogno di una generazione di configurazione automatica, ma ciò dovrebbe essere fattibile con alcuni script di shell.

Non ho usato questo metodo in ambienti di grandi dimensioni, ma IMHO è una buona soluzione per fornire buone prestazioni del sito Web PHP, pur isolando gli utenti a livello di processo.

Tutto ciò che hai finora sembra ben pensato. L'unica cosa che ho potuto vedere come un problema è il fatto che la maggior parte degli exploit cerca di ottenere l'accesso alla radice in un modo o nell'altro. Quindi, anche se ogni sito e i relativi processi e script sono imprigionati correttamente e ogni cosa ha il suo utente e le sue autorizzazioni, un hacker con root non potrebbe fregarsene di meno, semplicemente eviteranno tutto ciò che hai impostato.

Il mio suggerimento sarebbe di utilizzare una sorta di software VM (VMware, VirtualBox, Qemu, ecc.) Per assegnare a ciascun sito il proprio jail OS. Questo ti consente, come amministratore di sistema, di non preoccuparti di un singolo sito compromesso. Se un hacker ottiene il root sfruttando php (o qualsiasi altro software) sulla VM di un sito, basta mettere in pausa la VM e analizzarla in un secondo momento, applicare correzioni o ripristinare uno stato ininterrotto. Ciò consente inoltre agli amministratori del sito di applicare software specifici o impostazioni di sicurezza al loro ambiente di sito specifico (che potrebbe interrompere un altro sito).

L'unica limitazione a questo è il tuo hardware ma con un server decente e le estensioni del kernel corrette questo è facile da gestire. Ho eseguito con successo questo tipo di installazione su un Linode, purché sia ​​l'host che il guest fossero molto sparsi. Se ti senti a tuo agio con la riga di comando che presumo tu sia, non dovresti avere problemi.

Questo tipo di installazione riduce il numero di vettori di attacco che devi monitorare e ti consente di concentrarti sulla sicurezza delle macchine host e di gestire tutto il resto su un sito per sito.

Suggerirei di far funzionare ciascun sito con il proprio demone Apache e di eseguire il chrooting di Apache. Tutta la funzione php di sistema fallirà poiché l'ambiente chroot di Apache non avrà accesso a / bin / sh. Questo significa anche che la funzione mail () di php non funzionerà, ma se stai usando un provider di posta esterno per inviare posta dalla tua applicazione di posta elettronica, questo non dovrebbe essere un problema per te.

SELinux potrebbe essere utile con mod_selinux. Un breve howto è descritto qui:

Come posso usare SELinux per confinare gli script PHP?

Dato che le istruzioni sono un po 'datate, ho verificato se funziona su RHEL 7.1:

Ho usato la versione di Fedora 19 e compilato con simulazioni su RHEL 7.1 + EPEL.

YMMV se si utilizza la configurazione di base dell'epel confock con:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Aggiorna prima il tuo sistema di destinazione per assicurarti che selinux-policysia aggiornato.

Installa sulla casella di destinazione (o inserisci prima il tuo mirror locale):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Ora, devi assegnare a ciascun host virtuale in apache una categoria. Questo viene fatto aggiungendo una riga come nell'esempio sotto chiamato selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Successivamente, nella radice del documento per ciascun host, rietichettare le loro radici del documento nella stessa categoria di quelle etichettate nella configurazione httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Se vuoi rendere l'etichettatura onorata se fai una rietichettatura di sistema, è meglio aggiornare anche la politica locale!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Ci sono già molte buone risposte tecniche fornite (per favore dai un'occhiata anche qui: https://security.stackexchange.com/q/77/52572 e Suggerimenti per proteggere un server LAMP ), ma vorrei ancora menzionarlo qui un punto importante (da un'altra prospettiva) sulla sicurezza: la sicurezza è un processo . Sono sicuro che lo hai già preso in considerazione, ma spero ancora che possa essere utile (anche per altri lettori) a volte ripensarlo.

Ad esempio, nella tua domanda ti concentri principalmente sulle misure tecniche: "questa domanda è mirata solo alla sicurezza di una configurazione di Apache condivisa. In particolare, ci sono delle misure di sicurezza che sono importanti da prendere ma che mancano dall'elenco sopra quando si esegue la condivisione Apache e PHP. "

Quasi tutte le risposte qui e su altre 2 domande che ho menzionato sembrano essere puramente tecniche (tranne la raccomandazione di rimanere aggiornati). E dal mio punto di vista questo potrebbe rendere alcuni lettori un'impressione fuorviante, che se configuri il tuo server secondo le migliori pratiche una volta, rimani sicuro per sempre. Quindi, per favore, non dimenticare i punti che mi mancano nelle risposte:

1. Prima di tutto, non dimenticare che la sicurezza è un processo e, in particolare, sul ciclo "Plan-Do-Check-Act", come raccomandato da molti standard, tra cui ISO 27001 ( http://www.isaca.org/ Journal / archives / 2011 / Volume-4 / Pages / Planning-for-and-Implementing-ISO27001.aspx ). Fondamentalmente, ciò significa che è necessario rivedere periodicamente le misure di sicurezza, aggiornarle e testarle .

2. Aggiorna regolarmente il tuo sistema. Ciò non aiuterà contro gli attacchi mirati che utilizzano vulnerabilità zero-day, ma aiuterà contro quasi tutti gli attacchi automatici.

3. Monitora il tuo sistema. Mi manca davvero questo punto nelle risposte. Dal mio punto di vista, è estremamente importante essere informati il ​​prima possibile di alcuni problemi con il sistema.

   Ecco cosa dicono le statistiche al riguardo: "Il tempo medio dall'infiltrazione alla scoperta è di 173,5 giorni" ( http://www.triumfant.com/detection.html ), "205 numero medio di giorni prima del rilevamento" ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-trends-2015.pdf ). E spero che questi numeri non siano ciò che tutti desideriamo avere.

   Esistono molte soluzioni (anche gratuite) non solo per monitorare lo stato del servizio (come Nagios), ma anche sistemi di rilevamento delle intrusioni (OSSEC, Snort) e sistemi SIEM (OSSIM, Splunk). Se diventa troppo complicato, potresti almeno abilitare qualcosa come "fail2ban" e / o inoltrare i tuoi log a un server syslog separato e ricevere notifiche e-mail su eventi importanti.

   Ancora una volta, il punto più importante qui non è quale sistema di monitoraggio scegliate, il più importante è che avete un po 'di monitoraggio e lo revisionate regolarmente secondo il vostro ciclo "Plan-Do-Check-Act" .

4. Sii consapevole delle vulnerabilità. Come il monitoraggio. Basta iscriversi a un elenco di vulnerabilità per ricevere una notifica, quando viene rilevata una vulnerabilità critica per Apache o altri servizi importanti per la configurazione. L'obiettivo è ricevere notifiche sulle cose più importanti che compaiono prima del prossimo aggiornamento pianificato.

5. Avere un piano su cosa fare in caso di incidente (e aggiornarlo e rivederlo regolarmente in base al ciclo "Pianificare-Fare-Controllare-Agire"). Se fai domande sulla configurazione sicura, significa che la sicurezza del tuo sistema diventa importante per te. Tuttavia, cosa dovresti fare nel caso in cui il tuo sistema fosse stato violato nonostante tutte le misure di sicurezza? Ancora una volta, non intendo solo misure tecniche come "reinstallare il sistema operativo": dove si dovrebbe segnalare un incidente in base alla legge applicabile? Hai il permesso di spegnere / disconnettere immediatamente il tuo server (quanto costa per la tua azienda)? Chi dovrebbe essere contattato se il principale responsabile è in vacanza / malato?

6. Avere un server di backup, archiviazione e / o sostituzione / replica. Sicurezza significa anche disponibilità del tuo servizio. Controlla regolarmente il tuo backup / archivio / replica e verifica regolarmente le procedure di ripristino.

7. Test di penetrazione? (di nuovo, vedi il ciclo "Plan-Do-Check-Act" :) Se ti sembra troppo, potresti almeno provare alcuni strumenti online gratuiti, che scansionano i tuoi servizi web alla ricerca di malware e problemi di sicurezza.

Il tuo caso d'uso è ideale per i contenitori docker.

Ogni contenitore può rappresentare un cliente o un client, con ID utente univoci assegnati a ciascun gruppo di contenitori Apache come sicurezza aggiuntiva. La chiave sarebbe quella di eliminare i privilegi di root all'avvio del contenitore, prima di avviare lo stack di apache. Ogni cliente ottiene il proprio servizio DB con le proprie password uniche, senza il mal di testa di alzare in piedi decine di macchine virtuali, ognuna delle quali richiede i propri kernel con fiocchi di neve speciali e altre spese generali. Dopotutto, nel cuore della finestra mobile c'è il chroot. Se amministrato correttamente, lo prenderei su un tipico cluster virtuale ogni giorno.

Molti buoni suggerimenti qui già. Tuttavia, finora ci sono state delle cose perse nella discussione.

Presta attenzione ai processi esterni a quelli eseguiti nell'ambito della pubblicazione di pagine Web. vale a dire assicurarsi che tutti i lavori cron che toccano dati non attendibili siano in esecuzione come utente appropriato e nella jail appropriata, indipendentemente dal fatto che tali lavori siano definiti dall'utente o meno.

Nella mia esperienza, cose come l'analisi dei log, quando fornita dal servizio di hosting, viene eseguita come root quasi tutte le volte, e il software di analisi dei log non ha il controllo di sicurezza che vorremmo. Fare questo bene è un po 'complicato e dipende dalla configurazione. Da un lato, non vuoi che il tuo processo apache di proprietà di root (cioè il processo genitore) scriva in qualsiasi directory che l'utente potrebbe compromettere. Ciò probabilmente significa non scrivere direttamente in galera. D'altra parte è necessario rendere tali file disponibili per i processi nella jail per l'analisi e si desidera che siano il più vicino possibile in tempo reale. Se puoi consentire alle tue jail di accedere a un mount di sola lettura di un file system con i log, questo dovrebbe essere buono.

Le app PHP in genere non servono i propri file statici e se hai un processo apache condiviso, allora suppongo che il tuo processo apache stia leggendo cose direttamente dalle jail dall'ambiente host? In tal caso, ciò apre una serie di preoccupazioni.

.htaccessi file sono ovvi, dove dovresti stare molto attento a ciò che permetti. Molte, se non la maggior parte delle app php sostanziali, dipendono molto dalla disposizione dei file .htaccess che probabilmente non puoi consentire senza sovvertire lo schema pianificato.

Meno ovvio è come Apache decide comunque cos'è un file statico. ad es. Cosa fa con un file *.php.gifo *.php.en? Se questo o un altro meccanismo ingannano la discriminazione su cosa sia un file statico, è possibile che apache esegua php dall'esterno del carcere? Avrei creato un web server leggero separato per il contenuto statico, che non è configurato con nessun modulo per l'esecuzione di contenuti dinamici, e avrei un bilanciamento del carico che decide quali richieste inviare al server statico e quali a quello dinamico.

Per quanto riguarda il suggerimento di Docker di Stefan, è possibile avere un singolo server Web che si trova all'esterno del contenitore e che parla con demoni php in ciascun contenitore per il contenuto dinamico, pur avendo anche un secondo server Web, che si trova in un contenitore docker, e che condivide i volumi che ciascuno utilizza per il proprio contenuto ed è quindi in grado di servire il contenuto statico, che è più o meno lo stesso del paragrafo precedente. Mi congratulo con la finestra mobile tra i vari approcci di tipo jail, ma con questo o altri approcci di tipo jail, avrai una serie di altri problemi da risolvere. Come funziona il caricamento di file? Metti demoni di trasferimento file in ciascun contenitore? Adotti un approccio basato su git in stile PAAS? Come si rendono accessibili i registri generati all'interno del contenitore, e farli rotolare? Come gestisci ed esegui cron job? Darai agli utenti qualsiasi tipo di accesso alla shell e, in tal caso, c'è un altro demone all'interno del contenitore? ecc. ecc.

La prima cosa che non vedo è la gestione dei processi, quindi un processo non può far morire di fame un altro processo di CPU o RAM (o I / O del resto, anche se il tuo filesystem potrebbe essere progettato per impedirlo). Un grande vantaggio di un approccio "container" alle tue istanze PHP rispetto al tentativo di eseguirle tutte su un'immagine "OS" è che puoi limitare l'utilizzo delle risorse in questo modo. So che non è il tuo design, ma è qualcosa da considerare.

Ad ogni modo, torniamo al caso d'uso di PHP in esecuzione dietro Apache sostanzialmente funzionante come proxy. suexec non impedisce l'esecuzione di qualcosa come utente apache, ma offre la possibilità di essere eseguito come un altro utente. Quindi una preoccupazione sarà assicurarsi che tutto sia fatto correttamente - la pagina del documento per esso indica quel potenziale pericolo: https://httpd.apache.org/docs/2.2/suexec.html . Quindi, sai, granello di sale e tutto il resto.

Dal punto di vista della sicurezza può essere utile disporre di un insieme limitato di file binari utente con cui lavorare (che fornisce la gabbia), in particolare se sono compilati in modo diverso o su una libreria diversa (ad esempio uno che non include funzionalità indesiderate) ma il il pericolo è che a quel punto non stai più seguendo una distribuzione nota per gli aggiornamenti, stai seguendo una diversa distribuzione (cagefs) per le tue installazioni PHP (almeno rispetto agli strumenti dello spazio utente). Anche se probabilmente stai già seguendo una distribuzione specifica con cloudlinux che è un rischio incrementale, non necessariamente interessante da solo.

Lascerei AllowOverride dove potresti averlo voluto. L'idea alla base della difesa in profondità è quella di non fare affidamento su un singolo strato per proteggere l'intero stack. Supponi sempre che qualcosa possa andare storto. Mitigare quando ciò accade. Ripeti finché non hai mitigato il più possibile anche se hai solo una recinzione davanti ai tuoi siti.

La gestione dei log sarà la chiave. Con più servizi in esecuzione in filesystem isolati, l'integrazione di attività per correlare quando c'è un problema potrebbe essere un problema minore se non lo hai impostato dall'inizio.

Questa è la mia discarica. Spero che ci sia qualcosa di vagamente utile lì dentro. :)