Sarà successo a molti di voi che, all’improvviso, tutti i siti web fossero offline. Soprattutto a coloro i quali utilizzano servizi di Hosting condiviso.
Oddio, cosa può essere successo? Si è rotto il server? C’è stato un attacco hacker? Gli alieni??? L’invasione delle locuste???
Ansia e interrogativi a parte, la risposta è molto semplice: è stato il tuo Hosting Provider a spegnere tutto. Si, proprio così.
Perché? E soprattutto, perché non sono stato avvisato prima?
Ora come diavolo faccio? Non posso accedere per fare dei controlli né per sistemare. Sono bloccato! Maledetto Provider di m***a!!!
Imprecazioni e disquisizioni tra gentlemen a parte, le motivazioni possono essere molteplici ma tutte hanno un filo conduttore: c’è sempre di mezzo un Hosting Shared.
Scegliere un hosting condiviso è un po’ come prendere casa in un condominio. Non puoi sceglierti i vicini, quindi se sei fortunato avrai un vicinato gentile, tranquillo e garbato, ma se le cose ti vanno male, i vicini saranno rumorosi, fastidiosi (in molti modi) e petulanti. Ah, questi vicini, quanto petulano!
L’equivalente sul server condiviso di un vicino rumoroso, è un sito web che per un motivo o per un altro richiede una quantità di risorse tale da compromettere il corretto funzionamento del server e, di conseguenza, anche del tuo sito web.
Facciamo un esempio
Diciamo che hai un sito web di piccole dimensioni. Avrai pensato, perché acquistare un server dedicato? Il mio sito è leggero e non riceve tantissimo traffico, almeno per il momento, quindi è inutile spendere (tanto) di più per un server le cui risorse sono decisamente sovrabbondanti rispetto alle mie necessità. Questo ragionamento è corretto, se non fosse che scegliendo un hosting condiviso, le risorse a tua disposizione variano in funzione di quelle necessarie ai singoli siti web ospitati sullo stesso server. Se cioè i tuoi “vicini” ad un certo punto cominciano ad essere esosi in termini di risorse, a scontarla potrebbe essere proprio il tuo sito web pur senza averne alcuna colpa, perché potrebbe risentire di rallentamenti nei tempi di apertura di pagina, o di downtime del server.
In quali condizioni possono verificarsi questi problemi?
Molto spesso per noncuranza si sceglie il servizio hosting senza rendersi effettivamente conto di cosa serva realmente ad un progetto business per affrontare il mercato del web in tranquillità. In sostanza quello che manca è la ponderazione, alla base della quale ci dev’essere cognizione di causa.
In pratica il tuo sito web potrebbe essere rallentato (fino a non essere più raggiungibile) perché uno o più d’uno tra gli altri siti ospitati potrebbero presentare le seguenti caratteristiche, singolarmente o tutte insieme:
- Sviluppano troppo traffico
- Presentano un codice inutilmente pesante
- Presentano media non ottimizzati per il web
- Sono sotto attacco di tipo cracker o Negative SEO
Quelle sopraelencate sono le condizioni più frequenti che determinano problemi sia al sito web “pesante” che potenzialmente anche agli altri siti. In caso di SEO negativa ci si può mettere al riparo prendendo un indirizzo IP dedicato, anche se in linea di massima i problemi riguardano il dominio interessato, non l’intero IP.
Quello che un buon provider dovrebbe fare in caso constatasse un rallentamento di più siti dovuto ad uno solo di essi, è contattare il webmaster del sito in questione e sottoporgli il problema. A questo punto è chiaro che se passano diversi giorni e il proprietario del sito “incriminato” non si adopera per risolvere il problema, il provider deve pensare a tutelare gli altri siti sullo stesso server… l’unico modo è spegnere il sito che rallenta tutto il sistema, per lo meno finché il titolare non decide di rispondere.
Come risolvere il problema alla radice
L’importanza di un sito web non è data per forza dalle sue dimensioni. Un sito “piccolo”, di poche pagine, che viene raggiunto solo da 100 visitatori al giorno, può generare un business enorme a seconda del progetto che ha alle spalle. Quando le cose stanno così, sarebbe opportuno mettere il sito in sicurezza migrandolo su di un server virtuale, cioè una macchina che pur ospitando diversi siti web, definisce ed alloca per ciascuno di essi una quantità di risorse definite. In questo caso il server è diviso in compartimenti stagni, per cui se un sito va in esubero di risorse non può andare a pesare sul tuo.
Conclusioni
Quando il tuo progetto è importante, ma non tanto sviluppato da richiedere un server dedicato, puoi trovare nel VPS un ottimo compromesso in termini di sicurezza, affidabilità… e non ultimo, per il rapporto qualità/prezzo.
Nella mia esperienza questi problemi derivano spessissimo da backdoor o malware inseriti in modo subdolo in theme (e a volte anche plugin) WordPress, ma il discorso si potrebbe estendere a qualsiasi altro CMS. L’inesperienza di alcuni utenti e l’incompetenza di certi provider fanno il resto… Sono da sempre dell’idea che bisognerebbe insistere parecchio sulla formazione in campo sicurezza informatica, che ormai non è più materia per soli esperti, dato che un po’ tutti ormai hanno un sito proprio da gestirsi. Grazie dello spazio concesso 🙂
La maggior parte di questi problemi derivano, quantomeno in base a ciò che vedo da diversi anni, non tanto dall presenza di codice malevolo inserito in modo subdolo nei temi e nei plugin ad opera degli stessi sviluppatori. L’incidenza maggiore è dovuta invece proprio all’incompetenza degli sviluppatori di quegli stessi temi e plugins, il cui inevitabile risultato è la produzione di software molto poco sicuro che si presta alla grande a sql injections ed exploits di diverso genere.
L’aspetto, a mio avviso, davvero sconcertante è che la presenza di malware passa del tutto inosservata sia agli occhi del proprietario del sito web, sia agli occhi del webmaster/programmatore. Eppure basterebbe un banalissimo sistema di scansione antimalware (che per altro in FlameNetworks usiamo di default su tutti i nostri sistemi) per evidenziare queste criticità ed implementare determinate azioni di messa in sicurezza delle applicazioni.
Sul sw di terze parti (es: moduli, plugins, estensioni, temi, etc…) si dovrebbero effettuare delle analisi per “certificare” che quel software può essere rilasciato in produzione. Una sorta di auditing, così da eliminare un pò di bug alla fonte ed avere codice più sicuro e pulito.
La sicurezza non è mai abbastanza, sono d’accordo sull’esigenza di insistere con la formazione in tal senso.
Ciao! 🙂