Indice dei contenuti dell'articolo:
Introduzione
Nei sistemi UNIX e Linux, la sicurezza e la separazione dei privilegi rappresentano un elemento cardine per garantire la protezione dei dati e la corretta gestione degli accessi ai file. Il cuore di questo sistema si basa sugli identificatori degli utenti (UID) e dei gruppi (GID), accompagnati da un sistema di permessi che regola le operazioni di lettura, scrittura ed esecuzione sui file (rwx). Ogni processo eseguito sul sistema operativo viene associato a un UID e a un GID specifico, limitando l’accesso ai file e prevenendo potenziali exploit da parte di processi malevoli. Questo approccio strutturato assicura che utenti e processi diversi non abbiano accesso ai file altrui, a meno che non abbiano espliciti permessi, creando una linea di difesa critica contro molte vulnerabilità di sicurezza.
Tuttavia, nonostante questi principi solidi alla base di UNIX e Linux, molti pannelli di controllo commerciali come cPanel, Plesk, e DirectAdmin adottano una gestione dei terzi livelli (sottodomini) che mette a rischio la sicurezza degli utenti. In questo articolo esploreremo come questi pannelli gestiscono i sottodomini, i problemi legati alla condivisione degli UID/GID e le potenziali vulnerabilità che derivano da questa architettura, offrendo allo stesso tempo soluzioni e consigli su come una gestione professionale possa garantire una sicurezza maggiore.
Gestione dei terzi livelli nei pannelli di controllo: cPanel, Plesk, DirectAdmin
I pannelli di controllo Linux come cPanel, Plesk e DirectAdmin sono tra i più utilizzati nel settore del web hosting per la loro interfaccia intuitiva e la capacità di semplificare operazioni tecniche complesse. Tuttavia, quando si tratta di gestione dei sottodomini, questi strumenti presentano delle lacune significative dal punto di vista della sicurezza.
Quando si crea un terzo livello (un sottodominio) come, ad esempio, blog.dominio.com, questi pannelli tendono a inserirlo come una directory annidata all’interno della home directory del dominio principale. Ad esempio, in cPanel la directory di un sottodominio può essere strutturata come segue:
/home/nome_utente/public_html/blog
Anche in Plesk e DirectAdmin la logica è simile:
/var/www/vhosts/dominio.com/blog
Questa organizzazione ha delle implicazioni rilevanti: il sottodominio non ha un UID/GID separato, ma gira con gli stessi permessi (utente e gruppo) del dominio principale. Ciò significa che tutti i processi PHP (e altri processi web) vengono eseguiti con gli stessi privilegi del dominio principale.
Il problema della sicurezza: condivisione di UID e GID
Una delle principali problematiche legate alla gestione dei sottodomini in questi pannelli è proprio la condivisione degli UID e dei GID tra il dominio principale e i suoi sottodomini. Poiché i sottodomini sono semplicemente directory all’interno del dominio principale e condividono gli stessi permessi di esecuzione, qualsiasi vulnerabilità scoperta in un sottodominio può compromettere l’intera installazione del dominio principale.
Per chiarire meglio il concetto, facciamo un esempio pratico.
Caso di studio: esempiostore.com
Immaginiamo il caso di un’azienda che gestisce il dominio principale esempiostore.com, dove è ospitata una moderna installazione di PrestaShop 8 per la vendita online. Tuttavia, per motivi storici, contabili e fiscali, la stessa azienda mantiene un vecchio sottodominio old.esempiostore.com che ospita una versione non aggiornata di PrestaShop 1.6.
Nel pannello di controllo, questo sottodominio viene gestito come una semplice directory all’interno dell’installazione principale, con un percorso simile a /home/esempiostore.com/public_html/old.
Scenario di attacco
Un attaccante scopre una vulnerabilità in un modulo non aggiornato della vecchia installazione PrestaShop 1.6 nel sottodominio old.esempiostore.com. Sfruttando questa vulnerabilità, l’attaccante riesce ad ottenere l’accesso amministrativo alla piattaforma e carica una PHP shell o un file manager. Da quel momento, l’attaccante ha la capacità di leggere e modificare i file all’interno della directory del sottodominio.
Ma il vero problema sorge dal fatto che, poiché i sottodomini condividono gli stessi permessi del dominio principale, l’attaccante può navigare liberamente nella directory superiore e accedere ai file di configurazione del dominio principale esempiostore.com. Per esempio, l’attaccante potrebbe accedere al file parameters.php di PrestaShop 8, che contiene le credenziali di accesso al database.
A questo punto, l’attaccante ha tutto ciò di cui ha bisogno per compromettere l’intero dominio principale. Potrebbe accedere al database, creare un nuovo account amministratore e ottenere pieno controllo della nuova installazione PrestaShop 8, che fino a quel momento era considerata sicura e aggiornata.
L’importanza della separazione dei privilegi
In un sistema operativo UNIX/Linux, la separazione dei privilegi è uno dei principi fondamentali di sicurezza. Ogni processo o operazione all’interno del sistema è eseguito da un utente con un determinato UID (User ID) e GID (Group ID), e questi identificatori controllano l’accesso a risorse come file, directory e processi. Questo modello, noto come Discretionary Access Control (DAC), permette di limitare rigorosamente ciò che un utente o un processo può fare, creando un perimetro di sicurezza intorno a dati e applicazioni critiche. In ambienti multitenant, come quelli in cui più domini e sottodomini condividono risorse, la separazione dei privilegi diventa essenziale per garantire che una violazione della sicurezza in un’area del sistema non possa propagarsi ad altre.
Come la separazione dei privilegi dovrebbe funzionare in un ambiente web
In un contesto ideale, ogni dominio o sottodominio dovrebbe avere un proprio ambiente isolato, con un proprio UID e GID separato, in modo tale che un processo avviato all’interno di un dominio non possa accedere ai file di altri domini. Questo isolamento non è solo teorico, ma una pratica standard in configurazioni più sicure, ad esempio con l’uso di container come Docker o ambienti isolati con strumenti come CageFS (CloudLinux).
Ogni dominio, che sia principale o di terzo livello, dovrebbe essere trattato come un’entità separata:
- File e directory: Ogni dominio dovrebbe avere una propria struttura di directory, con permessi distinti che impediscano a un utente di dominio A di accedere ai file del dominio B.
- Processi PHP/CGI: Idealmente, ogni dominio dovrebbe eseguire i propri script PHP o CGI con un utente specifico, evitando che un processo di un dominio possa interferire o intercettare i processi di un altro dominio.
- Ambienti virtuali e sandboxing: Gli ambienti isolati dovrebbero essere integrati per garantire che una vulnerabilità in un dominio non possa compromettere l’intero server.
Cosa succede nei pannelli di controllo come cPanel, Plesk e DirectAdmin?
Purtroppo, cPanel, Plesk e DirectAdmin utilizzano una gestione centralizzata dei permessi per domini e sottodomini, trattando questi ultimi come semplici directory annidate all’interno del file system dell’utente principale. Questo approccio può sembrare conveniente, ma comporta gravi problemi di sicurezza:
- Condivisione di UID/GID tra domini e sottodomini: Come evidenziato in precedenza, sia il dominio principale che i suoi sottodomini vengono eseguiti con lo stesso UID e GID dell’utente principale. Questo significa che se un processo PHP o un modulo vulnerabile viene compromesso su un sottodominio, l’attaccante ha potenzialmente accesso a tutti i file e le directory appartenenti al dominio principale e ad altri sottodomini.
- Esecuzione dei processi PHP sotto lo stesso utente: In questi pannelli di controllo, gli script PHP vengono eseguiti come l’utente proprietario del dominio. Questo implica che non c’è alcuna differenziazione tra un processo PHP eseguito dal dominio principale e un processo PHP eseguito da un sottodominio. Se un attaccante riesce a sfruttare una vulnerabilità in un sottodominio, ha la stessa capacità di manipolare i file o i processi del dominio principale come se fosse l’utente proprietario.
- Architettura obsoleta e problematiche di annidamento: L’approccio di creare directory annidate per sottodomini (ad esempio
/home/nome_utente/public_html/sottodominio) aumenta ulteriormente i rischi, in quanto non c’è alcuna separazione fisica o logica tra i dati dei sottodomini e del dominio principale. Ciò rende facile per un attaccante passare da un sottodominio compromesso a file di dominio principale o a database sensibili.
I rischi reali di questa architettura
Consideriamo di nuovo il caso dell’esempio pratico menzionato in precedenza: il dominio principale esempiostore.com con un sottodominio old.esempiostore.com, che contiene una vecchia versione di PrestaShop 1.6. Questa situazione non è rara in ambienti reali, dove per motivi contabili o di transizione si mantengono versioni legacy di software su sottodomini. Anche se il dominio principale esempiostore.com è aggiornato e sicuro, la presenza del sottodominio legacy con software non aggiornato introduce un punto di ingresso vulnerabile.
Un attaccante potrebbe sfruttare una vulnerabilità di un modulo di PrestaShop 1.6 presente nel sottodominio. Dal momento in cui l’attaccante riesce a compromettere il sottodominio, può caricare un file manager o una shell PHP per navigare nel file system del server, eseguendo comandi con lo stesso UID dell’utente proprietario. Questo gli consente di accedere ai file di configurazione della versione aggiornata di PrestaShop 8 sul dominio principale, compromettendo non solo i dati del sottodominio, ma l’intera infrastruttura del dominio principale.
La conseguenza diretta di questo scenario è devastante:
- Perdita di dati: L’accesso al database attraverso file di configurazione non adeguatamente protetti può consentire all’attaccante di manipolare o rubare dati sensibili.
- Escalation dei privilegi: L’attaccante può ottenere l’accesso completo al sistema e creare nuovi utenti amministrativi nel database del sito principale.
- Compromissione di informazioni finanziarie: Se il sito principale gestisce transazioni finanziarie, queste potrebbero essere intercettate o manipolate, esponendo l’azienda a frodi o violazioni della privacy.
- Danno alla reputazione: Ogni compromissione della sicurezza può causare danni irreparabili alla reputazione dell’azienda, allontanando clienti e partner.
Una soluzione professionale: separazione di UID/GID e domini isolati
La nostra filosofia come Managed Server S.r.l. è sempre stata quella di garantire che ogni dominio, sia esso di secondo, terzo o quarto livello, venga eseguito con UID e GID differenti, e che i privilegi siano completamente separati. Questo approccio garantisce che nessun file di un dominio possa essere letto o scritto da un altro dominio. Una soluzione che dovrebbe essere standard in ogni ambiente di hosting professionale.
Anche l’alberatura delle directory dovrebbe riflettere questa separazione. Invece di annidare i sottodomini all’interno della directory del dominio principale, come fanno cPanel, Plesk e DirectAdmin, riteniamo che ogni dominio o sottodominio debba avere la sua directory dedicata e separata. Ad esempio, nel caso di old.esempiostore.com, la directory dovrebbe essere qualcosa del tipo:
/home/old.esempiostore.com
Con questa architettura, anche se un sottodominio viene compromesso, l’attaccante non avrebbe accesso ai file del dominio principale, poiché i due ambienti sarebbero completamente separati a livello di utente e gruppo.
Perché sconsigliamo i pannelli di controllo commerciali
Spesso ci troviamo a sconsigliare ai nostri clienti l’utilizzo di pannelli di controllo commerciali come cPanel, Plesk o DirectAdmin per la gestione dei server. Questo non è un mero approccio di marketing volto a differenziarci, ma una scelta consapevole e motivata da anni di esperienza sul campo.
Questi pannelli sono nati con lo scopo di semplificare la gestione dei server per chi non avesse le competenze tecniche o le risorse economiche per affidarsi a un sistemista professionista. Tuttavia, con il passare del tempo, i costi delle licenze per questi pannelli sono aumentati, mentre il costo per una gestione professionale da parte di sistemisti esperti è sceso.
Oggi, con una differenza di 20 o 30 euro al mese – meno di un caffè al giorno – è possibile evitare completamente i rischi e le limitazioni di questi pannelli, affidandosi invece a un team di professionisti con decennale esperienza che non solo ottimizza le performance, ma implementa soluzioni di sicurezza avanzate, monitoraggio continuo, backup e disaster recovery.
Evita rischi inutili, affidati a veri esperti per proteggere il tuo sito.
Se la sicurezza della tua infrastruttura web è una priorità, è il momento di abbandonare i vecchi pannelli di controllo commerciali e passare a una gestione professionale su misura. Da Managed Server S.r.l., offriamo un servizio di hosting avanzato, con sistemi di sicurezza “by design” che garantiscono che ogni dominio, sottodominio e applicazione siano completamente isolati e protetti.
Non lasciare che la vulnerabilità di un sottodominio comprometta l’intera tua attività online. Con un piccolo investimento mensile, puoi assicurarti che la tua piattaforma sia gestita da esperti in grado di prevenire problemi di sicurezza come quelli descritti in questo articolo. Contattaci oggi per scoprire come possiamo aiutarti a proteggere e ottimizzare il tuo sito con un livello di sicurezza e professionalità che i pannelli di controllo commerciali non potranno mai garantire.
