CageFS nell'attività quotidiana di hosting: isolamento del file system tra gli account dei clienti

Perché gli account di hosting hanno bisogno di isolamento

Nell’hosting condiviso, più clienti gestiscono i propri siti web sullo stesso server. Se uno script nell’account A viene compromesso, può tentare di raccogliere informazioni sull’ambiente e accedere ai file di altri account. Tra questi possono figurare file di configurazione contenenti credenziali di accesso o dati personali. La separazione degli account ha lo scopo di rendere più difficile tale accesso, nonostante l’infrastruttura sia condivisa.

Tra questi vi sono Visibilità e diritti di accesso questioni diverse. Il nome di una cartella può essere visibile, anche se la lettura del suo contenuto è impedita dai permessi del file. Al contrario, una visualizzazione limitata non è di per sé sufficiente a sostituire permessi impostati con cura: ciò che è accessibile all’interno dell’ambiente deve comunque essere adeguatamente protetto.

CageFS aggiunge alle autorizzazioni un ambiente del file system specifico per l'utente. Un processo nel contesto previsto non ha semplicemente la stessa visione dell'host di un amministratore. In questo modo si intende impedire che uno script eseguito dall'account A possa esplorare facilmente le directory di altri account. Quali aree siano effettivamente visibili dipende dalla configurazione.

Per gli operatori si tratta di un ulteriore Strato di separazione, nessuna garanzia contro eventuali ripercussioni su altri clienti. Errori nei servizi condivisi, autorizzazioni troppo ampie o un’integrazione incompleta dei servizi possono influire sull’efficacia della protezione. Pertanto, l’isolamento deve essere verificato nel punto in cui i programmi dei clienti vengono effettivamente eseguiti, e non solo sulla base di un’impostazione nell’area di amministrazione.

Anche per i clienti dei servizi di hosting questa distinzione è importante: il fatto che un’applicazione non riesca a vedere una directory esterna descrive, in primo luogo, solo il suo specifico contesto di esecuzione. Ciò non garantisce né la configurazione di tutti i servizi né la protezione di tutti gli altri account. La responsabilità della configurazione e del controllo complessivi rimane a carico del fornitore.

Come CageFS struttura la visualizzazione del file system

CageFS offre agli utenti una propria visione del file system. Alla base c'è il Scheletro: un modello contenente file e directory messi a disposizione per il rispettivo ambiente. Le parti necessarie vengono integrate; anche la directory home dell'utente viene integrata nel suo ambiente. L'albero delle directory visibile non è quindi semplicemente una copia inalterata della vista dell'host.

L'integrazione può essere illustrata con un esempio: un amministratore installa un programma sull'host, ma un processo del cliente non riesce a trovarlo nel proprio ambiente. Ciò non costituisce automaticamente un errore di installazione. Il programma può essere presente sull'host senza essere disponibile nello "skeleton" o tramite le integrazioni previste per il cliente.

Al contrario, ogni file aggiuntivo messo a disposizione amplia l’ambiente visibile a un processo. Lo stesso vale per una directory montata. Gli amministratori devono quindi valutare le esigenze funzionali rispetto alla visibilità aggiuntiva: un'applicazione potrebbe aver bisogno di un determinato strumento e delle sue dipendenze, ma non necessariamente di un'intera directory dell'host.

Il sito Configurazione del supporto determina quali parti del file system vengono visualizzate nell'ambiente. Tuttavia, non è l'unico fattore che determina se un processo possa leggere, modificare o eseguire un file visibile. A tal fine, rimangono rilevanti, tra l'altro, la proprietà e i permessi. Un percorso visibile non equivale quindi a un accesso in scrittura consentito.

La propria directory home rimane particolarmente importante per le attività quotidiane di hosting: è lì che si trovano in genere i file del rispettivo account. L'integrazione consente l'accesso nel contesto previsto, mentre il resto della visualizzazione viene limitato. Tuttavia, la possibilità che un'applicazione specifica possa raggiungere tutti i file necessari dipende dalla sua configurazione e dai percorsi effettivamente disponibili.

CageFS, LVE e rischi comuni

CageFS e LVE risolvono problemi diversi. CageFS gestisce la visualizzazione del file system e il contesto di esecuzione di un utente; LVE serve a monitorare e limitare risorse quali CPU, memoria e operazioni di input/output. Un processo con visibilità limitata sul file system può comunque continuare a richiedere risorse. Al contrario, un limite alle risorse di per sé non impedisce l’accesso a file condivisi in modo errato.

Un pannello di controllo di hosting svolge un’ulteriore funzione: tra le altre cose, gestisce gli account e può integrare i componenti di CloudLinux. Tuttavia, la semplice installazione di un pannello non garantisce che ogni processo web, ogni shell e ogni attività pianificata venga eseguita nel contesto CageFS previsto. Gli amministratori devono verificare l’integrazione adeguata per la propria piattaforma specifica.

CageFS non prevede una macchina virtuale dedicata per ogni account. Gli account continuano a utilizzare un kernel condiviso e possono dipendere da servizi gestiti in comune. Una vulnerabilità o una configurazione errata in questi componenti condivisi continua quindi a far parte del modello di minaccia. L'isolamento del file system riduce una parte dell'ambiente visibile, ma non sostituisce la protezione e la manutenzione dell'host.

Anche all’interno di un account correttamente isolato permangono dei rischi. Un'applicazione vulnerabile può, ad esempio, divulgare i propri dati; credenziali di accesso rubate possono consentire a un malintenzionato di accedere all'account in questione. CageFS non corregge né il codice applicativo non sicuro né i permessi eccessivamente generosi sui file accessibili all'interno di tale account.

Per una strategia di sicurezza efficace, è quindi necessario che i vari livelli siano ben coordinati: integrare correttamente account e servizi, controllare i diritti di accesso ai file, impostare limiti adeguati per le risorse e mantenere aggiornate le applicazioni. L’efficacia della protezione che ne deriva dipende dalla configurazione effettiva e dai servizi in esecuzione. Il nome di un singolo componente non sostituisce questa verifica.

Considerare separatamente conti e siti web

Due account utente sullo stesso server sono un caso diverso rispetto a due siti web all’interno di un unico account. CageFS fornisce un ambiente specifico per ogni utente, limitando così la visibilità di un account sul file system. Ciò non significa però che ogni sito web all’interno di quell’account disponga di un proprio confine nel file system.

Se un’agenzia gestisce più progetti con lo stesso account di hosting, le relative applicazioni possono accedere ai file di altri progetti a seconda del contesto di esecuzione e delle autorizzazioni. Se un malintenzionato riesce a penetrare in un sito web tramite un plugin vulnerabile, è quindi necessario verificare quali file di configurazione e dati di accesso siano accessibili tramite tale account. La separazione rispetto a un secondo account cliente non risponde a questa domanda.

Per una maggiore precisione Separazione del sito web CloudLinux, con CloudLinux Isolates, offre un ulteriore isolamento del file system a livello di dominio. La sua utilizzabilità dipende dalla disponibilità specifica del prodotto, dalla versione e dall’integrazione con il pannello di controllo. Verifica questi prerequisiti per il tuo stack di hosting, invece di dedurre una separazione dei domini basandoti esclusivamente sull’attivazione di CageFS.

Anche i limiti LVE relativi ai domini costituiscono una funzione distinta con requisiti propri. Un limite aggiuntivo a livello di file system non implica quindi automaticamente che la CPU o la memoria siano limitate separatamente per ogni dominio. L'articolo su Isolamento dei siti con CloudLinux approfondisce la differenza tra il livello dell'account e quello del sito web; per la configurazione rimangono determinanti i requisiti della variante di prodotto utilizzata.

Per la pianificazione, vale la pena fare innanzitutto un punto della situazione: quali siti condividono un account, quali file devono essere condivisi e quali credenziali di accesso devono rimanere separate? Da ciò è possibile dedurre se gli account separati o un isolamento basato sul dominio siano più adatti al modello operativo. Entrambe le varianti richiedono una verifica dei percorsi di utilizzo effettivi.

Verifica lo stato di Pilot e CageFS

Prima di avviare un progetto pilota, in qualità di amministratore devi verificare che la versione del sistema operativo utilizzata sia supportata, che siano disponibili i pacchetti necessari e la licenza e che il pannello di controllo sia integrato correttamente. Il supporto documentato di un pannello non implica che ogni funzione operi allo stesso modo in ogni combinazione. Prendi inoltre nota delle applicazioni e degli strumenti necessari per gli account di prova selezionati.

Inizia con account di prova espressamente autorizzati e una selezione limitata di applicazioni tipiche. Verifica le loro directory home, i programmi necessari e i percorsi di esecuzione rilevanti prima di aggiungere altri account. Per l’implementazione iniziale puoi utilizzare la modalità in cui CageFS è disattivato di default e i singoli account vengono attivati; in alternativa, esiste una modalità in cui CageFS è attivato di default con alcune eccezioni.

I seguenti comandi di lettura sono destinati agli amministratori autorizzati su un sistema su cui è installato CageFS. TESTBENUTZER Sostituiscilo con un account esistente e autorizzato per il test. I diritti necessari e il risultato concreto dipendono dal sistema; i comandi non modificano alcuna configurazione.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

Il primo comando mostra lo stato globale di CageFS, il secondo quello Modalità operativa. Il terzo verifica lo stato dell'account selezionato. La modalità e lo stato dell'account vanno considerati insieme: una modalità attivata di default può prevedere delle eccezioni, mentre nell'altra modalità i singoli account vengono espressamente inclusi.

Un risultato positivo non è di per sé una prova che ogni servizio funzioni effettivamente nel contesto previsto. Documenta quindi separatamente ciò che riporta l’amministrazione e quali percorsi di esecuzione sono stati verificati con l’account di prova. Solo in seguito sarà possibile decidere se il progetto pilota possa essere esteso ad altri conti e quali eccezioni siano necessarie dal punto di vista operativo.

Confronto tra le strategie di protezione

Gli approcci si differenziano soprattutto per il confine che tracciano e per chi lo gestisce. La tabella classifica i relativi obiettivi di protezione; i dati relativi ai costi operativi sono indicazioni qualitative di pianificazione, non valori misurati. I requisiti concreti dipendono dalla piattaforma specifica e dalla sua configurazione.

I permessi sui file e una visibilità limitata non sono concetti intercambiabili: anche un percorso visibile non deve necessariamente essere leggibile, e un percorso reso accessibile deve essere adeguatamente protetto. CageFS integra questi diritti con un ambiente strutturato. LVE, invece, si occupa del consumo delle risorse; per un utilizzo congiunto, entrambi i livelli devono essere configurati in modo adeguato.

A macchina virtuale propria sposta il confine amministrativo rispetto a un ambiente specifico per l'utente: il sistema ospite deve essere gestito autonomamente e rimane dipendente dalla piattaforma di virtualizzazione. Un server separato modifica ulteriormente l’infrastruttura condivisa. La scelta della variante più adeguata dipende dal modello di minaccia, dai diritti necessari e dalle risorse operative disponibili.

Una classifica generale in termini di sicurezza sarebbe quindi fuorviante. Per un confronto tra altri meccanismi e i rispettivi ambiti di applicazione, è utile la panoramica su Isolamento dei processi nell'hosting. A questo punto è fondamentale procedere a una verifica concreta: quale limite deve impedire quale tipo di accesso, quali servizi lo superano e chi controlla la configurazione?

Testare i percorsi di esecuzione in modo controllato

Il fatto che un account sia attivato non garantisce che ogni processo ad esso associato venga effettivamente avviato in CageFS. Ciò che conta è il rispettivo Percorso di esecuzione: L'accesso SSH, il server web e le attività pianificate possono avvalersi di integrazioni diverse. Gli amministratori devono quindi verificare, per ogni servizio pertinente, in che modo esso assegna i processi all'account e al relativo ambiente.

Per eseguire un test controllato, il gestore crea un account di prova autorizzato e utilizza esclusivamente file di prova propri, espressamente approvati. Un file all’interno dell’ambiente previsto può indicare se l’accesso previsto funziona; un file preparato separatamente al di fuori della vista prevista serve a verificare i limiti di accesso. Le directory dei clienti esterni non costituiscono materiale di test idoneo a tale scopo.

Verifica innanzitutto tramite SSH quale ambiente viene effettivamente assegnato all'account di prova e se i file di prova previsti sono accessibili come previsto. Ripeti la verifica utilizzando un'applicazione web configurata a tale scopo e un'attività pianificata. I risultati potrebbero variare se i servizi sono integrati in modo diverso o vengono eseguiti in un contesto utente diverso.

Per ogni tentativo, registra il servizio, l'account, il percorso e il risultato. Un accesso negato dimostra solo il limite osservato in quel preciso contesto; non prova né il corretto isolamento di tutti i servizi né la sicurezza dell'intero host. Al contrario, un accesso inaspettatamente riuscito dovrebbe essere esaminato prima di mettere in funzione ulteriori account.

In qualità di cliente del servizio di hosting, puoi verificare il tuo contesto di esecuzione e i file condivisi. Di norma, non è possibile verificare autonomamente le impostazioni globali di CageFS, gli altri account e l’integrazione di tutti i servizi. La responsabilità di tali questioni spetta al gestore; in caso di anomalie, descrivigli il servizio interessato e il percorso specifico.

Strumenti mancanti e manutenzione dello scheletro

Se uno strumento è installato sull'host ma non è presente nell'account cliente, verifica innanzitutto il contesto di esecuzione. Una chiamata tramite SSH non deve necessariamente utilizzare lo stesso ambiente di un'applicazione web o di un'attività pianificata. Verifica quindi il percorso di ricerca e il messaggio di errore specifico prima di supporre che manchi un pacchetto.

Successivamente, il gestore esamina il Scheletro e la configurazione del mount. Lo skeleton contribuisce a determinare quali file e directory vengono resi disponibili in CageFS. Un programma può quindi essere presente sull'host e tuttavia non essere disponibile nell'ambiente specifico dell'utente; anche le librerie necessarie e altre dipendenze devono essere prese in considerazione durante la distribuzione.

La soluzione pratica non consiste nell'integrare, a titolo precauzionale, directory host di grandi dimensioni. Ciò potrebbe rendere visibili più file di quanti ne siano necessari per l'attività. L'amministratore dovrebbe invece selezionare i file di programma e le dipendenze necessari sulla base della documentazione del produttore e, successivamente, verificare nel contesto di servizio previsto se lo strumento funziona.

A Manutenzione dello skeleton È inoltre necessario tenere conto delle modifiche apportate ai pacchetti di sistema e al pannello di controllo. CloudLinux prevede un aggiornamento periodico; a seguito di determinate modifiche, potrebbe essere necessario un aggiornamento forzato. Ciò può rendersi necessario anche dopo una ricostruzione di Apache. Ciò non significa però che dopo ogni aggiornamento si debba eseguire lo stesso comando manuale.

Pianifica l'aggiornamento in base alla piattaforma utilizzata e verifica successivamente le applicazioni e gli strumenti interessati. Se un'applicazione funzionava in precedenza e smette di funzionare dopo una modifica, la data della modifica del pacchetto, il servizio interessato e il messaggio di errore esatto aiutano a circoscrivere il problema. In questo modo è possibile distinguere tra un problema di distribuzione e un errore dell’applicazione.

Operare in sicurezza e decidere con consapevolezza

Ai fini delle decisioni operative, non è sufficiente sapere se CageFS sia disponibile in linea di principio. L’operatore deve sapere quali account e servizi devono essere protetti, quali programmi sono necessari a tal fine e chi è responsabile dell’integrazione e della manutenzione. La visibilità limitata sul file system integra altre misure di sicurezza; non sostituisce né le applicazioni sicure né la protezione delle credenziali di accesso.

Meritano particolare attenzione aree comuni e mount aggiuntivi. CloudLinux descrive per /dev/shm un collegamento condiviso e una possibilità di isolamento per ciascun utente. Per stabilire quale variante sia effettivamente applicabile, è necessario verificare la configurazione specifica. I mount aggiuntivi dovrebbero fornire solo ciò di cui le applicazioni hanno bisogno, poiché possono ampliare l'ambiente visibile.

Anche un errore durante l'accesso a CageFS ha rilevanza in termini di sicurezza. A partire dalla versione 7.2.0-1 di CageFS, CloudLinux documenta un'opzione che consente di impedire l'esecuzione dei processi in caso di un errore di questo tipo. Verifica la versione installata e l'impostazione effettiva, invece di dedurre il comportamento di questa opzione in un'offerta di hosting specifica basandoti semplicemente sulla sua esistenza.

Le modifiche relative a Skeleton, ai mount o all'assegnazione degli account devono essere inserite in un Procedure di manutenzione. A tal fine, occorre tenere conto di eventuali rimontaggi, delle applicazioni interessate e di una finestra di manutenzione; documentare inoltre come la modifica possa essere annullata in caso di problemi. Successivamente, i percorsi di esecuzione rilevanti e gli strumenti necessari dovrebbero essere nuovamente verificati utilizzando gli account di test previsti.

Per i clienti, la questione fondamentale è quale livello di isolamento il fornitore garantisca effettivamente e in che modo lo verifichi. Gli operatori, invece, devono considerare insieme le esigenze di protezione e l’onere gestionale: un ambiente troppo generoso può indebolire la separazione, mentre uno troppo limitato può compromettere il funzionamento delle applicazioni necessarie. Entrambe le situazioni richiedono una configurazione consapevole e controlli regolari.