Mettere in sicurezza WordPress: l'ordine in cui conviene farlo

Chi cerca «mettere in sicurezza WordPress» trova elenchi di venti punti. Il problema non è che i punti siano sbagliati, ma che stanno uno accanto all'altro con lo stesso peso. I primi tre valgono più degli altri diciassette messi insieme.

Posizione 1: aggiornamenti, e tempestivi

La maggior parte dei siti compromessi non cade per un attacco sofisticato, ma per una falla nota in un plugin per cui esiste un aggiornamento da settimane. Le scansioni automatizzate di massa cercano proprio questo.

In pratica significa: aggiornamenti di sicurezza automatici, aggiornamenti funzionali a mano dopo una breve verifica — e prima di ogni aggiornamento un punto di ripristino, così che la paura dell'aggiornamento non diventi un motivo per rimandarlo.

Un plugin che non riceve aggiornamenti da due anni è un rischio, anche se funziona. Approfittane per fare ordine: ciò che non si usa va eliminato, non disattivato.

Posizione 2: l'accesso

La seconda porta più frequente è una password. Quattro misure, in quest'ordine:

1. Limitare i tentativi falliti — toglie la base ai tentativi automatizzati di indovinare la password.
2. Imporre password robuste, almeno per tutti coloro che possono pubblicare.
3. Attivare il secondo fattore, almeno per gli amministratori.
4. Nessun account con il nome utente «admin», e nessun ruolo più alto del necessario.

Spostare l'indirizzo di accesso è un quinto punto, ma più debole: tiene lontane le scansioni di massa e riduce il carico, ma non sostituisce nessuna delle quattro misure precedenti. Chi lo usa dovrebbe annotare il nuovo indirizzo prima di salvare.

Posizione 3: hardening — da impostare una volta e poi dimenticare

• Disattivare la modifica dei file nel backend — è lì che il codice malevolo viene depositato più spesso
• Disattivare XML-RPC, se nulla lo richiede
• Impedire l'elenco del contenuto delle directory
• Bloccare l'esecuzione di PHP nella cartella uploads
• Limitare l'enumerazione degli utenti tramite la REST API
• Impostare gli header di sicurezza

Questi interruttori non costano nulla durante il funzionamento e ognuno chiude una scorciatoia nota. Sono il punto con il miglior rapporto costi-benefici dell'intero elenco.

Posizione 4: vedere cosa cambia

Da qui in poi non si tratta più di impedire, ma di accorgersi. Due cose valgono la pena:

La verifica del core confronta i file di WordPress con i checksum di api.wordpress.org. Un file del core modificato è un segnale molto chiaro — lì nessuno ha un motivo legittimo per cambiare qualcosa.

La sentinella dei file acquisisce uno stato di riferimento e segnala le differenze. È affidabile solo quanto il momento in cui lo stato è stato acquisito: uno stato acquisito dopo un'infezione dichiara il codice malevolo condizione normale.

Acquisisci lo stato di riferimento finché è certo che il sito sia pulito — idealmente subito dopo una nuova installazione o dopo un ripristino verificato.

Posizione 5: firewall e scansione

Entrambi sono utili ed entrambi stanno volutamente qui in fondo. Un firewall in PHP entra in funzione solo quando WordPress si sta già avviando — non sostituisce un firewall davanti al server web. Una scansione trova ciò che somiglia ai suoi pattern, non ogni codice malevolo.

Più importante del numero di regole è la gestione dei falsi positivi. Uno strumento il cui riepilogo è sempre rosso non protegge più nulla — allena a liquidare le segnalazioni con un clic. Lascia quindi che il firewall per una settimana si limiti a segnalare ed esamina il registro prima di passare al blocco.

Cosa sta spesso in cima e non dovrebbe starci

Il punto che quasi tutti gli elenchi dimenticano

Un plugin di sicurezza previene gli incidenti, un backup sopravvive loro. Chi dovesse scegliere tra i due dovrebbe prendere il backup — è l'unica misura che aiuta ancora anche quando tutte le altre hanno fallito.

Domande frequenti