Le ultime settimane sono state molto particolari, soprattutto per l’attivismo online italiano e per il fattore sicurezza.

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.

Dopo aver rivisto il contesto, ed essermi assicurato di essere meno esposto possibile, vorrei iniziare questa guida ricordando una regola fondamentale:

“Se quel dato non lo conservi, non può essere rubato.”

Primo passo, tutto deve essere aggiornato…

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à. Assicurati di avere le versioni più aggiornate di tutto ciò che concerne il tuo portale.

ATTENZIONE! IL BACKUP E’ DA ADESSO FORTEMENTE CONSIGLIATO – NEXTRED SI SOLLEVA DA OGNI RESPONSABILITÀ

Procediamo con ordine. Io controllerei e relativamente aggiornerei ad ultima versione i seguenti elementi:

• versione di WordPress;
• versione PHP;
• MySQL/MariaDB;
• plugin;
• tema;
• plugin e temi non più utilizzati.

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ò 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 è 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à deriva dal fatto che i temi sono leggeri e mantenuti.

Altra cosa importante, è ricordarsi che un plugin non mantenuto ma di cui non si segnalano vulnerabilità non è necessariamente migliore di uno in cui si sono resi conto di una vulnerabilità e hanno corretto il problema con una patch. Scegli sempre software mantenuto e che garantisca aggiornamenti di sicurezza minimi.

Secondo passo, (pre)occupati del file wp-config.php…

Il file wp-config.php è essenzialmente uno dei file più 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.

In generale, se su un forum ti stanno dando assistenza, mai copiare ed inviare queste informazioni:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST
Authentication Keys
Salts
API keys e token

Quando compatibile è buona norma negare l’accesso tramite webserver:

<Files “wp-config.php”>
Require all denied
</Files>

Attenzione però non è una buona idea aggiungere codice a caso preso da internet. Nell’articolo io inserirò una serie di comandi, che dovrete voi valutare e vagliare e comprendere se compatibile con il vostro sito e le impostazioni scelte.

Terzo passo, se qualcuno entra è meglio far trovare porte chiuse…

Il rischio c’è, dobbiamo dircelo. C’è sempre. Dunque se qualcuno entra, o riesce ad utilizzare una vulnerabilità per aumentare i privilegi fino ad amministratore, potrebbe trovare porte aperte dovunque. Se però tu chiudi tutto, a lui sarà più complesso aprire ogni porta (cosa che ovviamente presumibilmente potrà fare comunque) e a te sarà concesso più tempo per bloccare accessi e prenderti nuovamente la gestione del tuo sito.

L’edito di codice di wordpress è uno strumento molto importante, ma al contempo non sempre necessario. Se è qualcosa che normalmente utilizzi, puoi superare questo paragrafo, altrimenti conviene disabilitare la funzionalità sempre dal file wp-config.php.

(A QUESTO PUNTO MI ASPETTO CHE TU ABBIA GIA’ FATTO UN BACKUP, SE ANCORA NON L’HAI FATTO, PENSA A QUANDO È COMODO AVERE UNA COPIA DI CIÒ CHE C’ERA PRIMA DI ROMPERE TUTTO)

Inserisci nel file suddetto:

define( ‘DISALLOW_FILE_EDIT’, true );

Questo blocca la possibilità 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.

Attenzione! Non confondiamo però il comando scritto con il seguente:

DISALLOW_FILE_MODS

Questo infatti ha conseguenze molto più vaste. Il rischio è di bloccare aggiornamenti e funzionalità essenziali del sito.

Quarto passo, siamo sicuri che tutti i file debbano essere alla portata di tutti…

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 è per niente una buona idea. Ci sono bot e malintenzionati che non vedono l’ora di mettere mano a configurazioni errate di questo genere.

Normalmente, file e directory avranno impostazioni

File:       644
Directory:  755

Ma ovviamente bisogna discriminare con attenzione i permessi che vogliamo concedere. Non possiamo dunque dire che questa è una regola generale: hosting, ownership, PHP handler e configurazioni server possono essere diversi.

Dunque attenzione. 777 è 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à anche molto arduo ritrovare la vulnerabilità.

Quinto passo, non tutti i file che potrebbero essere letti, devono essere letti….

Alcuni file, non hanno ragione di essere consultabili. Per tal motivo si può impedirne l’accesso HTTP. Un esempio interessante è l’aggiunta della configurazione

# BEGIN SITE SECURITY
<FilesMatch “^(wp-config\.php|\.htaccess|readme\.html|license\.txt)$”>
  Require all denied
</FilesMatch>
# END SITE SECURITY

Giusto per essere un po’ più essenziali, ricordiamo che queste aggiunte di codice vanno inserite fuori dai blocchi generali creati da WordPress per il funzionamento. Il rischio è 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.

Sesto passo, attenzione alla cartella upload, la porta di ingresso alla tua fortezza…

Ovviamente non si può dare ad un utente non registrato la possibilità di caricare in upload tutti i file che si vuole. Sarebbe da sprovveduti e anche un po’ da folli.

Ma anche l’upload da utenti con livelli di accesso superiori (incluso gli amministratori) dovrebbero essere limitati. Nella cartella wp-content/upload salvo necessità differenti, dovrebbero starci file PDF, o immagini di vario formato. Se dovesse esserci codice PHP, questo non dovrebbe avviarsi.

Per tal motivo buona norma è quella di rimuovere la possibilità di eseguire un file PHP in upload. Si può utilizzare una configurazione, come segue, di un file .htaccess dedicato all’interno della cartella upload (versione Apache permettendo):

# Prevent PHP execution in uploads
<FilesMatch “\.(php|php[0-9]?|phtml|phar)$”>
    Require all denied
</FilesMatch>

Questo può creare una ulteriore difesa. Soprattutto nel caso una vulnerabilità concedesse ad un malintenzionato di caricare un file php. A quel punto, bloccare la sua esecuzione è l’ultima linea di difesa.

Settimo passo, i Security Headers…

Un intervento che possiamo fare è quello di sfruttare alcune impostazioni dei nuovi browser. Le seguenti impostazioni sono relativamente conservative.

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Gli header che hai appena letto, intervengono su: MIME sniffing (intercettazione passiva dei dati), embedding/framing delle pagine e quantità di informazioni trasmesse attraverso il Referer (Nel protocollo HTTP, il referer o HTTP referer è un campo di intestazione HTTP opzionale che identifica l’indirizzo della pagina web da cui è stata richiesta la risorsa. Cit. Wikipedia).

Attenzione! non è sufficiente inserire codice per essere sicuro che questo funzioni. Ricorda di provare dal terminale Linux, la risposta dei cambiamenti effettuati

curl -I https://example.org/

Infatti può succedere che cache, configurazione hosting, CDN e reverse proxy cambino la risposta finale

Ottavo passo, laddove possibile prediligere HSTS

HSTS è l’acronimo di HTTP Strict Transport Security. 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.

Se il sito è totalmente disponibile su HTTPS, ed è attivato il redirect di HTTP, è possibile pensare a HSTS. I moderni browser lo supportano senza grossi problemi.

Header always set Strict-Transport-Security “max-age=2592000”

solitamente si imposta 31536000 (1 anno) come età massima. 2592000 invece equivale ad un mese. E va bene nelle prime fasi di testing.

Controllate che la risposta sia corretta richiamando dal terminale:

curl -I http://example.org/
curl -I https://example.org/

Nono passo, impedite di attivare funzionalità non utili nel vostro sito…

Se per il tuo sito non è essenziale geo-localizzazione, fotocamera e microfono, bloccate tutto a monte. Dire semplicisticamente che non esistono come funzionalità non significa chiudere quelle porte. Se non servono, chiudete!

Header always set Permissions-Policy “camera=(), microphone=(), geolocation=()”

Decimo passo, proteggi l’amministratore…

L’amministratore è 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ù importante e critico del sito.

Prima di tutto, non tutti devono essere amministratori. Rivedete le tue policy, e riduci il numero di amministratori. Inoltre attivate la funzionalità 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.

Undicesimo passo, controlla XML-RPC e REST API

L’idea iniziale è di bloccare tutto. Ma se il vostro sito è federato o ha delle funzionalità particolari, questi endopoint possono essere utili. Su questo è meglio approfondire il discorso in un altro articolo. Ma sappiate che anche questo va controllato. Bloccare questi endopoint può ridurre la superficie d’attacco e avere maggiore resistenza nei brute-force e attacchi, ma è legato anche al malfunzionamento di alcuni plugin importanti del sito.

Dodicesimo passo, se hai due copie del sito web puoi rinascere velocemente…

Il backup è una panacea. Due backup è 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.

Dunque, lasciate che il provider faccia il suo backup, ma voi salvate le varie versioni del sito. Può essere comodo!

Tredicesimo passo, non conservate nulla…

So che questo non è hardening. Ma in senso lato può essere considerato tale. Non lasciare dati di alcun genere sul vostro sito web è una buona scelta. Se non c’è nulla, non si può rubare nulla. Inoltre se non c’è nulla, perché non entrare altrove allora? Prediligete la privacy dell’utente e evitate di raccogliere informazioni se riuscite. Questo vi renderà una vittima poco interessante.

Chiudiamo questa guida…

Questa guida non ha la presunzione di difendervi dai mali dell’internet, ma spero che vi faccia interrogare su ciò che deve essere fatto per migliorare e proteggere il vostro sito web. Fare hardening significa indurire e ridurre la superficie esposta. Lo scopo è quello di rispondere prontamente e rendere complesso il lavoro dei malintenzionati che hanno scelto voi come vittima.

Link e Fonti:

Hardening WordPress

XML-RPC WordPress: sicurezza e quando serve

Coretech – https://www.coretech.it/it/service/articoli/articoli.php?ID=1281

Wikipedia – https://it.wikipedia.org/wiki/Referer