Le ultime settimane sono state molto particolari, soprattutto per l’attivismo online italiano e per il fattore sicurezza. <\/p>\n\n\n\n
Da poco, degli attivisti italiani sono stati attaccati sulla loro piattaforma, riaccendendo il dubbio in tutti noi, di quanto siano sicuri i nostri portali e siti web. Sono stato il primo, che ho rivisto un po’ tutte le impostazioni, per essere sicuro di non aver tralasciato nulla. <\/p>\n\n\n\n
Dopo aver rivisto il contesto, ed essermi assicurato di essere meno esposto possibile, vorrei iniziare questa guida ricordando una regola fondamentale:<\/p>\n\n\n\n
\n“Se quel dato non lo conservi, non pu\u00f2 essere rubato.”<\/p>\n<\/blockquote>\n\n\n\n
Primo passo, tutto deve essere aggiornato…<\/h3>\n\n\n\n
Gli aggiornamenti non migliorano solo le prestazioni o gli aspetti meramente funzionali ed estetici del tuo sito web, ma spesso includono importanti miglioramenti in termini di sicurezza e stabilit\u00e0. Assicurati di avere le versioni pi\u00f9 aggiornate di tutto ci\u00f2 che concerne il tuo portale. <\/p>\n\n\n\n
ATTENZIONE! IL BACKUP E’ DA ADESSO FORTEMENTE CONSIGLIATO <\/em><\/strong>– NEXTRED SI SOLLEVA DA OGNI RESPONSABILIT\u00c0<\/p>\n\n\n\n
Procediamo con ordine. Io controllerei e relativamente aggiornerei ad ultima versione i seguenti elementi:<\/p>\n\n\n\n
\n
- versione di WordPress;<\/li>\n\n\n\n
- versione PHP;<\/li>\n\n\n\n
- MySQL\/MariaDB;<\/li>\n\n\n\n
- plugin;<\/li>\n\n\n\n
- tema;<\/li>\n\n\n\n
- plugin e temi non pi\u00f9 utilizzati.<\/li>\n<\/ul>\n\n\n\n
L’ultima voce segnala plugin e temi non utilizzati. WordPress stesso, nella sezione Stato di Salute del tuo Sito, ti consiglia di disinstallare tutto ci\u00f2 che non utilizzi. Non per una questione di mero ordine, quando per la riduzione effettiva della superficie d’attacco. Il fatto che un plugin o un tema non sia attivo, non significa che non potrebbe essere vulnerabile comunque. Il consiglio \u00e8 comune di mantenere un tema di backup, nel caso quello in uso dovesse in qualche modo rompersi. Comunemente si tende a lasciare uno dei temi preimpostati di WordPress. La comodit\u00e0 deriva dal fatto che i temi sono leggeri e mantenuti. <\/p>\n\n\n\n
Altra cosa importante, \u00e8 ricordarsi che un plugin non mantenuto ma di cui non si segnalano vulnerabilit\u00e0 non \u00e8 necessariamente migliore di uno in cui si sono resi conto di una vulnerabilit\u00e0 e hanno corretto il problema con una patch. Scegli sempre software mantenuto e che garantisca aggiornamenti di sicurezza minimi. <\/p>\n\n\n\n
Secondo passo, (pre)occupati del file wp-config.php…<\/h3>\n\n\n\n
Il file wp-config.php \u00e8 essenzialmente uno dei file pi\u00f9 delicati del tuo sito. All’interno ci trovi molte informazioni importanti. Informazioni per accedere al database e chiavi wordpress e tante altre informazioni utili possono essere estrapolate da questo file. <\/p>\n\n\n\n
In generale, se su un forum ti stanno dando assistenza, mai copiare ed inviare queste informazioni:<\/p>\n\n\n\n
DB_NAME
DB_USER
DB_PASSWORD
DB_HOST
Authentication Keys
Salts
API keys e token<\/p>\n\n\n\nQuando compatibile \u00e8 buona norma negare l’accesso tramite webserver:<\/p>\n\n\n\n
\n<Files “wp-config.php”>
Require all denied
<\/Files><\/p>\n<\/blockquote>\n\n\n\nAttenzione per\u00f2 non \u00e8 una buona idea aggiungere codice a caso preso da internet. Nell’articolo io inserir\u00f2 una serie di comandi, che dovrete voi valutare e vagliare e comprendere se compatibile con il vostro sito e le impostazioni scelte. <\/p>\n\n\n\n
Terzo passo, se qualcuno entra \u00e8 meglio far trovare porte chiuse…<\/h3>\n\n\n\n
Il rischio c’\u00e8, dobbiamo dircelo. C’\u00e8 sempre. Dunque se qualcuno entra, o riesce ad utilizzare una vulnerabilit\u00e0 per aumentare i privilegi fino ad amministratore, potrebbe trovare porte aperte dovunque. Se per\u00f2 tu chiudi tutto, a lui sar\u00e0 pi\u00f9 complesso aprire ogni porta (cosa che ovviamente presumibilmente potr\u00e0 fare comunque) e a te sar\u00e0 concesso pi\u00f9 tempo per bloccare accessi e prenderti nuovamente la gestione del tuo sito. <\/p>\n\n\n\n
L’edito di codice di wordpress \u00e8 uno strumento molto importante, ma al contempo non sempre necessario. Se \u00e8 qualcosa che normalmente utilizzi, puoi superare questo paragrafo, altrimenti conviene disabilitare la funzionalit\u00e0 sempre dal file wp-config.php.<\/p>\n\n\n\n
(A QUESTO PUNTO MI ASPETTO CHE TU ABBIA GIA’ FATTO UN BACKUP, SE ANCORA NON L’HAI FATTO, PENSA A QUANDO \u00c8 COMODO AVERE UNA COPIA DI CI\u00d2 CHE C’ERA PRIMA DI ROMPERE TUTTO)<\/p>\n\n\n\n
Inserisci nel file suddetto: <\/p>\n\n\n\n
\ndefine( ‘DISALLOW_FILE_EDIT’, true );<\/p>\n<\/blockquote>\n\n\n\n
Questo blocca la possibilit\u00e0 ad un nuovo amministratore di mettere mano a plugin e temi direttamente. Ovvio che se ha accesso non a wordpress ma al tuo FTP, CPanel oppure al tuo account host il giochetto non funziona. Motivo per cui le password devono essere sempre differenti e l’autenticazione a due fattori sempre attiva. <\/p>\n\n\n\n
Attenzione! Non confondiamo per\u00f2 il comando scritto con il seguente:<\/p>\n\n\n\n
\nDISALLOW_FILE_MODS<\/p>\n<\/blockquote>\n\n\n\n
Questo infatti ha conseguenze molto pi\u00f9 vaste. Il rischio \u00e8 di bloccare aggiornamenti e funzionalit\u00e0 essenziali del sito. <\/p>\n\n\n\n
Quarto passo, siamo sicuri che tutti i file debbano essere alla portata di tutti…<\/h3>\n\n\n\n
Se stai avendo problemi ad accedere a dei file, oppure a fare funzionare qualcosa, concedere permessi illimitati di una cartella in modo che il tuo flow non si blocchi, non \u00e8 per niente una buona idea. Ci sono bot e malintenzionati che non vedono l’ora di mettere mano a configurazioni errate di questo genere.<\/p>\n\n\n\n
Normalmente, file e directory avranno impostazioni <\/p>\n\n\n\n
\nFile: 644
Directory: 755<\/p>\n<\/blockquote>\n\n\n\nMa ovviamente bisogna discriminare con attenzione i permessi che vogliamo concedere. Non possiamo dunque dire che questa \u00e8 una regola generale: hosting, ownership, PHP handler e configurazioni server possono essere diversi. <\/p>\n\n\n\n
Dunque attenzione. 777 \u00e8 una configurazione molto rischiosa. Se l’avete scelta per risolvere problemi di permessi avete appena aperto una porta a dei malintenzionati. E se ve ne dimenticate, sar\u00e0 anche molto arduo ritrovare la vulnerabilit\u00e0. <\/p>\n\n\n\n
Quinto passo, non tutti i file che potrebbero essere letti, devono essere letti….<\/h3>\n\n\n\n
Alcuni file, non hanno ragione di essere consultabili. Per tal motivo si pu\u00f2 impedirne l’accesso HTTP. Un esempio interessante \u00e8 l’aggiunta della configurazione <\/p>\n\n\n\n
\n# BEGIN SITE SECURITY
<FilesMatch “^(wp-config\\.php|\\.htaccess|readme\\.html|license\\.txt)$”>
Require all denied
<\/FilesMatch>
# END SITE SECURITY<\/p>\n<\/blockquote>\n\n\n\nGiusto per essere un po’ pi\u00f9 essenziali, ricordiamo che queste aggiunte di codice vanno inserite fuori dai blocchi generali creati da WordPress per il funzionamento. Il rischio \u00e8 che venga visto come una modifica di quel blocco e al primo aggiornamento interamente cancellato. Dunque se troviamo un # BEGIN WordPress \/ # END WordPress o qualcosa di simile riguardo plugin e altro, meglio non inserire nulla tra i due hashtag. <\/p>\n\n\n\n
Sesto passo, attenzione alla cartella upload, la porta di ingresso alla tua fortezza…<\/h3>\n\n\n\n
Ovviamente non si pu\u00f2 dare ad un utente non registrato la possibilit\u00e0 di caricare in upload tutti i file che si vuole. Sarebbe da sprovveduti e anche un po’ da folli. <\/p>\n\n\n\n
Ma anche l’upload da utenti con livelli di accesso superiori (incluso gli amministratori) dovrebbero essere limitati. Nella cartella wp-content\/upload salvo necessit\u00e0 differenti, dovrebbero starci file PDF, o immagini di vario formato. Se dovesse esserci codice PHP, questo non dovrebbe avviarsi. <\/p>\n\n\n\n
Per tal motivo buona norma \u00e8 quella di rimuovere la possibilit\u00e0 di eseguire un file PHP in upload. Si pu\u00f2 utilizzare una configurazione, come segue, di un file .htaccess dedicato all’interno della cartella upload (versione Apache permettendo):<\/p>\n\n\n\n
\n# Prevent PHP execution in uploads
<FilesMatch “\\.(php|php[0-9]?|phtml|phar)$”>
Require all denied
<\/FilesMatch><\/p>\n<\/blockquote>\n\n\n\nQuesto pu\u00f2 creare una ulteriore difesa. Soprattutto nel caso una vulnerabilit\u00e0 concedesse ad un malintenzionato di caricare un file php. A quel punto, bloccare la sua esecuzione \u00e8 l’ultima linea di difesa. <\/p>\n\n\n\n
Settimo passo, i Security Headers…<\/h3>\n\n\n\n
Un intervento che possiamo fare \u00e8 quello di sfruttare alcune impostazioni dei nuovi browser. Le seguenti impostazioni sono relativamente conservative. <\/p>\n\n\n\n
\nHeader always set X-Content-Type-Options \"nosniff\"\nHeader always set X-Frame-Options \"SAMEORIGIN\"\nHeader always set Referrer-Policy \"strict-origin-when-cross-origin\"<\/code><\/pre>\n<\/blockquote>\n\n\n\nGli header che hai appena letto, intervengono su: MIME sniffing (intercettazione passiva dei dati), embedding\/framing delle pagine e quantit\u00e0 di informazioni trasmesse attraverso il Referer<\/a> (Nel protocollo HTTP, il referer o HTTP referer \u00e8 un campo di intestazione HTTP opzionale che identifica l’indirizzo della pagina web da cui \u00e8 stata richiesta la risorsa. Cit. Wikipedia). <\/p>\n\n\n\n
Attenzione! non \u00e8 sufficiente inserire codice per essere sicuro che questo funzioni. Ricorda di provare dal terminale Linux, la risposta dei cambiamenti effettuati<\/p>\n\n\n\n
\ncurl -I https:\/\/example.org\/<\/a><\/p>\n<\/blockquote>\n\n\n\n
Infatti pu\u00f2 succedere che cache, configurazione hosting, CDN e reverse proxy cambino la risposta finale<\/p>\n\n\n\n
Ottavo passo, laddove possibile prediligere HSTS<\/h3>\n\n\n\n
HSTS \u00e8 l’acronimo di HTTP Strict Transport Security<\/em>. Si tratta di un metodo utilizzato dai siti Web per dichiarare che dovrebbe essere accessibile solo utilizzando una connessione sicura (HTTPS). Se un sito Web dichiara un criterio HSTS, il browser deve rifiutare tutte le connessioni HTTP e impedire agli utenti di accettare certificati SSL non sicuri.<\/p>\n\n\n\n
Se il sito \u00e8 totalmente disponibile su HTTPS, ed \u00e8 attivato il redirect di HTTP, \u00e8 possibile pensare a HSTS. I moderni browser lo supportano senza grossi problemi. <\/p>\n\n\n\n
\nHeader always set Strict-Transport-Security “max-age=2592000”<\/p>\n<\/blockquote>\n\n\n\n
solitamente si imposta 31536000 (1 anno) come et\u00e0 massima. 2592000 invece equivale ad un mese. E va bene nelle prime fasi di testing. <\/p>\n\n\n\n
Controllate che la risposta sia corretta richiamando dal terminale:<\/p>\n\n\n\n
\ncurl -I http:\/\/example.org\/<\/a>
curl -I https:\/\/example.org\/<\/a><\/p>\n<\/blockquote>\n\n\n\nNono passo, impedite di attivare funzionalit\u00e0 non utili nel vostro sito…<\/h3>\n\n\n\n
Se per il tuo sito non \u00e8 essenziale geo-localizzazione, fotocamera e microfono, bloccate tutto a monte. Dire semplicisticamente che non esistono come funzionalit\u00e0 non significa chiudere quelle porte. Se non servono, chiudete!<\/p>\n\n\n\n
\nHeader always set Permissions-Policy “camera=(), microphone=(), geolocation=()”<\/p>\n<\/blockquote>\n\n\n\n
Decimo passo, proteggi l’amministratore…<\/h3>\n\n\n\n
L’amministratore \u00e8 il re della fortezza. E la tua fortezza deve difendere anche chi ha il potere di modificarla o peggio farla sparire. Non potete usare una semplice password per difendere l’account (o gli account) pi\u00f9 importante e critico del sito.<\/p>\n\n\n\n
Prima di tutto, non tutti devono essere amministratori. Rivedete le tue policy, e riduci il numero di amministratori. Inoltre attivate la funzionalit\u00e0 di accesso a doppio fattore. Aumentate gli standard minimi delle password, o meglio usate un password manager. Proteggete anche le email degli amministratori con autenticazione a due fattori. Monitorate periodicamente le sessioni attive.<\/p>\n\n\n\n
Undicesimo passo, controlla XML-RPC e REST API<\/h3>\n\n\n\n
L’idea iniziale \u00e8 di bloccare tutto. Ma se il vostro sito \u00e8 federato o ha delle funzionalit\u00e0 particolari, questi endopoint possono essere utili. Su questo \u00e8 meglio approfondire il discorso in un altro articolo. Ma sappiate che anche questo va controllato. Bloccare questi endopoint pu\u00f2 ridurre la superficie d’attacco e avere maggiore resistenza nei brute-force e attacchi, ma \u00e8 legato anche al malfunzionamento di alcuni plugin importanti del sito.<\/p>\n\n\n\n
Dodicesimo passo, se hai due copie del sito web puoi rinascere velocemente…<\/h3>\n\n\n\n
Il backup \u00e8 una panacea. Due backup \u00e8 perfezione. Lasciate che il vostro servizio di hosting faccia il backup periodico, ma non lasciate tutto solo a lui. Ciclicamente, salvate in locale il vostro sito e le vostre impostazioni. E’ il modo migliore per proteggersi da eventuali perdite di dati.<\/p>\n\n\n\n
Dunque, lasciate che il provider faccia il suo backup, ma voi salvate le varie versioni del sito. Pu\u00f2 essere comodo!<\/p>\n\n\n\n
Tredicesimo passo, non conservate nulla…<\/h3>\n\n\n\n
So che questo non \u00e8 hardening. Ma in senso lato pu\u00f2 essere considerato tale. Non lasciare dati di alcun genere sul vostro sito web \u00e8 una buona scelta. Se non c’\u00e8 nulla, non si pu\u00f2 rubare nulla. Inoltre se non c’\u00e8 nulla, perch\u00e9 non entrare altrove allora? Prediligete la privacy dell’utente e evitate di raccogliere informazioni se riuscite. Questo vi render\u00e0 una vittima poco interessante.<\/p>\n\n\n\n
Chiudiamo questa guida…<\/h3>\n\n\n\n
Questa guida non ha la presunzione di difendervi dai mali dell’internet, ma spero che vi faccia interrogare su ci\u00f2 che deve essere fatto per migliorare e proteggere il vostro sito web. Fare hardening significa indurire e ridurre la superficie esposta. Lo scopo \u00e8 quello di rispondere prontamente e rendere complesso il lavoro dei malintenzionati che hanno scelto voi come vittima. <\/p>\n\n\n\n
Link e Fonti:<\/p>\n\n\n\n