Archives For Security

Ci hai mai pensato? Utilizzi una casella di Google come principale. Probabilmente ci fai arrivare qualsiasi tua e-mail, che sia personale o di lavoro, senza pensarci su due volte. È capitato solo una manciata di giorni fa che una mia collega di lavoro si sia chiusa la porta dietro le spalle. Un banale cambio password che, per un motivo o l’altro, dopo un soffio è scappato via. Ha dimenticato quella password appena modificata perché il processo non era andato a buon fine al primo colpo. Una scemenza? Certo che sì. Una cosa che non potrebbe mai capitare a te? Forse. C’è modo di rimediare al detto “il backup è quella cosa di cui ti preoccupi dopo aver fatto il danno“? Si.

SMTP di GMail: l'utilizzo tramite app 2

Prima di arrivare alla situazione attuale ho provato diverse alternative. Non vorrei perdere da un giorno all’altro l’accesso al mio indirizzo e alla cronistoria scritta. Per il primo non c’è problema (il dominio è mio, posso facilmente reindirizzare la posta in ingresso), per il secondo un po’ meno, serve giusto il tempo di fare restore verso una diversa casella. Questo grazie a Gmvault, programma gratuito che funziona su più sistemi.

Senza scendere troppo nel dettaglio, puoi scaricare e installare facilmente Gmvault sul tuo PC. A quel punto dovrai semplicemente autenticarti e iniziare la prima sincronizzazione che creerà una copia di tutte le tue e-mail all’interno di una directory da te scelta.

Autenticazione

Una volta avviata la shell di Gmvault, potrai semplicemente lanciare un gmvault sync tuoaccount@gmail.com per chiedere al software di far partire una nuova finestra del browser tramite la quale autenticarti sul tuo account di posta elettronica, quindi tornare indietro con il token che autorizza l’azione e procedere con la prima sincronizzazione. Tutto viene riportato nella documentazione ufficiale, e nello specifico all’indirizzo gmvault.org/in_depth.html#authentication

Un backup in locale di GMail con Gmvault

Se hai un’autenticazione in due fattori e preferisci passare da una password specifica per applicazione, puoi lanciare un gmvault sync tuoaccount@gmail.com -p, ti verrà richiesto di inserire la password a video subito dopo. Aggiungendo in coda il parametro --store-passwd potrai chiedere a Gmvault di salvare quella password nelle sue impostazioni così da non doverla specificare successivamente (basterà un -p senza null’altro, Gmvault utilizzerà la password memorizzata), ma ricorda che seppur offuscata è pur sempre rischioso.

Dove salvare

Gmvault, salvo diversa specifica da parte tua, salverà ogni singola mail in formato eml, con un ulteriore file .meta in cui inserirà ulteriori informazioni (utili per un successivo restore, se mai dovesse servire), il tutto all’interno di una cartella predefinita chiamata gmail-db che troverai nella tua cartella utente di Windows. Per questo motivo ho preferito sin da subito modificare il puntamento di quella cartella, stessa cosa che puoi fare anche tu con il parametro -d. Tanto per farla completa, potrai lanciare Gmvault passandogli il giusto parametro per l’autenticazione e modificare la directory dove effettuare il salvataggio, per esempio gmvault sync tuoaccount@gmail.com -p -d C:\BackupGmail

Da qui in poi è solo attesa e velocità della connessione per scaricare tutto il contenuto della tua casella di posta elettronica.

Un backup in locale di GMail con Gmvault 1

Ora manca solo uno step, quello che riguarda la costanza.

Schedulazione

Ammirevole voler effettuare un backup ora che il disastro è stato sfiorato (nel caso della mia collega abbiamo fatto un redirect temporaneo verso un’altra casella grazie a un’ultima sessione viva collegata ancora al suo account principale, poi recuperato l’accesso dopo circa tre settimane di attesa e innumerevoli tentativi di farsi riconoscere da Google), ma ciò che è davvero importante è continuare a essere costanti, ripetere l’operazione nel tempo, basta una schedulazione :-)

Sul PC dove è stato installato e utilizzato per la prima volta Gmvault, ti basterà aprire l’Utilità di Pianificazione di Windows, quindi creare una nuova attività di base. Pubblico qui di seguito una galleria che ti permette di vedere tutti i passaggi, dopo riporto ciò che c’è da sapere / copiare per rendere tutto più semplice:

Crea una nuova attività di base e programmala per partire quando credi di averne necessità (io, visto il carico di posta ricevuta e inviata, ho programmato un job alle 20:30, 4 volte alla settimana), seleziona l’avvio di un programma e scegli gmvault.bat, lo trovi in %LocalAppdata%\gmvault (ti ricordo che %LocalAppData% corrisponde alla cartella C:\Users\TUONOME\AppData\Local), aggiungi un comando in coda (quindi specificalo nella riga “Aggiungi argomenti”) che permette al batch di lanciare la sincronizzazione:

sync -t quick TUOACCOUNT@gmail.com -d C:\BackupGMail

Tranne la prima parte (dove ritoccare solo il tuo indirizzo di posta elettronica), la seconda è del tutto modificabile. Il -d dovrà essere utilizzato solo per variare la directory dove salvare le nuove mail trovate sul tuo account. Ovviamente, alla stessa maniera, potrai specificare il -p se hai inserito e memorizzato precedentemente una password, e così via (vale quanto già raccontato nel paragrafo relativo al backup, ma anche ogni diverso riferimento riportato nella documentazione ufficiale del programma).

Se vuoi verificare di aver fatto tutto per bene, puoi provare ad avviare manualmente il job (tasto destro sull’operazione schedulata, un clic su Esegui), quindi dare un’occhiata alla finestra che ti comparirà a video, la quale dovrebbe portare a termine il lavoro in maniera del tutto automatica, per poi chiudersi.

Tutto funziona bene, i file EML li puoi aprire con Outlook (o altri programmi compatibili) e il tutto è fatto perché un domani tu possa recuperare ciò che hai perso eseguendo un restore con la stessa facilità del backup, anche se non te lo auguro! ;-)

Stamattina mi trovavo in giro per Milano per un paio di appuntamenti. Ho ingannato l’attesa dando un’occhiata a Twitter, e ho fatto caso ad alcuni strani movimenti decisamente poco avvezzi all’essere autorizzati dai relativi proprietari, si trattava di stati clonati tra di loro, tutti più o meno pubblicati in una stessa fascia oraria, un evidente attacco a tappeto. Si è trattato di un vero e proprio sfacelo, di quelli che da qualche tempo non se ne vedevano più, pare che colpa sia stata di un’applicazione di terza parte con autorizzazioni di lettura e scrittura sugli account Twitter dei suoi utilizzatori.

Di Twitter, Turchia e accessi indesiderati

Ho visto per primi i tweet di Paolo Attivissimo, che è solito ricevere, verificare e rilanciare materiale solo se non si tratta di bufale (che in realtà combatte da sempre e stronca sul nascere). Uno, poi un altro, poi altri ancora e così via, sembra che account non collegati tra di loro abbiano pubblicato stati pro-Erdoğan (il presidente turco):

Il tweet contiene una svastica, alcuni hashtag che si riferiscono al nazismo, un video celebrativo del presidente turco Recep Tayyip Erdoğan e varie scritte fra cui “ci vediamo il 16 aprile”. È la data del referendum costituzionale in Turchia che deciderà se rafforzare i poteri del presidente, una riforma promossa e sponsorizzata dallo stesso Erdoğan. I riferimenti al nazismo e ai Paesi Bassi si legano probabilmente ai diversi litigi diplomatici che Erdoğan ha avuto con alcuni leader europei la scorsa settimana, dopo che in diversi paesi ai membri del governo turco è stato impedito di tenere comizi politici in vista del referendum (probabilmente perché non vogliono legittimare un governo autoritario e ultra-nazionalista come quello di Erdoğan).

vedi: ilpost.it/2017/03/15/attacco-hacker-twitter-turchia

I tweet si susseguono, l’attacco dilaga e gli account violati aumentano, basta dare un’occhiata a questo piccolo elenco di tweet, che in realtà sono poi diventati ancora di più, ma non posso certo star lì a recuperarli tutti ;-) (ci vuole ben poco in realtà):

Impossibile fare diversamente, Paolo cala l’asso e consiglia caldamente l’utilizzo della 2FA (l’autenticazione a due fattori, per la quale combatto e scrivo da sempre):

Twitter aveva attivato l’autenticazione a due fattori tramite SMS già nella prima metà del 2013, evolutasi e passata ad autenticazione (sempre a due fattori) tramite la sua stessa applicazione pochi mesi dopo. Dal 2013 le cose sono ulteriormente cambiate e ci sono stati altri miglioramenti. Ora è possibile anche generare codici temporanei utilizzando applicazioni di terze parti come Google Authenticator o Authy. Non hai quindi più scuse per perdere tempo, attivala subito.

È solo dopo un’ora circa dai primi attacchi (orario italiano) che si scopre che il problema non è Twitter, né tanto meno una password troppo debole degli utilizzatori colpiti. Il cavallo di Troia si chiama TwitterCounter, un servizio (a ora che sto scrivendo l’articolo è down per manutenzione) che permette di rilevare diverse statistiche riguardo il proprio utente Twitter. Per utilizzarlo è necessario autenticarsi tramite il proprio user Twitter (sfruttando le API) e dargli accesso in lettura e scrittura. La seconda ACL è quella che ha causato il danno più visibile, evidentemente.

Paolo ha raccolto diverse informazioni e le ha messe a disposizione di tutti nell’articolo che potrai leggere all’indirizzo attivissimo.blogspot.it/2017/03/violazioni-di-massa-di-account-twitter.html.

Da lì a poco anche Matteo è entrato in gioco e ha fornito dettagliate statistiche che mostrano l’evoluzione dell’attacco e gli account colpiti, con relativi rimbalzi, visualizzazioni e chi più ne ha più ne metta. Trovi tutto il materiale all’indirizzo matteoflora.com/a-social-media-analysis-of-the-turkish-%E5%8D%90-nazialmanya-attack-294ff653085c#.mxnysyvy7.

Nel frattempo, anche Gizmodo ha raccolto ulteriori informazioni e le ha inserite all’interno del loro articolo riepilogativo (gizmodo.com/twitter-accounts-hacked-with-swastikas-through-third-pa-1793286451). I passaggi più importanti sono quelli relativi alle affermazioni di Twitter e del servizio di terza parte TwitterCounter, che riporto:

Update, 5:36am: Twitter just sent us this statement:

We are aware of an issue affecting a number of account holders this morning. Our teams are working at pace and taking direct action on this issue. We quickly located the source which was limited to a third party app. We removed its permissions immediately. No additional accounts are impacted. Advice on keeping your account secure can be found here.

vedi: support.twitter.com/articles/76036 (consigli di sicurezza che tutto sommato riportano quanto già detto da me, da Paolo e da molti altri, mille volte)

Da lì a poco, inevitabile il tweet di TwitterCounter:

Ciò vuol dire che, almeno per il momento, nulla si può muovere tramite TwitterCounter, il quale ha anche modificato la sua chiave privata per sfruttare le API di Twitter, così da evitare (si spera) ulteriori attacchi. Se e quando verrà scoperta la falla beh, questo non è ancora dato saperlo (ma salterà sicuramente fuori nelle prossime ore, o almeno tutti ce lo auguriamo).

Occhio a chi hai autorizzato

Il mio consiglio, oltre a quello di andare ad attivare l’autenticazione a due fattori e rimuovere immediatamente l’accesso all’applicazione TwitterCounter (ammesso tu l’abbia mai autorizzata) da twitter.com/settings/applications, è quello di verificare quante altre applicazioni possono accedere al tuo account Twitter, e fare una pulizia di primavera in leggero anticipo, per evitare che chiunque possa sfruttare falle che esulano da Twitter o dalla tua capacità di proteggere l’account con una robusta password e un corretto metodo di verifica.

Se non utilizzi più un’applicazione, se non ne riconosci il nome, se pensi di non averci nulla a che fare, rimuovi il suo accesso. Ricorda che potrai sempre ridarglielo in un secondo momento, senza conseguenze (dovrai semplicemente riautenticarti a Twitter). Fai distinzione tra lettura e scrittura, e prediligi l’eliminazione immediata di chi ha accesso in scrittura al tuo account, guarda la differenza in questa immagine catturata dal mio account:

Di Twitter, Turchia e accessi indesiderati 1

Ricorda solo che, nel caso tu utilizzi iOS o macOS abitualmente (sistemi operativi di casa Apple), revocare i diritti di accesso non è immediatamente banale, devi pensare più in grande e toglierli all’intero sistema, come spiegato nella documentazione ufficiale di Twitter.

Non perdere altro tempo, dai un’occhiata alle tue impostazioni di sicurezza e fai in modo da proteggerti il più possibile da accessi (e utilizzi) indesiderati.

Cheers.

G

Qualcuno lo avrà certamente notato. Da qualche giorno questa installazione di WordPress è raggiungibile al suo “nuovo” URL in HTTPS. Dico “nuovo” perché da circa un anno avevo già forzato la Dashboard in HTTPS, lasciando ancora in HTTP il blog visibile pubblicamente a tutti i lettori. Il tutto ha potuto funzionare generando un certificato con Let’s Encrypt e chiedendo al supporto di Serverplan (l’hosting che ospita questo blog) di caricarlo.

WordPress: passaggio da HTTP a HTTPS 8

Qualche giorno fa, tutti i clienti del provider hanno però ricevuto una comunicazione decisamente più ufficiale:

[…]

Dopo un periodo di test, necessario per la tranquillità dei clienti, Serverplan ha attivato il certificato TLS gratuito Let’s Encrypt su tutti i piani Hosting. Cosa devi fare per attivare questo servizio? Niente, è già attivo. Devi solo goderti la tranquillità di una connessione sicura.

[…]

Ho quindi pensato fosse arrivato il momento giusto per portare tutto su HTTPS, anche perché Google sembrerebbe avere tutte le intenzioni di cominciare a penalizzare chi non passa alla connessione più sicura e che permette maggiore sicurezza nel caso in cui si debbano utilizzare delle credenziali di autenticazione (cosa che però qui sul blog non accade, poiché i commenti –unico login che potresti voler effettuare– vengono gestiti da Disqus, anch’esso passato a HTTPS).

Molti hosting provider oggi propongono un certificato di Let’s Encrypt in maniera semplice, attivabile direttamente dal proprio pannello di controllo oppure pre-attivato sul proprio spazio (quello che ha scelto di fare Serverplan, nda). Se nel tuo caso questo non è ancora possibile, sappi che puoi procedere in autonomia, creando il tuo certificato personale e chiedendo al supporto tecnico del tuo provider di attivarlo sul tuo sito web.

Creare un certificato Let’s Encrypt

Le linee guida per la richiesta e creazione di un certificato sono disponibili sul sito web ufficiale del progetto, all’indirizzo letsencrypt.org/getting-started. Per fartela più semplice, puoi passare dal sito web sslforfree.com, ti propongo la solita galleria esplicativa ma ti indico istruzioni più dettagliate subito di seguito, per evitare possibili errori:

  • Inserisci il sito web che vuoi certificare. Puoi specificare il dominio di secondo livello (tuodominio.tld), il sito web inserirà in maniera automatica il www davanti, per certificare anche il terzo livello.
  • Scegli di effettuare una verifica manuale tramite upload di file sul tuo spazio FTP (questo è quello che ti consiglio). Scarica i due file necessari alla verifica da sslforfree (fai clic su Download File #1 e Download File #2, scarica entrambi i file sul Desktop o equivalente, servono per poco tempo).
  • Vai sul tuo spazio FTP, crea una cartella chiamata .well-known, entra al suo interno e crea una nuova cartella chiamata acme-challenge. Carica entrambi i file che hai precedentemente scaricato all’interno di quest’ultima cartella.
  • Torna su sslforfree e procedi con la verifica, ti basterà fare clic su Download SSL Certificate e, salvo errori, potrai avere accesso al tuo set di chiavi. Fai clic su Download All SSL Certificate Files e metti a disposizione il pacchetto che scaricherai ora al tuo hosting provider, aprendo un ticket di richiesta supporto per caricare il tuo nuovo certificato SSL Let’s Encrypt.

Passiamo a WordPress, adesso

Se il tuo Hosting Provider ti confermerà il caricamento del certificato, potrai finalmente procedere con la migrazione del tuo blog. Provo a fartela semplice anche in questo caso, ti consiglio l’utilizzo di un paio di plugin che possono fare tutto il lavoro al posto tuo, cercando così di abbattere i rischi di possibili errori.

Easy HTTPS Redirection
Easy HTTPS Redirection
SSL Insecure Content Fixer
SSL Insecure Content Fixer
Developer: WebAware
Price: Free

Entrambi ti aiuteranno a redirigere il traffico facilmente e correggere tutto quello che punta al vecchio indirizzo HTTP, salvo modifiche manuali (per esempio nel tema o in un file functions.php modificato, facilmente individuabili se sei stato tu a farlo). C’è ben poco di complesso da impostare, è tutto dannatamente semplice:

  • Vai in SettingsHTTPS Redirection, seleziona Enable automatic redirection to the “HTTPS” e Force resources to use HTTPS URL. Salva la tua scelta e, quando la pagina sarà aggiornata, seleziona la voce The whole domain in corrispondenza di You can apply a force HTTPS redirection on your entire domain or just a few pages. Salva ancora una volta. Hai appena terminato qui.
  • Spostati ora in SettingsSSL Insecure Content. Il plugin seleziona una papabile configurazione basata su un’analisi della tua installazione. Nel mio caso le opzioni selezionate sono:
    • Fix insecure content → Simple;
    • Fixes for specific plugins and themes → WooCommerce + Google Chrome HTTP_HTTPS bug (fixed in WooCommerce v2.3.13);
    • HTTPS detection → standard WordPress function.

Puoi –in qualsiasi momento– verificare che venga individuato correttamente il funzionamento HTTPS da Tools → SSL Tests.

Salvo errori, la tua configurazione ti permetterà ora di vedere il sito in HTTPS. Ricordati però che, a meno che il tuo Hosting Provider non lo preveda, dovrai ricordarti di rinnovare il tuo certificato SSL di Let’s Encrypt ogni 90 giorni. Puoi farlo facilmente tramite sslforfree, dovrai poi ricontattare il tuo provider per far caricare le nuove chiavi.

WordPress: passaggio da HTTP a HTTPS 16

Se utilizzi il sistema di commenti integrato in WordPress, il tuo lavoro finisce qui. In caso contrario potresti aver scelto di utilizzare Disqus (il sistema in uso su questo blog), e dovrai quindi seguire ancora qualche passaggio prima di poterti congedare ;-)

Migrare i commenti di Disqus

Cerco di riepilogare rapidamente anche questa: Disqus carica i commenti nei tuoi articoli grazie a un banale (si fa per dire, da gestire lato server) sistema di mappature URL. Il sistema capisce che commenti caricare in base all’indirizzo visitato in quel momento. Avendo tu migrato tutto sotto HTTPS, occorrerà allineare anche Disqus.

Tale funzione è ovviamente prevista, e viene spiegato all’indirizzo help.disqus.com/customer/portal/articles/286778-using-the-migration-tools, nasce più probabilmente per cambiare completamente URL (primodominio.tld verso secondodominio.tld per esempio), ma torna comodo anche per questo caso.

Accedi alla tua area di amministrazione Disqus, quindi spostati in Migration Tools (dalla colonna di sinistra), dovresti arrivare all’URL TUOUTENTE.disqus.com/admin/discussions/migrate/?p=migrate. A questo punto dovrai scaricare una lista completa delle tue mappature commenti, modificarla e darla nuovamente in pasto a Disqus, così che possa aggiornarsi. Dai un’occhiata alla galleria qui di seguito (sotto includo istruzioni più dettagliate):

  • Cominciata la migrazione, Disqus invierà all’indirizzo di posta elettronica (che hai fornito durante l’iscrizione al servizio) la lista degli URL indicizzati.
  • Apri la lista con Excel (o equivalente), clona la prima colonna, seleziona solo la seconda colonna e sostituisci tutti gli http:// con https:// (utilizza la funzione Cerca e sostituisci di Excel).
  • Salva il file, esci da Excel, riapri il file con Notepad++ (o qualsiasi altro editor di testo) e sostituisci tutti i punti e virgola con semplici virgole (anche in questo caso utilizza il Cerca e sostituisci), è richiesto da Disqus (che evidentemente non digerisce poi tanto bene i ;).
  • Carica il file su Disqus, verifica che la mappatura sia corretta, quindi lascia partire il lavoro in batch, a quel punto dovrai solo attendere che termini.

Entro le successive 24 ore, Disqus metterà a posto le cose, e tu finalmente potrai tornare a vedere i tuoi commenti :-)

Google Search Console

Update

In base al giusto suggerimento di Emanuele (nei commenti), mi sono
accorto di non averti parlato di Google Search Console, nonostante sia andato ad aggiornare la proprietà del sito inserendo l’URL con HTTPS. Trovi qui un suo articolo dedicato alla migrazione di WordPress da HTTP a HTTPS pubblicato al termine dello scorso anno, davvero molto interessante e completo.

In realtà è molto semplice anche questa cosa e va fatta se hai già configurato il tuo sito web nella console di big G. Secondo la documentazione ufficiale (support.google.com/webmasters/answer/6073543?hl=it), in caso di migrazione, si adotta questo metodo:

Se esegui la migrazione del sito da HTTP a HTTPS, Google considera l’operazione uno spostamento del sito con modifiche agli URL. Ciò può influire temporaneamente sulle cifre relative al traffico. Per ulteriori informazioni, consulta la pagina recante una panoramica sullo spostamento di un sito.
Aggiungi la proprietà HTTPS a Search Console. Search Console gestisce HTTP e HTTPS separatamente, non condividendo i dati relativi a tali proprietà. Pertanto, se hai pagine che adottano entrambi i protocolli, devi indicare una proprietà Search Console distinta per ciascuno di essi.

Quindi ti basterà entrare in Search Console, aggiungere “una proprietà” e specificare il tuo solito dominio, con l’unica differenza che ora avrà https:// davanti. Al resto, salve tue specifiche necessità di diversa configurazione, ci penserà Google, secondo un intervallo variabile che servirà ad analizzare nuovamente i contenuti del sito disponibili, indicizzandoli quanto prima e rendendoli disponibili nelle sue ricerche. Continueranno -contestualmente- a rimanere disponibili anche tutti i dati in HTTP semplice.

WordPress: passaggio da HTTP a HTTPS 17

Troubleshooting

Questione di Cookie

Paragrafo che spero non ti serva, ma ti lascio un consiglio spassionato: avvia quanto prima una sessione anonima con il tuo browser preferito, quindi visita il tuo sito web ora sotto HTTPS. Tutto si vede correttamente? Noti problemi o strani caricamenti che non vanno a buon fine? Io l’ho scoperto dopo un un po’ di tempo (stupidamente non ci avevo pensato, sono un po’ un pirla) e grazie anche alla segnalazione di alcuni lettori (che ancora ringrazio). Il plugin che caricava il famoso blocco di accettazione cookie (per quella stupida legge europea), impediva al CSS di fare il suo lavoro, rendendo di fatto inutilizzabile il blog.

Ho sostituito il plugin di (eu-cookie-law-widget) con Cookie Notice di dFactory:

Cookie Notice by dFactory
Cookie Notice by dFactory
Developer: dFactory
Price: Free

Un .htaccess per intercettare ogni cosa

Update

Anche questo nasce dal commento di Emanuele (vedi commento),
ed entra in gioco perché è riuscito a collegarsi a uno dei contenuti del blog forzando manualmente il protocollo HTTP dalla barra dell’URL. Per questo motivo, ho messo in produzione una modifica del file .htaccess, che ognuno di noi ha nella root della propria installazione WordPress (cos’è un file .htaccess?), pari a quella da lui utilizzata.

ATTENZIONE: Prima di partire, il solito consiglio: occhio sempre a quello che tocchi e che rimuovi, effettua il backup del tuo file .htaccess per sicurezza, così potrai agilmente tornare indietro in caso di problemi.

Apri il tuo file .htaccess con un editor di testo e scorrilo fino a trovare qualcosa che assomigli a questo:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

A questo punto, inserisci ciò che ti permetterà di intercettare i tentativi di connessione via HTTP, che verranno automaticamente portati verso HTTPS:

RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Entrambe le righe possono essere inserite prima della RewriteBase /, ottenendo quindi questo risultato:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Se aggiornando il tuo blog (sia come utente autenticato, sia come visitatore ospite, mi raccomando!) qualcosa non dovesse funzionare, ripristina immediatamente il backup che avevi precedentemente effettuato. Probabilmente hai toppato qualcosa, o magari il codice riportato qui sopra non è adatto alla tua configurazione e occorrerà approfondire con il tuo fornitore di servizi (il provider sul quale hai acquistato il tuo piano di hosting).

Ora mi sembra che ci sia davvero tutto, spero di non aver dimenticato nulla.

Enjoy.

Ne hanno già parlato in molti, io ho atteso, ho provato a capire se potesse “starmi bene addosso“, un po’ come le palme di Piazza Duomo a Milano. Se queste ultime posso tranquillamente sopportarle (un tocco esotico in qualcosa che di esotico non ha nulla, ma tant’è), la prima proprio non va giù. Una verifica 2-Step anomala, che non ci si aspetta, ma evidentemente in Facebook hanno pensato di dare una svecchiata al metodo.

Per permettere a WhatsApp di funzionare, dovrai associare un numero telefonico univoco che andrà verificato tramite un semplice SMS (o chiamata in caso di problemi). La vera “novità” è quella relativa però all’introduzione dell’autenticazione a due fattori, quella che chiunque di noi è abituato a vedere passare da applicazioni di terze parti in grado di leggere l’ormai tradizionale codice QR e fornire la sequenza numerica che cambia ogni 30 o 60 secondi (o altri intervalli di tempo regolari).

WhatsApp è diversa. La loro autenticazione a due fattori in realtà è un codice di 6 cifre che non cambia, come una password senza scadenza, uno step in più –certamente– ma che fa comunque parte di noi utilizzatori, perché siamo noi a sceglierlo, perché nella maggior parte dei casi –senza prestare la dovuta attenzione– si andrà a utilizzare qualcosa che ci può essere associato. Una data di nascita, la parte numerica di una targa, un numero di telefono e altro ancora, tutti dati che in qualche maniera possono venirci sottratti, come tradizione vuole con le password facilmente aggirabili. Non è una vera 2-Step, è –concedimi la battuta scema– uno step e mezzo a fatica.

In ogni caso, il consiglio è quello di attivare la funzione, si tratta pur sempre di un’ulteriore strato di difficoltà che si interpone tra il tuo account e un eventuale malintenzionato:

Non servirà null’altro, solo tanta pazienza. WhatsApp ti richiederà di inserire quel codice di tanto in tanto (pure troppo) per evitare che tu possa dimenticarlo, e per proteggersi da accessi eventualmente non autorizzati. Funziona così anche con Authy (te ne ho parlato qui), ma in versione meno “ansia” e ignorabile secondo richiesta dell’utilizzatore.

La tradizionale verifica 2-Step è da sempre disponibile su Facebook (sito web e applicazione), non riesco a capire perché non portare a bordo anche WhatsApp, ma per il momento ci si dovrà accontentare (ancora ricordo i primi passi di 2-Step authentication di Twitter, poi tornata sui suoi passi, tutti possono cambiare in meglio).

Il titolo è volutamente simile a quanto già scritto poco tempo fa, e vuole analizzare alcuni consigli che anche io cerco di dare a chiunque si mette a preparare una nuova installazione WordPress (spero prima per sé, poi forse –con buona esperienza sulle spalle– anche per altri), anche se in realtà i concetti di base valgono per qualsiasi accesso a qualunque servizio disponibile sulla grande rete. Basandomi sul blog di chi iThemes Security lo scrive, riporto alcuni passaggi secondo me fondamentali.

WordPress e Authy: autenticazione OneTouch 6

According to this infographic by WP Template on WordPress safety, insecure WordPress themes and plugins contribute to over 50% of all successful WordPress hacks.

Plugins and themes have to go through a screening process before they are released for public use from the WordPress.org plugin repository, so it is important to download your plugins and themes from trustworthy sources and always keep active themes and plugins update to the latest version.

fonte: ithemes.com/2016/11/08/wordpress-hacks

e ancora:

Using the same password on multiple sites is risky.

Using strong passwords for all your logins is one of the best online security practices you can develop.

The best practice to follow is creating a different password for every sing website you are registered on. Definitely don’t use the password you use for your bank account on another site.

An average of 30,000 sites are hacked every day.
This should give you an idea of how many people are affected by cyber attacks, and motivate you to use stronger passwords.

fonte: ithemes.com/2016/11/04/brute-force-attacks

Che poi non è che proprio ci voglia la scala eh. Strumenti come KeePass o simili (anche quelli completamente in cloud) sono fatti apposta per ricordarti password altrimenti (probabilmente) molto difficili da ricordare, soprattutto quando decidi di lasciare fare loro nella fase di generazione di una nuova password complessa. Vale anche il vecchio (ma ancora perfetto) consiglio del “utilizza password apparentemente stupide“, perché ti assicuro che “Il cavallo bianco di Napoleone!” può essere una password certamente più complessa della targa della tua automobile (puoi provare tu stesso su passwordmeter.com, tanto per levarti la curiosità).

Sulla base di ciò, è semplice stilare una ToDo List da tenere sempre bene a mente:

  • Sempre tenere aggiornato il tuo WordPress. Questo vale per il motore principale del CMS, ma anche (soprattutto, in realtà) plugin, temi e codice personalizzato che potresti aver scritto e poi dimenticato lì dopo poco, offrendo una possibile backdoor poco simpatica. Se il server che lo ospita è controllato da te, occorre tenere aggiornato ciò che gli permette di stare online (server web, MySQL, PHP, ecc.).
  • Disinstallare sempre plugin e temi non più utilizzati. Perché qui non si tratta solo di pulizia (sicuramente necessaria per tenere sempre snella l’installazione), ma perché così si vanno a chiudere possibili ulteriori falle, esattamente come da ragionamento del precedente punto della lista.
  • Utilizzare password complesse per ciascun account, possibilmente. Perché se è vero che il tuo blog è aperto alle iscrizioni (e si basa così sul buon senso dei tuoi utenti), è -spero- anche vero che tu possa stabilire delle regole precise per le password di coloro che possono pubblicare qualcosa, o peggio che possono modificare il comportamento del blog intero (un amministratore, tanto per essere chiari).
  • Abilitare l’autenticazione in due fattori per WordPress. E qui ti rimando all’articolo dedicato ad Authy e alla sua possibile integrazione con WordPress, comoda, funzionale, sicura.
  • Cancellare o declassare l’account “admin” predefinito di WordPress. Detto e stradetto, anche nel mio precedente articolo sulla protezione degli accessi alla Dashboard amministrativa, perché quell’utente creato di default nel database, è sempre scomodo e attaccabile (perché è quello che si da per scontato che esista).
  • Scegliere un buon hosting provider per il proprio CMS. Perché la sicurezza comincia dalle fondamenta, e affidarsi a chiunque non è –probabilmente– la migliore scelta, almeno per come la vedo io (e non solo). Un buon partner (perché di questo si tratta, nda) è quello che è sempre attento e pronto ad affrontare una difficoltà, a suggerirti le prossime mosse da fare, a bloccare chi è sgradito prima che faccia danni (più di quanti ne abbia già fatti entrando nel tuo sistema), e che ci tiene alla salvaguardia dei tuoi dati ma anche di coloro che abitano nel tuo stesso “condominio” (quando si parla di hosting condiviso, molto diffuso e primo step per tutti).
  • Scarica plugin e temi solo da fonti sicure. Evita come la peste siti web che promettono di regalarti il tema all’ultimo grido, creati con ore di sudato lavoro e ricchi di plugin solitamente a pagamento, pacchetti “all-in-one” appositamente clonati da siti web che li vendono e supportano quotidianamente. Spesso quei temi contengono codice malevolo, codificato (quindi di difficile decodifica per chi è alle prime armi), da qui in poi è tutto un salto nel buio. Se pensi che un tema sia assolutamente irresistibile, valuta l’acquisto della sua licenza, otterrai così anche un aiuto qualificato in caso di problemi, certamente meno costoso di qualcuno in grado di rimetterti in piedi dopo un deface (o simile) ai danni del tuo sito web.

Hai altri consigli? Vuoi raccontare la tua esperienza e dare qualche suggerimento in merito? L’area commenti –manco a dirlo– è a tua completa disposizione :-)