Come prevenire attacchi di forza bruta in WordPress (9 livelli di protezione)

Se il tuo sito WordPress è online, è probabile che sia sotto attacco proprio ora.

I bot automatizzati scansionano continuamente Internet, testando /wp-login.php su ogni sito WordPress che trovano. Provano prima i login "admin", poi un elenco delle password più comuni.

Un sito senza protezione viene colpito da centinaia di questi tentativi ogni giorno, silenziosamente, senza alcun segno visibile.

Cosa c'è di peggio: gli attacchi falliti non sono gratuiti. Ogni tentativo di accesso avvia un processo PHP sul tuo server.

Abbastanza tentativi simultanei e il tuo piano di hosting raggiunge i suoi limiti.

I visitatori reali iniziano a vedere tempi di caricamento lenti o pagine di errore. Alcuni host limitano automaticamente il tuo account. Questo accade anche quando nessun aggressore riesce a entrare.

Un attacco riuscito è un problema diverso. L'accesso completo da amministratore significa modifiche ai contenuti, malware iniettato nei file del tuo tema, account backdoor creati, spam SEO incorporato nei tuoi post o dati dei clienti esposti.

Il recupero da una violazione riuscita richiede ore nel migliore dei casi; giorni se non hai un backup pulito.

In questo post, ti fornirò i modi migliori per difendere il tuo sito dagli attacchi brute force.

Ecco i punti chiave:

• Anche gli attacchi brute force falliti danneggiano il tuo sito. Esauriscono i worker PHP, rallentano i tempi di caricamento e possono attivare il throttling dell'hosting prima che una singola password venga indovinata correttamente.
• Il credential stuffing non è la stessa cosa del brute force. Gli aggressori utilizzano password reali trapelate da altre violazioni, il che significa che una password forte da sola non è sufficiente se i tuoi utenti riutilizzano le credenziali.
• WordPress non ha una protezione integrata contro il brute force. Il throttling degli accessi, l'autenticazione a due fattori (2FA) e la funzionalità WAF richiedono tutti un plugin o una configurazione del server.
• L'autenticazione a due fattori è il passaggio con il più alto ritorno in termini di efficacia in questo elenco. Blocca sia il brute force che il credential stuffing anche quando una password è corretta.
• Il metodo system.multicall di XML-RPC aggira la maggior parte delle difese della pagina di accesso. Disabilitarlo chiude una superficie di attacco separata che i plugin di rate-limiting non coprono.
• Cambiare l'URL di accesso riduce il volume degli attacchi ma non è una difesa primaria. Consideralo un ostacolo, non una protezione.
• Un backup che non hai mai ripristinato è un backup che in realtà non hai. Testa il tuo processo di ripristino trimestralmente prima di averne bisogno sotto pressione.
• Più plugin di sicurezza non significano più sicurezza. Un plugin ben configurato batte quattro plugin parzialmente configurati, che possono creare conflitti e overhead.

Indice

Cos'è un attacco brute force?

La maggior parte delle persone immagina un attacco di forza bruta come un bot che prova a caso password finché una non funziona. Succede, ma non è l'unica versione di questo attacco, e non è nemmeno più la più comune.

Forza bruta classica vs. Credential Stuffing

La forza bruta classica si verifica quando un software automatizzato prova ogni possibile combinazione di caratteri finché non trova una password che funziona.

Contro una password lunga e casuale, questo è impraticabile. Una password casuale di 16 caratteri richiederebbe più tempo per essere violata a forza bruta di quanto ne rimanga al sole per bruciare.

Il credential stuffing è diverso, e più pericoloso.

Gli aggressori acquistano o scaricano database trapelati da altre violazioni di dati: indirizzi email abbinati a password di servizi compromessi. Quindi testano queste coppie sui siti WordPress.

Se uno dei tuoi utenti si è registrato con la stessa email e password che usa ovunque, il credential stuffing potrebbe accedervi e accedere al primo tentativo.

Ecco perché "ho una password forte" non protegge completamente i tuoi utenti. La tua password potrebbe essere forte. La loro potrebbe non esserlo.

Gli attacchi a dizionario si collocano tra i due. Invece di ogni possibile combinazione, testano un elenco curato di password comuni, schemi noti e variazioni di parole reali. Più veloci della vera forza bruta, più mirati del tentativo casuale.

Il moltiplicatore XML-RPC

WordPress include un file chiamato xmlrpc.php, originariamente creato per la pubblicazione remota e le integrazioni API. Accetta un metodo chiamato system.multicall che consente a una singola richiesta HTTP di testare migliaia di combinazioni di nome utente/password in una singola chiamata.

Questo è importante perché la maggior parte dei plugin di limitazione degli accessi monitora /wp-login.php. Un bot che utilizza xmlrpc.php aggira completamente quella protezione. Limitare la velocità della tua pagina di accesso lasciando aperto XML-RPC è come chiudere a chiave la porta d'ingresso e lasciare la finestra sbloccata.

Se non stai usando XML-RPC, chiuderlo è uno dei passaggi con il più alto ritorno di questa lista. Il Livello 5 spiega esattamente come.

Cosa ti costa anche un attacco fallito

Un attacco di forza bruta che non indovina mai una singola password corretta ti costa comunque qualcosa di reale.

Ogni tentativo di accesso è una richiesta HTTP. Ogni richiesta avvia un processo PHP. Su hosting condiviso, il tuo piano include un numero finito di worker PHP concorrenti.

Un attacco ad alto volume riempie quei worker con tentativi di accesso invece di servire i tuoi visitatori effettivi. Il risultato sono tempi di caricamento lenti, timeout e, nei casi più gravi, una sospensione temporanea dell'hosting che non avevi previsto.

Inoltre, seppellisce eventi di sicurezza legittimi nel rumore dei log. Se un aggressore riesce infine ad entrare, i log dei tentativi falliti che avrebbero segnalato attività insolite sono già pieni di migliaia di voci. Stai cercando un ago in un pagliaio.

Le protezioni a livello di plugin riducono il danno. Le protezioni a livello di server e di edge lo eliminano. Questo è il motivo principale per cui questa guida è strutturata a livelli piuttosto che come un elenco.

Come prevenire attacchi brute force in WordPress

Non esiste un'unica impostazione che renda il tuo sito immune. Ciò che funziona sono gli strati: ognuno cattura ciò che il precedente perde.

Le tue credenziali bloccano la maggior parte dei bot automatizzati. Il rate-limiting blocca quelli che passano. Un WAF blocca il volume prima che raggiunga il tuo server. I backup coprono lo scenario in cui tutto il resto fallisce.

Gli strati sottostanti sono ordinati per impatto e facilità di implementazione. Inizia dall'alto. Vai il più lontano possibile in base alla configurazione del tuo hosting. Anche i primi tre strati riducono drasticamente la tua esposizione.

Ecco cosa fare:

• Strato 1: Credenziali: cambia il nome utente amministratore predefinito, usa password uniche per ogni account e abilita l'autenticazione a due fattori per tutti gli amministratori
• Strato 2: Limita i tentativi di accesso: limita i tentativi di accesso falliti tramite un plugin o, per una protezione più forte, tramite Cloudflare o il rate limiting a livello di server
• Strato 3: Cambia l'URL di accesso predefinito: sposta l'indirizzo che la maggior parte dei bot prende di mira, riducendo il volume di attacchi automatizzati al tuo modulo di accesso
• Strato 4: Aggiungi CAPTCHA: filtra le sottomissioni di bot automatizzati nel modulo di accesso; più efficace se combinato con il rate limiting piuttosto che usato da solo
• Strato 5: Disabilita o limita XML-RPC: chiude una superficie di attacco separata che consente agli aggressori di testare migliaia di password in una singola richiesta HTTP, bypassando le difese della pagina di accesso
• Strato 6: Web Application Firewall: blocca il traffico dannoso e gli IP noti come dannosi prima che raggiungano la tua pagina di accesso; i WAF a livello di edge come Cloudflare prevengono l'esaurimento delle risorse durante attacchi ad alto volume
• Strato 7: Indurimento a livello di server: limita wp-login.php per IP, implementa Fail2ban e usa SFTP con autenticazione tramite chiave SSH; per i proprietari di server VPS e dedicati
• Strato 8: Mantieni tutto aggiornato: corregge le vulnerabilità che gli aggressori sfruttano per stabilire un punto d'appoggio prima di forzare la loro strada più in profondità
• Strato 9: Esegui il backup del tuo sito: l'ultimo strato di difesa; un backup offsite testato con un percorso di ripristino funzionante è l'unica garanzia che un attacco riuscito non metta fine al tuo sito

Livello 1: Inizia con le tue credenziali

Ogni strumento di brute force automatizzato inizia con il nome utente "admin" e le password più comuni. Rimuovere entrambi dal tuo sito richiede forse cinque minuti ed elimina immediatamente la maggior parte dei tentativi di attacco automatizzati.

Non è una difesa completa, ma è il ritorno sull'investimento di tempo più rapido che troverai in questa guida.

Usa un nome utente amministratore non predefinito

Quando WordPress è stato installato per la prima volta sul tuo sito, ha suggerito "admin" come nome utente predefinito. Molti siti non lo cambiano mai. Gli aggressori lo sanno, e ogni strumento di brute force inizia da lì.

Usare un nome utente diverso costringe un aggressore a indovinare due incognite invece di una. Non è un miglioramento drastico contro un attacco mirato sofisticato, ma elimina la stragrande maggioranza dei bot automatizzati che non superano mai l'ipotesi "admin".

Per controllare il tuo nome utente attuale, vai su Utenti » Profilo in wp-admin. Il campo nome utente si trova nelle impostazioni Nome.

WordPress non ti permette di cambiare direttamente il tuo nome utente, ma puoi creare un nuovo account amministratore con un nome utente diverso, trasferire la proprietà dei tuoi contenuti ed eliminare il vecchio account "admin".

Gli utenti WP-CLI possono farlo con un solo comando:

wp user update 1 --user_login=yourname

Usa Password Forti e Univoche per Ogni Account

Ogni account amministratore sul tuo sito necessita della propria password univoca.

Il credential stuffing funziona testando coppie nome utente/password note da altre violazioni. Se un utente ha riutilizzato la password della propria email su più siti e quella password è trapelata altrove, il credential stuffing potrebbe accedere al primo tentativo.

WordPress include un indicatore di robustezza della password integrato che segnala le password deboli nella schermata del profilo. Questo impedisce le scelte peggiori, ma non impone una lunghezza minima né previene il riutilizzo.

Per un maggiore controllo, Password Policy Manager ti consente di impostare requisiti di password a livello di sito e forzare il reset degli account che non li soddisfano.

Abilita l'Autenticazione a Due Fattori

Con l'autenticazione a due fattori (2FA) abilitata, una password corretta non è sufficiente per accedere. L'attaccante necessita anche di un codice sensibile al tempo da un dispositivo fisico che non possiede.

Questo blocca gli attacchi brute force classici, il credential stuffing e gli attacchi a dizionario. Anche se un attaccante possiede la tua password esatta da una violazione di dati, non può accedere senza il secondo fattore.

Il core di WordPress non include la 2FA. Hai bisogno di un plugin.

WP 2FA è gratuito, attivamente mantenuto e semplice da configurare. Supporta app di autenticazione come Google Authenticator, Authy e 1Password.

miniOrange 2FA e il plugin Two Factor sono altre opzioni ampiamente utilizzate con maggiore flessibilità di configurazione.

Le passkey sono l'alternativa più recente. Utilizzano lo standard WebAuthn e sono resistenti al phishing per progettazione: non ci sono codici da intercettare, SMS da scambiare o app di autenticazione da compromettere. Il supporto dei plugin è ancora in fase di maturazione, ma se la tua configurazione lo supporta, le passkey valgono la pena di essere considerate.

Applica la 2FA a ogni account amministratore sul sito. Non solo al tuo. Un singolo account admin non protetto è tutto ciò di cui un attaccante ha bisogno.

Livello 2: Limita i tentativi di accesso

Per impostazione predefinita, WordPress consente tentativi di accesso illimitati. Un bot può provare diecimila password nel tempo necessario per preparare un caffè.

Il rate-limiting interrompe questo processo dopo una manciata di tentativi, bloccando l'IP offensore prima che si avvicini a credenziali corrette.

Limitazione degli accessi basata su plugin

I plugin di limitazione degli accessi funzionano monitorando i tentativi falliti per indirizzo IP. Dopo un certo numero di fallimenti, il plugin blocca quell'IP per un periodo definito. Il bot dell'attaccante passa oltre.

Limit Login Attempts Reloaded è l'opzione gratuita più utilizzata, con una schermata di configurazione semplice e senza fronzoli.

Wordfence include la limitazione come parte del suo set di funzionalità più ampio, il che lo rende degno di considerazione se desideri un singolo plugin che copra più livelli di sicurezza.

Per la maggior parte dei siti, 5-10 tentativi falliti prima di un blocco temporaneo è un buon punto di partenza.

Soglie più basse aumentano la sicurezza ma potrebbero creare grattacapi al supporto. Uffici aziendali, università e reti mobili spesso condividono un singolo IP tra centinaia di utenti. Una persona che digita erroneamente la password tre volte blocca tutti gli altri.

Testa la tua soglia rispetto a come i tuoi utenti effettuano effettivamente l'accesso.

Una limitazione da conoscere: i plugin a livello di applicazione invocano ancora PHP ad ogni richiesta che elaborano. Sotto un attacco a volume veramente elevato, il tuo server riceve ancora tutto quel traffico.

Il plugin impedisce all'attaccante di avere successo, ma non ferma il consumo di risorse. È ciò che affronta la sezione successiva.

Quando spostare la protezione più in alto nello stack

Il piano gratuito di Cloudflare ti consente di creare regole personalizzate di rate-limiting che puntano specificamente a /wp-login.php e /xmlrpc.php.

Il traffico viene filtrato al edge di Cloudflare prima che raggiunga il tuo server. I tuoi worker PHP rimangono liberi per i visitatori effettivi.

Questo è l'aggiornamento più accessibile dalla protezione a livello di plugin e non costa nulla.

Livello 3: Cambia l'URL di accesso predefinito

La maggior parte dei bot automatizzati prende di mira /wp-login.php perché è lì che WordPress posiziona il modulo di accesso per impostazione predefinita. Spostarlo su un URL personalizzato significa che la maggior parte dei bot non lo trova mai. Colpiscono un 404, registrano il tuo sito come un vicolo cieco e vanno avanti.

Questo è uno strato di attrito, non una difesa primaria. Un attaccante determinato che prende di mira specificamente il tuo sito può trovare un URL di accesso personalizzato con altri mezzi.

Ma ridurre il volume degli attacchi automatizzati ha un valore reale:

• Meno tentativi di accesso falliti
• Meno rumore nel registro delle attività
• Meno overhead di processi PHP dai plugin di throttling che elaborano richieste vuote

Il rischio principale è perdere l'URL. Se dimentichi il tuo percorso di accesso personalizzato e il tuo host non offre un accesso di emergenza a wp-admin, sarai bloccato fuori dal tuo stesso sito.

Prima di apportare questa modifica, memorizza l'URL personalizzato nel tuo gestore di password e conferma il metodo di accesso di emergenza del tuo host. Alcuni host offrono l'accesso a phpMyAdmin o un ripristino dell'accesso assistito dal supporto.

WPS Hide Login gestisce questo con una configurazione minima: installalo, imposta il tuo percorso personalizzato e salva.

Un'aggiunta che rende questo passaggio più efficace: crea una regola Cloudflare che restituisca un 403 sul percorso originale /wp-login.php dopo averlo spostato.

Senza quella regola, il vecchio URL esiste ancora e risponde, il che significa che uno scanner persistente può ancora trovarlo sondando percorsi comuni. Bloccare il vecchio URL al edge chiude quella lacuna.

Livello 4: Aggiungi CAPTCHA al modulo di accesso

CAPTCHA impedisce ai bot automatizzati di inviare moduli di accesso richiedendo una prova di interazione umana. Uno script che colpisce la tua pagina di accesso migliaia di volte all'ora non può risolvere una sfida visiva o comportamentale come può fare una persona.

Per la maggior parte dei siti, l'aggiunta di CAPTCHA al modulo di accesso riduce significativamente il volume di invii automatizzati.

Tieni presente che non è imbattibile. Esistono servizi di risoluzione CAPTCHA: esseri umani reali pagati frazioni di centesimo per risolvere sfide su larga scala o modelli di machine learning addestrati per decifrare formati CAPTCHA più vecchi.

Contro un aggressore mirato e ben finanziato, un CAPTCHA è un ostacolo. Contro i bot automatizzati responsabili della stragrande maggioranza del traffico di forza bruta, è efficace.

Le tre opzioni degne di considerazione adottano ciascuna un approccio diverso.

1. Google reCAPTCHA v3 viene eseguito in modo invisibile in background, valutando il comportamento dell'utente e segnalando le richieste sospette senza chiedere agli utenti di fare nulla.
2. hCaptcha adotta una posizione incentrata sulla privacy ed è un'alternativa diretta "drop-in".
3. Cloudflare Turnstile è gratuito, senza attriti per la maggior parte degli utenti e non invia dati comportamentali a Google.

Dei tre, Turnstile è la mia attuale raccomandazione per le nuove configurazioni. I compromessi sulla privacy sono migliori e l'esperienza utente è più pulita.

Wordfence include opzioni CAPTCHA. Se lo stai già utilizzando, verifica se il loro CAPTCHA integrato copre il tuo modulo di accesso prima di aggiungere un plugin separato.

Livello 5: Disabilita o limita XML-RPC

XML-RPC era l'API di pubblicazione remota originale di WordPress, creata per un'epoca prima che esistesse l'API REST. La maggior parte dei siti non la utilizza più. Lasciarla abilitata offre agli aggressori una superficie di attacco separata che aggira la maggior parte delle difese della pagina di accesso che hai impostato finora.

Xmlrpc.php accetta un metodo chiamato system.multicall che raggruppa migliaia di tentativi di accesso in una singola richiesta HTTP.

Un plugin di rate-limiting che monitora /wp-login.php non lo vedrà. Il tuo CAPTCHA non si attiverà. L'attacco atterra sotto le tue difese perché è rivolto a una porta diversa.

Prima di disabilitarlo, verifica se lo stai effettivamente utilizzando. Jetpack si connette a WordPress.com tramite XML-RPC. Alcuni flussi di lavoro di pubblicazione mobile più vecchi dipendono da esso.

Se non stai usando Jetpack o non stai pubblicando da un'app mobile, probabilmente non ne hai bisogno.

Plugin di sicurezza come Wordfence hanno un interruttore "one-click" nella sezione delle impostazioni di accesso.

Il plugin Disable XML-RPC-API è un'alternativa leggera se preferisci non installare una suite di sicurezza completa.

Su Nginx o Apache, puoi bloccare xmlrpc.php a livello di server in modo che la richiesta non raggiunga mai PHP.

Se hai bisogno di XML-RPC per Jetpack o un'altra integrazione, la soluzione mirata è bloccare specificamente system.multicall piuttosto che l'intero endpoint. Una regola WAF di Cloudflare può farlo senza interrompere la funzionalità XML-RPC legittima.

Limitare l'accesso a xmlrpc.php a specifici indirizzi IP è un'altra opzione per integrazioni con origini note e stabili.

L'API REST è il moderno sostituto per le nuove integrazioni. Se stai costruendo qualcosa che avrebbe utilizzato XML-RPC, costruiscilo invece contro l'API REST.

Livello 6: Utilizza un firewall per applicazioni web

Un Web Application Firewall (WAF) si posiziona tra il traffico in entrata e il tuo sito WordPress, ispezionando le richieste e bloccando quelle dannose prima che raggiungano la tua pagina di accesso.

Più vicino opera al limite della rete, meno lavoro fa il tuo server sotto attacco. Un WAF basato su plugin ferma gli attacchi dopo che sono arrivati al tuo server. Un WAF a livello di edge li ferma prima che arrivino.

WAF basati su plugin

I WAF basati su plugin come Wordfence e MalCare filtrano le richieste a livello di applicazione. Mantengono database di indirizzi IP dannosi noti, firme di bot e pattern di attacco, e bloccano le richieste corrispondenti prima che WordPress le elabori.

Per i siti su hosting condiviso dove la configurazione del server non è accessibile, un WAF basato su plugin è il punto di partenza giusto.

Il limite è che il tuo server riceve ancora ogni richiesta che il WAF valuta. Sotto un attacco su larga scala, PHP si avvia ancora, il plugin viene ancora eseguito e le tue risorse di hosting subiscono ancora il colpo. L'attaccante non entra, ma il costo delle risorse è reale.

WAF a livello di Edge

Il piano gratuito di Cloudflare filtra il traffico sulla loro rete globale prima che raggiunga il tuo server. La gestione dei bot, il limitatore di frequenza e le sfide CAPTCHA di Turnstile operano tutti al edge.

Il tuo server vede solo il traffico che Cloudflare ha già esaminato. Durante un attacco di forza bruta ad alto volume, il tuo sito rimane veloce per i visitatori reali perché il traffico di attacco non arriva mai.

Sucuri offre un WAF gestito con set di regole specifici per WordPress e un livello CDN incluso. È un servizio a pagamento, ma la manutenzione gestita delle regole vale la pena di essere considerata per i siti che non hanno uno sviluppatore che monitora attivamente le configurazioni di sicurezza.

Gli host WordPress gestiti, tra cui WP Engine e Kinsta, includono WAF a livello di infrastruttura come parte del loro stack di hosting. Se sei su una di queste piattaforme, hai già una protezione edge. Conferma con il tuo host cosa copre specificamente il loro WAF e se sono disponibili regole personalizzate.

Una configurazione Cloudflare degna di nota: una regola firewall personalizzata che blocca tutto il traffico verso /wp-admin tranne dal tuo indirizzo IP o dall'intervallo IP del tuo team.

Per i siti gestiti da un piccolo team che accede da IP prevedibili o da una VPN condivisa, questo è uno dei passi singoli più efficaci disponibili. I bot automatizzati non possono raggiungere l'area di amministrazione.

Assicurati solo che il tuo sito non utilizzi URL /wp-admin per funzionalità rivolte ai clienti (come le pagine dell'account personale di WooCommerce o gli accessi al portale di appartenenza) prima di abilitare questa regola.

Livello 7: Indurimento a livello di server

Se gestisci il tuo server o VPS, puoi spingere la protezione a monte di WordPress, bloccando gli attacchi prima che tocchino PHP o qualsiasi codice WordPress.

Questa sezione è per sviluppatori e proprietari di server VPS o dedicati. Se sei su hosting condiviso senza accesso alla configurazione del server, salta alla Layer 8.

Restringi wp-login.php per IP

Se tu e il tuo team accedete sempre da indirizzi IP prevedibili, come una rete d'ufficio o una VPN condivisa, puoi restringere /wp-login.php a quegli IP a livello di server. Ogni richiesta da qualsiasi altro IP riceve un 403 prima che WordPress venga caricato.

Su Nginx, appare così all'interno del tuo blocco server:

location = /wp-login.php {

allow 203.0.113.10;

deny all;

}

Sostituisci l'IP con il tuo. Aggiungi più righe 'allow' per più IP. La richiesta da qualsiasi indirizzo non elencato non raggiunge mai PHP.

Questo non funziona per i siti WooCommerce, le piattaforme di appartenenza o qualsiasi configurazione in cui i clienti accedono tramite WordPress. È più adatto a siti aziendali o portfolio con un piccolo e stabile team di amministratori.

Implement Fail2ban

Fail2ban legge i log del tuo server e bannare automaticamente gli indirizzi IP che corrispondono ai modelli da te definiti. Per WordPress, ciò significa che un IP che genera ripetuti tentativi di accesso falliti nel log viene aggiunto alla blacklist del tuo firewall, solitamente tramite iptables o nftables, prima che accumuli abbastanza tentativi da essere rilevante.

Richiede un plugin di integrazione per WordPress per funzionare: Fail2ban deve leggere i tentativi di accesso falliti in un formato analizzabile e WordPress non li scrive nei log del server per impostazione predefinita.

WP fail2ban gestisce questo, scrivendo gli eventi di autenticazione in un formato che Fail2ban può analizzare direttamente.

Il risultato è una protezione che opera a livello di rete: gli IP bloccati non raggiungono mai il tuo web server, tanto meno WordPress. Combinato con il rate limiting di Nginx sull'endpoint di accesso, questa è la configurazione non enterprise più sicura disponibile.

Usa SFTP e chiavi SSH, non FTP

Gli attacchi brute force non prendono di mira solo la tua pagina di accesso. FTP funziona sulla porta 21 e trasmette le credenziali in chiaro. Gli aggressori scansionano le porte FTP aperte ed eseguono lo stesso approccio di indovinamento delle credenziali che utilizzano su wp-login.php.

SFTP crittografa la connessione. Se il tuo host lo supporta, passa a SFTP e disabilita completamente FTP. La maggior parte degli host moderni lo supporta; alcuni disabilitano FTP per impostazione predefinita.

Per l'accesso SSH al tuo server, utilizza l'autenticazione basata su chiavi invece dell'autenticazione tramite password. Una coppia di chiavi SSH elimina il vettore di indovinamento della password a livello di server: non c'è nessuna password da forzare.

Genera una coppia di chiavi localmente, aggiungi la chiave pubblica al file `~/.ssh/authorized_keys` del tuo server e disabilita l'accesso SSH basato su password nel tuo `sshd_config`.

Se stai gestendo un VPS e non l'hai ancora fatto, questa è la prima cosa che vale la pena configurare.

Livello 8: Mantieni aggiornati WordPress, plugin e temi

Il brute force è spesso il secondo attacco, non il primo. Gli aggressori sfruttano frequentemente una vulnerabilità in un plugin obsoleto per stabilire un punto d'appoggio, creare un account backdoor o elevare i privilegi.

Il brute force arriva dopo, mirando agli account già esistenti. Rimanere aggiornati chiude i punti di ingresso che rendono il brute force utile in primo luogo.

Il core di WordPress gestisce gli aggiornamenti delle versioni minori automaticamente per impostazione predefinita. Le release principali richiedono un'azione manuale o un'impostazione esplicita di aggiornamento automatico nel tuo pannello di hosting.

Gli aggiornamenti automatici per singolo plugin sono disponibili direttamente in wp-admin. Vai su Plugin » Plugin installati e vedrai un'opzione Abilita aggiornamenti automatici nella colonna di destra per ogni plugin.

Per la maggior parte dei siti, abilitare gli aggiornamenti automatici per tutti i plugin attivi è la scelta giusta. Il rischio di un aggiornamento che causi problemi è reale, ma molto inferiore al rischio di eseguire un plugin con una vulnerabilità nota per settimane dopo il rilascio di una patch.

I temi seguono la stessa logica. Un tema inattivo presente sul tuo server con una vulnerabilità non patchata è ancora sfruttabile anche se non è il tema attivo.

Elimina tutto ciò che non stai utilizzando. Disattivato non significa sicuro.

Lo stesso vale per i plugin. I file di un plugin disattivato sono ancora sul server e ancora accessibili. Se esiste una vulnerabilità in quei file, può essere sfruttata indipendentemente dal fatto che il plugin sia attivo in WordPress.

Se non stai usando un plugin, eliminalo completamente invece di lasciarlo disattivato.

Per i team che gestiscono più siti, strumenti come ManageWP, MainWP e Jetpack Manage ti consentono di monitorare e applicare aggiornamenti su tutti i siti da un'unica dashboard. Eseguire aggiornamenti un sito alla volta su dieci o venti installazioni è il tipo di attrito che porta a patch mancate.

Livello 9: Esegui il backup del tuo sito e impara a ripristinarlo

La guida di WordPress.org per la protezione contro la forza bruta lo dice chiaramente: mantieni backup testati e capaci di funzionare offline e prova le tue procedure di ripristino.

Ogni livello precedente a questo riduce il rischio. Questo elimina l'esito peggiore.

Se un aggressore supera ogni altro livello, un backup recente è la differenza tra un recupero di un'ora e una ricostruzione totale. Il backup non impedisce la violazione. Determina quanto sia grave la violazione.

“Testato” è la parola che conta di più in quella frase. Testare significa eseguire un ripristino su un ambiente di staging, confermare che il sito venga visualizzato correttamente e conoscere esattamente i passaggi che il processo comporta prima di doverlo fare sotto pressione.

Pianifica un test di ripristino trimestrale. Richiede meno di un'ora e rimuove tutte le incertezze dal momento peggiore.

Automatizza backup e ripristini con Duplicator

Cosa rende un backup utile specificamente in uno scenario di violazione con forza bruta: deve essere offsite, indipendente dal server compromesso, con un percorso di ripristino che funzioni anche quando WordPress è completamente bloccato.

Duplicator Pro copre ciascuno di questi requisiti.

Backup automatici pianificati vengono eseguiti a intervalli orari, giornalieri, settimanali o mensili senza intervento manuale. Imposti la pianificazione una volta e hai sempre un punto di ripristino recente.

Per l'archiviazione, Duplicator Pro si collega ad Amazon S3, Google Drive, Dropbox, OneDrive e altri servizi cloud di terze parti.

Duplicator Cloud è l'archiviazione di Duplicator: nessun account separato richiesto, nessun servizio di terze parti da configurare. A differenza di altre opzioni, è stato creato specificamente per l'archiviazione dei backup di WordPress.

Se succede qualcosa di brutto, puoi ripristinare direttamente dall'archiviazione cloud senza dover prima ricaricare i file sul server. Quando il tuo server è compromesso e non ti fidi di ciò che c'è sopra, estrai il ripristino direttamente dalla copia cloud.

Gli URL di disaster recovery sono la parte che la maggior parte delle persone non conosce finché non ne ha bisogno. Dopo un attacco di forza bruta riuscito, una delle prime cose che un aggressore fa è cambiare la password dell'amministratore o creare nuovi account e bloccare il proprietario originale.

Un URL di disaster recovery bypassa completamente wp-admin, permettendoti di avviare un ripristino anche quando non riesci ad accedere. L'ho usato una volta in un incidente reale. È la funzionalità che fa la differenza tra recuperare in un'ora e passare un giorno al telefono con il supporto di hosting.

Il ripristino con un clic gestisce i recuperi standard senza trasferimenti manuali di file o accesso FTP. Seleziona il backup, fai clic su ripristina e conferma. Questo è il processo.

Come monitorare l'attività brute force

La maggior parte dei proprietari di siti WordPress scopre di essere sotto attacco dall'avviso di limitazione del proprio provider di hosting, non dal proprio monitoraggio. A quel punto l'attacco ha già consumato le risorse del server, riempito i tuoi log di rumore e, in alcuni casi, è riuscito.

La configurazione di una visibilità proattiva richiede meno di un'ora e significa che sai cosa sta succedendo sul tuo sito prima del tuo host.

Monitoraggio Proattivo

Activity Log ti fornisce una traccia di controllo completa di ogni azione intrapresa sul tuo sito, come tentativi di accesso falliti, accessi riusciti, modifiche ai ruoli utente, attivazioni e disattivazioni di plugin, modifiche alle impostazioni e modifiche ai file.

Questa portata è importante dopo una violazione brute force. Un aggressore che entra non si limita ad accedere; apporta modifiche.

Activity Log presenta queste modifiche in una sequenza temporale leggibile in modo da poter vedere esattamente cosa è successo e in quale ordine. Queste sono le informazioni di cui hai bisogno per valutare i danni e sapere cosa ripulire.

Fai in modo che Activity Log ti invii avvisi via email per attività di accesso insolite. Questo ti aiuterà a identificare e fermare immediatamente un attacco brute force invece di ripulire dopo uno.

Il tuo pannello di controllo di hosting è un altro livello di monitoraggio. Picchi inspiegabili di worker PHP o utilizzo della CPU in orari non lavorativi sono spesso il primo segno visibile di un attacco ad alto volume, che appare prima che il tuo plugin di sicurezza abbia registrato abbastanza eventi da attivare un avviso.

Segni che sei già sotto attacco

Alcuni attacchi si annunciano da soli. Altri sono più silenziosi.

Un improvviso picco di notifiche di accesso fallito nel tuo activity log è il segnale più chiaro. Se normalmente vedi due o tre tentativi falliti al giorno e ne vedi improvvisamente centinaia, qualcosa è cambiato.

Avvisi di blocco da parte di utenti che in realtà non hanno tentato di accedere sono un segno più sottile. I blocchi basati su IP influiscono su ogni utente che condivide quell'IP: un ufficio aziendale o una rete universitaria in cui una persona attiva un blocco può bloccare tutti gli altri sulla stessa connessione.

Se la tua casella di posta di supporto inizia a riempirsi di messaggi "Non riesco ad accedere" da persone che non stavano cercando di reimpostare le password, controlla il tuo registro blocchi.

Lenta risposta di wp-admin o errori di esaurimento dei worker PHP nel tuo registro errori di hosting indicano il consumo di risorse da un attacco ad alto volume. Il sito funziona ancora, ma è più lento del dovuto e i log spiegano perché.

Dopo qualsiasi incidente di sicurezza, vai su Utenti » Tutti gli Utenti in wp-admin e filtra per il ruolo Amministratore.

Un account amministratore non autorizzato creato durante una finestra di attacco è un segno che l'aggressore è riuscito e si è lasciato un backdoor. Controlla questo prima di considerare chiuso un incidente.

Cosa non funziona (e perché la gente lo consiglia ancora)

Alcuni dei consigli di sicurezza WordPress più comunemente ripetuti suonano ragionevoli ma offrono poca protezione reale. Conoscere la differenza ti risparmia lo sforzo di implementare cose che danno un falso senso di sicurezza.

Geoblocking per Paese

Il fascino è ovvio: se la maggior parte dei tuoi attacchi proviene da un paese specifico, blocca quel paese. Il problema è che le botnet non funzionano in quel modo.

Una botnet è una rete di macchine compromesse: router domestici, server, dispositivi IoT, computer ordinari infettati da malware. Quelle macchine sono ovunque, anche nel tuo paese.

Bloccare il traffico dalla Russia o dalla Cina non ferma una botnet con nodi negli Stati Uniti, nel Regno Unito e in Australia. Blocca i visitatori legittimi da quei paesi. Per la maggior parte dei siti, il compromesso non ne vale la pena.

Protezione con password di wp-admin tramite autenticazione HTTP

Aggiungere una seconda richiesta di password prima della directory wp-admin sembra un utile livello aggiuntivo. In pratica, può interrompere AJAX di WordPress, da cui wp-admin dipende per le funzionalità principali, inclusi il salvataggio dei post, l'esecuzione delle impostazioni dei plugin e la gestione dei caricamenti multimediali.

I siti che implementano correttamente questo con attente esclusioni AJAX possono farlo funzionare, ma per la maggior parte dei proprietari di siti, la complessità della configurazione supera il beneficio.

Domande frequenti (FAQ)

Prima del prossimo attacco, assicurati di poterne uscire

Gli attacchi brute force stanno diventando sempre più economici da eseguire. Botnet basate su cloud, database di credenziali derivanti da anni di violazioni accumulate e servizi di risoluzione CAPTCHA hanno tutti abbassato il costo di esecuzione di un attacco sostenuto contro un sito WordPress a quasi zero.

Ogni livello di protezione in questo post riduce il tuo rischio. Nessuno di essi lo riduce a zero. L'unica garanzia che un attacco riuscito non metta fine al tuo sito è un backup testato da cui puoi ripristinare, anche quando wp-admin è completamente bloccato.

Oltre 1,5 milioni di professionisti WordPress utilizzano Duplicator Pro esattamente per questo: backup automatici pianificati su Duplicator Cloud o su qualsiasi provider di archiviazione cloud principale, ripristino remoto senza dover ricaricare i file su un server compromesso e URL di ripristino d'emergenza che ripristinano il tuo sito anche quando non riesci ad accedere.

Se questo post ti ha fatto riflettere sulla sicurezza e sul recupero di WordPress, queste guide valgono la pena di essere lette successivamente.

• Come proteggere il tuo sito web dagli hacker (Guida definitiva alla sicurezza)
• WordPress è sicuro? Sveliamo la verità
• Checklist di sicurezza WordPress: Guida passo passo per proteggere il tuo sito
• Come recuperare un sito WordPress compromesso (9 consigli esperti)
• Come pulire un sito WordPress
• Padroneggiare il debug di WordPress: dalle basi alle tecniche avanzate
• I 9 migliori plugin di backup del database per WordPress (per proteggere i tuoi dati)