Dall’inizio di quest\u2019anno ho iniziato a notare un pattern curioso. Ogni settimana parlo con agenzie, freelancer o piccole imprese che gestiscono diversi siti web presso altri provider di hosting. Molti approdano da noi dopo aver riscontrato lo stesso problema con il loro operatore: un sito si infetta e, poco dopo, anche tutti gli altri siti presenti sul server seguono a ruota.<\/p>\n\n\n\n
Tutto inizia con un singolo sito compromesso, poi appaiono script sospetti in altri progetti e, in alcuni casi, l’intero ambiente finisce per essere contaminato. La reazione \u00e8 quasi sempre la stessa: frustrazione, costi di bonifica, tempo prezioso sottratto al core business<\/em> e la netta sensazione che un aspetto cos\u00ec basilare come la sicurezza dovrebbe essere gestito meglio.<\/p>\n\n\n\n Ma quella che spesso sembra sfortuna, in realt\u00e0 non lo \u00e8. In molti casi, si tratta semplicemente di un problema di architettura. Quindi, cosa sta succedendo con tutti questi provider?<\/p>\n\n\n\n Quando gestisci pi\u00f9 siti web su uno stesso server, \u00e8 facile dare per scontato che ognuno funzioni in modo indipendente. E, in teoria, avresti ragione a pensarlo.<\/p>\n\n\n\n Quasi 11 anni fa, durante il mio primo training per il team di supporto di SiteGround, ci spiegarono l’isolamento degli account come uno standard aziendale<\/strong>. L’esempio che usavano era \u201c\u00c8 come la cintura di sicurezza, non esiste casa automobilistica che la pubblicizzi come un optional eccezionale, dato che ormai la offrono tutti\u201d. Per molti anni \u00e8 sembrato fosse cos\u00ec, tuttavia, in alcuni ambienti di hosting, questa separazione non \u00e8 cos\u00ec reale come appare<\/strong>.<\/p>\n\n\n\n Se il server non \u00e8 progettato con un adeguato isolamento tra gli account, un malintenzionato che riesce ad accedere a un sito pu\u00f2 tentare di muoversi lateralmente all’interno del sistema. Ci\u00f2 significa che, partendo da un singolo sito compromesso, pu\u00f2 provare a:<\/p>\n\n\n\n Questo fenomeno \u00e8 noto come contaminazione crociata<\/strong> (cross-contamination<\/em>) ed \u00e8 una delle cause pi\u00f9 comuni di infezioni di massa negli ambienti di hosting condiviso<\/strong>.<\/p>\n\n\n\n Molti utenti puntano il dito direttamente contro il CMS, i temi o i plugin, ma la realt\u00e0 \u00e8 che WordPress, ad esempio, alimenta oltre il 40% del web e la sua sicurezza dipende enormemente dall’ambiente in cui viene eseguito<\/strong>.<\/p>\n\n\n\n Se l’architettura del server non \u00e8 progettata per isolare correttamente ogni account, una vulnerabilit\u00e0 in un singolo sito pu\u00f2 trasformarsi rapidamente in un problema per tutti gli altri. Ecco perch\u00e9 cos\u00ec tante agenzie vivono lo stesso ciclo infinito:<\/p>\n\n\n\n Rilevare malware > Pagare per la pulizia > Il sito si reinfetta dopo poche settimane.<\/em><\/p>\n\n\n\n E questo non accade perch\u00e9 le agenzie in questione abbiano sbagliato qualcosa, ma perch\u00e9 l’ambiente continua a presentare la stessa debolezza strutturale<\/strong>.<\/p>\n\n\n\n Molti provider di hosting offrono assistenza solo quando il problema si \u00e8 gi\u00e0 verificato<\/strong>. Puliscono i file, ripristinano i backup<\/a> … e per quanto questo sia un processo necessario, non \u00e8 sufficiente per una gestione professionale di pi\u00f9 siti web.<\/p>\n\n\n\n La vera <\/strong>cybersicurezza<\/strong><\/a> inizia prima<\/em> che si verifichi l’infezione<\/strong>. In SiteGround<\/strong> abbiamo progettato la nostra infrastruttura con un approccio differente: dato che un sito web \u00e8 come una casa (puoi avere i migliori sistemi di sicurezza, ma se lasci una finestra aperta qualcuno pu\u00f2 entrare), cerchiamo di ridurre al minimo la possibilit\u00e0 che un’infezione si propaghi<\/strong> nelle altre stanze. Questo risultato si ottiene combinando diversi livelli di sicurezza<\/strong>.<\/p>\n\n\n\n Dopo oltre un decennio in SiteGround, se c’\u00e8 una cosa che ho potuto constatare con mano \u00e8 che la sicurezza rappresenta per noi le fondamenta di tutto. Il nostro sistema incorpora molteplici livelli di protezione<\/a>:<\/p>\n\n\n\n Questa \u00e8 la prima linea di difesa. I nostri server utilizzano un ambiente Apache chrooted con suEXEC<\/strong>, il che significa che ogni account opera all’interno del proprio ambiente isolato<\/strong>. In parole povere, questo impedisce a un sito di accedere ai file o ai processi di un altro.<\/p>\n\n\n\n Ogni account vive nella propria camera blindata. In sostanza, per ogni utente \u00e8 come essere l’unico sul server, gli altri siti web si trovano in uno userspace<\/em> completamente indipendente. Questo garantisce che, anche se il sito del vicino commette un errore e si infetta, il malware non ha fisicamente modo di saltare nei tuoi file o nei tuoi processi.<\/p>\n\n\n\n Molto prima che l’IA diventasse l’argomento di conversazione globale, noi la usavamo gi\u00e0 per proteggerti. I nostri sistemi IDS\/IPS agiscono come un radar che identifica bot malevoli e attacchi<\/strong><\/a> noti in millisecondi<\/strong>.<\/p>\n\n\n\n Ci\u00f2 che ci rende eccezionali \u00e8 che il nostro team di amministratori mitiga le minacce in modo cos\u00ec proattivo che, nella stragrande maggioranza dei casi, l’attacco viene bloccato ancora prima che l’utente possa accorgersi che il suo sito \u00e8 stato preso di mira.<\/p>\n\n\n\n Non ci accontentiamo di ci\u00f2 che viene fornito di serie. Abbiamo sviluppato un modulo di sicurezza interno basato su NGINX<\/strong> che analizza ogni singola richiesta che tenta di accedere al tuo sito. Trattandosi di una tecnologia proprietaria e personalizzata dai nostri esperti, il server non si limita a \u201cvedere\u201d il traffico, ma comprende e blocca automaticamente pattern sospetti che altri sistemi generici ignorerebbero.<\/p>\n\n\n\n Sviluppiamo le nostre Regole di Sicurezza WAF<\/strong> (Web Application Firewall<\/em>) e le aggiorniamo costantemente per proteggerti dalle nuove vulnerabilit\u00e0.<\/p>\n\n\n\n In altre parole, non ci limitiamo a monitorare i server, ma aggiorniamo il nostro WAF in tempo reale per bloccare tutto, dalle minacce storiche agli attacchi pi\u00f9 moderni<\/strong><\/a>, come i bot di IA che setacciano la rete alla ricerca automatica di qualsiasi punto debole nel tuo sito web.<\/p>\n\n\n\n Il software non aggiornato \u00e8 la porta aperta preferita dagli hacker. Per questo motivo, gestiamo gli aggiornamenti automatici di WordPress<\/strong> e dei suoi plugin in modo intelligente. Inoltre, i nostri server eseguono sempre le versioni di PHP pi\u00f9 recenti e stabili<\/a>. Mantenendo ogni ingranaggio al passo con i tempi, riduciamo drasticamente la superficie di attacco del tuo sito senza che tu debba muovere un dito.<\/p>\n\n\n\n La tecnologia \u00e8 fondamentale, ma il fattore umano \u00e8 ci\u00f2 che ci rende leader \u2013 e lo so bene, avendo trascorso 10 anni nel servizio clienti<\/a>.<\/p>\n\n\n\n Abbiamo un team di esperti dedicato esclusivamente a monitorare la nostra infrastruttura 24 ore su 24<\/strong>, 365 giorni all’anno. Se emerge una nuova vulnerabilit\u00e0 globale alle 3 del mattino, il nostro team sta gi\u00e0 applicando le regole di sicurezza prima ancora che tu ti svegli. Per noi, la sicurezza \u00e8 un impegno costante, molto pi\u00f9 di un processo automatizzato.<\/p>\n\n\n [86]<\/p>\n\n\n\n Non esiste una piattaforma invulnerabile al 100%, ma esistono architetture progettate affinch\u00e9 un incidente isolato non si trasformi in un disastro per tutti i siti presenti sul server.<\/p>\n\n\n\n La differenza tra il dover pulire costantemente infezioni ed evitarle del tutto, spesso risiede in qualcosa che non si vede, cio\u00e8 come \u00e8 costruito il telaio dell\u2019ambiente di hosting. Se gestisci diversi siti web, la domanda cruciale non \u00e8 solo cosa succede quando un sito si infetta, ma soprattutto: quell’infezione pu\u00f2 propagarsi al resto dei tuoi progetti?<\/strong><\/p>\n\n\n\n Se la risposta \u00e8 s\u00ec, probabilmente il problema non riguarda i tuoi siti, ma una configurazione inadeguata dell’hosting che non offre quell’isolamento degli account che dovrebbe essere ormai uno standard del settore.<\/p>\n\n\n\n In SiteGround, dal 2014 abbiamo migrato la nostra infrastruttura dai server dedicati all’architettura Cloud. Nel 2019, siamo passati dall’uso di cPanel a un pannello di controllo proprietario<\/a>. Successivamente, nel 2020, abbiamo trasferito tutto sull’infrastruttura di Google Cloud<\/a>.<\/p>\n\n\n\n In tutti questi anni e attraverso tutte queste evoluzioni <\/strong>\u2014 offrendo servizi a oltre 4 milioni di domini e avendo gestito personalmente migliaia di casi \u2014 posso dire che, nonostante le occasionali finestre lasciate aperte da qualche sito, non ho mai visto un singolo caso di contaminazione crociata tra i nostri clienti.<\/strong><\/p>\n\n\n\n<\/span>Quand\u2019\u00e8 che un’infezione si diffonde in tutto il server?<\/span><\/h2>\n\n\n\n
\n
Il problema potrebbe risiedere nell’ambiente scelto<\/h3>\n\n\n\n
Sicurezza reattiva vs sicurezza preventiva<\/h3>\n\n\n\n
<\/span>Come proteggiamo gli account sui nostri server<\/span><\/h2>\n\n\n\n
Isolamento degli account<\/h3>\n\n\n\n
Rilevamento e blocco degli attacchi<\/h3>\n\n\n\n
Protezione a livello di server<\/h3>\n\n\n\n
Firewall per applicazioni web (WAF)<\/h3>\n\n\n\n
Aggiornamenti e manutenzione continua<\/h3>\n\n\n\n
Monitoraggio attivo delle vulnerabilit\u00e0<\/h3>\n\n\n\n
<\/span>La differenza sta nel prevenire il problema<\/span><\/h2>\n\n\n\n