Indice dei contenuti dell'articolo:
Quando si parla di sicurezza di un CMS, l’attenzione si concentra quasi sempre su aggiornamenti, plugin vulnerabili, password, firewall applicativi e backup. Sono aspetti fondamentali, ma esiste un livello più basso e spesso trascurato che può contribuire in modo concreto alla mitigazione degli attacchi: il filesystem.
Il discorso è generico e può essere applicato, con le dovute differenze, a CMS dinamici come Magento, PrestaShop, Drupal, Joomla e naturalmente WordPress. In questo articolo ci focalizzeremo su WordPress per la sua enorme diffusione e perché, proprio per questo, è uno dei bersagli più frequenti di exploit automatizzati, bot e campagne massive di compromissione.
Il punto di partenza è semplice: un sito dinamico deve poter leggere molti file, scriverne alcuni e attraversare directory per funzionare correttamente. Ma questo non significa che l’intera installazione debba essere sempre modificabile. Non tutti i file devono essere scrivibili, non tutti i percorsi devono consentire lo stesso livello di operatività e non tutte le directory devono permettere modifiche fuori dai momenti di manutenzione.
Quando un exploit scrive dentro WordPress
Molti attacchi contro WordPress non si limitano a sfruttare una vulnerabilità in modo temporaneo. Spesso cercano di ottenere persistenza: scrivono nuovi file, modificano file esistenti, iniettano codice in un tema, alterano un plugin o depositano una web shell in una directory raggiungibile via web.
Questo accade perché molte installazioni sono lasciate, per comodità, in una condizione troppo permissiva. WordPress deve poter aggiornare plugin e temi, caricare immagini, generare cache e talvolta modificare file come .htaccess. Da questa esigenza legittima nasce però un’abitudine pericolosa: trattare l’intera installazione come se dovesse essere sempre scrivibile.
Se un exploit riesce a eseguire codice nel contesto dell’utente del sito o del processo web, proverà a sfruttare proprio questa possibilità. Se trova directory modificabili e file sovrascrivibili, può installare backdoor o alterare componenti legittimi. Se invece alcune aree critiche sono protette e non modificabili durante la normale operatività, una parte importante dell’attacco viene resa più difficile.
Non tutto deve essere scrivibile
Un esempio evidente è la directory dei plugin. Un sito WordPress non ha bisogno che wp-content/plugins sia scrivibile in ogni momento. Deve esserlo quando si installa, aggiorna o rimuove un plugin. Ma tra un aggiornamento e l’altro, soprattutto su un sito in produzione gestito professionalmente, quei file possono rimanere statici.
Lo stesso ragionamento può valere per molti file del core, per parti del tema attivo, per file di configurazione e per componenti che non devono cambiare al di fuori di una manutenzione pianificata. Al contrario, directory come wp-content/uploads hanno esigenze diverse: devono permettere il caricamento di media, ma proprio perché sono scrivibili dovrebbero essere trattate con attenzione e non diventare un punto comodo per eseguire codice malevolo.
La sicurezza, quindi, non dovrebbe essere vista solo come una distinzione tra “permesso” e “vietato”, ma come una separazione più precisa tra ciò che deve essere letto, ciò che deve essere scritto e ciò che deve rimanere intatto.
Questa separazione riguarda anche il concetto di esecuzione. Su Linux il bit di esecuzione sulle directory serve anche per attraversarle, quindi non va interpretato in modo superficiale; tuttavia, dal punto di vista applicativo, non ogni percorso che contiene file caricati o generati dal CMS dovrebbe poter diventare un punto da cui eseguire codice. Un’area destinata agli upload, per esempio, dovrebbe essere pensata per conservare contenuti, non per ospitare script PHP pronti a essere richiamati dal browser.
Che cosa fa chattr +i
Su Linux, oltre ai permessi classici gestiti con chmod e chown, esistono attributi del filesystem gestibili tramite chattr. Tra questi, l’attributo più interessante in ottica di hardening è +i, cioè l’attributo di immutabilità.
Quando un file viene marcato come immutabile, non può essere modificato, cancellato, rinominato o aperto in scrittura finché l’attributo non viene rimosso da un soggetto autorizzato. Non è quindi equivalente a togliere semplicemente il permesso di scrittura con chmod: è un vincolo più forte, applicato a livello di filesystem.
In forma essenziale, i comandi sono questi:
chattr +i file-o-directory chattr -i file-o-directory lsattr file-o-directory
chattr +i applica l’immutabilità, chattr -i la rimuove, mentre lsattr consente di verificare gli attributi presenti. Naturalmente questi comandi non dovrebbero essere applicati in modo indiscriminato su tutta l’installazione. Un CMS deve continuare a scrivere dove serve: cache, upload, log e altri percorsi dinamici non possono essere bloccati senza una valutazione precisa.
Perché viene usato così poco?
Nonostante sia uno strumento potente, chattr +i è poco usato nell’hosting web tradizionale (diciamo pure mai), fate pure qualche ricerca con Google per rendervene conto che solo noi ne parliamo. Il primo motivo è culturale: molte guide sulla sicurezza dei CMS si fermano ai permessi standard, ai plugin di sicurezza o alle regole del web server. L’immutabilità del filesystem è un tema più vicino alla sistemistica Linux che alla gestione ordinaria di WordPress.
Il secondo motivo è operativo. Se si rende immutabile un file che deve essere aggiornato, l’aggiornamento fallirà. Se si blocca la directory sbagliata, il CMS potrebbe non riuscire più a generare cache, caricare file o completare manutenzioni. Questa tecnica richiede quindi metodo, documentazione e procedure chiare.
Il terzo motivo riguarda i pannelli di controllo. Plesk, cPanel e DirectAdmin semplificano la gestione di domini, file, database, posta e certificati, ma non hanno trasformato l’immutabilità del filesystem in un modello standard di hardening applicativo per CMS. Alcuni documentano l’attributo immutabile o spiegano come rimuoverlo quando causa problemi, ma non lo propongono normalmente come workflow ordinario per proteggere in modo chirurgico una installazione WordPress.
La ragione è comprensibile: un pannello generico deve funzionare in moltissimi scenari, spesso con utenti non sistemisti. Automatizzare l’immutabilità senza conoscere il sito potrebbe generare disservizi. È proprio qui, però, che un hosting gestito professionalmente può offrire un valore aggiunto.
L’approccio corretto: chirurgico, non indiscriminato
L’immutabilità non deve essere usata come un lucchetto da applicare ovunque. Il sito non va congelato completamente. Bisogna invece distinguere i percorsi in base alla loro funzione.
I file di configurazione critici possono richiedere una protezione maggiore. I file del core possono essere considerati statici tra un aggiornamento e l’altro. I plugin possono essere resi non modificabili fino alla successiva manutenzione. Le directory di upload devono restare scrivibili, ma non dovrebbero consentire l’esecuzione di codice. Le directory di cache devono poter essere rigenerate, ma senza concedere libertà eccessiva su aree sensibili.
Un esempio puramente concettuale, non una procedura universale, potrebbe essere:
# Protezione di un percorso critico fuori manutenzione chattr +i percorso/critico # Sblocco controllato prima di un aggiornamento chattr -i percorso/critico # Verifica dello stato degli attributi lsattr percorso/critico
La parte importante non è il singolo comando, ma il processo: analizzare il comportamento del sito, identificare ciò che deve cambiare e proteggere ciò che invece non dovrebbe essere modificato durante la normale operatività.
Un livello di sicurezza in più per l’hosting gestito
In un hosting standard, il provider offre spazio web, database, pannello di controllo e strumenti generici. L’utente installa il CMS, aggiorna plugin e gestisce il sito. In questo modello è difficile applicare un hardening realmente mirato, perché il provider non conosce necessariamente il comportamento specifico del progetto.
Un hosting gestito da sistemisti professionisti può invece adottare un approccio diverso. Dopo un tuning iniziale, è possibile individuare i percorsi che devono essere scrivibili, quelli che devono essere solo leggibili e quelli che possono essere protetti con attributi più restrittivi. Questo riduce la superficie d’attacco e rende più difficile per un malware modificare componenti critici.
Il valore non sta solo nell’eseguire chattr +i, ma nel sapere dove applicarlo, quando rimuoverlo e come reintegrarlo nei processi di aggiornamento. L’immutabilità deve convivere con la manutenzione: prima si sblocca, poi si aggiorna, si verifica il sito e infine si ripristina la protezione.
Limiti da non ignorare
L’attributo immutabile non è una soluzione miracolosa. Non sostituisce aggiornamenti, backup, isolamento degli utenti, scansioni malware, monitoraggio, WAF o buone policy di accesso. Inoltre, se un attaccante ottiene privilegi elevati sul server, potrebbe riuscire a rimuovere l’attributo, a seconda del contesto e delle capability disponibili.
Resta però una misura molto interessante contro una categoria frequente di attacchi: quelli che, dopo aver sfruttato una vulnerabilità del CMS o di un plugin, cercano di scrivere o modificare file all’interno dell’installazione web. In questi casi, ridurre la scrivibilità dei percorsi critici può fare una differenza concreta.
Conclusione
Aumentare la sicurezza di un CMS significa anche smettere di considerare il filesystem come un contenitore indistinto. Ogni file e ogni directory hanno una funzione diversa. Alcuni percorsi devono essere dinamici, altri dovrebbero rimanere stabili e altri ancora dovrebbero essere modificabili solo durante manutenzioni controllate.
Nel caso di WordPress, ma anche di Magento, PrestaShop, Drupal e Joomla, l’attributo di immutabilità del filesystem può rappresentare un livello aggiuntivo di difesa. Non elimina la necessità di aggiornare, monitorare e proteggere l’applicazione, ma riduce lo spazio di manovra di molti attacchi che puntano a scrivere backdoor o alterare file esistenti.
chattr +i è poco usato perché richiede competenza sistemistica e perché i pannelli di controllo generalisti non lo integrano normalmente come modello di sicurezza applicativa. Proprio per questo può diventare un elemento distintivo in un hosting gestito da professionisti: un tuning iniziale, una mappatura dei percorsi e una separazione precisa tra lettura, scrittura ed esecuzione possono trasformare una normale installazione CMS in un ambiente più robusto, più controllato e meno esposto agli attacchi automatizzati.
