Purtroppo non possiamo evitare di essere mira di qualche sedicente hacker, se oltretutto gli offriamo la strada spianata con qualcosa di non aggiornato o maldestramente aggiunto da noi, aspettiamoci pure qualche brutto scherzo. E ora che si fa? La cosa più sbagliata è tentare di fare cose a caso, ci ritroveremo in breve tempo a non capire più nulla e a peggiorare la situazione, magari copiando il malware, distrattamente, anche nei backup "sani".
Cercare di dare uno scenario a ciò che è successo ci permetterà di capire cosa è meglio fare, magari anche pianificare con carta e penna degli step ci può aiutare a non ripercorrere strade sbagliate e soprattutto ci permetterà di tornare sui passi appena fatti. Ricordate comunque di fare i backup dei files e del database prima di incominciare e di conservarli, compressi sul desktop o su un disco usb.
1) Come scoprire se si è vittime di un attacco
Il malware introdotto può non funzionare su alcuni browser o sistemi operativi, quindi può darsi che sia un utente ad avvisarci di anomalie perchè noi non notiamo nulla. E' molto probabile che il codice del malware sia javascript e magari mirato ad una vulnerabilità specifica di browsers, o che richiede plugin del browser o applet o multimedia che noi non abbiamo installato.
Solitamente sono script che mirano al duplice scopo del furto di credenziali e di propagazione del malware.
Esistono online molti tool di verifica, il più popolare lo si trova negli "Strumenti webmaster" di Google.
Se siete un'attimino più avanzati potete installare Tamper Data, che si trova tra i plugin di Firefox, il quale mostra un dump degli headers dai quali si possono cercare quelli "strani" o che non centrano nulla col proprio sito.
Nell'ipotesi che vi rimanga il dubbio provate a consultare il vostro servizio di hosting che, grazie ai log e ad altri controlli può darvi risposte più certe.
2) Siete sicuri di essere stati attaccati
La prima domanda che ci viene è sicuramente "da chi?" e la seconda "perchè?"; quelle che seguono sono le ipotesi più probabili e comuni.
- Bandiere di pirati, rivendicazioni e simili sono opera sicura di ragazzini. Sfruttano il vostro cms o le sue estensioni non aggiornate contenenti vulnerabilità già rese pubbliche e copiano e incollano la stringa di esploit, nulla di più sareste capacissimi anche voi, credetemi. Aspettatevi danni di tutti i generi, non sanno cosa fanno quindi difficile prevedere, magari lasciano shell con cui rientrare comodamente nel dominio difficilmente ci sono veri e propri virus o trojan. Tovata la shell e cambiate le password l'attaccante è nuovamente inoffensivo, a patto però che aggiorniate il software vulnerabile.
- Poi c'è l'hacker più evoluto, sicuramente non professionista, che semplicemente vi lascia un messaggio tra quelli in home e vi segnala con una mail il problema o come contattarlo, per recuperare la password di admin che vi ha cambiato o suggerirvi la soluzione: lasciate perdere! La soluzione vera resta sempre quella sopra: aggiornate il software vulnerabile e se avete un dominio di proprietà cambiate la password dal database o chiedete all'hoster di farlo per voi spiegandogli l'accaduto. Non contattate il signore in questione perchè potrebbe spedirvi o farvi fare cose che portano ad ulteriori problemi.
- Poi c'è il caso più semplice, noto su qualche sito un problema o qualcosa che può condurmi ad un esploit e mi diverto a studiare il software e cercare il punto debole. Una volta trovato, provo se funziona poi segnalo al proprietario indicando anche la soluzione (se la so e se c'è).
Non copio nulla e non tocco nulla, non vi chiedo nulla, se volete approfittare della segnalazione fatelo altrimenti aspettate che la trovi qualcun'altro che vi spacca tutto, scegliete voi.
Perchè ho escluso i professionisti? Semplice, chi si occupa di sicurezza informatica o cerca obbiettivi notevolmente più "alti" del vostro sito o è in giro a cercare chi lo paga per trovare vulnerabilità, a gratis... non pigia un tasto!
- Per ultimo il caso più "rognoso",... quando vi arrivano le segnalazioni di malware. Perchè rognoso? Perchè a volte è difficile capire il meccanismo, il vero scopo, l'entità del danno e sicuramente l'autore.
Diciamo che la casistica comune è abbastanza circoscritta, il profilo informatico dell'autore solitamente è abbastanza elevato, aspettatevi tranquillamente qualcosa di complicato da rimuovere e di essere causa di una propagazione.
Solitamente se i problemi si verifcano su tutti i siti ospitati dal server è stata sfruttata qualche vulnerabilità del server, mentre se riguarda solo un certo cms possono essere passati da lì proseguendo poi con privilegi più alti a passeggiare per il server.
Gli ultimi casi di script dannosi su Joomla hanno dimostrato che la causa dell'iniezione del codice dannoso potreste essere pure voi, per vulnerabilità del vostro software locale di ftp o del vostro browser.
Durante la navigazione vi infettate visitando siti inappropriati o cliccando su link sconosciuti, magari attraverso tool di Facebook piuttosto che di altri social network. Accedendo successivamente ai contenuti del vostro sito come admin o facendo ftp i vostri files vengono modificati iniettando il codice (su diversi files). Molto difficile trovarlo e rimuoverlo.
In questo tipo di atacco solitamente non vengono danneggiati i contenuti poichè lo scopo è di rubare dati sensibili durante le altre normali operazioni col pc, il fatto di infettare il sito rigurada la propagazione.
3) Cosa si può fare
Innanzitutto una mail all'hoster è utile in quanto se non è stupido controllerà se può dipendere da lui, non lo ammettrà mai ma almeno c'è una buona probabilità che non si verifichi; tenete presente che arrabbiarsi o comunque per poter dialogare con un hoster vi serve mooolta calma.
Nella migliore delle ipotesi avete un backup e non è conservato sul server.
Avere backup sul server serve quasi a nulla, se vengono fatti danni vengono fatti anche su quelli e se siete voi la causa di infezione, non appena li trasferirete con l'ftp, li rendereste inutilizzabili.
Se avete il "backup perfetto", ovvero file zippato conservato su un disco locale con il backup del database, prima di procedere a qualsiasi operazione è necessario cercare l'infezione sul vostro pc.
Nell'esatto ordine faremo:
a) Se non abbiamo un backup da recuperare facciamolo salvando tutto in una cartella sulla scrivania. Evitate di aprire i files, per ora dimenticateveli lì. Quando parlo di backup parlo dei files e del database mysql.
b) Poi, pc fuori rete, avvio modalità provvisoria e scansione con almeno due antivirus a vs scelta.
c) Sostituzione di tutte le credenziali: ftp, mysql, posta e accesso al cms. Quello che non potete fare chiedete all'hoster che lo farà lui o vi spiegherà come procedere.
d) Pulite completamente il vostro spazio sul server e cancellate le tabelle del database mysql, attenzione ad eventuali tabelle che non riguardano il vostro cms (solitamente hanno un suffisso, Joomla di default usa jos_).
e) Se abbiamo il backup "sicuro" ripristiniamo con quello, nel caso non lo avessimo installiamo l'ultima versione del nostro cms sul sito ufficiale e sempre e solo da repository ufficiali, diffidate di modding, versioni light sviluppate da singoli etc...
f) Reinstallate le extensions che avevate in precedenza, anche quì vale quello detto sopra, ultima versione e dai repo ufficiali. Controllate sempre che l'estensione sia correntemente seguita e corretta dallo sviluppatore altrimenti scegliete sempre quelle dove potete contare su un supporto dello sviluppatore o di una community.
g) Ora dobbiamo riallineare il vecchio e probabilmente infetto e il nuovo cms.
In questa parte tutto ciò che verrà detto è rivolto specificamente a Joomla 1.5.xx (attuale 1.5.21).
Il rischio in questa operazione è di far ripartire il malware o di reinserire script nocivi tra i contenuti.
Con un buon antivirus si potrebbe analizzare la cartella del backup e nel caso venga segnalato qualche files eliminarlo con la sua procedura (quarantena etc..).
Bisogna a questo punto fare una valutazione su come procedere e questa sarà in base alla quantità di contenuti che erano presenti nel cms.
Quì non posso farla io per voi, la mia scelta sarebbe sempre quella dei "pochi contenuti", anche se a volte non sono affatto pochi, ma è la più sicura, ovvero: aprire il file di backup del database con un editor come notepad++ e copiare manualmente il contenuto di ogni articolo etc. nel editor del cms. Guardate se nel contenuto vi sono righe strane, solitamente molto disarmoniche con il resto del contenuto e quindi evidenti, se avete sospetti chiedete su un forum o rieditate il contenuto.
Alcune tabelle del db sono facilmente recuperabili avendo a disposizione phpmyadmin in locale e caricando il backup del solo db (no i files).
Ad esempio se avevate utenti registrati potete, dopo aver controllato che non vi siano altri utenti con privilegi non concessi, copiare le tabelle acl_aro e users al posto di quelle esistenti. Se la password era stata cambiata non riuscirete ad accedere all'area amministrativa, seguite la procedura di ripristino della password di Joomla.
Oppure se eravate l'unico editor e non c'era la possibilità di inserire contenuti, la probabilità che negli articoli vi sia qualcosa di dannoso è abbastanza bassa, se proprio i contenuti sono tanti da reinserire manualmente si può tentare. Dovrete riallineare gli id delle sezioni / categorie, quelle tabelle possono essere tranquillamente sostituite se nelle descrizioni non vi sono stringhe strane.
Altre indicazioni importanti può darvele sapere il tipo di vulnerabilità sfruttata; controllate sui siti dei vari sviluppatori e anche di Joomla quali erano i problemi riguardanti la vostra versione e come veniva sfruttata la falla.
Nei contenuti inoltre vengono solitamente inseriti link verso script esterni che sono innocui se non cliccati.
Tutte le altre tabelle riguardanti i componenti seguite più o meno questa logica ma non posso entrare nei particolari, poichè la casistica è troppo ampia.
Poi se ad esempio avevate una galleria e la possibilità di uploadare immagini o documenti, quelle sono cartelle a rischio, o meglio tra i contenuti può essere stato inserito qualche file con altra estensione, basta un controllo visivo, non devono esserci altro che files con estensioni di immagini o multimedia.
Se le varie cartelle contengono un file html di circa 40byte, non cliccateci sopra ma sostituitelo sovrascrivendolo con quello della nuova installazione, sono files vuoti che Joomla usa per non far visualizzare il contenuto della cartella e spesso sono contenitori di codice dannoso.
Un metodo sicuro per ripristinare non esiste, un po' di rischio di ricreare la situazione c'è sicuramente o meglio, il metodo sicuro sarebbe rifare tutto daccapo. Teniamo presente che è inutile cristare con il mondo intero e prendersela con uno o con l'altro, la colpa è solo nostra, un backup locale e in dieci minuti saremmo stati nuovamente online... non è complicato no?
4) Ora che è tutto a posto voglio blindarmi!
Umanamente comprensibile ma non vuol dire nulla.
Nessuna estensione sarà mai risolutiva e aumenterà le probabilità di rischio.
D'altronde è logica: più codice più possibilità di vulnerabilità, perchè un addons per la sicurezza dovrebbe esserne esente?
Io stesso scrivo estensioni per aumentare la sicurezza, ma intervengono in qualcosa di specifico, l'ombrello per tutto non esiste e non sarebbe neppure opportuno crearlo a scapito di velocità e incompatibilità o bugs con altri componenti che si vengono a creare.
Joomla (pacchetto base normalmente scaricabile) è già sicuro di suo, il codice è sicuro, nel senso che è scritto bene, è comunque in miglioramento continuo, seguito e testato da migliaia di utenti ad ogni livello di esperienza.
I problemi solitamente avvengono con le estensioni: chiunque può scrivere estensioni per joomla e renderle pubbliche; solitamente sul contenuto garantisce lui e una serie di commenti o opinioni di altri users piuttosto che vere e proprie comunità che offrono supporto. Scaricare estensioni a caso o sconosciute o non mantenute e via dicendo non è una buona idea.
5) La vera sicurezza è un atteggiamento
... E le best practices!
Se ti entrano in casa perchè lasci le chiavi sull'uscio è inutile sostituire la porta, probabilmente devi smettere di bere...
Non è una battuta, o meglio, è importante chiedersi sempre se si agisce in modo sicuro, probabilmente, pensandoci, commettiamo infiniti errori dettati da molteplici fattori.
Senza citare tricks tecnici fissiamo dei punti che possono essere utili:
- I browser sono causa di molti problemi di vulnerabilità e infettato il browser c'è poco da fare, tenetelo aggiornato e così pure tutti gli strumenti con cui lavorate in locale. Hanno inoltre problemi di steeling di dati quindi visitare più siti con sessioni autenticate possono diventare dei problemi. I browser sui social network raggiungono l'apice dei problemi. Non ditevi mai " ... ma io uso linux", non centra nulla, i rischi ci sono eccome, la sicurezza mitizzata di linux deriva da altre cose.
- Abbonarsi a feed di sicurezza sia di Joomla sia di molte estension è gratuito, perchè no? Aggiornando joomla non si perde nulla e così pure con le estensioni serie, e se avete dubbi c'è un forum quasi in ogni lingua. Se avete paura di fare pasticci... il backup esiste!
- Usare password sicure. Ci sono moltissimi metodi, vi dico uno che secondo me è semplice e offre un buon livello di sicurezza. Le password vengono salvate nel database di joomla, come nella maggior parte dei database delle applicazioni online, criptate in md5. Di per se è già una buna sicurezza solo che comincia ad essere vecchiotto e ci sono vari tool che appoggiandosi a liste online, con password deboli riescono a risalire alla stringa. Solitamente il danno è a cascata perchè la probabilità che usiate la stessa password un po' ovunque è molto alta.
Se la vostra stringa password è "paperino" criptatela prima voi con l'md5 (meglio tool locali), anche se il database venisse violato sarebbe molto difficile riuscire a decriptare la password, oserei dire impossibile per la quasi totalità delle persone. Macchinoso? ..forse si ma la sicurezza a fatica 0 non esiste: se una porta a 10 mandate è più sicura di una da 5 dovrete fare la fatica delle 5 mandate in più, se gliene date solo 5 per non fare fatica il risultato della sicurezza aggiunta è appunto 0.
- I backup. Questa dovrebbe essere sempre una policy di sicurezza! ...se ci fosse un backup valido il più grave dei problemi o delle catastrofi sarebbe risolvibile in 5 minuti. Ovviamente anche questo è questione di fatica e di impegno, d'altronde avere un sito online è un impegno dimenticatevi di qualcosa che sia "eterno", anzi ultimamente è tutto così provvisorio...
Ovviamente il nostro hosting ci offre la soluzione e a costo quasi di un caffè, perchè non approfittarne e non fare più fatica? Semplice perchè si ricade nell'esempio delle mandate della porta, se il backup è online è raggiungibile anche dal nostro hacker e se avete un virus lo danneggerete al momento dell'"ftp". Praticamente il backup online sullo stesso server e con lo stesso privilegio di accesso del sito è inutile.
- L'affannosa ricerca dell'estensione miracolosa, che risolva tutti inostri problemi ogni volta, senza pensare che a volte Joomla ha già funzionalità facilmente adattabili, lascia il nostro sito e il nostro database pieno di codice obsoleto. Se nel db può essere solo causa di peso, i files abbandonati funzionano benissimo come passaggio e così pure i componenti disattivati.
- Anche l'ambiente che ospita la nostra applicazione deve essere adatto, perchè chi l'ha scritta assicura il funzionamento in determinate condizioni, se questo non fosse un fattore determinante si sarebbe potuto sorvolare, ma non lo è.
L'ambiente diventa poi essenziale se si offono servizi commerciali dove un minimo di sicurezza dovrebbe essere garantita, se la vostra banca usasse Joomla per fare home banking sull server di qualche rinomato hosting sarebbe per loro notevolmente più pratico ed economico forse però non durerebbe 10 minuti e non potrebbero certo dire ai loro clienti che joomla non ha vulnerabilità note.
- Se riuscire ad aggiugere i nostri script ci può far sentire padroni dell'applicazione a volte diventa un rischio se non si sa valutarne l'impatto sul resto del codice, ciò che si può o si riesce a fare non sempre è un vantaggio farlo.
Il malware introdotto può non funzionare su alcuni browser o sistemi operativi, quindi può darsi che sia un utente ad avvisarci di anomalie perchè noi non notiamo nulla. E' molto probabile che il codice del malware sia javascript e magari mirato ad una vulnerabilità specifica di browsers, o che richiede plugin del browser o applet o multimedia che noi non abbiamo installato.
Solitamente sono script che mirano al duplice scopo del furto di credenziali e di propagazione del malware.
Esistono online molti tool di verifica, il più popolare lo si trova negli "Strumenti webmaster" di Google.
Se siete un'attimino più avanzati potete installare Tamper Data, che si trova tra i plugin di Firefox, il quale mostra un dump degli headers dai quali si possono cercare quelli "strani" o che non centrano nulla col proprio sito.
Nell'ipotesi che vi rimanga il dubbio provate a consultare il vostro servizio di hosting che, grazie ai log e ad altri controlli può darvi risposte più certe.
2) Siete sicuri di essere stati attaccati
La prima domanda che ci viene è sicuramente "da chi?" e la seconda "perchè?"; quelle che seguono sono le ipotesi più probabili e comuni.
- Bandiere di pirati, rivendicazioni e simili sono opera sicura di ragazzini. Sfruttano il vostro cms o le sue estensioni non aggiornate contenenti vulnerabilità già rese pubbliche e copiano e incollano la stringa di esploit, nulla di più sareste capacissimi anche voi, credetemi. Aspettatevi danni di tutti i generi, non sanno cosa fanno quindi difficile prevedere, magari lasciano shell con cui rientrare comodamente nel dominio difficilmente ci sono veri e propri virus o trojan. Tovata la shell e cambiate le password l'attaccante è nuovamente inoffensivo, a patto però che aggiorniate il software vulnerabile.
- Poi c'è l'hacker più evoluto, sicuramente non professionista, che semplicemente vi lascia un messaggio tra quelli in home e vi segnala con una mail il problema o come contattarlo, per recuperare la password di admin che vi ha cambiato o suggerirvi la soluzione: lasciate perdere! La soluzione vera resta sempre quella sopra: aggiornate il software vulnerabile e se avete un dominio di proprietà cambiate la password dal database o chiedete all'hoster di farlo per voi spiegandogli l'accaduto. Non contattate il signore in questione perchè potrebbe spedirvi o farvi fare cose che portano ad ulteriori problemi.
- Poi c'è il caso più semplice, noto su qualche sito un problema o qualcosa che può condurmi ad un esploit e mi diverto a studiare il software e cercare il punto debole. Una volta trovato, provo se funziona poi segnalo al proprietario indicando anche la soluzione (se la so e se c'è).
Non copio nulla e non tocco nulla, non vi chiedo nulla, se volete approfittare della segnalazione fatelo altrimenti aspettate che la trovi qualcun'altro che vi spacca tutto, scegliete voi.
Perchè ho escluso i professionisti? Semplice, chi si occupa di sicurezza informatica o cerca obbiettivi notevolmente più "alti" del vostro sito o è in giro a cercare chi lo paga per trovare vulnerabilità, a gratis... non pigia un tasto!
- Per ultimo il caso più "rognoso",... quando vi arrivano le segnalazioni di malware. Perchè rognoso? Perchè a volte è difficile capire il meccanismo, il vero scopo, l'entità del danno e sicuramente l'autore.
Diciamo che la casistica comune è abbastanza circoscritta, il profilo informatico dell'autore solitamente è abbastanza elevato, aspettatevi tranquillamente qualcosa di complicato da rimuovere e di essere causa di una propagazione.
Solitamente se i problemi si verifcano su tutti i siti ospitati dal server è stata sfruttata qualche vulnerabilità del server, mentre se riguarda solo un certo cms possono essere passati da lì proseguendo poi con privilegi più alti a passeggiare per il server.
Gli ultimi casi di script dannosi su Joomla hanno dimostrato che la causa dell'iniezione del codice dannoso potreste essere pure voi, per vulnerabilità del vostro software locale di ftp o del vostro browser.
Durante la navigazione vi infettate visitando siti inappropriati o cliccando su link sconosciuti, magari attraverso tool di Facebook piuttosto che di altri social network. Accedendo successivamente ai contenuti del vostro sito come admin o facendo ftp i vostri files vengono modificati iniettando il codice (su diversi files). Molto difficile trovarlo e rimuoverlo.
In questo tipo di atacco solitamente non vengono danneggiati i contenuti poichè lo scopo è di rubare dati sensibili durante le altre normali operazioni col pc, il fatto di infettare il sito rigurada la propagazione.
3) Cosa si può fare
Innanzitutto una mail all'hoster è utile in quanto se non è stupido controllerà se può dipendere da lui, non lo ammettrà mai ma almeno c'è una buona probabilità che non si verifichi; tenete presente che arrabbiarsi o comunque per poter dialogare con un hoster vi serve mooolta calma.
Nella migliore delle ipotesi avete un backup e non è conservato sul server.
Avere backup sul server serve quasi a nulla, se vengono fatti danni vengono fatti anche su quelli e se siete voi la causa di infezione, non appena li trasferirete con l'ftp, li rendereste inutilizzabili.
Se avete il "backup perfetto", ovvero file zippato conservato su un disco locale con il backup del database, prima di procedere a qualsiasi operazione è necessario cercare l'infezione sul vostro pc.
Nell'esatto ordine faremo:
a) Se non abbiamo un backup da recuperare facciamolo salvando tutto in una cartella sulla scrivania. Evitate di aprire i files, per ora dimenticateveli lì. Quando parlo di backup parlo dei files e del database mysql.
b) Poi, pc fuori rete, avvio modalità provvisoria e scansione con almeno due antivirus a vs scelta.
c) Sostituzione di tutte le credenziali: ftp, mysql, posta e accesso al cms. Quello che non potete fare chiedete all'hoster che lo farà lui o vi spiegherà come procedere.
d) Pulite completamente il vostro spazio sul server e cancellate le tabelle del database mysql, attenzione ad eventuali tabelle che non riguardano il vostro cms (solitamente hanno un suffisso, Joomla di default usa jos_).
e) Se abbiamo il backup "sicuro" ripristiniamo con quello, nel caso non lo avessimo installiamo l'ultima versione del nostro cms sul sito ufficiale e sempre e solo da repository ufficiali, diffidate di modding, versioni light sviluppate da singoli etc...
f) Reinstallate le extensions che avevate in precedenza, anche quì vale quello detto sopra, ultima versione e dai repo ufficiali. Controllate sempre che l'estensione sia correntemente seguita e corretta dallo sviluppatore altrimenti scegliete sempre quelle dove potete contare su un supporto dello sviluppatore o di una community.
g) Ora dobbiamo riallineare il vecchio e probabilmente infetto e il nuovo cms.
In questa parte tutto ciò che verrà detto è rivolto specificamente a Joomla 1.5.xx (attuale 1.5.21).
Il rischio in questa operazione è di far ripartire il malware o di reinserire script nocivi tra i contenuti.
Con un buon antivirus si potrebbe analizzare la cartella del backup e nel caso venga segnalato qualche files eliminarlo con la sua procedura (quarantena etc..).
Bisogna a questo punto fare una valutazione su come procedere e questa sarà in base alla quantità di contenuti che erano presenti nel cms.
Quì non posso farla io per voi, la mia scelta sarebbe sempre quella dei "pochi contenuti", anche se a volte non sono affatto pochi, ma è la più sicura, ovvero: aprire il file di backup del database con un editor come notepad++ e copiare manualmente il contenuto di ogni articolo etc. nel editor del cms. Guardate se nel contenuto vi sono righe strane, solitamente molto disarmoniche con il resto del contenuto e quindi evidenti, se avete sospetti chiedete su un forum o rieditate il contenuto.
Alcune tabelle del db sono facilmente recuperabili avendo a disposizione phpmyadmin in locale e caricando il backup del solo db (no i files).
Ad esempio se avevate utenti registrati potete, dopo aver controllato che non vi siano altri utenti con privilegi non concessi, copiare le tabelle acl_aro e users al posto di quelle esistenti. Se la password era stata cambiata non riuscirete ad accedere all'area amministrativa, seguite la procedura di ripristino della password di Joomla.
Oppure se eravate l'unico editor e non c'era la possibilità di inserire contenuti, la probabilità che negli articoli vi sia qualcosa di dannoso è abbastanza bassa, se proprio i contenuti sono tanti da reinserire manualmente si può tentare. Dovrete riallineare gli id delle sezioni / categorie, quelle tabelle possono essere tranquillamente sostituite se nelle descrizioni non vi sono stringhe strane.
Altre indicazioni importanti può darvele sapere il tipo di vulnerabilità sfruttata; controllate sui siti dei vari sviluppatori e anche di Joomla quali erano i problemi riguardanti la vostra versione e come veniva sfruttata la falla.
Nei contenuti inoltre vengono solitamente inseriti link verso script esterni che sono innocui se non cliccati.
Tutte le altre tabelle riguardanti i componenti seguite più o meno questa logica ma non posso entrare nei particolari, poichè la casistica è troppo ampia.
Poi se ad esempio avevate una galleria e la possibilità di uploadare immagini o documenti, quelle sono cartelle a rischio, o meglio tra i contenuti può essere stato inserito qualche file con altra estensione, basta un controllo visivo, non devono esserci altro che files con estensioni di immagini o multimedia.
Se le varie cartelle contengono un file html di circa 40byte, non cliccateci sopra ma sostituitelo sovrascrivendolo con quello della nuova installazione, sono files vuoti che Joomla usa per non far visualizzare il contenuto della cartella e spesso sono contenitori di codice dannoso.
Un metodo sicuro per ripristinare non esiste, un po' di rischio di ricreare la situazione c'è sicuramente o meglio, il metodo sicuro sarebbe rifare tutto daccapo. Teniamo presente che è inutile cristare con il mondo intero e prendersela con uno o con l'altro, la colpa è solo nostra, un backup locale e in dieci minuti saremmo stati nuovamente online... non è complicato no?
4) Ora che è tutto a posto voglio blindarmi!
Umanamente comprensibile ma non vuol dire nulla.
Nessuna estensione sarà mai risolutiva e aumenterà le probabilità di rischio.
D'altronde è logica: più codice più possibilità di vulnerabilità, perchè un addons per la sicurezza dovrebbe esserne esente?
Io stesso scrivo estensioni per aumentare la sicurezza, ma intervengono in qualcosa di specifico, l'ombrello per tutto non esiste e non sarebbe neppure opportuno crearlo a scapito di velocità e incompatibilità o bugs con altri componenti che si vengono a creare.
Joomla (pacchetto base normalmente scaricabile) è già sicuro di suo, il codice è sicuro, nel senso che è scritto bene, è comunque in miglioramento continuo, seguito e testato da migliaia di utenti ad ogni livello di esperienza.
I problemi solitamente avvengono con le estensioni: chiunque può scrivere estensioni per joomla e renderle pubbliche; solitamente sul contenuto garantisce lui e una serie di commenti o opinioni di altri users piuttosto che vere e proprie comunità che offrono supporto. Scaricare estensioni a caso o sconosciute o non mantenute e via dicendo non è una buona idea.
5) La vera sicurezza è un atteggiamento
... E le best practices!
Se ti entrano in casa perchè lasci le chiavi sull'uscio è inutile sostituire la porta, probabilmente devi smettere di bere...
Non è una battuta, o meglio, è importante chiedersi sempre se si agisce in modo sicuro, probabilmente, pensandoci, commettiamo infiniti errori dettati da molteplici fattori.
Senza citare tricks tecnici fissiamo dei punti che possono essere utili:
- I browser sono causa di molti problemi di vulnerabilità e infettato il browser c'è poco da fare, tenetelo aggiornato e così pure tutti gli strumenti con cui lavorate in locale. Hanno inoltre problemi di steeling di dati quindi visitare più siti con sessioni autenticate possono diventare dei problemi. I browser sui social network raggiungono l'apice dei problemi. Non ditevi mai " ... ma io uso linux", non centra nulla, i rischi ci sono eccome, la sicurezza mitizzata di linux deriva da altre cose.
- Abbonarsi a feed di sicurezza sia di Joomla sia di molte estension è gratuito, perchè no? Aggiornando joomla non si perde nulla e così pure con le estensioni serie, e se avete dubbi c'è un forum quasi in ogni lingua. Se avete paura di fare pasticci... il backup esiste!
- Usare password sicure. Ci sono moltissimi metodi, vi dico uno che secondo me è semplice e offre un buon livello di sicurezza. Le password vengono salvate nel database di joomla, come nella maggior parte dei database delle applicazioni online, criptate in md5. Di per se è già una buna sicurezza solo che comincia ad essere vecchiotto e ci sono vari tool che appoggiandosi a liste online, con password deboli riescono a risalire alla stringa. Solitamente il danno è a cascata perchè la probabilità che usiate la stessa password un po' ovunque è molto alta.
Se la vostra stringa password è "paperino" criptatela prima voi con l'md5 (meglio tool locali), anche se il database venisse violato sarebbe molto difficile riuscire a decriptare la password, oserei dire impossibile per la quasi totalità delle persone. Macchinoso? ..forse si ma la sicurezza a fatica 0 non esiste: se una porta a 10 mandate è più sicura di una da 5 dovrete fare la fatica delle 5 mandate in più, se gliene date solo 5 per non fare fatica il risultato della sicurezza aggiunta è appunto 0.
- I backup. Questa dovrebbe essere sempre una policy di sicurezza! ...se ci fosse un backup valido il più grave dei problemi o delle catastrofi sarebbe risolvibile in 5 minuti. Ovviamente anche questo è questione di fatica e di impegno, d'altronde avere un sito online è un impegno dimenticatevi di qualcosa che sia "eterno", anzi ultimamente è tutto così provvisorio...
Ovviamente il nostro hosting ci offre la soluzione e a costo quasi di un caffè, perchè non approfittarne e non fare più fatica? Semplice perchè si ricade nell'esempio delle mandate della porta, se il backup è online è raggiungibile anche dal nostro hacker e se avete un virus lo danneggerete al momento dell'"ftp". Praticamente il backup online sullo stesso server e con lo stesso privilegio di accesso del sito è inutile.
- L'affannosa ricerca dell'estensione miracolosa, che risolva tutti inostri problemi ogni volta, senza pensare che a volte Joomla ha già funzionalità facilmente adattabili, lascia il nostro sito e il nostro database pieno di codice obsoleto. Se nel db può essere solo causa di peso, i files abbandonati funzionano benissimo come passaggio e così pure i componenti disattivati.
- Anche l'ambiente che ospita la nostra applicazione deve essere adatto, perchè chi l'ha scritta assicura il funzionamento in determinate condizioni, se questo non fosse un fattore determinante si sarebbe potuto sorvolare, ma non lo è.
L'ambiente diventa poi essenziale se si offono servizi commerciali dove un minimo di sicurezza dovrebbe essere garantita, se la vostra banca usasse Joomla per fare home banking sull server di qualche rinomato hosting sarebbe per loro notevolmente più pratico ed economico forse però non durerebbe 10 minuti e non potrebbero certo dire ai loro clienti che joomla non ha vulnerabilità note.
- Se riuscire ad aggiugere i nostri script ci può far sentire padroni dell'applicazione a volte diventa un rischio se non si sa valutarne l'impatto sul resto del codice, ciò che si può o si riesce a fare non sempre è un vantaggio farlo.
